三招轻松搞垮自动化测试

自动化测试的成功可以有很多种方式，也有很多种定义，但是自动化测试的失败却很简单，就是不再做自动化测试了,或者是因为做自动化测试把团队搞没了。那么有哪些问题会在你即使很努力的情况下，依然导致自动化测试的失败呢？

问题1-来不及写自动化测试用例

传统的自动化测试实施失败的一个典型问题就是“来不及写自动化测试”，也就是自动化用例的编写速度远远跟不上需求交付的速度，导致自动化测试的“负债”越来越多。因为通常意义上的所谓自动化测试，其实是测试用例执行的“自动化”，而测试用例的编写和调试过程依旧是个手工的工作，而且是需要测试人员在手工执行测试任务之外额外再承担的工作。因此这类的自动化实施，其投入和产出之间是一种线性关系，也就是投一个人插1天秧，就有一天的成果，投两个人，就有两个人天的成果。甚至随着投入规模的扩大，协同方面的负效应还会拉低这种方式的回报率。

因此，不少团队选择了加大人力投入、996等方式来积攒用例，努力成为富二代的爹。例如某些团队会设置专门的所谓测试开发岗，其主要工作就是将手工测试人员所编写的测试用例翻译成自动化用例。这个模式的危害笔者会在后续的部分进行分析。

如果有一个成为富二代的机会，你会珍惜吗？

业内有种说法（其实是我说的），“自动化测试成功的前提是已经有了足够多的自动化用例”，也就是如果你现在还没有足够的自动化用例，那么你的自动化测试就谈不上成功，是不是有点死循环的味道？所以，当某些同学新加入团队时，吐槽现有自动化测试框架/平台不够好，不如更换或者重建时，其实要转换一下思路，如果有个机会给你继承一笔Old Money, 你是会嫌弃它钞票不够新，还是会嫌弃它数量不够多？所以即使是焕新，也要考虑能带上既有的用例。

自动化测试平台能提高用例编写的效率嘛？

绝大部分人还是在普通的测试团队干着普通的测试工作。那么如何能跳出前面说的这个死循环，摆脱这种线性ROI的关系呢？笔者认为提高自动化测试用例的编写效率，才是团队能更快从自动化测试的投资泥潭中脱身，更快迎来Break-even Point, 形成自动化测试的正反馈循环的不二法门。这也是笔者对于建设所谓的自动化测试平台一直不甚感冒的原因之一。因为很多此类平台其实专注于管理诉求，忽视“用例编写效率提升”这一核心用户体验，只是提供了在UI上编写用例的功能而已，相较之下其用例编写效率甚至不如传统的Excel，甚至还有团队为此开发了类似“导入Excel/CSV自动化用例”这样的功能。

而通过接口引用（不用写URL/入参key）、预置入参数据(不用写入参value)、预期结果录制生成（不用写assert）等类似的举措，则可以一定程度上提高用例编写效率。但整体上，这些举措还是在传统框架内做着局部的优化，其效果还只是抬高了ROI的斜率而已。

实现非线性ROI的举措

那么，有没有什么跳出框架，通过颠覆性改进实现非线性ROI的方法呢？目前比较有成效的技术有诸如流量录制回放、日志反演等通过消费可观测数据来达到快速、零成本生成自动化用例的目标。业界也有类似 JVM-SANDBOX-repeater以及月光宝盒等基于repeater的二开轮子。笔者也做过一款简易的面向开发人员的录制回放工具，感兴趣的读者可以参考《录制回放实现测试用例自由》。当然，此类的测试用例主要还是适合于单个微服务的单元测试和集成测试。

此外，也可以通过MBT等方式来生成用例，这类方案的一个难点是Test Oracle，也就是预期结果的自动生成。因此此类方法也更适合用于一些异常测试的场景中,或者是通讯协议测试等特定的业务领域。

当然现在的软件工程已经进入了LLM的时代，各大公司也在投入资源研究测试用例的自动生成。当然目前来看主要还是围绕着手工测试用例的自动生成（甚至主要还是测试点，没到具体的步骤、数据）。对于自动化用例来说，主要是单元测试用例和单接口测试用例。对于系统测试用例，涉及多个步骤、上下文设定等任务的方案还比较少见。但是相信随着DevOps运动的持续深入，整个研发过程的数字化水平的提升，叠加了LLM能力的“数智化”测试用例生成方案相信会越来越多。

问题2-自动化测试不能发现缺陷

关于自动化测试最常见的诟病是自动化测试不能及时、全面地发现缺陷。读者也可以统计一下自身测试团队发现的缺陷中，自动化测试用例的占比。（笔者也专门写过一篇文章来讨论这个问题）

笔者认为，自动化测试不应成为一项后置任务，而是应该成为一种工作方式，并最终成为测试用例执行的唯一或者主要的方式。在前面笔者提到过一种设置专门的“翻译手工用例变成自动化用例”的所谓测试开发岗或者自动化测试岗。由于很难发现缺陷，此类岗位的价值也经常受到挑战。

其实大家也都知道，去嚼别人嚼过的甘蔗，再怎么努力也榨不出太多的汁水。

只是在以往的实践中，新功能的测试活动和自动化测试用例的编写往往是两个活动，后者往往是有一定的延迟的。这是自动化测试会给人造成“很难”发现缺陷的印象的根本原因。因为新的缺陷往往都是新的系统改造需求带来的。软件测试的一大流派就是基于风险的测试，也是这样一个道理。

