如何写好软件测试计划书
软件项目的测试计划是描述测试目的、范围、方法和软件测试的重点等的文档。对于验证软件产品的可接受程度编写测试计划文档是一种有用的方式。
详细的测试计划可以帮助测试项目组之外的人了解为什么和怎样验证产品。它非常有用但是测试项目组之外的人却很少去读它。
什么样的测试计划书符合要求
软件测试计划作为软件项目计划的子计划，在项目启动初期是必须规划的。在越来越多公司的软件开发中，软件质量日益受到重视，测试过程也从一个相对独立的步骤越来越紧密嵌套在软件整个生命周期中，这样，如何规划整个项目周期的测试工作；如何将测试工作上升到测试管理的高度都依赖于测试计划的制定。测试计划因此也成为测试工作的赖于展开的基础。《ANSI/IEEE软件测试文档标准829-1983》将测试计划定义为：“一个叙述了预定的测试活动的范围、途径、资源及进度安排的文档。它确认了测试项、被测特征、测试任务、人员安排，以及任何偶发事件的风险。”软件测试计划是指导测试过程的纲领性文件，包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计划，参与测试的项目成员，尤其是测试管理人员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。
案例：一份看似“不错的”软件测试计划书
下面是某项的测试计划书
提纲挈领，透过这份测试计划书的目录，如何对这份测试计划书进行评价？
在回答这个问题之前，我们先看看测试过程中的一个重要的活动或者阶段——测试计划阶段都需要做什么？这个阶段的产出物是什么？
测试计划阶段的任务
测试计划可以在项目计划或主测试计划中文档化，也可以在不同的测试级别（如系统测试和验收测试）的测试计划中文档化。测试计划文档的大纲可以参考“软件测试文档标准”（IEEE Std 829-1998）。
测试计划受到很多因素的影响：组织的测试方针、测试范围、测试目标、风险、约束、关键程度、可测试性和资源的可用性等。随着项目和测试计划的不断推进，将有更多的信息和具体细节包含在计划中。
测试计划是个持续的活动，需要在整个生命周期过程和活动中进行。从测试中得到的反馈信息可以识别变化的风险，从而对计划作相应的调整。
测试计划阶段需要做的事情
对整个系统或部分系统可能的测试计划活动包括：
- 确定测试的范围和风险，明确测试的目标；
- 决定总体测试方法，包括测试级别、入口和出口准则的界定；
- 把测试活动整合和协调到整个软件生命周期活动中去（采购、供应、开发和运维）；
- 决定测试什么？测试由什么角色来执行？如何进行测试？如何评估测试结果？
- 为测试分析和设计活动安排时间进度；
- 为测试实现、执行和评估安排时间进度；
- 为已定义的不同测试活动分配资源；
- 定义测试文档的数量、详细程度、结构和模板；
- 为监控测试准备和执行、缺陷解决和风险问题选择度量项；
明确了测试计划阶段需要完成工作，就很容易思考一份高质量的测试计划书中应该包括什么内容了。
软件测试计划的文档化（产出物）——软件测试计划书
下面是根据IEEE 829标准编写的一份测试计划的目录：
这份测试计划中：
- 在第2部分明确了被测软件系统（产品）待测的特性和不测试的特性。
- 在第3部分明确了测试目标
- 在第4部分明确定义了准入/准出规则；通过和失败的标准；暂停标准和测试恢复需求
这些内容都是很重要的内容。
最后还描述了：
- 测试提交产出物
对比以上两份软件测试计划书的目录，可以看出第二份软件测试计划书的内容更加合理一些。
如何写好软件测试计划书的内容？
这个问题其实是“仁者见仁，智者见智”。不同的软件测试项目经理或者测试负责人、Test Leader等都有自己的看法。什么内容该写进去？写道什么程度？是否真的用心去写好每一个章节的内容？
现实中，大多数软件测试项目经理或者测试负责人、Test Leader其实内心都是恐惧写文档的。很多时候不是不会写，而是不重视或者只是为了应付工作。原因其实很简单，无外乎有以下几种：
- “文档无用论”，写文档还不如多用一些时间在解决项目问题上；
- 写了软件测试计划其实也没有几个人看；
- 文档其实不被重视；
- 仅仅是为了应付公司品质部门、QAO的检查或者CMMI评估；
- 在工作中测试管理的具体实践活动，依赖的是经验，而不是一份写在纸上的测试计划书；
- 敏捷过程是“轻文档”化的；
- 其它种种原因……
软件测试计划真的仅仅只是一份文档吗？
软件测试计划真的没有用吗？
敏捷过程就真的不需要测试计划了吗？
这些显然是一些借口或者错误的认识。
（未完待续，更新中……）