软件测试计划
产品的开发需要文档，软件测试同样需要这样的文档。它包含了测试活动的内容，确保客户的需求被高质量的实现和交付。测试文档的定义则是从产品的定义，项目的相关文档，客户的需求文档中派生出来的。
它通常是测试的经理或者测试负责人来完成，具体内容包括了测试范围，要测试什么，不测试什么，如何实施测试，执行测试，有谁负责某个功能模块，测试需要选择什么样的测试工具，测试框架，配置怎么样的测试环境，测试自动化如何集成到CI/CD中，需要遵循的测试技术准则，会有怎么样的测试风险以及如何去应对这些风险。
它不是一个静态的文档，通常会随着项目的迭代开发而改变。它指导我们如何去执行测试，这样影响到最终产品的顺利交付。
同样它也是测试人员需要交付的一个文档，该文档也需要和研发团队，项目负责人一同分享。尽可能让团队成员了解到测试范围，方法，目标以及时间表。
如何制定有效的测试计划
谁来准备测试计划
通常，测试负责人准备测试计划，测试人员参与测试计划文件的编制过程。一旦测试计划准备好了，测试人员就会根据测试计划文档写测试场景和测试用例。
测试计划的模板
下面列举的每个方面都是符合标准IEEE 829的。
- 测试计划标识符
- 文档列表
- 项目介绍
- 测试项目列表
- 待测试功能
- 未测试功能
- 实现方法
- 合格/不合格标准
- 中止标准
- 测试可交付成果
- 测试任务
- 测试环境
- 责任
- 人员配置和培训需求
- 时刻表
- 风险和突发情况
- 批准
1. 测试计划标识符
测试计划标识符是用于标识测试计划的唯一编号。
示例：项目_0001
2. 文档列表
将指定支持当前创建的测试计划的所有文档列表。
示例：SRS（系统需求规范）、用例文档、测试策略、项目计划、项目指南等，
3. 项目介绍
介绍或概括包括项目的目的和范围
示例：本文档的目标是测试“项目名称”的功能
4. 测试项目列表
将要测试的测试项目列表
示例：测试应该在具体什么样的环境下的应用程序前台和后台进行。
5. 待测试的功能
列出将在项目中测试的所有功能。
示例：要测试的功能包括登录页、仪表板、报表。
6. 未测试的功能
我们将列出项目中未包含的功能。
示例：使用支付宝的支付将从应用程序中删除。无需测试此功能。
7. 实现方法
如何执行测试的总体策略。它包含测试方法、测试类型、测试技术等详细信息。
示例：在这个项目中，我们遵循敏捷项目开发测试方法。
8. 合格/不合格标准
指定用于确定测试项通过或失败百分比的标准。
示例：应用程序的所有主要功能都应按预期工作，测试用例的通过率应大于98%，自动化测试用例通过率100%，并且不应有任何严重的错误。
9. 暂停标准
将指定何时停止测试。
示例：如果任何主要功能不起作用或系统遇到登录问题，则应暂停测试。
10. 测试可交付成果
每个测试阶段需要交付的文档列表，所有测试的相关的文档和结果。
示例：测试用例、错误报告
11. 测试任务
将指定在当前项目中需要完成的测试任务列表。
示例：测试环境应该在测试执行阶段之前准备好。需要准备测试总结报告。
12. 测试环境
测试环境所需的硬件、软件和任何其他工具的列表。
13. 责任
指定了每个测试任务的角色和职责列表。
14. 人员配置和培训需求
计划培训课程，以提高项目人员的技能，实现预期目标。
15. 日程安排
完成关于何时开始、何时结束以及每项任务应进行多长时间的详细信息。
示例：执行测试执行–180工时，测试报告–20工时
16. 风险和突发情况
说明克服这些风险的风险和意外事件的可能性。
示例：风险-如果预算估计错误，则成本可能超支。应急计划-在测试任务开始前确定范围，并在项目规划中持续关注和更新动态，同时持续跟踪预算估计。
17. 批准
谁应该签署并批准测试项目
总结
好的测试计划可以让项目人员获得整个项目测试的整个框架和测试目标。不仅可以帮助到测试人员理清项目的测试内容和计划表，任务分配，技术需求，同时可以更具测试计划文档保证项目的测试顺利进行，产品正常交付。
