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

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

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

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

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

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

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

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

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

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

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

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

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

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