如何写好软件测试计划书

软件项目的测试计划是描述测试目的、范围、方法和软件测试的重点等的文档。对于验证软件产品的可接受程度编写测试计划文档是一种有用的方式。

详细的测试计划可以帮助测试项目组之外的人了解为什么和怎样验证产品。它非常有用但是测试项目组之外的人却很少去读它。

什么样的测试计划书符合要求

软件测试计划作为软件项目计划的子计划，在项目启动初期是必须规划的。在越来越多公司的软件开发中，软件质量日益受到重视，测试过程也从一个相对独立的步骤越来越紧密嵌套在软件整个生命周期中，这样，如何规划整个项目周期的测试工作；如何将测试工作上升到测试管理的高度都依赖于测试计划的制定。测试计划因此也成为测试工作的赖于展开的基础。《ANSI/IEEE软件测试文档标准829-1983》将测试计划定义为：“一个叙述了预定的测试活动的范围、途径、资源及进度安排的文档。它确认了测试项、被测特征、测试任务、人员安排，以及任何偶发事件的风险。”软件测试计划是指导测试过程的纲领性文件，包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计划，参与测试的项目成员，尤其是测试管理人员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。

案例：一份看似“不错的”软件测试计划书

下面是某项的测试计划书

提纲挈领，透过这份测试计划书的目录，如何对这份测试计划书进行评价？
在回答这个问题之前，我们先看看测试过程中的一个重要的活动或者阶段——测试计划阶段都需要做什么？这个阶段的产出物是什么？

测试计划阶段的任务

测试计划可以在项目计划或主测试计划中文档化，也可以在不同的测试级别（如系统测试和验收测试）的测试计划中文档化。测试计划文档的大纲可以参考“软件测试文档标准”（IEEE Std 829-1998）。

测试计划受到很多因素的影响：组织的测试方针、测试范围、测试目标、风险、约束、关键程度、可测试性和资源的可用性等。随着项目和测试计划的不断推进，将有更多的信息和具体细节包含在计划中。

测试计划是个持续的活动，需要在整个生命周期过程和活动中进行。从测试中得到的反馈信息可以识别变化的风险，从而对计划作相应的调整。

测试计划阶段需要做的事情

对整个系统或部分系统可能的测试计划活动包括：

• 确定测试的范围和风险，明确测试的目标；
• 决定总体测试方法，包括测试级别、入口和出口准则的界定；
• 把测试活动整合和协调到整个软件生命周期活动中去（采购、供应、开发和运维）；
• 决定测试什么？测试由什么角色来执行？如何进行测试？如何评估测试结果？
• 为测试分析和设计活动安排时间进度；
• 为测试实现、执行和评估安排时间进度；
• 为已定义的不同测试活动分配资源；
• 定义测试文档的数量、详细程度、结构和模板；
• 为监控测试准备和执行、缺陷解决和风险问题选择度量项；

明确了测试计划阶段需要完成工作，就很容易思考一份高质量的测试计划书中应该包括什么内容了。

软件测试计划的文档化（产出物）——软件测试计划书

下面是根据IEEE 829标准编写的一份测试计划的目录：

这份测试计划中：

• 在第2部分明确了被测软件系统（产品）待测的特性和不测试的特性。
• 在第3部分明确了测试目标
• 在第4部分明确定义了准入/准出规则；通过和失败的标准；暂停标准和测试恢复需求

这些内容都是很重要的内容。

最后还描述了：

• 测试提交产出物

对比以上两份软件测试计划书的目录，可以看出第二份软件测试计划书的内容更加合理一些。

如何写好软件测试计划书的内容？

这个问题其实是“仁者见仁，智者见智”。不同的软件测试项目经理或者测试负责人、Test Leader等都有自己的看法。什么内容该写进去？写道什么程度？是否真的用心去写好每一个章节的内容？

现实中，大多数软件测试项目经理或者测试负责人、Test Leader其实内心都是恐惧写文档的。很多时候不是不会写，而是不重视或者只是为了应付工作。原因其实很简单，无外乎有以下几种：

• “文档无用论”，写文档还不如多用一些时间在解决项目问题上；
• 写了软件测试计划其实也没有几个人看；
• 文档其实不被重视；
• 仅仅是为了应付公司品质部门、QAO的检查或者CMMI评估；
• 在工作中测试管理的具体实践活动，依赖的是经验，而不是一份写在纸上的测试计划书；
• 敏捷过程是“轻文档”化的；
• 其它种种原因……

软件测试计划真的仅仅只是一份文档吗？
软件测试计划真的没有用吗？
敏捷过程就真的不需要测试计划了吗？

这些显然是一些借口或者错误的认识。

为什么我们需要测试计划？

无论做什么工作，都是计划先行，然后按照所制定的计划去执行、跟踪和控制。软件测试也一样，先要制定测试计划，是做好整个测试工作的前提。所以在进行实际测试之前，应制定良好的、切实可行的、有效的测试计划。软件测试计划的目标是提供一个测试框架，不断收集产品特性信息，对测试的不确定性（测试范围、测试风险等）进行分析，将不确定性的内容慢慢转化为确定性的内容，该过程最终使得我们对测试的范围、用例数量、工作量、资源和时间等进行合理的估算，从而对测试策略、方法、人力、日程等做出决定或安排。

在编写测试计划之前，可以考虑下面几个问题：

• 为什么要编写测试计划？
  （1）Test Manager/测试主管等能够根据测试计划做宏观调控，进行相应资源配置等；
  （2）测试人员能够了解整个项目测试情况以及项目测试不同阶段的所要进行的工作等；
  （3）便于其他人员了解测试人员的工作内容，进行有关配合工作
