每个项目测试计划都会不一样，但是一般情况下，每个公司都会有相应的模板，尤其是项目很频繁的公司，相对应的模板应该就更全面，并且更容易修改，更能适应新项目。

并且，经常接触测试计划的人可能会察觉到，实际上很多测试的计划都大同小意，里面有很多相似的模块，像是说明，缺陷管理，项目通过标准，暂停标准，恢复标准，风险管理，等等，都是可以直接套用的，并且这其中有过多的官方的术语，就是一种套话，客套话，很多文字是为了使文章更好去读，读起来更舒服，充当的是绿叶的角色。

但是基本上说包含核心的内容都是根据不同的项目量身定做的，比如具体要测试特性，测试的milestone，schedule等等，这些是测试人员的测试的依据，时间安排的标准，是绝对马虎不得的，这也是测试计划的精髓所在。

所以总的来说测试计划可以宏观的认为包含两个部分，一个是具体项目的测试安排，日程安排，人员分工，任务分工，里程碑的成果物等等，另一个是，适用于很多项目的一些约定俗成的标准，管理的方案，风险、缺陷的管理等等，这些不必随着项目的变化而更改，只要有一份模板，针对不同的项目进行简单的更改就可以了。

其实这种写测试计划的方法也可以减少你的时间，更高效更有速度的阅读测试计划，因为当你拿到手中的是20几页的测试计划时，如果你选择从头一点一点的看，那真的很佩服你，如果是你的母语还好，文档若是一种外语，对自己来说很闹心，对公司来说也很浪费成本呀。一旦你清楚了测试计划中的窍门，你完全可一跳过那些标准，直接找到最核心的安排，分工，这样可以为您省去很多时间，也可以为公司创造更大的价值。

如果您不是第一次接触测试计划，想必对这些会有一些感觉，对于读测试计划而言，知道这些是不够的，而需要的是去剖析一篇测试计划，一旦将其中的各个模块都弄懂了，在以后的阅读中就会是飞速了，不管阅读那个公司的，因为他们的本质是一样的，就有点像只要你掌握了一门编程语言，在去学其他的语言，也就是几个小时的事了。

所以，理论讲到这里开篇也开到这里，接下来，我们就以随便的一篇文档进行剖析，最后可能会给各位一些网上普遍的测试模板，可以作为练习，自己阅读一下，是否可以快速阅读。

我的这篇文档并非母语，所以各位要有准备，我们先从目录入手，简单预览一下：

Test plan

1,introduction

2,test items

3,features to be tested

4,feature not to be tested

5,approach

6,item pass/fail criteria

7,suspension criteria and resumption requirement

8,test deliverables

9,testing task and schedule

10,environmental needs

11,staffing

12risks management

13,approvals

看起来有点多，不过仔细分析一下，里面需要写项只有1，3，4，8，9，10，11这几项，并且每一项需要写的东西都不多，其他的模块基本上都是绿叶啦！

在这些需要写的模块中，有些还只是更改部分就行了，并且，在有些项目中，其中的有些东西都可以省略，但是要看具体公司的规定，有些公司测试计划是越多越好呀，显得严谨周密，结果让写的人闹心，看得人也不舒心呀！

第1项中，有三项需要更改：

product summary(产品目录)，主要就是列出一些项目的功能特性，包含哪些模块，哪些软件，对与比较大的系统列出来，更有利于后面的分析，但是小的系统就没什么必要了。

references(参考文献)，这个就比较随意了，一般都会列出不同参与者的一些资料

product milestore candidates(里程碑)，这个是比较重要的，但是在后期也会出现，这里就是一个概览，一般都用表格的方式。

第3项，是核心的东西，一般的就用这项来代替需求分析了，可能额外没有具体的需求分析文档，所以阅读时这是最重要的，和需求是统一等级的，所以在编写的时候也不仅仅测试经理自己写，可能更多的回去参考开发的需求，或者开发文档中的一些特性项目，这个应该不需要原创太多，主要是需求分析人员已经做好的东西搬过来了。

第4项相对前面，就会好理解很多，主要由于一些硬性条件没法满足，无法进行测试的东西做一些说明。

第8项，可以和里程碑相对应起来，但是又没有里程碑那么重要，就是在测试过程的小阶段说产生的成果物提前进行的一个预计，主要就是为了把一个很大的目标（一个一年或半年的项目顺利完成），拆分成一个月的成果检验（里程碑），然后再拆分两周的小任务，可以指导你短期的工作，但是，这个也会根据时间做适当的相应的调整的。

第9项，这里主要的就是将里程碑进行完善和优化，要能够具体看了就知道怎么实施的文档。还有就是日程的安排，要对时间把握，另外有写时候会额外加一个文档schedule，专门就是做时间方面的计划的。

第10项是，环境要求，这个就比较容易了，有什么写什么。

第11项也是比较重要核心的东西，但是，有写的很详细，有些写的很宽松；对于大的项目，这个就会写的很简略，因为周期半年的项目没办法一下子把人员的任务都安排好呀，只能标记上需要哪些团队，都负责什么样的任务。具体的在根据具体的情况进行人员的分配。但是有些时候，对于项目比较小，可能就几周，人员也不多的时候，就需要将具体的分工分配下去，我当时分工分的很细，所以当时这个花费我很多时间去写，对后期的影响也很大，正因为这个任务分配的仔细，后期人执行起来有计可循，按照规定，每个人完成任务也都很有成就感。

其余的就是额外的，基本也是不用动的，这其中包含了一个大块，里面有些很多文档的内容很丰富占了整个测试计划的很大的篇幅。

第2项，列出了使用的测试的步骤，基本每个项目都可以按照这么去测试，里面包括冒泡，功能性能之类的，还会对具体的做一些特定的说明，尤其是公司会使用特定的工具。

第5项这是篇幅最大的一个，里面冉冉就是一个测试方案的缩写版本，所以，这部分完全可以取代测试方案了，里面包括了测试用例的设计规则，使用的测试的方法（冒烟，交互性，系统，性能等等），缺陷管理的方法，缺陷曲线，会议评审的方式，测量和度量，这些都包括目标和范围，所以里面分析的很细，想必很多公司在弄这个的时候都是集结了很多经验的。

第12项，风险管理，就是根据公司制定的了。

综上所述，对这一个测试计划做了简单 的分析，相信可以类比到很多的测试计划。

最后，再小小的总结一下，测试计划，其实是很简单的文档，写起来简单，读起来也简单，因为他有太多的相似和雷同，手中只要有一个模板，就有参考，再根据实际情况做一些小的调整。要弄清楚的是测试计划中核心部分和绿叶部分。