📝 面试求职： 「面试试题小程序」 ，内容涵盖 测试基础、Linux操作系统、MySQL数据库、Web功能测试、接口测试、APPium移动端测试、Python知识、Selenium自动化测试相关、性能测试、性能测试、计算机网络知识、Jmeter、HR面试，命中率杠杠的。（大家刷起来…）
📝 职场经验干货：
Q: 做了十年自动化测试，你应该自动化自由了吧 ?
A: 打了十年工，你应该财富自由了吧？
这次唠一唠自动化测试中的怪现象，作为这个系列的第三篇。
案例1：永远在冒烟的自动化测试
之前的文章《二十年测试目睹之怪现状 [1]》中提到了手工测试用例“一次性”的问题。通过查询测试用例管理系统，发现当年度新增手工测试用例的执行记录为1，因此为“一次性低值易耗品”。 其实在那次统计中，也顺手看了一下自动化测试用例的执行记录，发现其执行记录的中位数和手工用例差不多。
也就是在项目中存在着注重于增加自动化测试用例的数量，用例写成执行通过提交到用例库之后，便将精力投入到后续用例的自动化之中，而不是去反复执行已有的自动化用例。
这还不是个案。即使在项目中已经有效应用了每日集成冒烟、版本提测时全回归等自动化实践的团队，也是从零开始，独善其身。也就是自动化用例全靠项目组团队从零开始编写，回归时也只运行项目组自身编写的自动化用例。而这个团队编写的自动化用例，也不与其它测试团队、或者是开发、UAT测试环节共享。
再把时间维度拉长一点，可以想见，等到项目结束🔚，这些已经自动化了的用例就会被束之高阁，等到这个系统下次再次被重构之时，已是物是人非，一切又重头开始。
比写 1000 条用例更重要的，是让 1 条用例跑 1000 次
案例2：接口覆盖的策略应该是怎么样的？深度覆盖优先还是广度覆盖优先？
某个团队专门安排了一个同学来实施接口自动化测试，项目组其他同学也在业务测试任务的空隙参与自动化测试。在这个模式下工作了半年多后，眨眼到了年底了。笔者给他们拉了一笔账，这个项目组的自动化测试用例数量上看已经积攒了接近几千条，这是一个不小的数字了。考虑到这个部门一共有几千个接口，笔者也很好奇地拉了一下他们的接口覆盖率。
你猜怎么着？
从被覆盖的接口数量的角度定义的接口覆盖率来算，整个自动化测试的接口覆盖率只有5%左右。在复核了这个数字的正确性之后，笔者又去拉了一下接口的用例数量。
又被吓了一跳。
某个用例最多的接口，它的测试用例数量快接近400个！拥有上百个用例的接口还有好多个。
如果自动化测试是一个防护网的话，那这个网子只在某个局部编织得密密麻麻，而在整体上又是空空荡荡。
这两个案例中的项目团队的接口自动化测试，人员和时间投入也很多了。那你觉得他们的实践算成功吗？
最后： 下方这份完整的软件测试视频教程已经整理上传完成，需要的朋友们可以自行领取【保证100%免费】
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
