扫码阅读
手机扫码阅读

很不幸,自动化测试永远只能是必要非充分条件

56 2024-03-29

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

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)、实例化需求都有助于自底向上提高测试覆盖率,应该成为规范和习惯。

不服来辩

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

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

原文链接: http://mp.weixin.qq.com/s?__biz=MzI1MjQ3NzE2Mw==&mid=2247484368&idx=1&sn=518ab11c7080d406c340c5dd17b32f4b&chksm=e9e26854de95e14213e781ed207a0377ac6ea13a5313ec88564267e8ea0d8016ec42e2f60953#rd