如何写一份“靠谱”的测试计划书

测试计划应该是整个测试流程中第一份测试文档了，但是一般情况下去不是测试人员学习的第一站。或许是因为万事开头难的缘故，测试计划确实挺让人纠结了。

(一)——万事开头难

　　测试计划应该是整个测试流程中第一份测试文档了，但是一般情况下去不是测试人员学习的第一站。或许是因为万事开头难的缘故，测试计划确实挺让人纠结了。

　　很多有了一定的经验的测试人员在教新人的时候第一步都不是按照测试流程先从测试计划开始，而是让从测试用例的执行开始——这虽是无奈之举，但是对于测试新手来讲，还是可以学习很多东西的。闲话扯得有点远，回到我要介绍的正题上面来，计划测试。

　　对，是计划测试，不是测试计划。尽管我们刚才讨论了一些关于测试计划的内容。但是我们需要关心的的确是计划测试，而不是测试计划。永远要记住，我们是在做测试，而不是在完成文档，尽管我们经常需要诸如测试计划测试用例测试报告之类的各种各样的文档，但是那些都不是测试的本质。

　　既然是计划测试，那么我们首先要搞明白测试到底要干什么。笔者将它抽象概括为：特定的人在特定的时间在特定的地方做了特定的事情以实现特定的目标。其实任何一项工作都可以抽象成前面这句话，所以我们还需要将这句话与我们所从事的测试工作联系起来。

　　所谓人，当然是指测试人员了，而“特定的人”则坚持的是“按能力分工”各司其职的原则。测试用例设计人员做测试设计，测试用例执行人员做执行用例等等。

　　所谓“特定的时间”，是指我们的测试过程是分成各种阶段的，各种阶段所侧重的测试要点是不一样的。

　　所谓“特定的地方”则是指测试环境，这是指我们必须在计划我们的测试工作的时候就要考虑到某些特殊类型的测试是需要特殊的环境的，这个环境包括了硬件设施(如手机测试你总得拿个手机来试试吧，总不能一直纸上谈兵来着)环境，计算机硬件环境和软件环境。

　　所谓“特定的事情”即是指我们测试技术本身了，也就是诸如测试用例设计，测试用例执行，写测试代码，部署测试环境等等。

　　所谓“特定的目标”即是指我们测试的目的。测试是需要成本的，人力物力都是需要的，既然我们对测试有投入那么我们是期望获得一些东西的。测试最常喊的口号是改善质量水平，也有一些还在喊保证质量的，这就是我们所谓“目标”。不过，可惜的是这些口号并没有多大的用处，因为在实际的软件项目中我们更加看重的则是可度量的测试工作，也就是说我们要由一个可度量的“目标”——亦即“特定的目标”——可能是发现了多少bug可能是测试覆盖率达到了多少等等。

　　我们在计划测试的时候，需要考虑的不仅仅是测试本身，从上面的分析可以看出，我们要关注“人、时、地、事、责”，也就是古代中华所讲究的“天时地利人和”之类的东西。需要指出的是，在我们计划测试的过程中，最常被人忽略的就是我们测试应该达到什么目标这个问题了。在计划测试的时候，切记要约定好测试的目标，这一目标反映在测试计划文档中即“测试结束标准”。

　　关于计划测试的内容有很多，在接下来的文章中，笔者将逐一展开与大家分享。

(二)——测试计划

　　在前一篇文章中，我们提到了计划测试要考虑到人、事、时等诸多问题，也提到了计划测试重在计划这个过程而不在测试计划这个文档。

　　这篇文章却要专门讨论一些测试计划相关的话题。网络上现在已经泛滥了关于测试计划的模板——用泛滥只是表示很多，并没有贬损的意思，笔者才疏一时想不到好的词语——这些模板对于制作一份测试计划文档来讲非常有用，但是生搬硬套这些文档却并不能帮助我们很好的计划我们的测试工作，但是这些测试计划中的主题却可以很好地帮助我们计划我们的测试工作并有效避免疏漏。

　　我并不会给出一份我所常用的测试计划模板，因为这些模板实在已经太多，已经够用了。笔者在测试工作中，曾经写出两种测试计划，一种类似于当前网络上流传的版本，另外一种则是在笔者的某篇blog文章中提到的所谓“实用主义测试计划”——事实上是更接近测试设计书的一个文档，但是确实有些公司把它称之为测试计划，而在本系列文章中笔者将不再讨论这种测试计划，也不会考虑细到“怎样设计某个功能的测试用例”的程度的计划工作。

测试计划书

---

介绍

本测试计划书旨在详细说明计划进行的软件/系统的测试过程。本文档将包括测试目标、测试范围、测试方法和测试时间表等内容。

测试目标

本次测试的主要目标是验证软件/系统是否符合以下要求：

1. 功能需求 - 确保软件/系统根据需求规格说明书中定义的功能适当地工作。
2. 性能需求 - 确保软件/系统在各种负载条件下均具有足够的性能。
3. 可靠性需求 - 确保软件/系统稳定，不会因为任何原因崩溃或失败。
4. 兼容性需求 - 确保软件/系统可以与其他相关软件/系统无缝协同工作。
5. 安全需求 - 确保软件/系统在安全方面没有漏洞或风险。

测试范围

本次测试的范围将包括以下内容：

1. 功能测试 - 针对所有功能需求执行测试。
2. 性能测试 - 针对各种负载条件执行测试。
3. 可靠性测试 - 针对软件/系统的可靠性进行测试。
4. 兼容性测试 - 针对其他相关软件/系统执行测试，确保互操作性。
5. 安全测试 - 针对软件/系统的安全性进行测试。

测试方法

本次测试将采用以下方式：

1. 手动测试 - 使用人工操作进行测试。
2. 自动化测试 - 使用自动化测试工具执行测试。

测试时间表

下面是本次测试的时间表：

项目	时间
计划开始日期	YYYY/MM/DD
功能测试	YYYY/MM/DD - YYYY/MM/DD
性能测试	YYYY/MM/DD - YYYY/MM/DD
可靠性测试	YYYY/MM/DD - YYYY/MM/DD
兼容性测试	YYYY/MM/DD - YYYY/MM/DD
安全测试	YYYY/MM/DD - YYYY/MM/DD
测试报告编写	YYYY/MM/DD - YYYY/MM/DD
计划结束日期	YYYY/MM/DD

测试风险

以下是可能出现的测试风险：

1. 测试时间不足。
2. 测试资源不足。
3. 未能识别所有需求。
4. 软件/系统在测试期间发生故障或崩溃。

测试成果

本次测试的主要成果

因此我建立了一个软件测试开发自学团，正在学习测试的小伙伴可以通过点击下面的小卡片