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

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

 

2.5 维护问题

根据本章所述，我们可以得出一个结论：比起每次构建都改变测试策略，重复执行相同的测试所覆盖的被测程序范围显然更小。我们通过海战棋案例证明了这一观点，但并未讨论如何适时调整测试策略以提高覆盖率。

2.5.1 构建自动化测试

我们模拟了一个重复执行自动化测试的实验，很显然这种方法发现 bug 的效率依旧较低。而且，实现自动化测试还需要花费更多的精力。

我们看一个测试场景：进入 Excelon Development 网站主页，然后点击【Consulting】咨询菜单，接着点击【Contact Us】联系我们按钮，最后填写联系我们表单。使用 Selenium IDE（Selenium IDE 是一个记录和回放测试的开源工具）录制测试步骤，脚本如图 2-5 所示。

图 2-5 Selenium IDE 实现的测试脚本

表单提交成功后，检查页面如图 2-6 所示。

图 2-6 Excelon Development 网站 Contact Us 页面

值得注意的是，当前的脚本测试仅仅检查了消息发送成功后提示信息的正确性，没有进入邮箱确认消息是否真正发送到目的邮箱（这是一种常见的测试工具问题）。更重要的是，录制的脚本没有对其他任何内容进行检查，例如字体大小、表单提交时 Enter 键是否生效、左侧文本内容、字体类型或其他相关元素和功能。

正如第 1 章中所说，在完成每个测试用例后，都隐藏着一个预期结果—不会发生其他异常情况。上面的案例并不具备验证这一预期结果的能力。用迈克尔 · 博尔顿的观点来说，这种检查或许有所帮助，但它并不能算是真正的测试，仅仅是“将算法决策规则应用于对产品的具体观察”。简而言之，这类工具化测试会遗漏各种类型的 bug。

针对缺少检查的问题，我们可以通过其他一些方法进行解决。其中一种方法就是对页面进行截图，然后与基准图进行对比。但当内容有细微变化时，图片对比就会失败，此时就需要手动查看对比结果并重新设置基准图。更极端的情况下，所有内容都发生变化时，脚本就需要重新录制。如图 2-7 和图 2-8 是雅虎财经网站上关于苹果公司股票（AAPL）的两张截图，分别截取于 2022 年 11 月 2日和 11 月 14 日，相隔不到两周。

图 2-7 2022 年 11 月 2 日在雅虎财经网站截取的 AAPL 股票

注意，图 2-7 中包含 16 个指标，包括市值（Market Cap）、市盈率（P/ERatio）和交易量（Volume）等，而图 2-8 中只显示了 8 个指标，并且这些指标的位置和样式等都发生了变化。

暂且不讨论界面的检查，我们先聚焦于 Matthew 提出的三条准则：

（1）文档化测试原则：每个由人工执行的、预先设计好的、有文档记录的测试，除验证产生期望结果外，还隐含着不发生其他异常的预期。

图 2-8 2022 年 11 月 14 日在雅虎财经网站截取的 AAPL 股票

● 推论一：“不出现其他异常”的预期尤其难以实现自动化验证。