“自动化测试要发现缺陷”这个目标，其实应该转换为”能否将（手工）测试用例的首次执行是按照自动化测试的方式来执行？”这样的目标。你的用例的第一次执行，是用手点的，还是在IDE里或者流水线里调起的？

“手自一体”的测试模式

笔者曾经在某个核心系统的测试中推行过“手自一体”的测试模式。核心系统天然是可以独立运行的系统、通过接口与外部进行交互，包括行业协议接口、配置文件接口和数据库接口。测试用例在设计时就是按照自动化用例进行设计，当前前提是做好环境、配置尤其是数据的维护工作。用例在首次执行时，测试人员判断是否符合测试预期，如果不符合预期，则报告缺陷。如果符合预期，则将该用例纳入用例库，作为自动化用例进行回归。这种方式改变了过去团队先手工测试一遍，然后再在下一个迭代时再进行实现自动化的模式。

如果说团队已经实现了TDD/BDD/ATDD，则更加符合上述特征，因为自动化测试的设计和执行的时机更为提前。相信在这样的团队中也不太会有人关注到底自动化测试应不应该发现缺陷。因为自动化测试就是他们主要甚至是唯一的用例执行方式。

而突破了自动化测试用例自动生成的技术阻碍的团队，也可以使用类似流量录制回放等方式更顺滑地实现“手自一体”，通过按需录制手工测试人员的测试过程，自动形成可以重复使用的自动化测试用例。

问题3-拥有了超出团队维护能力的自动化测试用例

在通过测试用例编写的自动化之后，用例的产生不再是瓶颈，团队获得自动化测试用例的成本已经接近于0。在这个情况下，工作量的洪峰来到了测试执行结果的分析上面。

跟其它检测类似，自动化测试也存在“误报”和“漏报”的问题。

由于测试用例的巨大数量，即使是小概率的假失败，也会有相当数量的失败用例需要人工排查。然而因为这些是假失败用例，其排查结果必然是一场“死亡行军”，整个过程必然是充满压力，但是只会给团队带来挫败感。这是团队的自动化测试运动在启动之后会遭遇的最大陷阱。很多的自动化测试其实是在团队努力生产了过多的自动化测试用例而超越了他们的维护能力之后进而放弃整个自动化测试的工作，因为再也没有人有这个勇气去修复那些假失败的用例了（破窗效应）。

这个情况下，团队必然要考虑引入测试结果的自动化分析，以具备对“假失败（误报）”用例的判定能力，并持续提升其可信度。毕竟因为对”假失败“的误判可能会直接带来线上缺陷。

还有一些其它的因素会造成用例集不可维护的情况，如不合理的用例结构（过多的UI自动化用例）（（这里要给 云大的新作《分层自动化》带个货 ））、团队人员的变动（裁员裁到动脉或者核心人员调岗/跑路）、应用归属的交接（用例集从一个团队交接到另一个团队）、架构升级、技术栈转型（用例集需要大面积维护更新）等等，一个或者若干个冲击之下，就有可能导致自动化测试的溃败。甚至笔者都见过因为一个接口的向下不兼容（新增必填字段）就导致了数百个用例需要维护的情况。加之团队为了追求自动化测试用例数量，盲目新增用例，但是未将用例纳入持续测试的流水线，最终导致大部分用例无法执行最后丢弃的情况。

最后用KIMI来写个点评作为总结：

1.问题识别准确：文章成功地识别了自动化测试中的三个主要问题：测试用例编写的及时性、自动化测试发现缺陷的能力、以及自动化测试用例的维护能力。这些都是自动化测试实施过程中经常遇到的实际挑战。

2.深入分析原因：作者不仅指出了问题，还深入分析了导致这些问题的原因。例如，对于“来不及写自动化测试用例”的问题，文章分析了自动化测试用例编写的线性投入产出关系，以及团队可能采取的不恰当应对措施，如过度依赖人力投入。

3.提供解决方案：文章不仅停留在问题识别和原因分析上，还提供了一些可能的解决方案。例如，通过引入流量录制回放、日志反演等技术，以及利用机器学习模型自动生成测试用例，来提高测试用例的编写效率和质量。

4.强调测试用例的重要性：文章强调了测试用例在自动化测试中的核心地位，指出自动化测试的成功很大程度上依赖于已有的高质量测试用例。这一点对于很多团队来说是一个重要的提醒，即在追求自动化的过程中不应忽视测试用例本身的价值。

5.提倡“手自一体”的测试模式：文章提出的“手自一体”的测试模式是一个创新点，它鼓励在测试用例首次执行时就考虑自动化的可能性，这样可以更早地发现问题并将其纳入自动化测试流程。

6.对自动化测试平台的批判：作者对一些自动化测试平台的批判性思考也是值得关注的，指出了这些平台可能过于关注管理诉求而忽视了提高用例编写效率这一核心问题。

7.对未来趋势的展望：文章对自动化测试的未来趋势进行了展望，特别是在LLM（大型语言模型）时代，测试用例自动生成的可能性，这为读者提供了一个前瞻性的视角。

总体来说，这篇文章为自动化测试的实践者提供了深刻的见解和实用的建议，有助于团队避免常见的陷阱，并提高自动化测试的效率和效果。

最后： 下方这份完整的软件测试视频教程已经整理上传完成，需要的朋友们可以自行领取【保证100%免费】

软件测试面试文档

我们学习必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有字节大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。