目录
如果以前没有做过自动化测试，那么就不了解自动化测试，可能会觉得自动化测试比较神秘，但是，我们在日常的计算机操作中，可能会碰到一些自动化处理的过程，这些过程和自动化测试比较接近。
例如，
上述的自动化处理过程还不是测试，因为测试的重要一点是须要验证，将实际执行的结果和用户期望的结果进行比较。没有这个比较，就不是自动化测试。
亲手做过自动化测试之后，我们对自动化测试就有了一个感性的认识，至少有下列几点感觉：
l 机器人从来就不会感觉累
l 自动化测试的速度，是手工测试无法比的
l 测试结果准确。例如搜索用时即使是0.33秒或0.24秒，系统都会发现问题，不会忽视任何差异。
l 一旦脚本完成，可以一劳永逸地运行很多遍，重复使用。
从这里就可以初步体会到自动化测试的优越性――高效率、准确可靠和复用性。同时，自动化测试也有不利的一面，即在创造性、发现新缺陷等方面能力不足。
有资料显示，即使自动化测试实施良好，也只能发现软件系统中30%的问题，而70%的问题还要靠手工测试发现。所以自动化测试更适合于负载测试、性能测试和回归测试。
概括起来，通过自动化测试，软件企业可以获得许多好处。
l 测试周期缩短，因为自动化测试效率高、能够长时间不间断地运行。
l 完成更多的测试，实现更高的测试覆盖率，保证测试的一致性，提高测试的可靠性，最终获得更高质量的软件。
l 更高的测试团队士气，因为有更多机会学习编程、获取新技术；同时，自动化测试使测试工作变得更有趣。
谈到自动化测试，一般会提到测试工具。许多人觉得使用了一两个测试工具就是实现了测试自动化，这种理解是不对的，至少是片面的。的确，测试工具的使用是自动化测试的一部分工作，但是“用测试工具进行测试”不等于“自动化测试”。那么，什么是“自动化测试”呢？
自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程，即模拟手工测试步骤，通过执行程序语言编制的测试脚本自动地测试软件，自动地完成软件的单元测试、功能测试、负载测试或性能测试等全部工作。
实际上，对于自动化测试有两种说法――“自动化测试”和“测试自动化”。它们之间存在某些微妙的差别，如果严格地加以区分，可以看作是两个概念：
自动化测试（Automated Test），侧重说明由测试工具自动地执行某项软件测试任务，自动化处理范围比较小。例如通过某个软件工具完成应用系统的功能测试和性能测试等测试执行工作，而测试的计划、设计和管理等其他工作还是由手工完成的。
测试自动化（Test Automated），侧重说明整个测试过程都由计算机系统自动完成，体现了更理想的自动化测试思想，有更广的范畴和更大的挑战。它不仅要求由工具完成测试的执行，而且要求测试的设计和管理也能由系统自动完成，例如基于模型实现测试设计的自动化、基于软件设计规格说明书实现测试用例的自动生成、基于数据库系统实现测试管理的自动化等。
根据上面的描述，测试自动化的要求相对来说高得多，即要求所有的测试工作都由计算机系统自动完成。包括：
l 测试环境的搭建和设置，如自动上传软件包到服务器并完成安装。
l 脚本自动生成，如根据UML状态图、时序图等生成可运行的测试脚本。
l 测试数据的自动产生，例如通过SQL语句在数据库中产生大量的数据记录，用于测试；
l 测试操作步骤的自动执行，包括软件系统的模拟操作、测试执行过程的监控；
l 测试结果分析，实际输出和预期输出的自动对比分析；
l 测试流程（工作流）的自动处理，包括测试计划复审和批准、测试任务安排和执行、缺陷生命周期等自动化处理。
l 测试报告自动生成功能等。
这样，测试自动化意味着测试全过程的自动化和测试管理工作的完全自动化，是测试工程师所追求的一种理想境界。如果使整个软件测试过程完全自动化，而不需要丝毫的人工参与或干涉，这是不现实的。
在充分利用自动化工具、全力进行自动化测试的同时，牢记不要追求100%的自动化，手工测试仍然至关重要。对高风险的模块或领域要进行更多的人工测试。根据手工测试和自动化测试的各自优势，对人工测试和自动测试区别对待，进行有效分工。
| 适用于自动化测试 |
适用于手工测试 |
| l 明确的、特定的测试任务 l 软件包括验证测试（Build Verification Test、BVT） l 回归测试、压力测试、性能测试等 l 相对稳定且界面改动比较少的功能测试 l 人工容易出错的测试工作 l 在多个平台环境上运行相同的用例、大量组合性测试或其他重复性测试任务 l 周期长的软件产品开发项目 l 项目的时间压力不太大 l 被测试软件具有很好的可测试性 l 能确保多个测试运行的构建策略 l 拥有运行测试所需的软硬件资源 l 拥有较强编程能力的测试人员 |
l 一次性项目或周期很短的项目的功能测试 l 需求不确定或需求变化比较快 l 适用性测试或验收测试 l 产品的功能设计或界面设计还不成熟 l 没有适当的测试过程 l 测试内容和测试方法不清晰 l 项目的时间压力较大 l 团队缺乏编程能力的测试人才 l 缺乏软硬件资源 |
如表，概括起来，任务越单调，自动化测试越适合；重复性越大，自动化测试越适合；越容易量化，自动化测试越适合。
单元测试、集成测试、系统测试和验收测试等不同的测试阶段，虽然都可以采用自动化测试来完成，但自动化测试的程度不一样。
在单元测试中，自动化测试工具和开发工具集成在一起，自动化测试程度比较高，而且比较全面。如前面所说的，代码的静态扫描，可以充分利用测试工具来完成。而单元的功能测试，一般可以借助单元测试框架实现，但须要写大量的测试脚本或测试代码，手工的工作量不小，这也是许多软件公司的单元测试覆盖率总是不够高的主要原因。
在集成测试阶段，自动化测试工具的作用是间接的，不是直接的、主动的。多数测试组织不是通过测试工具验证模块之间的接口，而是通过基本功能的验证来验证系统的集成，即通过BVT来完成每日测试，以满足每日构建、每日集成（持续集成）的需要。
在系统测试阶段，人们首先会将自动化测试运用在性能测试、压力测试、可靠性测试中，而在功能测试中，自动化测试的投入会比较谨慎。功能测试中逻辑、数据和API等验证，比较适合自动化测试，而GUI界面、易用性等测试，更宜由手工完成。
在用户参与的验收测试中，一般不宜于采用自动化测试。同样，针对软件界面操作友好性、易用性的测试，自动化无能为力，必须由手工测试来完成。
满足测试任务及其特点的测试工具可能会比较多，我们须要考虑对它们进行评估，选择出正确的测试工具。如何评估测试工具呢？人们可能会想到下列这些指标：
l 工具的功能是否强大，或者是满足需要？
l 价格是否合适、在预算之内？
l 性能价格比如何、是否数一数二？
l 工具的质量，工具运行是否稳定？
l 目前的用户量或是否流行？
l 和其他测试工具的兼容性、集成是否容易？
l 技术支持和服务是否及时、方便？
有时候，工具的选择也没有那么复杂，而是根据市场决定，市场哪个流行就选择哪个。市场流行，自然也有优势，这样做也不无道理。但这样做，具有盲目性，毕竟功能最强的工具不一定适合自己，最合适的工具，才是最好的。
我们建议将开源测试工具作为首选目标。如果开源测试工具应用一段时间之后，确实不能满足自己的需求，可以考虑选择商业化的测试工具。实际上，如果发现工具不能满足自己的需求，因为它是开源工具，完全可以对它进行修改（二次开发），增加相应的功能特性，从而满足自己的特定需求，这也是开源测试工具的魅力所在。
千万不要一开始就用巨资引入商业化的测试工具，那样测试人员压力很大，急于求成，反而效果不好，要么测试工具成了摆设，要么从此以后再也不敢提“自动化测试”。
测试工具的选择，还须要从某类具体的工具着手，对症下药，才能达到期望的目标。一般来说，测试工具可以分为：
单元测试工具，包括静态测试工具和动态测试工具；
功能测试工具，包括WEB功能测试工具、Windows客户端功能测试工具等；
性能测试工具，包括负载测试工具、压力测试工具等；
测试管理工具，包括缺陷、测试用例和计划等管理工具；
其他测试工具，如安全测试、多媒体测试等。
（1）单元测试工具的选择
建议：用什么编程语言就选用对应这种编程语言的单元测试工具，如：
如果用JAVA语言编程，就要选用JAVA的单元测试工具，如Junit，TestNG
如果用NET语言，就要选用适用C#的单元测试工具，如：NUnit，NUnitForms等；
如果用PHP语言，就要选用PHPUnit作为单元测试工具；
如果针对C/C++语言的程序，就要选择相应的单元测试工具，如CppTest*等；
如果只是进行纯页面的开发，针对HTML文件的table\form\link等元素进行测试，则单元测试工具选择HtmlUnit。
（2）功能测试工具的选择
如：Selenium\TestMaker
（3）性能测试工具的选择
Grinder是一个很好的负载测试框架，被誉为J2EE上的LoadRunner。通过Jython来编写测试脚本，支持多种协议的WEB服务和应用服务器，基于HTTP的测试可以由浏览器来记录整个要测试的过程。
TestMaker通过基于Jython的测试代理来完成测试，并借助PTTMonitor以监控应用服务器的资源和统计信息。
OpenSTA是针对B/S结构的性能测试开源工具，基于公共对象请求代理体系结构，并通过虚拟代理来记录通过proxy的HTTP请求，而其性能测试指标收集各项性能指标，然后进行分析，能提供较为丰富的图形化测试结果，提高了测试报告的可读性。
Siege是一个开源的WEB压力测试和评测工具。
ApacheBench能同时模拟多个并发请求，专门用于Web服务器的基准测试。
DBMonster是一个生成随机数据、用来测试SQL数据库的压力测试工具。
JDB Hammer是针对MySQL数据库服务器进行压力测试的开源工具，而MySQL官方提供的压力测试工具则mysqlslap.
另外要说明的是，TestMarker是一个更灵活的框架，可以和Seleinium、soapUI集成，充分利用Selenium和soapUI的测试能力，而TestMarker只是更好地调度、监控和管理测试的过程，监控系统的性能指标，获得测试结果。
（4）测试管理工具
软件测试离不开管理，包括测试计划、用例、测试结果和缺陷等管理，这些管理也通过工具和系统来帮助处理，以提高管理的效率和准确性。测试管理工具的选择，依赖于测试组织的规模和流程。规模小的组织，可以选择轻量型的测试管理工具；而规模大的组织，应选择功能强、支持多项目和分布式的测试管理工具。
对于轻型的开源测试管理框架，如JtestCase\FitNesse\Salome TMF\JTR等
对于更为规范的、具有一定规模的软件组织，可以选用TestLink\Bromine\Eclipse TPTP等测试管理框架或系统。
软件测试管理的重要工作之一是缺陷管理，缺陷管理工具有Mantis、Bugzilla、Bugfree、Scarab、TrackIT、Itracker等。
（5）其它测试工具
安全测试工具
主要有Nikto、Paros Proxy、SPI Dynamics WebInspect、Tripwire、TamperIE、Wapiti，其中前３项工具的功能强大，而其他工具则检查某个方面的测试。例如，TamperIE是一个小巧的XSS漏洞检测辅助工具，而WebScarab分析HTTP和HTTPS协议的通信。除此之外，还有专门检查数据库SQL注入攻击漏洞的工具，如sqlninja.
Paros Proxy是基于JAVA的WEB代理程序，可以评估WEB的应用程序的漏洞。它支持动态地编辑、查看HTTP/HTTPS，从而改变cookies和表单字段等项目。它包括一个WEB通信记录程序。
可达性测试工具
可达性（Accessibility）在国际性软件测试中也是不可忽视的。这类工具包括色彩对比度分析，键盘和鼠标的特殊操作等。微软公司在２００９年３月发布了两种可达性测试工具（http://www.codeplex.com）。
AccChecker：用户界面可达性测试工具（UI Accessibility Checker）；
UIA Verify：用户界面自动验证（UI Automation Verify）.
除此之外，还有很多这类测试工具，详见：Web Accessibility Evaluation Tools List.
多媒体测试工具
多媒体应用越来越多，对测试工具的要求也越来越高，须要覆盖语言（VoIP）、视频（Vedio）和IP电话等各项多媒体应用的特殊测试，如多媒体数据交换、服务质量（Qos）等。多媒体方面的开源测试工具有Ethereal、Auto Tool、SIPp、Seagull、Asterisk和X-Lite等。
网络监控工具
网络监控工具也常常在测试中使用，这类开源工具比较多，选择的余地很大，常用的工具有Nessus、Ethereal/Wireshark、Snort、Switzerland和Netcat，其中Wireshark就很不错。
小白在想什么？
想必每一个大神，都是从小白一步步走上来的。当然呢，我很能理解小白的想法，因为平时经常和一些刚入门自动化测试的同行交流，也很深入的了解到他们的一些困惑。
大部分小白想的无非是以下几点问题：
1.自动化测试好学吗？
2.不学/不写代码能做自动化测试吗？
3.怎样学习自动化测试？
4.学自动化测试要先学习哪个方向？学ui自动化？还是接口自动化？好像App自动化也比较火？要么再来个小程序自动化？
5.我没有代码基础，工作都是点点点，要不要报培训班？
6.我需要学习什么语言？java 还是 python？
...等等
我来针对以上的问题，说一些自己的看法：
首先，自动化测试，很好学！但是要记住，一定要明确学习的方向，不要剑走偏锋，白花力气。
第一，不写代码当然可以做自动化测试，但是个人建议还是学习一门语言，至于学习什么语言的话，很简单，不用纠结，第一看你是否有编程基础，没有选py，有的话选java py都可
第二需要看你们的开发用的什么语言，和开发用同一门语言能在学习自动化测试的同时，降低你和开发之间沟通的门槛，提升你在公司的话语权。
第三，学习哪个方向？我建议：web ui自动化=》接口自动化=》App自动化/小程序自动化，当然，着重学习接口自动化，ui自动化要学，但是没太大必要深究。
第四，要不要报名培训班？这个看你个人，如果你觉得自己学习理解能力很强，本身自己又很自律，同时学习的方向又很明确，那么你当然可以不报名培训，多省点钱不香么？
假如你对自动化测试或者一些编程语言毫无理解，身边又没有能带你学习的人，那么报名培训绝对是一个快速提升的途径。
在上面我们也提到了，自动化要想做得好，必须要学习至少一门语言。当然至于学习语言要到什么程度了？我不可能一直学下去吧？答案是，会用就行！
掌握大部分的语法基础，已经能够满足你的自动化的日常需求了，因为我们写脚本并没有像开发那么难！
语言你需要学习，for循环，if判断，数据类型，运算符，面向对象编程等等，不管是java还是py，这些都是需要的，其实也差不多，会一门语言，其他的都类似。
selenium作为自动化的老祖宗，已经被玩烂了，基本上只要是做自动化的，无人不知无人不晓。为什么要先学习selenium？
它能帮助你快速理解，自动化到底是个什么东西，并且能直观的在页面上面反馈给你。咱当初也是，看着selenium的api，一点一点啃下来的，几乎每个方法都去尝试了一下。
selenium有1.0 2.0 3.0,建议你学习之前，先去了解以下它的历史，u以及它的运行原理，这样可以勾起你的学习兴趣。你学习selenium，需要去安装浏览器，强烈建议使用Chrome而不是FireFox，前者兼容的更好。
安装好Chrome，你需要去安装驱动，恭喜你，这时候你就会踩到自动化的第一个坑了！大部分原因还是因为你的驱动版本和浏览器版本对不上。等能访问百度后，这里印象很深的su和kw（具体是什么等你学了就知道了）
你会再去尝试各种selenium的方法，去操作浏览器，这时候仿佛打开了新世界的大门，奥！原来自动化测试是这么个东西！真神奇！
等你玩了几天，或者几个星期之后，你好像对Selenium提不起什么兴趣了，脚本也写的越来越6，能写出一些线性的自动化脚本了，这个时候，有点骄傲自满，自动化不过如此，就这？
我想说的是，不要高兴的太早，你仅仅只是刚跨入自动化测试的大门，走了一小步而已。此时，你可以开始尝试，把项目中一些重复的操作，写成脚本去跑，满满的成就感有木有！自动化的成效初步形成，仿佛你开始懂得如何用自动化提升效率了。
等你学会单元测试框架unittest/testNG，当你学会了selenium后,你会发现大部分的线性脚本，很难去管理，并且每个脚本需要去一个个run，而且还无法统计测试结果，这个时候，就需要单元测试框架登场了！
你会开始学习，单元测试框架的用法，如何创建一个测试类，如何写测试方法，如何把你的脚本写成测试用例，如何校验测试是否通过，用例的执行顺序怎么去控制，断言怎么去写，这些都是你要去探究学习的。
等你脚本写的很6，用例也会组织了，然后每次领导告诉你，跑一下测试，然后把测试结果发给他，要总结成测试报告的形式。
你这时候，屡次打开你的编辑器，run test，然后刷刷刷的跑完测试，一条一条的统计测试结果，累得半死，发给了领导。
第二天领导又说，下班前你再跑一下测试，给我份报告，想死的心都有了。那么你开始去逛百度，逛论坛，想要得到解决方法，那么“框架”一次就会映入眼帘。
此时，你已经开始琢磨如何写一个自动化框架出来了，那么说明你的自动化已经开始入门了，并且往着中级的方向发展，你开始研究框架的结构，发现有用例管理，日志，测试报告，邮件，基础封装类等等，还有一种框架的设计模式（经典PO模式）
你开始对你的用例进行整理，封装基类，编写页面类，封装日志，邮件模块等等，经过了几个星期的打磨，你的第一个自动化框架诞生了！
此时你可以去各个技术群去炫耀了，自动写出了一个自动化框架，很多小白也开始吹捧你，叫你大神了。
以上结束了UI自动化的学习，那么下面到接口这边。一般公司用的都是http接口，那么你就从http协议开始学习了，了解它的结构，请求头，请求参数，请求地址，请求方式等等等，尝试学习一些抓包工具
如fiddler,chales,wireshark或者浏览器的开发者工具等等，去抓包获取一些接口，慢慢的观察它的请求构造，但是这时候还是云里雾里，对接口一知半解。于是下载了一个接口测试工具，尝试把参数录入到工具中，手动发起调用。
当工具返回200 code时，奥，原来是这么回事。好像就是和服务端来传递和接受数据的，然后前端页面会把数据展示到前台！
在用完postman后，就会想到，那么我怎么用代码去发起一个请求呢？这时候就需要去学习这两个东西。pip install & import requests后，就开始了你的接口自动化之旅。
你尝试也是把之前ui自动化的增删改查，用接口来实现，你把抓包的请求参数拿过来，一个一个方法的调用，然后一键运行！一绿三红！为什么？然后发现接口返回了401，无权限！奥！我没有登入啊，那么怎么才能登入呢？？
抱着很多的疑惑开始研究，这时候你需要去了解cookie和token的工作机制，再配合你的代码，去缓存cookie，达到登入。等解决了这个问题，但是接口还是报错了啊，删除接口提示我没有这条数据！
查来查去，原来是我那条数据已经用掉了，那么怎么可以保证我每次录入的参数都是新的呢？这时候就需要去了解接口关联，如何把参数从上个接口的响应提取出来，给下个接口用。
一样的，等你学会了 request/HttpClient,自然也会想到用单元测试框架把他们集成起来，然后又发现了一个高大上的allure测试报告，再结合一些日志模块打印参数，轻车熟路的这么一个接口框架就出来了，和之前的差不多！小意思。
等你拿自己的框架，重复枯燥的写着测试用例，这时候你想了，我为啥每次都要request.post，方法都是一样的，只是数据不一样，为什么我要一直写代码呢，很累啊！为什么不用一些文件来读取测试数据，做参数化呢？
这时候你开始研究读写excel/yaml了，你想把所有的测试用例都放在文件里管理，就不用每次去写代码了，然而事情并没有那么简单！那么我在文件里如何去处理关联数据呢？如何去缓存cookie呢？如何做断言呢？如果做一些动态的输入呢？
以上问题就留给你们自己去想了。
走到这一步，你已经写过好几个框架了，并且基于自己的框架做了优化，那么你此时发现一个很严重的问题，我的代码居然只能在我本地运行，如果要给别人用，还需要去别人电脑上配置环境，copy代码给他。
那么为什么不用一些代码管理工具去管理我的脚本呢？那么就会需要去学习git，了解如何add commit push推送我的代码到公司的gitlab，这样别人也可以使用，那么有了gitlab，我想做一些定时任务，让它自动执行呢？
学jenkins。再更多，要是我想多个用例一起跑呢？学习selenium grid，docker等等。。
等你搭建好公司的自动化生态，你还是不满足，我为什么不把这些东西可视化管理呢？做个平台？管理用例，管理任务，管理测试报告？我还可以把公司的一些部署任务也集成过来？
想法很好！此时的你已经不仅仅是一名优秀的自动化工程师了，已经迈向了测试开发的道路！开始学习，了解了测试框架httprunner，开发框架django/flask/springboot，懂得了接口开发的流程，了解了mybatis,shiro,quartz等等，开始学习前端
vue/react，懂得了什么是组件开发，父子组件传值，开始了解很多东西，甚至运维方面的知识，开始了解k8s docker，微服务。。那么你越来越往着大神的方向去了，希望你还没有秃头，此时的你可以骄傲的称自己为一名合格的测试开发，或者叫全栈开发了有木有！到此告一段落。
PS: 以上就是我个人，也相信是大部分学习和喜欢自动化测试的一个学习路线，当然本次没提到一些App端/小程序端的自动化测试，其实也都大致类似。希望各位看完本文章点个赞！祝大家少走弯路！
这一些资料，对做【软件测试】的朋友而言应该是较为完整了，这类学习资料也陪伴我走过了最艰难的路程，希望也可以帮助到你！万事要尽早，尤其是技术行业，一定要提升技术功底。
以上软件测试资料领取小伙伴可以通过下面视频领取
B站2023年最详细的python自动化测试框架全栈测试开发技术入门到精通教程
