如何用自动化测试搞垮团队-技术圈

自动化测试是大家非常熟悉的测试手段，近年来随着行业内卷越来越严重，对于测试工程师的岗位要求也水涨船高。

如果你有留意一些测试工程师岗位的招聘要求，你就会了解很多细节，自动化测试技术已经不再是测试工程师找工作的「敲门砖」了，而是大部分测试工程师都应该具备的「基本生存技能」了，很多公司在招聘测试工程师时，最低要求都是「你得会自动化测试、你曾经做过自动化测试、你得把自动化测试用的很6」，当然，至于入职之后怎么做这项工作，那是另外一回事。

— 我关于自动化测试的理解 —

面对这个现象，我曾经思考过，发现其中存在2个有趣的逻辑：

1、自动化测试技术其实门槛很低

这块技术整体可以分为两类：一类是设计自动化测试框架，一类是用自动化测试框架编写脚本。

先说第一类：框架设计

自动化测试框架网上很多开源的，各种版本语言的都有，UI、接口、单元测试等各种场景也有很多分类，要从事这类工作至少需要会某一门编程语言，编程的逻辑得清晰，照着网上开源的框架捣鼓捣鼓，很快就熟悉了。

对于普通测试工程师来说，自动化测试框架设计看起来似乎是挺「高大上」的，但对于懂的人来说，也就那么回事，正所谓：会者不难、难者不会。

再说第二类：脚本编写

无论是UI自动化测试，还是接口自动化测试，依旧属于「黑盒测试」的范畴，本质上只是代替人工操作和验证，把手工测试用例用编程语言翻译成了自动化脚本。当然，这里面使用的技术手段可以多样化，可以使用各种各样的工具、借助各种平台。

这一类工作，测试工程师花一定量的时间去学习，可以轻松搞定这件事。

所以，结论就是，自动化测试技术无论是搭建框架、还是编写自动化脚本，相比开发工程师的技术门槛，其实真的不算高。

2、网上学习资源非常丰富

时间倒回是2007年那会，自己刚大学毕业，当年我准备入测试这一行当，为了弄清楚自动化测试，周末找了一个小网吧，向网管上了一台机，开机百度搜索「自动化测试」，能找到的文章寥寥无几，最后没办法，只能自己翻墙去国外找一些文章学习，一边摸索一边练习，学习进度可谓是举步维艰。

相反最近这些年网上的资源很多，想获取自动化测试的知识并不难，各大论坛、公众号、各大视频APP、各大学习平台，很多牛人写了很多博客，还有更6的小伙直接把进阶学习的文档全部集中起来放到了github工程里……。

只要你想学，学习资源这块可以说是相当地轻松，资源成体系的打包呈现在你面前，接下来要做的事就很简单：「学就是了」。

越来越多的年轻测试工程师掌握了自动化测试技术，让这项技术变得「烂大街」了。那么，既然这项技术这么普遍，为什么有的团队还做不好呢？大家忘记了，这里面还有一个「经验」属性，这其中某些经验都是大家耳熟能详的，某些经验又是老测试工程师们密不外传的「私货」。

接下来我们回归正题，如果你作为测试团队的技术骨干，如何利用自动化测试技术搞垮整个团队呢？我们还是以调楷的目光来审视以下几种情况吧：

— 用自动化测试搞垮团队的 9种方法 —

1、所有的测试场景都必须自动化

吃瓜度：

歪歪原则

：既然你都有了自动化测试了，那就把所有的测试活动都自动化掉吧。

正解

：

很多新人在学完自动化测试后，总想试图利用自动化测试技术代替所有手工测试，且不论这种可行性是不是存在。

我们首先要理解ROI的概念，既：投资回报率，是指通过投资而应该返回的价值，即企业从某项投资行为中得到的经济利益回报。

回到我们的工作中，自动化测试也是一样，根据ROI来决定这项测试工作是否需要自动化，如果用自动化测试来做，能带来什么样的回报。

结论就是，想要自动化一切测试活动是不可能的，要考虑投入产出比，否则整个团队做了很多ROI很低的事情，迟迟达不到效果，最终会被你活活整垮掉的。

