迷雾中的自动化测试体系建设_拨开流量录制回放从基建到业务落地的迷雾-CSDN博客

本文链接：https://blog.csdn.net/CODING_devops/article/details/122296785

本文探讨了自动化测试在DevOps转型中的重要性，强调了自动化测试的价值并提供了实践策略。文章指出接口测试是初期首选，流量录制回放和UI测试用例的录制各有适用场景。同时，提出了自动化测试用例的“聪明”执行，通过业务驱动测试和精准测试提高效率。CODING的自动化用例库被提及作为实现这一目标的工具。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

本文作者：程胜聪 - CODING 测试域产品总监

在业内如火如荼的 DevOps 转型过程中，自动化测试始终是热点之一，毕竟提供快速质量反馈是达成 DevOps 目标的关键。于是，作为测试领域的“皇冠”，自动化测试的落地实施始终为人们所关注。但是落地当中产生了种种问题甚至是争论，经久不衰，无形中给自动化测试体系建设蒙上了层层迷雾，让人疑惑。下面我们就一些踩过的“坑”进行探讨，期望这些经验分享能够有助于揭开迷雾、看清方向。

要不要做自动化测试？

在软件工程理论当中，测试相对开发来说是个“辅助”的角色，而软件交付的产物也不必包括测试的产出。随着软件研发过程的复杂度提升，虽然还是辅助角色，而且其价值仍然难以单独衡量，但是测试对质量保障的作用已经深入人心，以至于从 10 多年前开始，已经没有人会挑战测试作为研发体系中基本角色的存在了。

然而类似的，作为“辅助的辅助”，测试领域中的自动化测试又开始面临着同样的质疑：自动化测试到底有没有价值？这个问题在 10 多年前开始被频繁提出，而且难以回答。作为处于辅助地位的投入，人们肯定会密切关注其成本大小以及跟收益的对比。自动化测试最开始出现，是为了替代重复性的手工操作，从而节约回归测试的人力成本，于是要获取正向收益的前提是执行的次数够多：
自动化收益 = 迭代次数 x（手工执行成本 – 用例维护成本）- 用例编写成本

所以，在 DevOps 时代的频繁发布测试场景下，自动化测试的价值得到了充分展现。要不要做自动化测试的问题如今已经不会造成困扰，因为当下业内已经形成了一致的认识：**自动化测试是持续测试的基础，是 DevOps 时代中不可或缺的实践。**此外，由于自动化测试的执行效率很高，体现出来的时间成本优势更是明显，甚至比成本优势更能戳中这个快速发布时代的痛点：因为不这样做的话，我们会越来越难以应对短周期发布所需要的快速有效验证。

有策略地开展自动化测试

测试体系建设需要分层策略指引、接口测试往往最优先

罗马不是一天建成的，为了达成自动化的目标，进行自动化测试体系的建设是需要投入资源和人力的。因而在具体落地过程中，我们需要充分考虑 ROI，来设计符合实际情况的目标达成路径。自动化测试确实有很大价值，但不代表我们应该无节制地投入到各种类型的自动化测试当中：自动化测试是为了验证既定逻辑是否符合预期，在需求变更频繁的场景下，自动化代码的维护成本不可小觑。所以我们需要合适的策略，来指引自动化测试的实施——金字塔模型。

不少人对金字塔模型的第一印象，是其给出在 3 种测试上的投入占比建议：单元测试最多、接口测试居中、UI 测试最少，比如 70%、20%、10%。但更为重要的是，Mike Cohn 提出了对测试进行分层的理念，以及给出了每个层级的测试优缺点：越接近用户使用界面的高层次测试，粒度越粗，效率越低，写的测试应该越少；反之越接近底层代码的测试，粒度越细，效率越高，应该写的更多，也应该执行得更频繁。

而在实践当中，每个企业面临的场景不同，投入情况也不一样。比如现实情况可能并不是金字塔而是纺锤形状的，中间的接口测试占比最高。种种实践表明：**在自动化测试建设的初期，接口测试往往是团队开展自动化测试的首选。**这是因为接口测试兼备执行效率和体现业务价值两方面的优点，在这个领域进行资源投入较为容易被技术团队和业务团队共同接受。而且由于接口定义的稳定性也较高，其维护成本也是可控的。所以相对单元测试和 UI 测试来说，接口测试的投入产出比可以说是最高的。