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

Question

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

  

申请A
  申请B
  申请C

现在，在每次迭代中，我们都会获得新的Builds进行测试。

那么，我们应该保持相同的测试计划并编辑它们的相应字段（使用中的构建，迭代，配置， ......）还是为每次迭代创建新的更好？像这样：

  

申请A - 迭代1
  申请A - 迭代2
  申请B - 迭代1
  申请B - 迭代2
  申请C - 迭代1
  申请C - 迭代2

Answer 1

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

通常会为功能创建测试计划。并且当功能（功能规格）也发生变化时进行相应更新。但那是理想的世界。

从这里我可以告诉你“正在使用，迭代，配置......”，你在谈论测试报告而不是计划。为什么不提供带有测试计划的文档。另外一个 例如在本文档中，您将更新（添加一行）配置，构建，用于测试的环境吗？

Answer 2

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

  

测试计划流程和计划本身可作为与项目团队的其他成员，测试人员，同事，经理和其他利益相关者进行沟通的工具。此通信允许测试计划影响项目团队和项目团队，以影响测试计划，尤其是在组织范围内的测试策略和动机方面;测试范围，目标和关键测试领域;项目和产品风险，资源考虑和限制;以及被测物品的可测试性。您可以通过分发一个或两个测试计划草稿和审核会议来完成此通信。这样的草案将包括许多注释，如下：

     

[待定：Jennifer：请告诉我在每个系统测试执行周期中将测试项目发布到测试实验室的计划是什么？]

     

[戴夫 - 请让我知道哪个版本的测试工具将用于之前增量的回归测试。]

     

当您记录这些问题的答案时，测试计划将成为测试人员与项目团队其他成员之间之前讨论和协议的记录。测试计划还可以帮助我们管理变更。在项目的早期阶段，当我们收集更多信息时，我们会修改我们的计划。随着项目的发展和情况的变化，我们会调整计划。书面测试计划为我们提供了衡量此类修订和变更的基准。此外，在主要里程碑更新计划有助于使测试与项目需求保持一致。在我们进行测试时，我们会根据结果对计划进行最终调整。您可能没有时间 - 或精力 - 每次出现差异时更新您的测试计划，因为某些项目可能非常动态。在第6章[Black，2001]中，我们描述了一种简单的方法，用于记录可以使用数据库或电子表格实现的测试计划中的差异。您可以将这些更改记录包含在定期测试计划更新中，作为测试状态报告的一部分，或作为项目结束测试摘要的一部分（c）ISTQB Foundation book

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