彩票走势图

通过了解需要进行新测试的地方，智能地使用代码覆盖率指标将测试工作集中在最需要的地方，并创建可维护的测试套件。

敏捷的主要宗旨之一是确保增量交付物的可交付质量，同时响应不断变化的需求。但是，在平衡新功能测试同时验证现有功能的正确操作方面所面临的挑战使许多敏捷开发团队陷入了扩展，扩展测试套件的创建，管理和维护困境。最后，如果没有适当的信息财富，那么加速敏捷和对产品质量和安全性都充满信心将变得非常困难。

为了了解所执行的风险缓解水平，查看测试期间执行的代码量是一个有用的指标，但是它经常被滥用，并且从宏观角度来看，它并不是质量的良好指标。在本文中，我将向您展示如何智能地使用代码覆盖率指标，通过了解需要进行新测试的地方，将测试工作集中在最需要的地方。我们还将介绍一些创建可维护测试套件的最佳实践。

如何考虑有用的代码覆盖率

代码覆盖率不是确定您何时有足够测试的“数字”，而是对于指导团队关注的重点非常有用的“数字”。

不幸的是，它经常被错误地用来管理团队，因为他们只关注人数本身并针对代码库按特定百分比射击，例如，使用诸如“我们必须拥有80％的覆盖率才能发布”或“覆盖率”之类的策略应该与先前的版本相同或更高。”

这种方法的问题在于，获取和维护目标保险单号本身很困难且耗时，因此我们盲目地努力争取该保险单号，没有人会花时间问一些重要问题，例如：

• 我们涵盖了哪80％？

• 测试工作会验证质量并降低交付应用程序的风险吗？

• 随着代码的发展，我将如何维护测试？

正如我在上一个博客中所讨论的那样，代码库中的每个更改都代表引入风险，了解每个变更对现有代码的特定影响，以及了解如何减轻这种风险都很重要。

通过识别代码库中的更改，并使用代码覆盖率将测试与这些更改相关联，可以根据需要进行重新测试的位置来创建最佳测试计划（在此处了解有关基于更改的测试的更多信息。)

但这并不能涵盖所有风险。显然，我们仍然需要为新功能创建测试，但是现有/旧版代码又如何呢？我们讨论过的许多组织的目标是60-80％的代码覆盖率，但实际上要达到50％以上是很困难的。因此，很有可能现有的测试用例不会覆盖对现有代码的更改。宏覆盖目标仅关注于保留或逐步增长，就无法避免将回归引入“已经使用多年”的传统功能。

相反，通过仔细查看覆盖率详细信息，可以快速识别出未覆盖的特定已修改行，因此您可以将团队集中在需要创建新测试的位置。此外，利用测试用例与它们执行的特定代码之间的可追溯性，您可以识别出可以重复或扩展以覆盖更改的潜在测试用例。

通过专注于实现已修改代码的100％覆盖率，而不是团队任意设定的“总覆盖率80％”的目标，团队可以在降低新代码风险的同时更加高效，同时消除影响整体项目稳定性的因素（例如，对旧代码。）

修改后的代码覆盖范围

使用Parasoft DTP的Modified Code Coverage小部件（Parasoft DTP的过程智能引擎（PIE）的分析“切片”）可以测量此智能代码的覆盖率。在这里，您可以轻松查看在两个内部版本之间添加或更改的代码的覆盖范围（例如，当前内部版本和您选择的目标内部版本）。例如，图1显示了这样的小部件。在此示例中，在两个版本之间添加或更改了177行代码，并且其中的109行已经过测试，即61.6％。这意味着有68行新代码或更改的代码未经过任何测试，因此尚未通过验证，并且在代码库中代表风险。

此小部件后面的是修改后的覆盖率报告。该报告提供了有关缺少适当测试的代码的确切详细信息。这是开发人员和测试人员集中精力所需要的关键信息。图2显示了这样的报告，其中可以根据更改数量或缺少代码的代码对修改后的文件进行排序，未发现的修改行用红色标记。

该报告回答了“我缺少哪些测试？”这一问题。根据每个构建的此处信息，可以创建测试计划。

要创建哪种类型的测试？

一旦确定了缺少测试的代码，实际上就需要开始工作并创建测试以填补空白——但是，您将创建哪种类型的测试？测试金字塔（由Martin Fowler和Mike Cohn宣传）概述了如何创建有效，可管理和可维护的测试组合。通过最大程度地减少脆弱的UI级别测试，并专注于坚实的单元测试基础（以全面的Service/API级别测试作为后盾），您可以构建可扩展、可维护并且可以连续执行的测试策略。

我们不会在此博客中介绍创建单元或API测试的详细信息，但是您可以查看我以前的有关单元测试的博客，并关注有关Parasoft SOAtest的博客：用于简化API/服务级别测试的创建。

结论

代码覆盖率是一项重要指标，但是它经常被滥用和滥用，尤其是在用于衡量质量时。为了从代码覆盖范围中获取更多价值，请利用Parasoft DTP的分析智能来检测需要进行新测试的地方，降低风险，集中测试并优化实现质量目标。