软件测试计划作为软件测试中极为重要的一个规范性文档，本文我们来介绍测试计划的编写要点
软件研发生命周期
在说明软件测试计划应如何制定之前，我们先熟悉下软件研发生命周期的定义：
软件开发生命周期(Software Development Life Cycle，SDLC) 包含了软件从开始到发布的不同阶段。它定义了一种用于提高待开发软件质量和效率的过程。因此，SDLC旨在通过最少的资源，交付出高质量的软件。为了避免产生严重项目失败后果，软件开发的生命周期通常可以被划分为计划、需求分析、软件设计、软件实现、测试集成、维护 六大阶段：
从SDLC中我们可以看出，软件测试是软件研发生命周期的重要一部分，而软件项目的研发首先都是从制订计划开始。这里测试计划也是软件项目计划的一个组成部分。
测试计划的重要性
在最新的 ISO/IEC/IEEE 29119-3 标准中对测试计划的定义如下:
测试计划(Test plan): 描述测试为实现某个测试目标而执行的活动、任务和资源的文件。它提供了测试过程的蓝图，定义了测试工作的框架与指导，是管理测试工作的基础。
古人云：“凡事预则立，不预则废”，又云：“谋定而后动”。都是说我们做事预先计划的重要性。在软件测试中也是一样，只有在进入测试执行阶段之前，预先计划和确认好实施测试的相关原则、方法、资源和产出，才能保证我们后续的测试能够顺利开展。
本文的目的也就是讨论我们在计划阶段应该考虑和确认哪些因素并体现到测试文档中。
敏捷宣言中虽然有一条：
工作的软件高于详尽的文档
但是，测试计划文档的重要性在于，计划模板中会包含很多计划要素，依照这些要素去思考和准备后续的软件测试，可以避免一些重要事项的遗漏。
测试计划的主要构成
还是在ISO/IEC/IEEE 29119-3 标准中，对测试计划的主要构成也提供的详细的说明。以下我们就参考该标准来详细说明这些要素。（这里是一个比较全面的构成介绍，实际项目运作不用拘泥形式，根据项目自身实际情况进行裁剪即可）
文档信息
测试计划文档信息主要是用于文档本身的规范化管理要求的。一般会包含如下关信息：
- 文档标题 如：XXX项目XX版本测试计划
- 文档编写日期
- 文档状态 如：草稿、审核、发布等
- 文档版本 文档本身的版本历史
- 编写者及组织信息
- 文档评审、签署人员
- 文档变更历史记录
总体介绍
这部分主要说明当前测试的背景信息和介绍。
- 被测对象产品介绍，行业背景知识，测试的总体要求等。
- 参考文档的清单：比如需求文档、原型设计、系统架构、操作手册、安装手册、接口说明等等
- 术语、缩略语对照表
测试目标
这部分会重点说明当前测试的目标。
测试范围
这部分是测试计划中非常重要的部分，是明确当前测试的目标边界的。一般又会明确说明 In Scope 和 Out Scope 两部分，即明确哪些内容是本次测试需要覆盖的以及明确无法覆盖的。
一般确定测试范围的话，如In Scope的：
- 新增产品特性需求
- 历史版本的遗留bug修复
- 当前版本进行的技术实现优化
- 数据结构变更的验证
… 等等
而out scope的也需要根据项目讨论明确下来，举例如： - 安全加固相关的变更不包含在当前测试计划中
- 老旧历史版本（如3年前）的兼容
- 特定依赖的测试，如无法获取的测试设备相关的验证，经项目确认可以移出测试计划
- …
测试类型
当前计划需要覆盖的测试类型，比如功能测试、性能测试、兼容性测试、文档测试、安装部署测试、安全测试、兼容性测试、可靠性测试等等。说明相关类型的主要目的。
约束和假定
说明当前测试计划的一些预置条件和可能的约束。比如项目计划节点的有效性，人员、设备等资源的到位情况，需求变化情况，第三方关联系统的有效性等
干系人和合作方
测试中的干系人。哪些人这个测试计划的交付对象。
测试中的合作方。测试过程中需要和那些人协作，协作方式和沟通渠道
风险说明
根据项目的风险评估，列出当前跟测试相关的风险清单。又分项目风险和产品风险。
风险清单中列出的风险一般应包含这些要素：
- 识别出的风险说明
- 风险影响分析
- 风险级别的评估 （严重程度、发生概率、可识别概率）
- 当前对风险的已有举措
- 后续的风险消除方案
测试策略
测试方法
针对前面的测试类型，总体说明相应测试类型的主要测试方法，使用的测试工具，需要准备的测试数据和数据生成方案等
测试环境
这部分说明实施测试的测试环境要求，需要的设备资源情况（如移动应用测试需要准备的手机型号、web应用的服务器资源、网络环境），使用的测试工具等等
测试输出
列出测试过程中有哪些输出物，所存放的路径. 如
- 测试计划
- 测试方案
- 测试用例/集
- 测试数据
- 自动化测试脚本
- 测试状态报告
- 测试总结报告
- …
测试准入/准出标准
明确实施测试的开始和结束标准。比如准入要求单元测试通过率 95%，产品功能已完整开发并经过集成测试等。准出要求没有Critical的defect，遗留defect的总加权值不超过设定值等。
（这部分后续文章还会详细介绍）
测试暂停/重启标准
明确暂停测试和重启测试的标准。暂停和重启会影响后续的Schedule排期，所以有必要在计划阶段就明确说明。举例来说比如出现影响测试继续进行的严重bug会触发暂停，当相关bug解决后可以触发重启。
测试人员
参与测试实施的人员名单和相关职责说明，在项目期间的投入工作量估算。如有人力缺口或能力培训需求，在这一部分需要说明相关的计划。
测试计划分解
根据前述测试方案和人力，对后续测试过程进行任务分解和估算。这里不仅要考虑到实施阶段的测试任务，也应包含计划、设计阶段的任务分解和估算。一般包括：
- 计划阶段的目标、scope的确认
- 需求的评审、澄清，测试方案的整理
- 测试用例设计、工具准备、数据准备、自动化测试开发
- 测试执行阶段的多轮测试：新功能测试、全量回归、bug验证、发布、升级验证，发布后验证
- 测试报告输出
- 日常的状态更新、测试过程数据的收集
以上就是测试计划的主要构成。测试计划编写完成一般需要经过数轮和项目团队的评审和确认，作为后续测试实施的参考依据。
但大家理解测试计划的主要作用和定义这些构成要素的背后逻辑，实际项目操作也可以根据项目实际情况进行一些裁剪，而不是因为追求教条式的完备计划而投入大量精力。
一页测试计划示例
其实随着敏捷的推行，我们也可以在迭代阶段采用一些轻量级的计划模板，关注到核心要素。下面就是两个一页纸的计划模板，大家可以参考：
