软件测试职业发展，如果一直是功能测试，会不会淘汰 _功能性测试岗位的可替代性

在上面我们也提到了，自动化要想做得好，必须要学习至少一门语言。当然至于学习语言要到什么程度了？我不可能一直学下去吧？答案是，会用就行！

掌握大部分的语法基础，已经能够满足你的自动化的日常需求了，因为我们写脚本并没有像开发那么难！

语言你需要学习，for循环，if判断，数据类型，运算符，面向对象编程等等，不管是java还是py，这些都是需要的，其实也差不多，会一门语言，其他的都类似。

语言入门后，正式踏上开始自动化成神之路，入门篇Selenium

selenium作为自动化的老祖宗，已经被玩烂了，基本上只要是做自动化的，无人不知无人不晓。为什么要先学习selenium？

它能帮助你快速理解，自动化到底是个什么东西，并且能直观的在页面上面反馈给你。咱当初也是，看着selenium的api，一点一点啃下来的，几乎每个方法都去尝试了一下。

selenium有1.0 2.0 3.0,建议你学习之前，先去了解以下它的历史，u以及它的运行原理，这样可以勾起你的学习兴趣。你学习selenium，需要去安装浏览器，强烈建议使用Chrome而不是FireFox，前者兼容的更好。

安装好Chrome，你需要去安装驱动，恭喜你，这时候你就会踩到自动化的第一个坑了！大部分原因还是因为你的驱动版本和浏览器版本对不上。等能访问百度后，这里印象很深的su和kw（具体是什么等你学了就知道了）

你会再去尝试各种selenium的方法，去操作浏览器，这时候仿佛打开了新世界的大门，奥！原来自动化测试是这么个东西！真神奇！

玩腻了Selenium

等你玩了几天，或者几个星期之后，你好像对Selenium提不起什么兴趣了，脚本也写的越来越6，能写出一些线性的自动化脚本了，这个时候，有点骄傲自满，自动化不过如此，就这？

我想说的是，不要高兴的太早，你仅仅只是刚跨入自动化测试的大门，走了一小步而已。此时，你可以开始尝试，把项目中一些重复的操作，写成脚本去跑，满满的成就感有木有！自动化的成效初步形成，仿佛你开始懂得如何用自动化提升效率了。

开始接触自动化框架unittest/testNG

等你学会单元测试框架unittest/testNG，当你学会了selenium后,你会发现大部分的线性脚本，很难去管理，并且每个脚本需要去一个个run，而且还无法统计测试结果，这个时候，就需要单元测试框架登场了！

你会开始学习，单元测试框架的用法，如何创建一个测试类，如何写测试方法，如何把你的脚本写成测试用例，如何校验测试是否通过，用例的执行顺序怎么去控制，断言怎么去写，这些都是你要去探究学习的。

不满足于单元测试框架的功能

等你脚本写的很6，用例也会组织了，然后每次领导告诉你，跑一下测试，然后把测试结果发给他，要总结成测试报告的形式。

你这时候，屡次打开你的编辑器，run test，然后刷刷刷的跑完测试，一条一条的统计测试结果，累得半死，发给了领导。

第二天领导又说，下班前你再跑一下测试，给我份报告，想死的心都有了。那么你开始去逛百度，逛论坛，想要得到解决方法，那么“框架”一次就会映入眼帘。

学习自动化框架

此时，你已经开始琢磨如何写一个自动化框架出来了，那么说明你的自动化已经开始入门了，并且往着中级的方向发展，你开始研究框架的结构，发现有用例管理，日志，测试报告，邮件，基础封装类等等，还有一种框架的设计模式（经典PO模式）

你开始对你的用例进行整理，封装基类，编写页面类，封装日志，邮件模块等等，经过了几个星期的打磨，你的第一个自动化框架诞生了！

此时你可以去各个技术群去炫耀了，自动写出了一个自动化框架，很多小白也开始吹捧你，叫你大神了。

初始接口测试

