Testing 如何在测试管理器中有效地处理需求？

另外，在Microsoft测试管理器中创建测试套件时，有3种可能性：

静态测试套件

基于查询的测试套件

需求测试套件

到目前为止，我一直在使用基于查询的套件，这些套件允许我按软件区域组织测试。我就是这么做的：

当我们开始这个项目时，我创建了一个测试计划（release x.x.x.x）、一些基于查询的套件和一些测试用例。当我们完成第一个版本的开发并开始新的版本时，我创建了另一个测试计划（release x+1.x.x.x），克隆了我所有的套件和测试用例。这允许我对已经开发并交付给用户的特性进行回归，并继续创建新的测试。此外，正因为如此，我可以轻松地在旧版本上运行测试（因为我的许多测试都是自动化的），即使需求发生了变化（当需求发生变化时，我的测试用例和自动化也会发生变化）。我需要做的唯一一件事就是打开发布测试计划，然后我就可以开始了。到目前为止还不错

最近我读到有这样一个基于需求的套件。这个套件允许我创建与需求相关联的测试。但在我看来，这只有在我们只有很少的测试用例时才起作用，到目前为止，我有2000多个自动化测试。我将试图解释原因：

当我们开始开发一个新的软件版本时，我想复制（复制）已经存在的测试用例，这样它们就可以被重新执行（回归），以确保已经开发的任何东西都不会被破坏。但是，克隆测试计划是行不通的，因为我的需求已经改变，几乎不可能复制每个测试用例并将它们添加到它所属的基于需求的套件中

所以我的问题是：在这个场景中，我们如何使用基于需求的套件？微软是否只考虑过在测试计划中使用很少的测试用例？我们如何使用测试管理器处理数千个测试用例（自动化或非自动化）

---

我正在使用Visual Studio 2013 Premium、TFS 2013和敏捷项目与方法（某种）。

首先，基于查询的测试套件可以覆盖需求库测试套件的目标，因此您可以直接使用基于查询的测试套件，而不是基于需求的测试套件

---

如果您仍然只想对大量的测试用例使用“基于需求”的方法，那么使用定制的查询将测试用例与用户故事进行批量链接，这样就可以了。

您可以定义与需求相关的许多测试用例会遇到什么问题吗？在您遇到超过一百万个测试用例之前，我不知道有任何性能问题……我试图在上面解释：当我们克隆需求测试套件时，我们正在克隆需求（用户故事）。这没有意义，因为这些需求不再有效（因为每次迭代需求都会发生变化）。如果我不复制那些基于需求的套件，我必须将我已经拥有的每个测试用例链接到新的需求。这没有任何意义，因为我有数千个测试用例。