● 推论二：如果尝试借助自动化工具验证“不出现其他异常”这个隐含的预期，而且不借助 AI 技术，那么很可能会产生大量的假错误。[ 在此，我们采纳Danny Faught 的建议，采用假错误（false errors）替代误报（false positive）和漏报（false negative），因为后者容易引起混淆 。

（2）测试自动化原则：即使一个测试可以被自动化，当第二次运行时，就不再是测试自动化，而是变更检测。当然也存在例外情况，例如高容量自动化测试，以及基于模型测试。此类测试必须依赖某种自动化“先知”来判断结果是否正确。例如，一种常用的方法是将软件的前一个版本作为“先知”。

（3）自动化决策困境：工具要么检查所有可能的错误，但这样往往会产生假错误；要么只检查特定内容，但又可能忽略其他异常。要实现真正准确的测试，就需要事先知道哪些变化是错误的、哪些是正确的，而这在实践中非常困难。

当前所面临的问题是，测试维护困难，或维护跟不上程序的变化。仔细思考一下维护问题，大多数团队之所以选择进行测试自动化，是因为人工测试不能跟上频繁变更的节奏。然而，任何测试自动化工作的开展都需要重新录制脚本并通过验证，这就导致了所有交付工作暂时停滞。在最理想的情况下，这是一个跨团队协调合作的过程，通过迭代完成，总体上只会让交付速度放缓大约 10%。但在最糟糕的情况下，所有测试工具都失效，并且不会被使用。此时，将不再运行自动化测试，而是进行潦草的手工测试，随后便匆忙发布。6 周或 6 个月后，当有新的自动化测试需求时，企业便会请求咨询顾问协助。在咨询顾问问起上次的自动化测试是在哪里完成时，团队没有一个人记得。这不是一个理论性的陈述，而是真实发生过的事实。

2.5.2 全面自动化测试的风险

越全面的测试自动化，可能会带来更多的问题，因为自动化脚本更容易受到频繁变更需求的影响，而造成测试延期。代码提交后，自动化测试执行越晚，代码引入的变更就越多，就越容易出现问题。这就造成了我们所说的自动化延迟问题。自动化延迟是指自动化测试失败后，需要对其进行检查、修正并重新运行而带来的延迟。

当公司花钱引入测试工具后，最不希望看到的就是“为了运行测试，需要花费半天时间进行调试、修复和重新运行，之后才能给出测试结果”。在某些团队中，这一过程花费的时间可能远远大于半天。

此外，使用自动化工具进行测试还可能会遗漏一些错误。如图 2-9 是几年前一个真实客户的截图。在离线模式下，软件会提示“offline retry in X seconds”（离线状态，等待 X 秒后请重试）的消息，其中 X 会在一段时间后翻倍显示。但是由于程序员输入错误，原本应该显示数字的地方却出现了“%ss”。有趣的是，只有移动设备的菜单中才会出现该问题。如果使用自动化工具来检查该消息，那么测试人员很可能只会关注消息是否显示，而非确认其是否正确显示。遗憾的是，许多测试工具都未必能发现这类错误。

图 2-9 某咖啡产品主页

其实，市面上存在一些解决方案能够在一定程度上缓解这些问题，本书将在自动化动态检查规则时进行说明。提到解决方案，接下来我们来谈谈成本问题。

2.6 成本问题

试想一下，你正在领导一个尚未采用任何自动化测试工具的软件团队，当前人工测试效率低、耗时长，每一次迭代都需要耗费两周时间测试。因此，版本发布节奏缓慢，到了回归测试阶段，待测内容也往往处于非常糟糕的状态。或许你所在的团队在这方面做得很好。在我们接触过的所有团队中，都能够实现一天完成一次手工回归测试，尽管看起来非常不错，但一天一次的测试频率仍可能无法满足快速迭代的需求，也许团队希望在每次构建后就可以得到测试结果。

于是，你决定使用某些测试工具进行自动化工作，如通过用户界面实现。此想法非常不错。但是，谁来做这件事呢？

如果让当前的测试人员挤出一半时间来做，那么想要在工具化进程上取得有意义的进展将需要很长的时间。与此同时，原有的测试过程也将会加倍延迟。你最初就是因为现有的测试过程耗时太长，所以为了解决该问题，方案就是让团队成员减少在测试工具上的投入。但根据我们的经验，如果团队在测试工具化上投入的时间少于一半，那么自动化工作几乎不可能取得实质性的进展。

让测试人员来开发自动化工具还存在另一个问题，测试人员一般都不是专业的开发人员。如果工具涉及代码，测试人员编写的代码可能杂乱无章、不稳定且难以维护。在遇到难以自动化测试的内容时，如果不对脚本进行 review，他们很有可能会跳过测试这些内容。经验表明，测试设置项和条件越难，人们越倾向于跳过测试，这也意味着其中隐藏 bug 的可能性更大，这是因为越复杂的事情越难弄清楚。如果测试人员使用工具难以模拟测试，那么开发人员在开发代码时可能会更难弄清楚。难以理解的事物往往带有意外的副作用和规则，从而导致 bug 的出现。

未受过编程和设计模式培训的测试人员，很可能会创建出“大泥球”（BigBall of Mud）般的测试代码。这些测试代码运行一段时间可能不会有问题，但是一旦需要重大变更，更新这些测试代码就会变得缓慢且痛苦不堪。此时，团队可能会倾向于抛弃这些代码，或者将其搁置一旁。