如何用自动化测试搞垮团队

　　自动化测试是大家非常熟悉的测试手段，近年来随着行业内卷越来越严重，对于测试工程师的岗位要求也水涨船高。
　　如果你有留意一些测试工程师岗位的招聘要求，你就会了解很多细节，自动化测试技术已经不再是测试工程师找工作的敲门砖了，而是大部分测试工程师都应该具备的基本生存技能了，很多公司在招聘测试工程师时，最低要求都是你得会自动化测试、你曾经做过自动化测试、你得把自动化测试用的很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、自动化测试挺不错的，我们要立马开干
　　吃瓜度：
　　歪歪原则
　　：自动化测试就是要兵贵神速，项目立项后要立刻开展，争取在开发同事没有交付代码前，先把自动化测试脚本完成。
　　正解
　　：
　　对于很多不熟悉自动化测试工作的团队，很多系统都不具备手工测试的可测性（业务需求没稳定、代码技术方案没稳定、系统没稳定、人员没稳定），贸然开展自动化测试只会适得其反，关于可测试性可以专注这篇文章深入浅出谈软件的可测试性。
　　自动化测试最大的用途是用来做回归测试执行的，在系统不稳定时贸然开展自动化测试，最后只能导致一个结果：卒。
　　以上就是用自动化测试搞垮团队的方法，希望你能够喜欢。