《软件测试策略》——工具与自动化的基本问题（二）

京东购买链接：https://item.jd.com/10205955087769.html

 

2.3 雷区回归问题：覆盖模型

我们现在讨论的自动化测试是点击式的检查性测试，通过工具模拟并执行用户操作，检查操作过程中可能出现的问题。当然，对于没有太多随机变化元素的测试，单元测试和脚本测试也可以完成。模型驱动和其他一些测试方法好像可以应对随机变化元素的测试，但这些方法因为存在一些弊端，最终并没有得到广泛应用。

当前，也有一些人编写了他们所谓的测试代码，我们暂且不论他们是如何实现的。假设有一个电子商务系统，测试肯定需要模拟用户的一系列行为，例如创建账户，商品搜索，找到产品，将其添加到购物车，付款购买。

但对于搜索功能，早期的自动化测试并不能直接带来价值。对于多数自动化工具而言，在大部分时间里由于各种原因，搜索功能可能会出现搜索按钮找不到、搜索引擎本身存在 bug、搜索结果不一致或结果数据不断变化等问题，此时就需要和开发人员不断沟通和调试。直到这些问题都被修复，搜索功能稳定运行后，自动化测试才真正开始发挥作用，在此之前，它并不能提供有效的价值。故自动化工具的真正价值是从开发人员修复完所有问题后开始的，即回归测试。而回归测试的目的就是检查原有功能是否可以正确运行。例如点击第一页面上的元素 A 跳转到第二页面；第二页面中有元素 B，点击可跳转到第三页面。在某次迭代中，第三页面正在开发时，元素 A 突然消失，导致无法再进入第二乃至第三页面。

在自然增长的代码库中，代码之间相互影响，甚至破坏逻辑是一件很常见的事情，此现象也被称为“大泥球”（big ball of mud）现象，关于大泥球现象可阅读 Brian Foote 和 Joseph Yoder 在 20 世纪 90 年代末发表的文章（链接 2-1）。同一代码库中，不同程序员在同一区域进行开发，大泥球现象是避免不了的。

在第 3 章，本书会简要介绍现代工程实践对于降低回归问题发生频率的益处。本节讨论的是自动化测试对于回归测试的价值。接下来，我们通过探索狗狗公园并清除狗狗粑粑的示例进行说明。

本书第 1 章就提到，不可能做到完全测试，因此也不可能创建一个输入空间映射所有可能的输入变换组合。俗话说，地图并非疆域（The map is not theterritory）。模型也是一种地图，其试图以一种近似的方式反映出实际状况，在构建时，就需要做出一定的取舍，为了可理解性而牺牲全面性。正如乔治 • 博克斯(George Box) 所说：“所有的模型都是错误的，但有些确实有用”。

在本节示例中，我们将可能的输入空间构建成一个二维网格模型。你可将其想象为一片雷区，在此雷区内，我们可以做的事情就是软件的各种操作，而地雷就是软件 bug。或者也可以将二维网格模型想象成一个有很多人遛狗的公园，随着时间的推移，遛狗人次一直在增加，未被清理的“粑粑”也在增加，于是公园里留下了很多狗狗粑粑。软件测试就好比是探索这个公园，然后发现并清除狗狗粑粑。公园就是被测软件，狗狗粑粑则是软件 bug。

因此，我们手里拿着铲子在公园里行走，行走的区域就是软件可能的输入。在此过程中，我们看不到全局。此想法来自软件质量方法公司的 Doug Hoffman，如图 2-1 所示。

在 20 世纪 80 ～ 90 年代，软件测试深受制造业的影响，非常注重稳定性、可预测性和可重复性。人们讨论的重点是如何创建测试用例，并将这些测试用例整合到一个用例库中。当涉及自动化时，人们会将用例库转换为一套可以反复执行的测试套件。类比到在公园里清理狗狗粑粑的示例中，测试套件就是在公园里预先计划好的行走路径。由于是预先计划好的，且无法做到完全测试，因此只能覆盖相对较小的区域。故首次执行测试套件，可能得到的结果如图 2-2 所示。

首次执行测试套件，可以发现几个 bug。在之后的测试中，它会不断地重复执行同样的操作，具有高度的可重复性。与人的探索行为不同，一旦存在 bug，测试脚本就会被阻塞，无法执行。如果使用录制 / 回放的方式实现测试自动化脚本，在功能正确运行之前，自动化脚本可能会被阻塞，甚至不能实现。例如添加购物车功能存在 bug，则自动化运行就会被暂停，直到 bug 被修复。故此种风格的自动化测试，唯一的价值在于回归测试。

修复完 bug 后，再次运行测试套件，结果如图 2-3 所示。

从图 2-3 中可以看到，已经修复了四个 bug，重复执行测试套件不会再发现新的 bug。故回归测试的价值在于，确保先前已修复的问题不会再次出现，以及已覆盖的路径上不会出现新 bug。如果可以跟踪项目 bug 并统计回归测试中发现的 bug 量，你会发现回归测试所能发现的 bug 量占比非常小。这也正是 Heusser关于（传统，预定义）自动化测试的准则：100% 自动化测试团队中，大多数 bug不是通过运行回归测试工具发现的，而是由人类执行其他活动（包括在创建自动化测试脚本时，被 bug 阻碍的活动）发现的。换言之，如果团队致力于实现100% 的自动化测试，那么大部分 bug 将会以低效、手工或偶然的方式发现。此时，就需要立刻停止这种不切实际的做法，转而深入研究和改进测试方法，以提高测试的整体效率和质量。

Lisa Crispin 曾经对“100% 测试自动化”作出过宽泛且合理的解释：这是一种策略，如果需要每次都遵循固定步骤，那么这些操作应该交给计算机来执行，让人力专注研究和探索可能只需要运行一次的事情，或者每次运行都略有不同。这种工作方式可以看作探索性测试，我们也曾采用类似的做法，即仔细考虑哪些测试适合自动化，哪些适合保持手工，然后只将一小部分真正需要在每次构建时运行的核心测试纳入自动化测试套件。

至此，希望读者可以对重复执行相同测试的做法持有适度的怀疑态度。下一节，将通过海战棋游戏，探讨如何根据输入空间的变化调整自动化测试策略。