每次迭代创建新的测试计划，还是编辑现有的测试计划？

Question

我们使用Microsoft Test Manager测试应用程序。我们最初为每个想要测试的应用程序创建了Test Plans。所以我们的测试计划有这样的结构：

应用程序A 申请B 应用程序C

现在，在每次迭代中，我们都会得到新的测试构建。

因此，我们是否应该保持相同的测试计划并编辑它们的适当字段(构建在使用中，迭代，配置，.)还是为每次迭代创建新的迭代更好？就像这样：

应用程序A-迭代1 应用程序A-迭代2 应用程序B-迭代1 应用程序B-迭代2 应用程序C-迭代1 应用程序C-迭代2

Answer 1

为每一个新的构建创建一个新的测试计划是否有意义？

测试计划通常是为一般的特性创建的。并在功能规范(Functional )更改时进行相应的更新。但这是在理想世界里。

从这个我可以看出“在使用中构建，迭代，配置，.”你说的是测试报告而不是计划。为什么没有一个带有测试计划的文档。和一个单独的

例如，在本文档中，您将更新(添加一行)用于测试的配置、生成和环境的表？

Answer 2

考虑到定义及其测试计划的一个小的变通方法：

测试计划过程和计划本身作为与项目团队其他成员、测试人员、同行、经理和其他利益相关者进行沟通的工具。这种交流允许测试计划影响项目团队和项目团队，以影响测试计划，特别是在以下领域:组织范围内的测试策略和动机；测试范围、目标和测试的关键领域；项目和产品风险、资源考虑和约束；以及测试项的可测试性。您可以通过分发一两份测试计划草案和召开评审会议来完成这一交流。这样一份草案将包括许多说明，例如： 待定:请告诉我，在每个系统测试执行周期中，将测试项目释放到测试实验室的计划是什么？ 当您记录此类问题的答案时，测试计划将成为测试人员与项目团队其他成员之间先前的讨论和协议的记录。测试计划还可以帮助我们管理更改。在项目的早期阶段，随着我们收集更多的信息，我们修改了我们的计划。随着项目的发展和形势的变化，我们调整了我们的计划。书面测试计划为我们提供了衡量这些修订和更改的基准。此外，在重大里程碑上更新计划有助于使测试与项目需求保持一致。当我们运行测试时，我们会根据结果对我们的计划进行最终的调整。您可能没有时间或精力来每次发生变化时更新您的测试计划，因为有些项目可能是非常动态的。在2001年“黑色”第6章中，我们描述了一种记录测试计划中的差异的简单方法，您可以使用数据库或电子表格实现这种方法。您可以将这些更改记录包括在定期的测试计划更新中，作为测试状态报告的一部分，或者作为项目结束测试摘要(c) ISTQB基础手册的一部分。

我建议您更新现有的测试计划，以便能够在整个应用程序开发生命周期中看到任何修改或更正。