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