2、自动化就是用来替代测试人员的

吃瓜度：

歪歪原则

：我引入自动化测试就是为了节省人力呀，要不我没事弄什么自动化测试呢？

正解

：

很多非测试的测试领导会认为引入自动化测试后，测试人员的负担立刻会减轻，其实这是个误区。

开展自动化测试初期需要投入一定的人力进行自动化测试脚本开发，并逐渐将自动化测试脚本用于日常的测试中，逐步减少手工测试人员从事重复劳动的时间和人数。长期看也许会减少一定数量的测试人员数量，短期内的测试工作量一定是增加的。

从成本的角度来看，一个自动化测试脚本的成本大致可以分成：

自动化测试脚本的成本 = 编写成本 + 维护成本 + 执行成本 + 交接成本 + 沉没成本。

前面3类都比较容易理解，这里简单说1下后面2类成本。

交接成本：张三写的自动化测试脚本，能执行能验证，后来张三离职了。李四入职顶张三的岗，李四拿出来脚本一看，俺的勒个娘雷，写的这的这是啥（煞，四声）啊，乱七八糟的。还有，用别人的脚本就好比穿别人的内裤，太脏了。一怒之下，直接删掉脚本，自己重新写了。

沉没成本：张三写的自动化测试脚本，能执行能验证，后来需求变了，这个测试场景不存在了，测试用例废了，自动化测试脚本也跟着废了，成本沉没了。

所以，引入自动化测试不但不会减少工作成本，短期内反而会增加工作成本。而自动化测试可以提高测试效率，但是不是以减少人员数量为目的的，如果抱着减少人员的心态来入坑自动化测试，最后是没办法向领导交代的。

3、必须紧盯自动化的指标

吃瓜度：

歪歪原则

：没有指标就没办法度量，一个自动化测试脚本能发现几个bug，我要拿指标去衡量团队的工作质量。

正解

：

有些测试团队的领导会格外关注指标的有效性：

平均每条自动化脚本发现了多少个bug、平均每条自动化脚本用时多长、平均每条自动化脚本包含了多少步骤……。

可能是数学系毕业的领导，也可能是从大数据转岗过来的，要么怎么就盯着数据不放呢？

当然，这里提到的是「过度」，度量某一件事的效果，核心指标是要有的，但不用过度依赖指标。

打个比方，详细小伙伴过年回老家时会有这样的感叹，在上了年纪亲戚心目中，家里、邻居、亲朋的所有年轻人在他们心目中都有个「是否出息的排行榜」，榜单评比的维度就是，无非就是「赚钱多少、工作单位如何、职位高低」，你们肯定也很抵制这样的现象，同理，回到工作中也一样。

数字化管理是90年代外企比较注重的管理方式之一，数据是可以造假的，数据是可以骗人的，所以，没必要过度关注指标，关于这一点可以看看茹老师的这篇文章“研发效能度量引发的血案（长文慎入）“。

4、自动化测试一定可以发现更多的功能Bug

吃瓜度：

歪歪原则

：自动化测试你不发现bug你来做什么，我要你有何用？

正解

：

稍微懂行的测试工程师都知道，自动化测试最擅长的是做测试回归，而不是发现更多缺陷。要知道，目前缺陷的发现主要还是依赖于人工测试的。而对于不太懂的领导来说，就不是这回事了。

「哎，你们测试不都自动化测试了吗？怎么发现的bug这么少？看来自动化测试也没啥用嘛。」不止一位开发领导跟我这么吐槽过，而我也会耐心地跟他解释，为什么自动化测试这种测试手段不能发现很多Bug，其实自动化测试发现的问题少是好事，你可以思考一下这是为什么。

5、自动化测试框架越先进越好

吃瓜度：

歪歪原则

：团队必须得有一名首席自动化测试框架架构师坐镇，要把我们的自动化测试框架设计成行业最先进的框架。

正解

：

PDD的黄征曾经说过一句话让我记忆犹新：所谓的消费升级，不是让所有人都能穿上普达拉，而是让全国2345线城市的老百姓都能随时随地用上便宜、干净的卫生纸。

