是在制定测试计划之前还是在制定测试计划之前准备？？
-
两个如何相互关联？
-
在集成，系统，主测试计划的情况下 RTM 相关？
如何
rtm始终是任何项目的重要文档。/p>
一旦确定了要求，则需要将每个要求ID包含在RTM模板中。
完美地创建和审查了测试用例后，所有测试用例都需要映射到适当的要求ID。
有时，即使项目有任何遵循莫斯科规则的程序，也将帮助测试人员确定执行顺序。
最终RTM保证每个要求ID都为其具有测试用例。
RTM是在制定测试计划之前还是在制定测试计划之后制备？
这是一旦开发/测试完成后交付的文档，因此应该是一个活生生的文件。它本质上将您的要求映射到测试案例，以便在测试正在开发的任何内容时都具有覆盖范围的可追溯性。
两者如何相互关联？
没有100％耦合。您的测试计划将涵盖您的方法的测试方式。RTM地图您正在测试什么，以确保您在测试过程中具有足够的覆盖范围。
集成，系统，总测试计划RTM如何相关？
在系统/集成测试的情况下，理想情况下，您的RTM对两种测试都有覆盖范围。就我个人而言，我认为总体测试计划是浪费时间和精力。您的测试计划应涵盖您的需求。
编辑：这里有一个非常好的文章。
我希望这会有所帮助！
- 回答您的第一点，RTM是准备就绪时准备的东西。如果您打算在项目中采用一种创建RTM的做法，则可以在测试计划中提及这一点，而不论其创建是否创建。
- 测试计划和RTM无关。RTM准备牢记以下目标：
- 要求覆盖范围 - 验证是否针对测试案例涵盖了所有要求。
- 它在识别相关测试用例，因此简化回归测试 方面非常有用
- 我们遵循的实践是为每种要求创建RTM。一旦冻结了要求，QA团队就为其创建了测试用例，标记了所有相关的测试用例，并与开发团队分享。因此，在进行开发的同时，开发人员将矩阵转移，以确保在将要求传递给QA团队之前与该要求相关的所有测试用例。因此，理想情况下，应在已知要求后立即准备RTM。当然，这意味着需求的任何变化也将需要对RTM进行修改。这可能是添加新的TC，在此处删除TC或识别回归测试套件的形式。
您可以在此处阅读有关如何创建RTM的更多信息，因为它的填充正确非常重要，否则可能会导致不满意的客户。RTM与创建它的人一样好。
希望这会有所帮助！
收集要求后，准备了可食性矩阵，并且在发布后QA签名后，我们从HP ALM QC（测试管理工具）生成了RTM（要求可追溯性矩阵）。hp alm以这种方式完成。
收集了要求后，我们准备了测试计划策略文档，该文档涵盖了所有测试方案（INSCOPE，范围内，涵盖的回归项目），我们根据HP ALM QC中创建要求，并将与之相关的测试案例相关联每种情况。
签名后，我们生成了RTM来验证该版本中是否涵盖了所有要求，却没有遗漏。
stlc有5个登台需求分析退出标准为RTM，然后下一阶段是测试计划
然后测试案例开发。因此，在测试案例开发之前的RTM如何编写