问敏捷中是否存在可追溯矩阵？

EN

可测性矩阵是一种工具。它没有任何继承价值，但它可能是映射测试和需求之间某种关系的最简单方法。与任何其他工具一样，如果它看起来运行良好，就使用它。如果其他更合适的话，就用它吧。如果该工具几乎符合您的需要，请修改它以提供您需要的信息。

如果测试是在实现后很长一段时间内完成的，那么可能需要某种类型的跟踪来确保所有相关的内容都能被覆盖，并且所有的事情都是他们应该做的。但是，如果它们是在实现时进行测试的，那么确保它们与预期的匹配要容易得多。自动化的测试试图确保特性在很长一段时间后也能工作，它应该代替手动跟踪需求/测试链接的需求，因为它们一直都在被测试。在最好的情况下，即使是大量的坏测试也很容易通过在一个地方改变事物来解决，如果遵循干燥原则(不要重复自己)。

我从未见过这样的矩阵，也从未听说过。

你的目标是：

哪些需求几乎从未被测试过，哪些需求被测试得非常频繁？

可通过敏捷/技术手段实现：

• 使用行为驱动开发作为用户故事的自动测试，以验证它是否完整且仍然有效。
• 有一些代码覆盖工具可以显示哪些产品代码被测试所接触(而不是)。

然而，我不知道如何回答你的第二个问题。

对特定需求的更改会导致系统中大量测试的修订吗？

在敏捷环境中，您可以(应该)用它们的敏捷等价物来替换这些传统工具。

您可以使用您的测试，而不是使用某种文档格式的矩阵(例如:带有需求和实现位置的Excel表)。

对于每个需求，您将实现一些测试(假设TDD)。然后，这些测试可以直接映射到代码(它们涵盖了哪些代码部分)。然后，这可以用作一个敏捷的双向跟踪工具。

虽然我在实践中从未见过这件事，但这可能会很好。即使是传统的矩阵也是很少见的。