“ 对自动化测试的合理预期非常重要。”



01 关于自动化测试的争论



关于自动化测试，一直是我们部门多年的痛。



我们的核心系统是第三方的供应商系统，大量复杂的需求需要在这套系统上实现，而这些需求的开发周期长，各项目为了能按自己的节奏开展，都要求供应商在各自的分支上进行开发。但是由于生产环境只有一套系统，这就不可避免要在上线前进行分支合并。



大家可以想象，这种大范围的分支合并必然是高风险的，基于多年的经验，我们对供应商的交付质量信心并不那么放心，因此合并后的回归测试必不可少。



但是这种大规模的回归测试如果手工进行的话，则起码需要耗时数周。因此，如何借助自动化测试来加快这个过程，成为一个重要议题。



然而，在我们的内部讨论中，对于自动化测试的预期并没有统一。



有人认为，自动化测试就是把项目累积的人工功能测试全部自动化；有人认为由于供应商系统对我们来说是黑盒子，我们只能通过调用UI来测试，但UI测试自动化成本高、执行时间长、脆弱，一味把所有功能测试自动化并不现实，即使花重金实现了，今后也会面临执行周期长、维护成本高和测试结果不稳定等问题，应该只精选少量核心的测试用例进行自动化。



02 测试金字塔



其实关于自动化测试，业内早就总结出了测试金字塔原理。不同类型的自动化测试的执行速度和投入成本是不一样的。





从上往下，最上层的UI测试，速度慢，容易因UI变动需要变更，只适合少量的测试用例。



大部分现代系统的设计都遵循MVC模型，也就是大部分的业务逻辑应该构建在后端，因此中间的服务层测试应该能覆盖主要功能，而且服务层测试应该是通过调用接口来实现（调用Controller或API），测试速度远比UI测试快，稳定性较UI测试高，接口变动频率通常不太高，测试维护成本也比UI测试低。



最下层的单元测试成本最低，执行最快，应该高筑墙、广积粮。



然而我想强调的是，即使你按照测试金字塔构造了三层测试框架，你依然无法得到充分的测试覆盖率。



“覆盖率”最高的单元测试，虽然可以任由开发人员发挥，不断增加边界测试以覆盖各种极端场景，但其针对的是代码中的某个或某些方法，无法反映与用户需求和功能直接相关的覆盖关系。也就是说，高代码覆盖率的单元测试并不等同于系统整体的测试覆盖情况。



服务层测试也无法模拟用户真正使用系统时的场景。而且由于它的自动化投资相对单元测试高，执行速度较慢，对测试环境、环境数据也有要求，是比较重的测试过程。测试用例越多，投入越高，执行时间越长。我们投入测试自动化的原始目的，是为了能够得到快速反馈，如果反馈周期过长，就无法满足这个目的。因此，服务层测试势必只能选择主要功能的测试用例。不可能也不应该做全覆盖。



UI测试，前面已经说过，自动化成本高、执行时间长、脆弱，对测试环境、数据也是有严格要求，只能精选最核心几个测试用例作为冒烟测试。功能覆盖率必然要低。



03 自动化测试只能是必要条件



综上所述，我们对自动化测试的合理定位应该是，它只能是必要非充分条件，也就是说，自动化测试的结果只能反映这么一个事实：测试失败代表系统一定有问题，测试全部通过不能代表系统没有问题。



只有理解和认可这样的定位，才能对自动化测试做出合理的投资回报预期。要在这种限制条件下在测试用例选择上做减法，选择最重要的测试用例。



在自动化测试的基础上，手工测试的补位依然不可或缺，两者是互补的关系，而不是相互替代的关系。



因此，我的建议是：



1. 尊重测试金字塔原理的客观规律；

2. 单元测试——落实测试驱动开发（TDD），成为编程习惯，主要用来提高开发人员的交付信心。尽量采用Mock和内存数据库，避免对测试环境产生依赖；

3. 服务层测试——落实验收测试驱动开发（ATDD）或实例化需求，在需求完善阶段就编写好验收测试用例，形成闭环，并通过服务层测试自动化关键的验收测试；

4. UI测试——选择最核心的功能测试作为每次部署的冒烟测试。



回到文章开头的故事，由于供应商系统对我们来说是个黑盒子，单元测试是供应商开发人员的责任，如果供应商系统没有提供API供我们调用、或者我们无法通过调用系统的Controller模拟UI操作来实现服务层测试，我们只能依赖UI测试，这就更要求我们对测试用例进行精选。



04 总结



1. 对自动化测试要有一个合理的预期，它只能是必要非充分条件，必须与其他的手工测试形成互补；

2. 基于测试金字塔原理，我们对于单元测试、服务层测试、UI测试应该分别有正确的定位，特别对于服务层测试、UI测试这些比较重的测试过程，对测试用例的选择必须做减法；

3. 测试驱动开发（TDD）、验收测试驱动开发（ATDD）、实例化需求都有助于自底向上提高测试覆盖率，应该成为规范和习惯。



不服来辩。



更不幸的是，其实，不管我们多努力，测试本身也只能是必要条件，而不会是充分条件，惊不惊喜、绝不绝望？



因此面对复杂的软件问题，光靠追求一切可设计、可控制、可预测，通过精准来规避风险的物理学思维是不够的，我们还需要生物学思维作为补充。如果你还没有听说过生物学思维，请留意我今后的文章。



关于作者





刘华（Kenneth）

• 就职于世界500强银行，负责基金服务业务软件开发与交付

• 敏捷、精益、DevOps专家

• 精通极限编程、Scrum、看板方法、测试驱动开发、持续集成、行为驱动开发、DevOps工具栈

• 曾在GDevOps、DevOpsDays Meetup、中国软件技术大会、ArchSummit等论坛发表主题演讲

• 著有《猎豹行动：硝烟中的敏捷转型之旅》一书



小说体敏捷/DevOps转型教科书和实战经验分享