十多年了,接口自动化测试越来越鸡肋?

引言

从《Google软件测试之道》到后来的敏捷开发、DevOps,10多年了,接口自动化测试一直是测试领域必谈的重点。各种自动化测试工具(Postman类)、自动化测试框架、自动化测试平台层出不穷,每个公司/部门甚至每个团队都有一套直接的自动化解决方案。但盲目投入后,反而会感觉越来越鸡肋,食之无用弃之可惜。

接口自动化的价值

不管你是 B/S 还是 C/S 架构,APP 还是小程序,还是什么协议,总体来说是由 GUI 和服务端 API 组成。通常一个迭代是 PM 需求、RD 开发/联调、QA 单功能测试、bugfix(穿插多轮)、合码 QA 集成/回归测试、发版。在这一套模式下,大家常说的接口自动化测试(暂不考虑 UI 自动化)的价值如下:

提高测试效率/降低人力成本?

因为自动化测试执行很快,所以引入接口自动化测试能提高测试效率。但有个很现实的问题,接口自动化只覆盖了服务端 API,GUI 这部分也有很多逻辑,RD 也是有大量工作量投入的,这部分的测试是少不了的。即使是偏服务端 API 的功能,你的手工 GUI 测试替代率是多少?接口自动化执行完了能不需要手工测试吗?这恐怕不敢打包票吧。所以对于一个端到端的测试团队,反而接口自动化 case 的编写和维护成了额外的负担

降低人力成本也是无稽之谈,因为你手工 GUI 测试的成本并没有降下来,反而需要投入写接口自动化的人力。除非你之前就有一批人是使用 Curl 测接口的。

提高测试覆盖率?

这个理论上有道理,一些接口参数分支,UI 上无法走到,通过接口则可以直接覆盖到,提升了覆盖率,后面 UI 上增加了此分支能保证基本的质量,提升迭代效率。但事实上产品变化很快,还没等覆盖到新参数分支,需求又变了,接口甚至都得重写一遍。掉入了过早优化的陷阱。

持续集成和持续交付(CICD)✓

互联网大部分开发模式都是迭代开发、小步快跑。接口开发完成后还没到测试环节,这时候跑一遍自动化(回归测试),能保证基础功能没影响,代码就可以合入了,过几天就自动进入到测试环节。也能尽早发现问题,缩短交付周期。

同时还可以用作线上监控,保障服务稳定性。这是手工测试无法做到的。

保证结果的一致性和准确性✓

手工用例总是需要人理解然后执行,因为各种原因,不同的人可能对同一条 case 理解不一样,造成执行偏差。然后人总有惰性,偶尔还是会有因觉得执行过程偷懒而导致的漏测。而接口自动化执行的结果是可靠的。

总的来说,如果你是想只通过接口自动化这一种方式降本提效,那可能会事与愿违。而是应该把提质作为目的,即接口自动化作为质量保障的重要手段,尽早的写(左移),穿插到整个研发生命周期里面去,才能发挥更大的作用(特别是现在 DevOps 时代)。对此合适的度量指标:线上问题召回率、自动化 Bug 发现比率(含 CICD 过程中发现的)。

接口自动化的成本

在评估自动化收益的时候我们常用这样一个公式:自动化收益 = 迭代次数 x(手工执行成本 - 用例维护成本)- 用例编写成本。现在来看可能不太合适,如上所述,接口自动化和手工测试并不对等,并不是替代人工。不过自动化测试的成本倒是可以通过类似的公式计算:运行次数 x 用例维护成本 + 用例编写成本。这可能和大家想象的不一样,接口自动化通常被认为是边际成本很低,即用例编写成本会随着运行次数增加而摊薄。但事实上维护成本也不低,而且无法摊薄,因为不运行就不需要维护,只要运行就会出问题,就需要排查、维护。

维护成本的来源可能是多方面的,虽然都有一定的解决办法,但不能忽视这部分的成本,而且分散在日常中还是隐性成本(leader 看不见),如果做的不好,甚至会出现团队都很累,但质量又很差的情况。

维护成本来源解决方案
接口参数不兼容改动,需要相关case都改动接口适当封装,case使用封装后的模板或函数,方便使用和维护
前置变量失效导致case失败,比如商品id
或者说一个新环境的适配成本
一方面case里面不能写死id,需要变量化,数据和逻辑分离
另一方面,case需要自给自足,相关依赖资源在前置操作中产生,并在后置操作中销毁
case间的量子纠缠适当的执行用户隔离,一些资源操作加锁

