作者曾承担团队接口自动化测试专项，参与团队自研测试平台开发、落地，作为自动化小组 owner 在团队内部多次分享自动化测试技术，并推动其他测试小组接入测试框架，最终促成团队所有系统接入测试框架，大大提升团队自动化能力，同时取得了多项技术专利。

业务测试为什么需要转型自动化测试？

员工成长

就个人而言，相信大多数测试同学都遇到过发展瓶颈。当你忙于频繁手工测试看不到个人成长时，大多数表现出对未来职业发展的焦虑，很容易滋生员工产生跳槽的想法。这是团队管理者必须面对的问题。频繁手工让测试缺乏对成长的思考，不到对个人造成负面情绪，团队的氛围也会受影响。想改变这种情况，需要让团队成员持续看到自己的成长。推动员工转型自动化测试则是非常不错的 idea。

项目压力

随着敏捷开发的普及，测试需要应对快速的版本迭代，不断变化的产品需求。纯手工测试属于"旧时代"生产力，已经无法满足敏捷测试对测试的要求，提升测试生产力，则是缓解项目压力的手段。而提高测试生产力，就要求测试人员从纯业务测试向技术转型，鼓励员工使用技术手段解决业务问题！

如何推动团队测试转型自动化测试？
测试自动化是一种意识形态（思维方式），测试转型自动化是一种认知的升级。

如何认知升级，培养测试自动化思维？答案就是 持续学习新技术 + 项目专项实践 + 扎实的编程能力，毕竟实践是检验真理的唯一标准。

下面我就介绍下团队的从业务测试到自动化测试的转型过程。

自动化小组

大家都听说过 头狼效应，自动化小组就是头狼的角色，带头推动团队自动化转型。自动化小组成员都具备自动化测试经验，在各自所在的公司有过成功的自动化实践。大家坐在一起，可以针对当前团队测试过程遇到的最棘手的问题进行脑爆，并提出技术解决手段。

（此外，自动化小组成员都是独立负责项目且有自己的虚拟小组（带外包做项目），小组长也同时担负虚拟小组内部成员自动化转型的责任。虚拟小组是团队的子集，虚拟小组自动化技术的提升，也是团队自动化技术的提升。）

当时所在的团队刚成立不久，正处于快速扩张期，测试基础设施不完善，以当时的测试人力无法承担即将到来的业务压力。通过人员招聘并最终融入团队缓解压力毕竟有时间成本，所以自动化测试被大家提上议程，综合考虑到接口自动化投入低产出高，决定以接口自动化为突破点，打造团队内部接口测试平台，终极目标是中台所有项目接入测试平台实现自动化测试。

项目立项

找到了突破点，怎么做又摆在了眼前。做接口自动化测试，当下有现成的开源工具 JMeter、HttpRunner 等可以选择，既有一些开源的自动化测试平台。但是，这些开箱即用工具也有弊端。1. 无法满足自动化平台诉求，短期内确实可以快速实现自动化，但是这些工具对于平台非自动化能力的拓展成本较高，毕竟改动开源工具的成本比自研高很多。2. 使用开源工具不利于提升团队在自动化技术方面的成长。自动化能力的提升离不开编程能力的提升，使用开源工具能提升工具学习使用能力，最终你的成长无外乎又掌握了一个测试工具的使用。3. 无法最大化提升自己解决问题的能力。

最终结论，我们既不用现成开源测试平台，也不再结合已有的测试工具进行二次开发以搭建自己的测试平台，而是从 0 到 1 搭建自己的接口测试平台，以 Spring + TestNg + Okhttp 底架的方案搭建自动化测试平台。项目分两步走：1. 接口测试框架建设 2. 接口测试平台建设。

做大量的技术专项，不但可以提升你的编程能力，更重要的是锻炼你使用技术手段解决问题的能力，能用代码做的就不要手工做。

打造 “样板房”

接口测试框架开发完成后，我带的小组先进行试用。使用前先给大家做了一次分享，演示框架操作原理，如何开发接口测试用例。为了让大家好理解，我就拿 postman 的使用步骤和框架测试一个接口做类比。既是如此， 大家刚使用测试框架时候仍遇到了不少问题（也是意料之中，大多数外包几乎 0 编程经验），包括接口测试用例开发成本高，外包同学代码能力差遇到问题解决不了，不会 debug 代码，开发好的用例上传 gitlab 经常搞出冲突需要解决，每个同学用例的写法千奇百怪等等。还记得当时那段时间的内容，除了做手上的业务就是帮忙看各种大家在写用例遇到的问题。为了这些问题，我也挤时间编写小白级的测试框架使用说明书，制定测试用例开发规范，其他同学进行 git 使用分享，debug 培训等。针对用例开发成本高的问题，我通过在测试用例开发过程总结到 HTTP 不同请求方法对应的接口测试写法不一样，同方法的测试接口写法几乎一致，突然想到可以使用模板自动生成接口测试用例，然后我就整理几种接口测试用例生成模板（post、get、get 拼接参数等），这样大大降低测试用例开发成本，大家更多在于测试数据的准备和断言。基于此实践，也和同事一起申请一项自动化代码生成专利。

通过几个月的小组内推广使用，几乎解决了所有用例开发到运行过程可能会遇到的问题，将大家遇到的问题也汇总成知识库。

我们小组通过几个月的使用，在一定程度上提升了自动化回归的效率，起到了示范作用，然后就开始将框架推广到其他测试小组使用！

定期周会

我们团队比较大，所谓周会并非每周一次，基本上是半月/一月才会组织一次。

周会也是给团队成员普及自动化测试技术的一场非常好的机会。自动化小组成员可以分享一些最近学习的测试新技术，和大家脑爆是否能够解决当前团队中遇到的问题。也可以分享一个近期项目中利用技术手段解决业务问题的案例。分享形式不限，要能突出技术在工作中的重要性，增加团队成员对技术认知的体感。

对内/外交流

俗话说，山外有山，人外有人。永远要保持一颗谦逊的心。

鼓励与公司其他团队进行技术交流、分享技术上的产出。说不定你解决的问题正是别人当前遇到的。你遇到的问题也可能是别的团队早已解决的。在互联网大厂，通过对外交流能降低重复造轮子的概率。

当然除了与公司内部团队间交流，也可以经常参与对外交流。比如 参加每年的 MTSC 测试开发大会，多听取各大厂测试团队分享的自动化相关议题。

也可以参加公司组织的线下沙龙，将自己团队比较好的自动化实践分享出去，别的公司优秀的技术实践吸收进来。

测试开发技能图谱
前文说到，测试认知升级，离不开大量的技术专项实践，这也要求测试需要具备开发能力，即测试开发。

下面是一份测试开发技能图谱，可以作为大家转型的指导。