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

2022-05-25 10:00:00
司文
转贴:
公众号
3511
摘要:如果你有留意一些测试工程师岗位的招聘要求,你就会了解很多细节,自动化测试技术已经不再是测试工程师找工作的「敲门砖」了,而是大部分测试工程师都应该具备的「基本生存技能」了

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


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

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

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

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

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

先说第一类: 框架设计

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


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

再说第二类: 脚本编写

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


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


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

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

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


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

只要你想学,学习资源这块可以说是相当地轻松,资源成体系的打包呈现在你面前,接下来要做的事就很简单:「学就是了」。
auto testing-campus interview-2
越来越多的年轻测试工程师掌握了自动化测试技术,让这项技术变得「烂大街」了。那么,既然这项技术这么普遍,为什么有的团队还做不好呢?大家忘记了,这里面还有一个「经验」属性,这其中某些经验都是大家耳熟能详的,某些经验又是老测试工程师们密不外传的「私货」。

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

— 用自动化测试搞垮团队的 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和虚拟机的问题、通知方式……


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

auto testing-campus interview-3

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


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

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

吃瓜度:三颗瓜
歪歪原则:自动化测试就是要兵贵神速,项目立项后要立刻开展,争取在开发同事没有交付代码前,先把自动化测试脚本完成。

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


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


以上就是用自动化测试搞垮团队的方法,希望你能够喜欢。
发表评论
评论通过审核后显示。
联系我们
  • 联系人:阿道
  • 联系方式: 17762006160
  • 地址:青岛市黄岛区长江西路118号青铁广场18楼