我们使用Microsoft Test Manager 来测试应用程序。我们最初为要测试的每个应用程序创建了Test Plans。所以我们的测试计划有这样的结构：
应用程序 A
应用程序 B
应用C
现在，在每次迭代中，我们都会获得新的构建进行测试。
那么，我们应该保持相同的测试计划并编辑其适当的字段（使用中的构建、迭代、配置， ...）还是为每次迭代创建新的更好？像这样的：
应用程序 A - 迭代 1
应用程序 A - 迭代 2
应用程序 B - 迭代 1
应用程序 B - 迭代 2
应用程序 C - 迭代 1
应用程序 C - 迭代 2
【问题讨论】：
标签： visual-studio-2010 testing tfs microsoft-test-manager
为每个新版本创建一个新的测试计划是否有意义？
通常为功能创建测试计划。并在功能（功能规范）发生变化时进行相应更新。但那是在理想世界中。
据此，我可以告诉“使用中的构建、迭代、配置……”您是在谈论测试报告而不是计划。为什么没有包含测试计划的文档。和一个单独的
例如在本文档中的表格中，您将在其中更新（添加一行）用于测试的配置、构建、环境？
【讨论】：
考虑到定义及其测试计划的一个小变通方法：
测试计划流程和计划本身可作为与项目团队其他成员、测试人员、同行、经理和其他利益相关者进行沟通的工具。这种交流使测试计划能够影响项目团队，项目团队也能够影响测试计划，尤其是在组织范围内的测试政策和动机方面；测试范围、目标和要测试的关键领域；项目和产品风险、资源考虑和限制；以及被测项目的可测试性。您可以通过分发一两个测试计划草案和通过审查会议来完成这种沟通。这样的草稿将包括许多注释，如下所示：
[待定：Jennifer：请告诉我，对于每个系统测试执行周期，将测试项目发布到测试实验室的计划是什么？]
[Dave - 请告诉我哪个版本的测试工具将用于之前增量的回归测试。]
当您记录此类问题的答案时，测试计划就成为了测试人员与项目团队其他成员之间先前讨论和协议的记录。测试计划还可以帮助我们管理变更。在项目的早期阶段，随着我们收集更多信息，我们会修改我们的计划。随着项目的发展和情况的变化，我们会调整我们的计划。书面测试计划为我们提供了衡量此类修订和更改的基准。此外，在主要里程碑更新计划有助于使测试与项目需求保持一致。当我们运行测试时，我们会根据结果对我们的计划进行最终调整。每次出现差异时，您可能没有时间或精力来更新您的测试计划，因为有些项目可能非常动态。在第 6 章 [Black, 2001] 中，我们描述了一种记录测试计划差异的简单方法，您可以使用数据库或电子表格来实现该方法。您可以将这些更改记录包含在定期测试计划更新中，作为测试状态报告的一部分，或作为项目结束测试摘要的一部分 (c) ISTQB 基金会手册
我建议您更新现有的测试计划，以便在整个应用程序开发生命周期中看到任何修改或更正。
【讨论】：