对于自动化测试，我们要不要做？需要从团队管理层和个人两个角度来区分，这次我就从团队管理层来讲：自动化测试是不是烟雾弹？

作为测试leader，别人都在做，而我们没有，是不是说明我们测试团队很low，该被淘汰了？特别是，大领导也下任务要落地自动化测试，这时真是鸭梨山大，从而“病急乱投医”？看到别人UI测试自动化搞得好，自己也跟着搞，搞到一半，没多大起色；看到别人接口测试自动化搞得很好，赶紧又换，最后一年下来领导问话了“你自动化测试搞得怎样了？”，心里是有苦说不出，感觉很忙，但一点效果也没有，自己也很矛盾。这是很多测试leader的一个缩影，自动化测试各种类型搞得很多，但没有成果，最后认为自动化测试就是烟雾弹了。

对于这种情况：你得首先搞清楚各种类型的自动化测试落地的难点，比如UI自动化，前提是什么，UI频繁变更怎么办？编写脚本压力大怎么办？需要单独招聘写脚本的人吗？从这就看到三个问题：UI变更频繁，脚本编写压力，人员技术水平。

UI定位和变更频繁，就涉及到要跟开发定义好页面布局、控件以及要测试的场景；脚本编写压力就涉及圈定测试范围，落地的场景，是否开发录制工具等；人员技术水平就涉及到你的工具是否需要大面积推广，还是部分人使用，这涉及到使用率和招聘成本。所有这些问题都促使你需要从团队的实际情况出发，如果测试流程混乱，接口文档缺失，提测版本质量差等，此时把测试流程，测试规范落地才是首要任务。

当具有良好的项目/测试规范后，也不要急于上什么UI/接口/监控平台等自动化测试。应该从业务中找出反复的问题点或者痛点，可以用小工具或者脚本来提高效率，让大家感觉到自动化或者技术带来的好处。接下来团队再根据实际项目情况，分析可以先从哪方面入手，比如接口自动化测试，相对UI成本低、收益高。

但切记，自动化测试的主要作用并不是为了发现问题，而是保证以前测试通过的功能没有问题，即用于回归预防缺陷。不知道这一点，你就会越做越觉得自动化没意思，特别是遇到自动化问题的时候。不要轻易放弃，要去攻克、解决痛点，并改造优化，开发出适合自己的团队业务的自动化测试框架或者工具平台。还需要跟你的上级和团队成员达成统一的共识：自动化测试是一个长期的投入，短期内难以见效，所以得耐住寂寞。

最后，当别人在吹嘘自己牛叉的测试工具平台时，我们不要盲目崇拜，需要用心去了解合不适合我们当前的情况，不合适也不要紧，当做扩展自己的视野。

简而言之，混乱的时候不适合自动化测试，捋顺各个流程后，可以先着手解决痛点，让团队和高层认识到好处后再从工具，框架，衍生到平台，最后可以向左，向右移及精准定位等新领域实施，形成测试团队的技术闭环。不要脱离了业务搞自动化，那是PPT的自动化，能服务于业务的自动化测试，才是有用的。自动化测试不单单是测试团队的事，是整个项目团队协作的事；自动化测试也不是一蹴而就，是需要沉淀的；自动化搞好，项目质量并不一定就高；自动化测试是团队技术的一种体现，但不一定是质量最佳的展现方式。

-------- THE END --------

🍁