《软件测试策略》中工具与自动化如何避免雷区回归问题，覆盖模型有何关键？

京东购买链接：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 量占比非常小。