以上结束了UI自动化的学习，那么下面到接口这边。一般公司用的都是http接口，那么你就从http协议开始学习了，了解它的结构，请求头，请求参数，请求地址，请求方式等等等，尝试学习一些抓包工具

如fiddler,chales,wireshark或者浏览器的开发者工具等等，去抓包获取一些接口，慢慢的观察它的请求构造，但是这时候还是云里雾里，对接口一知半解。于是下载了一个接口测试工具，尝试把参数录入到工具中，手动发起调用。

当工具返回200 code时，奥，原来是这么回事。好像就是和服务端来传递和接受数据的，然后前端页面会把数据展示到前台！

尝试学习Request/HttpClient库发起请求

在用完postman后，就会想到，那么我怎么用代码去发起一个请求呢？这时候就需要去学习这两个东西。pip install & import requests后，就开始了你的接口自动化之旅。

你尝试也是把之前ui自动化的增删改查，用接口来实现，你把抓包的请求参数拿过来，一个一个方法的调用，然后一键运行！一绿三红！为什么？然后发现接口返回了401，无权限！奥！我没有登入啊，那么怎么才能登入呢？？

抱着很多的疑惑开始研究，这时候你需要去了解cookie和token的工作机制，再配合你的代码，去缓存cookie，达到登入。等解决了这个问题，但是接口还是报错了啊，删除接口提示我没有这条数据！

查来查去，原来是我那条数据已经用掉了，那么怎么可以保证我每次录入的参数都是新的呢？这时候就需要去了解接口关联，如何把参数从上个接口的响应提取出来，给下个接口用。

request/HttpClient结合unittest/testNG+allure

一样的，等你学会了 request/HttpClient,自然也会想到用单元测试框架把他们集成起来，然后又发现了一个高大上的allure测试报告，再结合一些日志模块打印参数，轻车熟路的这么一个接口框架就出来了，和之前的差不多！小意思。

尝试用yaml/Excel管理测试用例

等你拿自己的框架，重复枯燥的写着测试用例，这时候你想了，我为啥每次都要request.post，方法都是一样的，只是数据不一样，为什么我要一直写代码呢，很累啊！为什么不用一些文件来读取测试数据，做参数化呢？

这时候你开始研究读写excel/yaml了，你想把所有的测试用例都放在文件里管理，就不用每次去写代码了，然而事情并没有那么简单！那么我在文件里如何去处理关联数据呢？如何去缓存cookie呢？如何做断言呢？如果做一些动态的输入呢？

以上问题就留给你们自己去想了。

高级货？git?jenkins?docker容器？分布式？

走到这一步，你已经写过好几个框架了，并且基于自己的框架做了优化，那么你此时发现一个很严重的问题，我的代码居然只能在我本地运行，如果要给别人用，还需要去别人电脑上配置环境，copy代码给他。

那么为什么不用一些代码管理工具去管理我的脚本呢？那么就会需要去学习git，了解如何add commit push推送我的代码到公司的gitlab，这样别人也可以使用，那么有了gitlab，我想做一些定时任务，让它自动执行呢？

学jenkins。再更多，要是我想多个用例一起跑呢？学习selenium grid，docker等等。。

自动化顶端之测试平台/工具开发

等你搭建好公司的自动化生态，你还是不满足，我为什么不把这些东西可视化管理呢？做个平台？管理用例，管理任务，管理测试报告？我还可以把公司的一些部署任务也集成过来？

想法很好！此时的你已经不仅仅是一名优秀的自动化工程师了，已经迈向了测试开发的道路！开始学习，了解了测试框架httprunner，开发框架django/flask/springboot，懂得了接口开发的流程，了解了mybatis,shiro,quartz等等，开始学习前端

vue/react，懂得了什么是组件开发，父子组件传值，开始了解很多东西，甚至运维方面的知识，开始了解k8s docker，微服务。。那么你越来越往着大神的方向去了，希望你还没有秃头，此时的你可以骄傲的称自己为一名合格的测试开发，或者叫全栈开发了有木有！到此告一段落。