自动化测试框架的设计升级，其实能够满足团队和项目需求即可，点到为止，无需过度投入和钻研，做过了，就属于「项目镀金」了。

我非常能理解有些技术控的测试工程师，喜欢学习和钻研技术，非常享受那种「技术成就感」，花了很多心思在赋能框架这件事上，为框架增加各种各样的函数和黑科技，但殊不知，需要这些功能的测试人员寥寥无几，无端浪费了团队资源。记住永远不要为了技术而技术，技术只是你达成目标的手段。

6、脚本通过就可以了，管它质量如何呢

吃瓜度：

歪歪原则

：要绝对的相信团队，相信大家的工作质量，没事不要做什么抽查

正解

：

当自动化测试脚本的数量增长到一定量级后，建议测试团队对每位成员的脚本代码进行随机抽样评审。这样的目的并不是不相信团队，而是要关注测试的执行过程、验证检查点、脚本合理性、以及可维护性。

同时，只关注脚本通过与否，最终容易陷入「误报与漏报」的质量陷阱。

从不评审设计和脚本，不关注自动化测试的设计和脚本质量，导致的结果就是测试质量的直线下滑。

7、都有自动化工具和框架了，我还要测试工程师干嘛？

吃瓜度：

歪歪原则

：第一步先引入自动化测试，第二步把很多测试工作自动化了，第三步向领导申请砍掉测试团队。（由开发经理来管理测试团队的后果）

正解

：

人才是做测试活动最重要的部分。

有些测试领导过度迷信工具和框架的作用，不知道人才是真正能够开发和用好这些东西的关键要素。

这属于忘记了测试的本份：发现Bug。

自动化测试工具和框架再好，也得由人来判断测试场景，由人来判断是使用等价类划分、边界值分析方法，还是使用因果图、基于风险测试法。通常在自动化测试过程中，我们都忙着搭建自动化框架和编写测试脚本，但其实作为测试的职责是：设计合理的用例找到系统中的bug。

尊重做测试的人，才是尊重测试这项工作。

8、计算机基础没必要学习

吃瓜度：

歪歪原则

：测试工程师没有多少技术的，会点点点、写点脚本就行了。

正解

：

自动化测试脚本虽然也算代码，但那是按照测试用例翻译过来的“脚本”，真正有技术含量的是如何定制自动化测试框架。

对于框架层面，需要考虑的事情太多了，我粗略估算了1下大概分这么几类：

框架使用场景认知：考虑的业务重要程度、用例的分层分级、测试资源分配、执行频率和特点，还有技术难度……

自动化脚本的质量认知：脚本之间能否互不影响、被测系统能否保持清爽、快速定位问题、保留现场证据、易于编写、维护及扩展……

执行失败的调试认知：测试开发环境部署、网络异常、脚本本身问题、Docker和虚拟机的问题、通知方式……

数据管理策略认知：哪些是框架层面的数据，哪些是用例隔离数据，哪些是业务公共数据，数据能不能通过对象实时获得……

想设计好一款自动化测试框架，需要用到的技术、考虑的细节还是多方面的。

测试工程师说到底还是要关注技术，无论是转型测试开发还是继续在自动化测试方向深造，都需要扎实的技术功底。

9、自动化测试挺不错的，我们要立马开干

吃瓜度：

歪歪原则

：自动化测试就是要兵贵神速，项目立项后要立刻开展，争取在开发同事没有交付代码前，先把自动化测试脚本完成。

正解

：

对于很多不熟悉自动化测试工作的团队，很多系统都不具备手工测试的可测性（业务需求没稳定、代码技术方案没稳定、系统没稳定、人员没稳定……），贸然开展自动化测试只会适得其反，关于可测试性可以专注这篇文章”深入浅出谈软件的“可测试性”“。

自动化测试最大的用途是用来做回归测试执行的，在系统不稳定时贸然开展自动化测试，最后只能导致一个结果：卒。

以上就是用自动化测试搞垮团队的方法，希望你能够喜欢。

以上分享希望对你工作有所帮助、启发，有被帮助到的朋友欢迎点赞，在看、转发。