对于敏捷测试，通过测试影响分析快速失败

“快速失败”是敏捷的核心。 团队希望持续集成（CI）能够尽快提供有关其最新更新的反馈。 CI测试结果是开发人员用来确定继续进行下一个开发任务是否安全或是否无意中破坏了用户逐渐依赖的功能的主要晴雨表。

通过在CI期间进行更广泛，更有效的回归测试，您很可能在引入关键问题后立即发现它们，这是最快，最轻松，最便宜的解决方法。 但是，考虑到大多数敏捷流程的构建频率，根本没有太多时间可用于测试执行。 开发人员期望在几分钟内获得反馈，但是大多数回归测试套件（尤其是在Global 2000组织中）要花费数小时（或几天！）来执行。 这似乎迫使人们做出权衡：解决CI缓慢或缩减测试规模的问题。

CI变慢会影响所有等待审阅，扩展，记录和测试新集成功能的团队成员的工作效率。 结束打印的最后期限越近，每分钟的等待似乎就越痛苦。 当然，您可以（并且应该）通过并行/分布式测试执行和类似技术来加速该过程。 但最终，如果你想加快大型企业测试套件的执行，你将需要什么不需要测试每个构建要执行一些艰难的决定。

加快（和缩小）测试的方法

加快回归测试的一种常见方法是大幅削减端到端测试 。 这是一个巨大的错误。 正如我在过去的专栏中所提到的，我知道单元测试对于暴露实现错误非常有用。 但是，我只是看不到单元测试捕获真正影响最终用户的问题，这些问题主要是集成问题。 如果您跳过由真正了解该领域的专业测试人员设计的端到端测试，则不可避免地会错过很多直接影响用户体验的问题。

基于风险的测试是另一种“测试加速”策略，在提供令人印象深刻的结果方面拥有良好的记录。 但是许多组织避开了这种方法，因为他们担心这种方法需要太多的开销。 没有。 我将在下一专栏文章中对此进行详细探讨，但总而言之：除非您碰巧拥有无限的时间和资源， 否则必须使用基于风险的优先级来指导您的测试用例设计和测试执行工作。 否则，您的业务将面临太大的风险。

测试影响分析

对于本专栏，我们将重点关注敏捷世界中开始引起关注的一种方法：测试影响分析。 这项技术由慕尼黑工业大学的CQSE分支机构率先提出，它通过应用以下两个主要原理，Swift暴露了自上次测试以来添加或修改的代码中的问题：

• 将所有回归测试（甚至是端到端回归测试）与代码相关联，并仅选择与最新一轮代码更改相关的测试。 为什么要浪费时间执行无法发现新代码或修改代码中缺陷的测试？
• 订购基于他们的检测问题，并优先执行是最容易暴露缺陷的人的可能性的回归测试。 如果您的构建被设置为在第一个报告的测试用例失败时失败，那么您最好尽快达到这一点。

这使您能够在很短的时间内找到大部分缺陷。 实际上，研究表明，这种方法在完整测试执行时间的1％内即可发现80％的错误构建，而在完整测试执行时间的2％内则可发现90％的错误构建。 （由CQSE进行的这项研究分析了专有和开源代码，并涵盖了为商业信息系统和嵌入式系统编写的软件。）换句话说， 您可以将测试速度提高100倍，并且仍然可以发现大多数问题 。 是优化连续测试的理想选择。

显然，这种“快速失败”的新方法会导致更严格的反馈循环-这意味着失败的构建可以更快地得到解决，而工作构建则可以更快地交付。 它还通过其他几种方式加快了敏捷团队的速度：

• 使用测试<>代码相关性，可以更轻松地确定需要在哪里添加其他测试，以及何时已实现足够的代码覆盖率。
• 测试<>代码相关性还简化了缺陷修复过程。 尤其是对于端到端测试，查找导致测试失败的代码就像在大海捞针一样。 通过这种相关性，您可以获得从检测到问题的测试序列到负责该问题的代码的精确路径。
• 通过将更多且更有效的测试压缩到短时间内，可以减少在过程后期和交付后报告的缺陷数量。 最终，这将导致更少的时间浪费在错误修复和返工上，更少的中间打印中断，以及更多的资源专注于创新。

了解有关测试影响分析的更多信息

测试影响分析可以应用于任何类型的测试，包括单元测试（例如JUnit）和自动功能测试（Selenium，我公司的Tricentis Tosca等）以及手动测试。 通过测试影响分析，可以为每个测试运行选择一组专门的测试用例并执行：

1. 静态分析确定自上次测试运行以来已修改或添加了哪些代码。 该新代码或修改后的代码将可视化，以方便覆盖范围跟踪。
2. 动态分析将回归测试套件（理想情况下被设计为专注于最大的业务风险）与该版本中的新代码或修改后的代码相关联。
3. 在此测试运行中，消除了不涉及新代码或修改代码的回归测试。
4. 附加分析确定哪些测试最有可能暴露新的或修改的代码中的缺陷。
5. 对其余的测试进行排序，以便最有可能暴露出缺陷的测试被首先执行。
6. 以最佳顺序执行测试，然后将所有已执行测试（单元测试，端到端测试等）中合并的相关代码覆盖范围与新的或经过修改的代码映射进行可视化，从而轻松发现覆盖范围。

From: https://www.infoworld.com/article/3305326/for-agile-testing-fail-fast-with-test-impact-analysis.html