转载你自： 如何快速完成和读懂测试计划
我们先从目录入手，简单预览一下：
Testplan
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项
第1项中，有三项需要更改：
product summary（产品目录），主要就是列出一些项目的功能特性，包含哪些模块，哪些软件，对与比较大的系统列出来，更有利于后面的分析，但是小的系统就没什么必要了。
references（参考文献），这个就比较随意了，一般都会列出不同参与者的一些资料
product milestore candidates（里程碑），这个是比较重要的，但是在后期也会出现，这里就是一个概览，一般都用表格的方式。
第2项
第2项，列出了使用的测试的步骤，基本每个项目都可以按照这么去测试，里面包括冒泡，功能性能之类的，还会对具体的做一些特定的说明，尤其是公司会使用特定的工具。
第3项
第3项，是核心的东西，一般的就用这项来代替需求分析了，可能额外没有具体的需求分析文档，所以阅读时这是最重要的，和需求是统一等级的，所以在编写的时候也不仅仅测试经理自己写，可能更多的回去参考开发的需求，或者开发文档中的一些特性项目，这个应该不需要原创太多，主要是需求分析人员已经做好的东西搬过来了。
第4项
第4项相对前面，就会好理解很多，主要由于一些硬性条件没法满足，无法进行测试的东西做一些说明。
第5项
第5项这是篇幅最大的一个，里面冉冉就是一个测试方案的缩写版本，所以，这部分完全可以取代测试方案了，里面包括了测试用例的设计规则，使用的测试的方法（冒烟，交互性，系统，性能等等），缺陷管理的方法，缺陷曲线，会议评审的方式，测量和度量，这些都包括目标和范围，所以里面分析的很细，想必很多公司在弄这个的时候都是集结了很多经验的。
第8项
第8项，可以和里程碑相对应起来，但是又没有里程碑那么重要，就是在测试过程的小阶段说产生的成果物提前进行的一个预计，主要就是为了把一个很大的目标（一个一年或半年的项目顺利完成），拆分成一个月的成果检验（里程碑），然后再拆分两周的小任务，可以指导你短期的工作，但是，这个也会根据时间做适当的相应的调整的。
第9项
第9项，这里主要的就是将里程碑进行完善和优化，要能够具体看了就知道怎么实施的文档。还有就是日程的安排，要对时间把握，另外有写时候会额外加一个文档schedule，专门就是做时间方面的计划的。
第10项
第10项是，环境要求，这个就比较容易了，有什么写什么。
第11项
第11项也是比较重要核心的东西，但是，有写的很详细，有些写的很宽松；对于大的项目，这个就会写的很简略，因为周期半年的项目没办法一下子把人员的任务都安排好呀，只能标记上需要哪些团队，都负责什么样的任务。具体的在根据具体的情况进行人员的分配。但是有些时候，对于项目比较小，可能就几周，人员也不多的时候，就需要将具体的分工分配下去，我当时分工分的很细，所以当时这个花费我很多时间去写，对后期的影响也很大，正因为这个任务分配的仔细，后期人执行起来有计可循，按照规定，每个人完成任务也都很有成就感。
第12项
第12项，风险管理，就是根据公司制定的了。