测试计划概述了测试软件功能的过程。测试计划详细说明了为实现特定结果而采取的每个步骤，并说明了每个操作的目标。该计划还强调了测试中涉及的预计资源、风险和人员。如果您希望在软件可供客户使用之前消除软件中的错误和其他错误，您应该使用测试计划。按照以下步骤创建测试计划。
脚步
第 1 部分（共 2 部分）：准备测试计划
步骤 1. 了解基础知识。
您在测试计划中的内容在很大程度上取决于您计划测试的软件的复杂性。但是，测试计划中应始终包含三个基本部分：测试覆盖率、测试方法和测试职责。
- 测试覆盖率定义了您将要测试的内容以及您不会测试的内容。
- 测试方法定义了您将如何测试“覆盖率”部分中定义的每个部分。
- 测试职责将任务和职责分配给不同的各方。本节还应包括各方将记录哪些数据以及如何存储和报告这些数据。
步骤 2. 熟悉必要的 IEEE 标准文档。
电气和电子工程师协会 (IEEE) 发布了用于测试和记录软件和系统开发的国际标准。要将您的测试计划保持在最高标准，请查阅以下 IEEE 出版物：
- 29119-1-2013，软件和系统工程 - 软件测试 - 第 1 部分：概念和定义
- 29119-2-2013，软件和系统工程 - 软件测试 - 第 2 部分：测试过程
- 29119-3-2013，软件和系统工程 - 软件测试 - 第 3 部分：测试文档
- 829-2008，IEEE 软件和系统测试文档标准
- 1008-1987 - IEEE 软件单元测试标准
步骤 3. 查阅模板。
您可以在线找到测试计划的模板。模板的最佳来源是 IEEE 库，但访问需要付费。
都柏林城市大学还提供基于 IEEE 829 标准的免费测试计划模板。
第 2 部分（共 2 部分）：编写测试计划
步骤 1. 写介绍。
您的介绍充当测试计划的“执行摘要”：其目标、范围和时间表。这应该保持简短，因为您将在测试计划的后续部分中进一步详细说明。
- 您的目标和范围说明书应该概括地定义将在测试过程中使用的方法和预计的结果。范围说明书还应包括最关键的性能度量，以及测试计划未解决的问题及其原因的列表。
- 时间表详细说明了测试的每个阶段将完成的时间增量。
- 相关文档包括与当前项目相关的任何外围材料，例如规范列表。
步骤 2. 定义您的目标。
你的测试计划应该清楚地定义你将测试什么以及你为什么要测试它。这些应始终基于行业标准。
- 确定测试的范围。将测试哪些场景？
- 确定超出测试范围的内容。哪些场景不会被测试？
- 常见场景包括模块测试、集成测试、系统/验收测试和 Beta 测试。
步骤 3. 写一个关于所需资源的部分。
本节介绍完成测试所需的所有资源，包括硬件、软件、测试工具和人员。
- 在对员工进行会计核算时，请确保详细说明每个成员所需的职责以及执行这些职责所需的培训。
- 确保记录硬件和软件的确切规格。
步骤 4. 写一个关于风险和依赖性的部分。
详细说明您的项目所依赖的所有因素以及每个步骤所涉及的风险。项目中可接受的风险级别将有助于确定您将要测试和不测试的内容。
- 考虑各种风险的可能性。您将需要优先考虑关键领域。
- 请注意任何模糊或不明确的要求。用户通常缺乏理解技术语言或程序的专业知识，因此用户误解可能会带来风险。
- 使用您过去的“错误”历史记录来帮助您确定需要关注和额外测试的领域。
步骤 5. 写一个关于你要测试什么的部分。
列出您将测试哪些新方面以及您将重新测试哪些旧方面。确保详细说明每个测试的目的。
- 您可以使用软件应用程序清单、IEEE 指南和其他来源来帮助您确定此列表。
- 此部分还代表您的“可交付成果”，或者测试完成后您将向客户交付哪些数据。
步骤 6. 写一个关于你不会测试的部分。
列出当前项目中不会测试的所有功能。不测试功能的原因包括：
- 该功能将不包含在此版本的软件中
- 该功能风险低或之前使用过没有问题
第 7 步。列出您的策略。
本节概述了测试计划的整体测试策略。它将指定适用于上述测试的规则和流程。
包括有关要使用的工具、将收集哪些指标以及在什么级别上、将测试多少配置以及是否有任何特殊要求或测试程序的信息。
步骤 8. 制定通过/失败标准。
这些标准将指导您的测试人员，以便他们了解测试目标是否已实现。此部分还可以包括“退出标准”，以便您的员工知道何时可以停止测试某个功能。
您还应该包括一份暂停标准和恢复要求的清单。此信息告诉测试人员何时暂停测试以及恢复测试的可接受缺陷级别。
步骤 9. 写下测试期间将生成的文档列表。
这些文档也称为“可交付成果”，是将通过测试生成的数据、报告、脚本和结果。
将这些可交付成果分配给负责交付的“所有者”是个好主意。分配截止日期。
步骤 10. 写一个关于项目结果的部分。
概述您希望在测试过程中实现的所有目标。详细说明谁负责最终审批。
视频 - 通过使用此服务，某些信息可能会与 YouTube 共享。
提示
- 一些软件开发人员使用独立的测试公司来执行他们的测试计划。由独立的公司进行测试，可以以不同的方式审查方法和结果。
- 如果您的软件项目被分解为不同团队的几个部分，则每个团队都应该创建自己的测试计划。各团队的测试计划经审核通过后，可合并为项目整体测试计划。
- 一个完整的测试计划可以消除对测试程序的需求，而测试程序的开发成本可能很高。通常，测试计划描述正在测试的产品，测试程序描述如何测试该产品。但是，详细的测试计划可以涵盖测试程序通常概述的信息。
- 使您的测试计划符合您对测试的预期结果。进行了一些测试以查看哪些功能成功，而进行了一些测试以查看哪些功能会失败。每个都需要不同的规划。
- 为了快速提出测试用例和/或最小化忘记测试重要内容的风险，请考虑使用测试计划清单和/或测试计划模板。在开发一种产品并向该产品添加新功能和新功能时尤其有用。
- 为了快速提出测试用例和/或最小化忘记测试重要内容的风险，请考虑为您的测试计划提供结构。一种非常好的测试计划结构化方法是 ACC（属性、组件、能力）方法。识别属性（描述系统的形容词）、组件（功能部件的名词、系统的特性）以及属性和组件的每个组合，识别功能（用户动作、活动的动词）。