测试平台思考：自动化测试成熟度模型

自动化测试或者测试开发专题的能力分层。
这篇文章结合我自己的工作经历，谈谈自动化测试的成熟度模型，仅代表个人看法。
重新认识自动化测试

我从事软件测试工作以来，第一次知道自动化是15年年底，听大佬说QTP可以录制脚本然后自动化回放，测试效率很高，当时心向往之。不过当时技术比较菜，而且对工作也比较迷茫，听过就忘记了。
大概16年时候，测试圈子自动化测试开始火爆了起来，当时基于selenium的UI自动化测试特别火爆。圈子里讨论，培训班推广，很多关于基于selenium的UI自动化测试的技术文章和书籍开始不断涌现。
我本人是17年年初才开始学习自动化测试并且尝试在工作中应用的，确实在回归测试和造数据方面，给了我很多的帮助，当然由于比较早吃螃蟹，在后面跳槽找工作时候，涨薪幅度也挺大。
大概18/19年时候，各种自动化测试平台开始在各技术大会、技术沙龙以及技术社区被大家讨论了起来。几个大厂的测试平台之类的最佳实践也开始被大家模仿借鉴学习，这一点大厂做的还是很好的，最起码指引了部分迷茫同学的技术提升和职场发展方向。
差不多20年底21年时候，我已经是个测试圈子的老鸟了，开始带团队，负责部分招聘和技术面试工作，也会帮业务线的测试同学交叉面试一些候选人。我发现自动化测试已经成了业务测试同学的面试必问技能。前几年大家觉得功能测试最多只负责功能+接口，自动化测试需要有专门的岗位，而近几年，自动化测试成了业务测试的必备技能。我个人认为原因有如下几点：
软件工程理念在实际工作中的不断深入；
业务迭代加速以及系统架构不断复杂化倒逼测试提升效率；
自动化测试工具/框架/技术实践不断丰富成熟以及求职市场的整体水平提升；
其实自动化测试的理念很早就被提出来了，国外也有很多的实践，国内相对较慢，但近几年测试圈子整体的基础技术建设也在快速发展。在我现在的认知里，自动化测试的能力可以算是测试团队的基础技术建设了。
因此，我的建议是，无论是刚入行的萌新，还是之前一直做功能测试的同学，为了更好的职场发展和增强竞争力，具备做自动化测试的技术能力也需要快速提升起来。

新手落地自动化测试

在讨论新手从零到一落地接口自动化测试之前，我想先抛出我的几点建议：
从零开始，不要直接去学习所谓的自动化框架；
学习框架之前，很有必要学习网络协议和编码知识；
为什么这么说？新手一般基础不扎实，且没有太多编码实践，直接学习框架容易一步一个坑。
从零开始学习落地接口自动化或者其他自动化测试，我更建议从易到难的去落地实践，这样一方面可以在日常工作中优先保证工作的完成，提升工作效率；另一方面就像打怪升级一样，从易到难去学习提升自己，并不断优化自动化测试在工作中的实践。从易到难落地接口自动化测试，大概可以遵循如下几个步骤：
学会用工具进行接口测试(如jmeter/postman)；
学会用持续集成工具(如jenkins)将接口测试脚本批量执行；
学会诸如git/gitlab等版本和源代码管理的工具，便于团队多人协作；
学习一门编程语言，利用自动化测试框架将工具脚本转化为代码脚本；
学习将公共部分封装，优化代码结构，提高写代码脚本的效率，降低维护成本；
学习数据参数化管理的方法，可以从Excel——配置文件——数据库——造数工厂这个方向迭代；
尝试按照业务线和测试场景区分脚本集合，然后引入mock，降低服务间的调用依赖，提高执行效率；
开始画大饼，造轮子，搞KPI，开发自动化测试平台；

自动化测试成熟度模型

本文第二部分的内容来源于我前几天写的文章:《从零到一落地接口自动化测试》，这里以从零到一落地自动化测试的几个步骤，来谈谈自动化测试的成熟度模型。

初级阶段-测试半自动化

先利用工具将日常费时的手工测试部分转化为半自动化（如postman/jmeter/jenkins），不要考虑什么框架或者CICD等高大上的东西，先解决部分效率问题，才能有时间和资源投入后续的建设。当然这个阶段更适用于初创企业或者小型公司的测试同学。

中级阶段-回归测试自动化

有了前期的部分建设，接下来可以将日常的提测冒烟测试、系统测试阶段的主流程回归测试以及部分造测试数据的过程转化为自动化。这个过程中一方面需要培养提升建设团队同学的技术能力，另一方面为自动化测试的大范围落地做铺垫（毕竟很多公司自动化测试看不到短期效益就变成了纯粹的KPI然后不了了之）。
注意：上面我说的都是测试自动化，并不是自动化测试。测试自动化指的是先将日常手工测试比较费时且重复度较高的部分转化为利用工具执行，这样做是为了提高效率，解放人力资源，也是为了打好基础，顺带让领导知道，做这些事对团队有长期价值的。

高级阶段-大范围自动化测试

到了高级阶段，我个人认为就可以开展大范围的自动化测试了。这里的大范围并不是说完全不需要手工测试，而是按照自动化测试的纺锥模型(不是金字塔模型)，按照UI-10%/API-70%/UNIT-20%的占比去不断建设和落地。

当然，这个阶段可以开始尝试测试左移的实践，测试同学去做更多具有创造性和探索性的工作，比如：
花更多时间在需求阶段，包括需求分析和需求评审，做好需求阶段的质量卡点；
设计更高效的自动化测试流程框架，提升测试用例的有效覆盖率（正交实验法）；
推动研发同学实践单元测试，测试同学提供case并评审验证，研发同学负责落地；
建设质量度量相关的事情（为了解决问题验证效果而度量，并非为了度量指标而魔改自动化）；

成熟阶段-自动化测试流水线

有了前面三个阶段的技术建设和用例沉淀以及不同团队间的协同配合，这个阶段可以考虑将自动化测试融入到企业的自动化交付流水线中。大致思路如下图：
图片
关于devops的持续交付流水线相关的内容，请期待我后面的文章，目前还是草稿状态。
最后，我个人认为无论哪种技术体系，最终的目标还是要保障交付质量，提升交付效率。成熟度只是一种抽象的定义，本文的内容也是我个人的一些观点，仅供参考。