自动化测试的12个认识误区

1、自动化的软件测试与手工的软件测试过程一样

自动化测试所需要的技巧与手工测试所需要的技巧是不一样的。

通常，你的项目经理会被那些测试工具销售们迷惑，认为自动化的软件测试就是简单地按一个录制的按钮，产生测试脚本。而事实上并没有那么简单。

区分自动化测试所需要的技巧与手工测试所需要的技巧是非常重要的。最重要的是，自动化测试工程师需要掌握软件开发技巧，没有接受任何培训的手工测试人员，或者没有编程背景的手工测试人员，在实施自动化测试时会碰到很多困难。

2、自动化测试一定会马上大量减少测试人员数量

自动化测试不会马上大量减少测试人员数量。因为开展自动化测试初期需要投入一定的人力进行自动化测试脚本开发，并逐渐将自动化测试脚本用于日常的测试中，逐步减少手工测试人员从事重复劳动的时间和人数。为了缩短自动化测试脚本的开发时间，可以考虑将自动化测试脚本的开发工作借助外包的力量来早日实现大规模的自动化测试。

3、测试自动化就是录制和回放

仅仅录制得到的不是有效的自动化脚本。

很多项目经理仍然把测试自动化等同于使用录制回放工具。而事实上，录制得到的脚本通常是不可重用的脚本，脚本中充满了硬编码的值，这些值应该被参数化，否则脚本仅仅适用于一个测试情况，脚本还应该加入条件判断、循环等结构，以便增强测试脚本的灵活性。

4、自动化测试找不到bug

自动化测试不直接找bug，而是通过解放有经验的测试工程师的生产力，让其从重复的回归测试中解放出来，从事新的测试方法和测试手段的研究。通过自动化测试解放出测试人员的时间和精力来间接地找到更多、更深层次的新bug，将产品质量再提高一个档次。

5、自动化测试工具是“万能”的

很多人一听到自动化测试，就认为自动化测试工具可以完成一切测试工作，从测试计划到测试执行再到测试结果分析，都不需要任何人工干预。显然，这是一种理想状态，现实中还没有哪个测试工具有这个能力，并且将来也不会有。在现实中有关的测试设计、测试案例，以及一些关键的测试任务还是需要人工参与的，即自动化测试是对手工测试的辅助和补充，它永远也不可能完全取代手工测试。

6、自动化测试工具容易使用

对于这一点，很多测试工程师有同样的错误观点，认为测试工具可以简单地通过捕获（录制）客户端操作生成脚本，且脚本不加编辑就可用于回放使用。事实上，自动化测试不是那么简单的，捕获的操作是否正确，以及脚本编辑是否合理都会影响测试结果。因此，自动化测试需要更多的技能，也需要更多的培训。

7、自动化能提供百分百的测试覆盖率

并非所有内容都可以被自动化地测试到。不可能覆盖所有可能的输入，所有可能的组合和路径。

自动化测试可以增加测试的广度和深度，但是仍然无法达到100%的测试覆盖率，因为没有足够的时间或资源。

8、忘记了测试的最终目标：找到BUG

在自动化测试中，同样要注意把边界值分析、等价类分析、基于风险的测试方法、挑选最合适的测试用例等技术应用起来。

通常在自动化测试过程中，我们都忙着搭建自动化框架和编写测试脚本，但是我们往往忘记了测试的本来目的：找bug。

项目经理可能雇佣了最好的自动化开发人员来搭建框架，使用了最新最好的自动化开发技术，创建了成千上万的自动化测试脚本。但是如果BUG仍然被遗漏了，那些本该被自动化测试脚本捕捉到的BUG，结果没有被捕捉到，那么你的自动化测试仍然会被认为是失败的。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！

化测试仍然会被认为是失败的。

[外链图片转存中…(img-Lr29Jrmm-1719282213982)]
[外链图片转存中…(img-74mAhrwX-1719282213983)]
[外链图片转存中…(img-AK04tME8-1719282213984)]

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！