• 什么时间开始编写测试计划？
  （测试需求分析前总体测试计划书/测试需求分析后详细测试计划书）
• 由谁来编写测试计划？
  具有丰富经验的测试负责人Test Leader
• 测试计划编写的基本思路（5W1H）
  （1）why——为什么要进行这些测试；
  （2）what—测试哪些方面，不同阶段的工作内容；
  （3）when—测试不同阶段的起止时间；
  （4）where—相应文档，缺陷的存放位置，测试环境等；
  （5）who—项目有关人员组成，安排哪些测试人员进行测试
  （6）how—如何去做，使用哪些测试工具以及测试方法进行测试。

测试计划的要点

测试规划与软件开发活动同步进行，在需求分析时，就开始测试策划，确定测试需求、目标、资源等。测试计划可以按不同的测试阶段（集成测试、系统测试等）来组织，也可以为每个测试任务或目标(安全性、性能、可靠性等测试)进行考虑。

测试计划主要集中在测试目标、质量标准、测试策略、测试范围、测试用例设计方法、所需资源和日程安排等，其关键是制定有效的测试策略，界定清楚地测试范围，识别出测试中所存在的各种风险并找出风险回避、监控和管理的方法，针对不同的测试目标或阶段确定测试方法，对测试工作量及所需的资源、时间进行合理的估算。所有这些，都是为了两个根本目的：测试的质量和效率。

测试计划中需要明确测试范围

测试主要依据“产品设计规格说明书”、代码所发生的变化及其影响的区域，来确定哪些功能和特性要测试，哪些功能和特性不需要测试。在确定测试范围时，主要考虑的因素有：

• 优先级最高的需求功能
• 新增加的功能和编码改动较大的已有功能
• 容易出现问题的部分功能
• 过去测试不够充分的地方
• 经常被用户使用的功能和配置（占20%）
• 哪些不需要测试的功能和特性（排除出测试范围）

在实际的测试实施中，有时候存在测试执行到一定阶段，由于某种原因（例如：环境不具备、测试账号的问题、测试数据的问题、公司安全策略的限制等等导致测试条件不满足，从而一些之前计划在测试范围内的功能，需要排除出测试范围）测试范围需要发生变更。那么这就需要遵守变更流程，并且更新测试计划文档，以及更新后的测试计划获得审批。

这个环节其实常常被Test Leader和Test Manager或忽视。

我遇到过很多类似的情况，没有遵守变更流程，并且更新测试计划获得审批，这最终导致的结果是测试功能混乱；经历2-3个版本迭代之后，被测需求难以追溯。一旦存在产品发布之后出现功能上的问题，用户抱怨不断。其实这就反映出测试计划不合理而导致的问题。

测试估算：所需资源和日程安排

为了合理、准确地安排日程，对测试工作量要进行正确的估计。除了对工作量的估计之外，还要正确评估参与该项目人员的培训时间、适应过程和工作能力等。由于涉及到不同的项目、不同的测试人员、不同的前期介入方式，要对每人每天能够完成的平均测试用例数目做出一个准确的估计确实很困难，但是可以根据以前一些项目测试的经验或历史积累下来的数据进行判断推理，并适当增加10%-20%的余量，估算结果就比较准确了。
　　
在估算的基础上，进行有效的、合理的资源安排。在不同的测试阶段人力资源的需求是不一样的，所以人力资源的计划要有一定的灵活性和动态性，形成有机的动态平衡，保证测试的进度和资源的使用的效率。

需要精心编写准备测试计划

要做好测试计划，测试设计人员要仔细阅读有关资料，包括用户需求规格说明书、设计文档等，全面熟悉系统，并建议注意以下方面：

• 让所有合适的相关人员参与测试项目的计划制定，特别是在测试计划早期；
• 测试所需的时间、人力及其它资源的预估，尽量做到客观、准确、留有余地；
• 测试项目的输入、输出和质量标准，应与各方达成一致；

测试计划的主要内容

测试计划的主要内容包括以下要点：

1. 测试计划标识
2. 版本修订记录
3. 简介（目的）
4. 主要阅读者
5. 测试项（交付测试的一切内容）
6. 需要测试的功能
7. 不需要测试的功能
8. 测试项通过/失败的准则
9. 测试准则（入口准则、出口准则、暂停和恢复准则）
10. 测试交付物/产出物
11. 测试任务
12. 进度计划（可以与10.测试任务合并做出一个进度和任务的矩阵，关键里程碑点的描述）
13. 环境需求
14. 工具
15. 职责矩阵
16. 人员和培训的需求
17. 风险和缓解风险/预防风险的对策
18. 批准（测试计划需要进行评审和审批）

有一些时候对上述内容可以进行裁剪。还有一些测试团队/组织会将测试计划与测试策略合并成为一个文档。
我在测试管理中，允许一些小的测试项目或者临时性的测试项目将测试计划（Test Plan）和测试策略（Test Strategy）进行合并。事实上，很多Test Leader，Test Manager是不愿意花费太多的精力去写文档、维护文档的。即便如此，2-3页纸的测试计划还是需要的。此时，测试策略（Test Strategy）就尤为重要了。

测试计划需要评审

测试计划不可能一气呵成，而是要经过计划初期、起草、讨论、审查等不同阶段，才能将测试计划制定好。测试计划的评审是完成测试计划关键的一个环节，包括测试组织内部的自我评审、讨论和修改，然后交到评审会进行正式的评审，直至测试计划得到审批。

测试计划的正式评审，项目中的每个人（产品经理、项目经理、开发工程师等）都应当参与。计划的审查是必不可少的，每一个参与者都可能根据其经验及专长提出问题或建议，弥补在测试范围、工作量、风险等各方面的不足，进一步完善测试计划。

（更新完）