让我们从测试计划开始对测试过程的讨论，测试计划是测试过程中最重要的活动。它包括风险评估、鉴别和确定测试需求的优先级，估计测试资源的需求量，开发测试项目计划以及给测试小组成员分配测试职责。所有这些部分就构成了一份正式的测试计划，也可以独立开发这些部分并在合适的时间使用。
测试计划的传统思想是关于测试过程中谁来测试，对什么测试，何时测试，何地测试，怎么测试，测试持续多长时间。由于使用R丑tjollalRequl萄tePr。工具，我们已经对于什么是测试过程以及怎么使用它的一些想法进行了调整。我们可以将软件需求文档引入到工具中，如Rati,蛳缸RequisttePm。然后再直接从这些工具开发测试场景，这样得到了测试计划．而这些测试计划是使用RuP测试计划模板(我们已经广瑟修改过，见图l-2)构建的。从测试计划场景，我们可以得到测试需求。它们可以在测试计划文档的场景表中直接创建，或者它们也可以使用RuP模板在独立的测试需求文档中产生。由这些文档，我们可以得到测试需求视图，并且将其输出到csv(Cormm Se pa=rated vdues，逗号分隔值)文件。然后我们可以在测试过程中用微软的Excel打开该测试需求，这样我们就可以根据测试结果在线修改测试需求并把修改后的测试需求导回Reqtli萄tePro中。以上介绍了如何来定义我们的手工测试过程。尽管我们还没有将其完全实现，但是我们已经试用了它而且它也工作得很好。
我们将测试计划视为从软件需求中抽出来的工作文档，并且是和测试需求和测试结果相联系的。在测试阶段，它是一个动态文档。对于测试计划，旧观点认为它是计划性文档，它迫使测试者去考虑在测试过程中要做什么。从这个观点来说，测试计划就成了一个一旦测试阶段完成就柬之高阁的文档。由我们的经验可知，几乎没有人会在测试执行阶段再参考测试计划。而事实上，在我们曾经工作过的几家公司，测试计划往往在测试完成后产生。然而，若采用我们的方法，测试计划不但在测试之前产生，而且它会随着软件需求的更新而更新；脏之，更新也会被反映在测试需求中，这些测试需求将在测试阶段中用到。测试计划标准是基于包含在RUP中的模版的修订版，它是伴随RatiollalSulte TestSllidio一同发布的。
以下我们将讲述如何在一个客户组织中定义手工测试过程。我们也已经试用了这个测试过程并且它工作得很好。在各个测试计划场景，我们需要建立测试用例需求。测试用例需求直接建立在测试计划文档的场景表中以及分开的测试需求文档中(需求表)。由这些需求材料，我们可以建立测试需求视匾并可以将其导出到CSV文件。我们往往用微软的Excel来打开CSV文件用于手工测试。我们利用这些信息来指导手工测试执行过程，并且我们可以用测试结果在线地更新CSV文件。然后我们可以把修改过的文件导回到自动化工具中用于测试结果分析和报告。测试计划的目的是收集从需求倦计文档中得到的信息。并将这些信息表现在测试需求中，而测试需求将在测试场景中得到实现。测试场景是测试计划的一部分，它直接提供给测试条件、测试用例、测试数据的开发。
有一些桌面工具可用于自动化测试的计划和项目的管理，比如：微软Office和微软P删ect。举例来说，在微软Excel电子数据表中生成的检测表可用于风险的评估和分析，并且可用于生成测试需求文档；微软Pmiect可以用于产生项目计划；微软word可用于生成正式的测试计划。这些文档是测试计划的相关产物。和软件开发产物需要配置管理一样，测试对象也是如此。
文章来源于领测软件测试网 https://www.ltesting.net/
