敏捷开发中不为人知的小秘密
当目标确实是更准确地投放市场时，敏捷通常会误售给高级管理人员，以此来缩短产品上市时间。然而，我们没有告诉任何人的小秘密是，这实际上是有代价的……上市时间变慢了！是的，我们发布的频率更高（即“更快”），但最终要花更长的时间才能将完整的功能推向市场。当我们将问题分解成更小的部分时，为什么要花更长的时间呢？好吧，到目前为止，最大的罪魁祸首是后期缺陷检测和降低风险的措施所带来的瓶颈。
增量代码更改（尤其是它们对测试和整体系统稳定性的影响）使敏捷开发的许许多多速度降低了。由于质量检查/测试着重于验证所实现的新功能，每个sprint通常以一个短划线结尾。然后，由于缺乏对代码更改所产生的间接影响的了解，因此组织需要在发布时进行完全回归。这通常会在周期后期发现许多问题，从而导致工作时间过长和难以做出业务决策。
但是，一定有更好的方法！
关注风险
由于当今代码库的复杂性，每一个代码更改（无论多么无害）都会微妙地影响应用程序的稳定性，并最终“破坏系统”。这些意想不到的后果是无法通过人工检查发现的，因此测试对于降低它们所代表的风险至关重要，但是除非你了解需要重新考虑的内容，否则你将无法实现有效的测试实践。如果每个sprint测试过多，那么你将失去敏捷开发带来的许多收益。如果测试太少，则会使自己处于后期检测周期。
需要一种方法来确定需要重新执行哪些测试，并将测试工作（单元测试、自动功能测试和手动测试）集中在验证受最新更改影响的功能和相关代码上。通过结合使用Parasoft的代码分析引擎（Jtest，C/C++test，dotTEST）和Parasoft DTP中的流程智能引擎（PIE），开发人员和测试人员可以了解两次构建之间的代码库变化，并深入了解敏捷的承诺。这称为基于变更的测试。
基于变更的测试（CBT）使Sprint持续进行
关键是要知道可以使用哪些测试来验证代码更改，这是Parasoft的相关覆盖范围交付货物的地方。通过了解这些文件中的哪些已更改以及哪些特定测试接触了这些文件，DTP的分析引擎（PIE）可以分析两次构建之间的差异，并确定需要重新执行的测试子集。下图显示了DTP仪表板中的小部件，该小部件显示了CBT分析结果的饼图。此图表显示了可用于验证代码更改的测试子集，按测试状态分类：通过、失败、不完整和需要重新测试。
通过、失败或不完整的状态表示这些
此高级视图表明，已修改的代码引入了许多故障，并且尚未执行但可以用来进一步验证更改的许多测试。
通过、失败或不完整的状态表示这些测试已经针对构建执行，作为全自动测试过程的一部分（例如，CI驱动的构建步骤），或者在测试新功能时进行。但是，状态为“重新测试”的测试是尚未执行的手动测试，或者是自动化运行的一部分，这些测试未计划在当前sprint期间执行。
深入研究图表，我们可以快速了解代码中发生了哪些更改，现有测试如何与这些更改相关以及需要集中测试资源的地方。
从这里，我们可以创建一个测试计划，以最高的优先级处理失败和不完整的测试用例，并使用重新测试建议来重点安排其他自动运行的计划并确定手动测试工作的优先级。
DTP中的Violation Explorer提供了用于定义和管理测试计划的界面。浏览测试和结果，资源管理器显示每个测试用例的详细信息。使用优先级视图来设置测试元数据，用户可以为每个测试用例分配所有者，操作并设置优先级。
如何应用CBT工作流程
那么，这如何有助于敏捷过程？简而言之，这是一种快速简洁地确定需要在何处应用测试资源的能力。通过仅测试需要的内容而不是所有内容（或只是猜测），测试时间大大减少了。质量提高，sprint按时完成。
在实践中这将如何工作？尽管基于变更的测试（CBT）分析的结果可以以几种不同的方式使用，但我建议以下工作流程是最有效的方法，以专注于基于sprint的测试工作：
- 确定你的基线。这是你要用于重点重新测试的已完成测试工作的内部版本。通常，这是从先前的sprint或发行版的末尾开始的构建。
- 执行单元测试和可用的自动化功能测试。将自动化测试集成到你的CI流程中，并根据最新版本衡量/监控CBT结果。这使你能够查看自己的工作方式并计划重新测试的工作。
- 缩小重新测试差距。根据目标构建进行测试，并将重新测试工作的结果提交回去进行分析；并重新审查CBT的结果。
- 重置基线。在sprint结束时，将基线移至你已完成测试的内部版本，并为下一个sprint重置/重复。
总结
我们需要在敏捷开发中提高测试效率。测试是持续交付的主要瓶颈，由于错误的测试，在发布周期结束时发现了太多缺陷。为了获得最佳结果，请将测试工作重点放在你所做更改的影响上，并释放敏捷性以加快向市场的交付速度。