软件测试工具与自动化在维护和成本方面有哪些基本问题需要注意？

京东购买链接：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%。但在最糟糕的情况下，所有测试工具都失效，并且不会被使用。此时，将不再运行自动化测试，而是进行潦草的手工测试，随后便匆忙发布。