很多测试框架/平台把重点放在写 case 这块,宣称功能更强大(比如流量录制导入)、体验更好。但拉长 case 周期来看,编写成本是一次性的,10分钟写完一条 case 和1小时写完一条差别不大。更多的应该放在如何写好 case(场景构造、数据准备等)、维护好 case,这才能降低最终的成本。(放心没广告)

总结

还是那句话:软件工程没有银弹。鸡肋不鸡肋要看目的,降本增效可能不是直接的收益。同时也要注意接口自动化维护成本也不小,需要重点投入解决这块的问题,才能使最终的 ROI 高。

当然,本文看着还是泛泛而谈,并没有说接口自动化该如何写,但我认为具体怎么写都是招式问题,先修一下内功心法总纲更重要。

参考资料

迷雾中的自动化测试体系建设,https://cloud.tencent.com/developer/article/1927415

知识分享|自动化测试首选接口自动化?https://v2ex.com/t/1020718

关于产品质量的思考 - 如何评估质量,https://mp.weixin.qq.com/s/PEeKEJ1FBwvVUOeEJkixQw

接口自动化不是救命稻草,https://testerhome.com/topics/38202

Apifox:API 接口自动化测试完全指南,https://apifox.com/blog/api-testing-guide/

Lego-美团接口自动化测试实践,https://tech.meituan.com/2018/01/09/lego-api-test.html

关于产品质量的思考 - 如何评估质量,https://mp.weixin.qq.com/s/PEeKEJ1FBwvVUOeEJkixQw

【QA&QE校招培训】 浅谈自动化测试,https://bytetech.info/videos/6857809063481507847

工作5年,后3年都重复着前2年?写在离职百度之际(QA篇)

最近各种原因换了个工作,回想起来校招(实习)就进百度了,一晃5年多了。最近又宣传“十四五”,也想着自己确实得好好总结下这五年,而且市面上做 QA 的比较少,希望能对新同学有些帮助。

重新review下工作

做程序员这一块,可能都会遇到第一个瓶颈,工作前2两年成长很快(特别是 QA,都是现学),但后面就慢了,感觉重复着之前的工作。这里以“捕鼠器案例”为引子(杨震原字节内部分享,来源王梦秋百度的内部分享),重新捋一下 QA 的工作:

工作第1年

刚工作接到的任务一般比较简单、直接,比如导师可能叫你去放一下捕鼠器。这个时候你一般看看文档,多观察下,就知道捕鼠器是用来捕老鼠的,你只要不给它挂在墙上就行。甚至前人已经放过捕鼠器了,你只要依样画葫芦隔一段距离放一下就行了。

这个时候你就要稍微总结下了,放捕鼠器为什么有时没捕到老鼠,你可以会观察录像,看别人的捕鼠器怎么做的,这个时候稍作改进就会效果明显。具体的到QA的工作,你现在已经非常熟悉这块的业务,每次小功能的测试都游刃有余,而且通过学习你还会了 API/UI 自动化测试,效率也变高了。

工作第2年

由于表现还不错,你已经晋升为 T4 了。这个时候你会发现只放好老鼠夹子效果还是不好,具体到工作可能会发现线上还是有很多问题。你一想,捕鼠器是干啥,消灭老鼠,但消灭老鼠,不仅仅只有捕鼠器一种方法,或者说一种方法不够。

当一个人从完成任务到解决问题,能够再问一步,这个问题关联的问题是什么,进而去提出新的问题,这就是关键的突破点。

你可能会发现老鼠药更管用。类比测试工作上来说,你引入了更多的测试方法:diff 测试、性能测试、稳定性测试、兼容性测试、安全测试、ET测试等,工作开始变的顺风顺水。

工作第3-5年

这个时候你测试环节已经做的很不错了,能负责一个系统或者业务方向的测试了,一般的话也晋升为 T5(高级测试工程师)之列了。但这个时候就开始重复之前的工作了,项目不停迭代、新功能测也测不完。而且随着需求积累,回归测试也很多了,因此对于 QA 来说这种重复的感觉比 RD、FE 更强烈

这个时候还得回到原点来,捕老鼠是为了什么?为了保护粮食。那 QA 找 Bug 是为了什么?是为了“质量”。

(图 来源百度王梦秋分享 PPT)

这个时候介绍一个在百度内部非常重要的概念:全流程质量保障。作为 QA(Quality Assurance,质量保障),自己把自己定位成测试是不行的。

全流程质量保障

可能每个公司的项目流程都不一样,但都会包含以下几部分,当你跳出“测试”来看,就会发现能做的事情还有很多: Continue Reading...