在可追溯性矩阵中,需求和测试之间的联系可以帮助回答以下问题:


几乎从未测试过哪些需求,并且经常测试哪个需求?
将对特定需求进行更改吗?导致对系统中的大量测试进行修订?

在敏捷中,除了故事外没有其他要求,因此传统意义上不存在可追溯性矩阵。好吧,故事描述了需求,但是当您完成故事时,您将其关闭,然后关闭迭代,而忽略了该故事。它完成,接受并关闭。因此,也许这就是一个原因,为什么在我们用于计划和跟踪迭代以及测试的软件中没有这样的矩阵。

或者我的猜测是错误的。我很好奇您是否使用某种可追溯性矩阵(将故事/史诗与测试链接)?

我会觉得有用的一个地方是,当您获得额外的预算/迭代来更好地验证您的史诗,并且您想要确定哪些故事需要进行额外的测试时...

评论

您读过sqa.stackexchange.com/questions/3869/…吗?

#1 楼

追溯矩阵是一种工具。它没有任何继承值,但是它可能是映射测试和需求之间某种关系的最简单方法。与其他任何工具一样,如果它看起来运作良好,请使用它。如果还有其他更合适的方法,请使用该方法。如果该工具几乎可以满足您的需求,请对其进行修改以提供所需的信息。

如果在实施之后很长时间进行了测试,则可能需要进行某种跟踪,以确保涵盖了所有相关内容和内容。是他们应该的样子。但是,如果在实施时对它们进行了测试,则确保它们符合预期要容易得多。试图确保功能也能在很长时间后自动执行的测试应取代对手动跟踪需求/测试链接的需求,因为它们一直处于测试状态。在最好的情况下,如果遵循DRY原则(不要重复自己的话),那么即使在一个地方更改也可以很容易地修复很多损坏的测试。

#2 楼

我从未见过这样的矩阵,也从未听说过它:-(。

您的目标:


哪些需求几乎从未测试过,哪些要求可以通过敏捷/技术手段来进行测试吗?


可以通过敏捷/技术手段来实现:


使用行为驱动开发bdd作为自动测试供用户验证它是完整的并且仍然可以正常工作。
有代码覆盖工具可以显示测试未触及到哪些生产代码。

但是,我不知道如何回答您的问题第二个问题。


对特定要求的更改会引起系统中大量测试的修订吗?


评论


谢谢。 BDD如何告诉我从未测试过哪些需求?

– dzieciou
2012年11月2日17:04



codecovarage告诉您在测试中未调用哪些代码片段。如果您确定未经测试的代码属于哪个用户故事,则可以知道未经测试的用户故事。

– k3b
2012年11月2日17:11



代码覆盖率和故事覆盖率不是同一回事。链接代码和故事可能不是那么简单,我更喜欢黑盒方法:-)

– dzieciou
2012年11月2日17:16



#3 楼

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

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

对于每个需求,您都将实现一些测试(假设TDD)。然后可以将这些测试直接映射到代码(它们涵盖什么代码部分?)。然后可以将其用作敏捷的双向可追溯性工具。

它可以很好地工作,尽管我在实践中从未见过。甚至传统的矩阵也很少见。

#4 楼

我有点不同意dzieciou和Attila,这有两个原因。


它们将一个过程(TDD / BDD)混合在一起,这可能会导致
该工具测量覆盖率,从而获得良好的覆盖率。
从“敏捷,一切都比以往任何时候都不同,更好”的意义上讲,它们太教条了。
说“ BDD太好了,你没有”是没有意义的。甚至不必
衡量结果”

在我眼中,敏捷意味着不要对工具或过程步骤一无所知,而是要不断改进。使用适合您特定项目的工具。

可追溯性矩阵回答了与敏捷开发相关的问题。如果明智地使用,您将从可追溯性维护中受益匪浅。