一、测试计划模板
1、测试计划标识（Test Plan Identifier）
用于唯一标识测试计划文档的名称和版本。在其他项目文件中，通过该标识必须能够清晰准确地引用到该文件。标识文档的标准通常是由项目经理或组织的主要文档管理部门所指定的规范集所规定的。
根据项目组织的大小不同。标识的复杂程度也不尽相同。组成标识的最小元素必须包含计划的名称、版本以及其状态
2、介绍（Introduction）
介绍部分提供了该项目背景的简短概述。其目的是帮助参与项目的人员(客户、管理者、开发人员以及测试人员)能够更好地理解测试计划的内容。
在该部分中，应该包含引用到的所有文件列表。通常包括一些策略和标准，比如行业标准、公司标准、项目标准、用户标准、项目授权(有可能为合同)、项目计划及其他计划、规格说明等。
在多层次的测试计划中，每个较低层的测试计划必须参考其更高层的测试计划。
3、测试对象或测试项（Test Objects or Items）
这一部分应该包含被测产品部分及其组件的简单概述、标识包含版本和修订级别的测试条目、详细说明传输介质的特性和规格说明。为了避免误解，还应该包含不被测试的项目列表。
4、需要测试的特性（Features to be tested）
这一部分应该确定系统中所有应该被测试的功能和特征。这一部分应该参考测试规格说明和更多相关的描述，以及相对应的测试等级或测试阶段。
5、不需要测试的特性（Features not to be tested）
为了避免误解和防止不切实际的预期，应该定义产品中哪些是不需要或者无法进行测试的(这可能是由于资源限制或者技术原因导致的)。针对不同的特性，也可能需要不同的测试级别。
Addition：由于测试计划是在项目前期就准备好的，所以上面的列表是不完善的。随着项目的进展，会发现有些组件或者特性是无法测试的。测试经理应该在状态报告中报告这些问题。
6、测试方法或策略(Test Approach or Strategy)
如果可能，应根据风险分析来描述测试目标。风险分析应该显示：假如缺少测试导致错误无法发现，将会产生哪些风险。根据这些信息，就可以得到哪些测试项是必须测试的，以及相关的重要程度。这样就可以确保将测试重点放在重要的测试项上。
根据上面的分析，选择描述将要使用的测试方法。根据标识出的风险和可以用的资源，必须清楚地阐明所选择的方法是否可以到达测试目标以及为什么能够到达目标
7、验收标准（Acceptance Criteria）
当针对测试对象的所有相关测试执行完成之后，需要根据测试结果来决定是否可以发布和交付测试对象。为了到达这个目的，就必须定义验收准则或者测试出口准则。
“无缺陷”的准则是不太有效的，因为测试不能表明产品不存在缺陷。因此，通常情况下，准则应该包含：“执行的测试数据”，“发现的bug数目”和“所发现的问题的严重程度”。
eg:计划要进行的测试中至少有90%被正确地执行，未发现第一类问题（即崩溃）。
针对不同的测试对象，验收准则可以有所不同。验收准则的完整性依赖于对风险的分析，例如，针对非安全关键的测试对象的测试准则，就可以比安全关键的测试对象的验收准则弱一些。这样，就可以将测试资源集中在系统的重要部分上。
8、挂起准则和恢复要求
除了验收准则之外，测试计划还需要定义测试的挂起准则或者终止准则。
及时进过大量的测试工作，测试对象任然无法达到可以接收的水平，这是一个非常糟糕的情况。为了避免这种浪费的测试，我们需要要在早期就有能够终止这些无效测试的准则。这样就不必等到执行完所有测试才能将测试对象返回给开发人员：
与此相似，测试计划中同样需要确定恢复要求或继续测试的准则。相关的测试人员会执行一些准入的测试。测试通过后，才开始实际测试。
【比如冒烟报告等，避免出现bug无法收敛的情况】
9、测试交付物（Test Deliverable）
在这一部分中，我们确定每个测试活动需要交付的测试数据和结果。以及以何种方式来沟通这些测试结果。这并不仅仅指狭义上的测试结果（如测试报告和测试协议），也包含计划和准备文档。如测试计划、测试规格说明、时间进度表、用以描述测试对象移交的文档以及测试总结报告
Addition:在测试计划中，只涉及正式文档。但是，也不能忘了非正式的交流和沟通，尤其是项目处于困境或者非常困难的阶段(例如发布周临近)，有经验的测试经理应该尝试直接去和项目参与人员交流。这种交流并不是为了去发布坏消息，而是在坏消息可能发生之后，确保能选择正确的方向。
10、测试任务(Testing Tasks)
这部分为针对测试计划和执行的所有任务列表，包括责任分配。跟踪所有任务的状态（开始、进行中、延迟、完成）。这个正常项目计划和跟踪的组成部分，因此需要在项目或测试状态报告中定期汇报
11、测试基础设施和环境要求（Test Infrastructure and Environment Needs）
该部分列举出了执行计划中的测试所必需的测试基础设施元素。
比如：需要的压测工具，接口平台、GUI自动化测试平台，测试需要的设备、环境的配置和搭建等等
12、责任（Responsiblities）
项目的测试是如何组织的?谁有什么样的权限和责任？基于不同的测试小组和测试级别
13、进度表（Schedule）
带有主要里程碑的全面测试活动的进度表。从测试计划开始到测试验收交付的完整流程
14、风险和意外事故（Risks and Contingencies）
关于测试策略的那部分，描述了测试对象中风险或其他作用。
然而，这一部分主要针对测试项目本身来描述存在的风险，比如实现测试概念时的风险；以及在实际项目中由于没有资源致使不能完成合理的活动所引发的风险。这部分最低限度应该输出一份风险列表，并且在某些时间点上进行监控，以便寻找方法使风险最小化。
Addition：应该在这部分明确地描述下列风险：
1、开发的延期
2、被测系统质量太差
3、测试基础设施问题
4、缺少有资质的人员或者其他关键人员。
15、审批（Approval）
相关人员审批测试计划，测试计划变更后也需要以文档形式同步
理想情况“为了系统测试符合描述，您同意在此所提到的资源能够被提供和被使用”
实际情况“由于缺少资源，测试智能以不适合的方法或者最简单的方法进行，只有最重要的测试才能被执行。您同意这种测试方法并接受其发布决定，该决定由于基于这种测试将会承担高风险”
以上是基于《软件测试基础教程》附录A 根据IEEE829标准制定的测试计划模板，具有一定参考意义