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

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

　　但是基本上说包含核心的内容都是根据不同的项目量身定做的，比如具体要测试特性，测试的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（产品目录），主要就是列出一些项目的功能特性，包含哪些模块，哪些软件，对与比较大的系统列出来，更有利于后面的分析，但是小的系统就没什么必要了。