[注：以下提供的模板用于 Rational Unified Process。其中包括用方括号括起来并以蓝色斜体（样式=InfoBlue）显示的文本，它们用于向作者提供指导，在发布此文档之前应该将其删除。按此样式输入的段落将被自动设置为普通样式（样式=Body Text）。]
[要定制 Microsoft Word 中的自动字段（选中时显示灰色背景），请选择 File >Properties，然后将 Title、Subject 和 Company 等字段替换为此文档的相应信息。关闭该对话框后，通过选择 Edit> Select All（或 Ctrl-A）并按 F9，或只是在字段上单击并按 F9，可以在整个文档中更新自动字段。对于页眉和页脚，这一操作必须单独进行。按 Alt-F9，将在显示字段名称和字段内容之间切换。有关字段处理的详细信息，请参见 Word 帮助。]
修订历史记录
|
日期 |
版本 |
说明 |
作者 |
|
<日/月/年> |
<x.x> |
<详细信息> |
<姓名> |
目录
1. 简介 4
1.1 目的 4
1.2 范围 4
1.3 定义、首字母缩写词和缩略语 4
1.3.1 术语 4
1.3.2 缩写语 4
1.4 参考资料 4
1.5 概述 4
2. 测试目标 4
3. 测试标准 4
4. 测试数据 5
5. 主要评测方法 5
6. 测试完成标准 5
7. 缺陷管理指南 5
8. 变更管理标准 5
测试指南
1. 简介
[测试指南的简介应提供整个文档的概述。它应包括此测试指南的目的、范围、定义、首字母缩写词、缩略语、参考资料和概述。]
1.1 目的
[阐明此测试指南的目的。]
[说明此测试指南的书写目地是什么？ 读者对象是谁？ 以及读者应该具备哪方面知识？]
1.2 范围
[简要说明此测试指南的范围：它的相关项目，以及受到此文档影响的任何其他事物。]
[测试指南相关联的项目简要描述，与测试指南相关的其他模块，文档等等。比如软件规范，软件设计以及描述本测试应该测试哪些？而不应该测试哪些？]
1.3 定义、首字母缩写词和缩略语
[本小节应提供正确理解此测试指南所需的全部术语、首字母缩写词和缩略语的定义。这些信息可以通过引用项目词汇表来提供。]
1.3.1 术语
术语：解释
1.3.2 缩写语
缩写语：全名，（中文名称，解释）
1.4 参考资料
[本小节应完整地列出此测试指南中其他部分所引用的任何文档。每个文档应标有标题、报告号（如果适用）、日期和出版单位。列出可从中获取这些参考资料的来源。这些信息可以通过引用附录或其他文档来提供。]
[格式：作者，版本，出版日期，[出版社名]，”文件名称”，比如：
廖洪涛， V1.0， 2005/10/11，“媒体烽火台系统-数字电视机顶盒设计需求参考规范” ]
1.5 概述
[本小节应说明此测试指南中其他部分所包含的内容，并解释文档的组织方式。]
[1.1-1.4应该描述而没有描述的部分]
2. 测试目标
[陈述组织执行和使用测试的原因。][测试应该达到那种目标？ 为什么要进行该测试？]
3. 测试标准
[本节确定并说明将在计划、设计、实施、执行和评估等活动中使用的所有指南和标准。这些指南和标准包括：[测试指南的主体部分]
· 测试用例标准：确定应该为测试而开发的测试用例的类型，例如有效测试用例、无效测试用例、边界测试用例等。[比如java API测试中应该包括功能性测试，完整性测试，监听测试以及稳定性测试，并且简单描述每项测试的功能]
· 命名约定：说明应该如何给各种实体（如测试用例和测试过程）命名。[测试用例编号应该按照何种规则命名？ UI中的名称应该用啥符号引起来? …]
· 设计指南：说明测试过程和脚本模块化在复用和维护方面的目标。[如果测试需要书写测试脚本，对测试脚本进行架构设计，可用图及文字进行描述，注明模块与模块之间的关联和依赖关系，必要的时候加上数据流向说明。
测试用例的设计大纲，以及哪些测试用例可以被其他模块复用，比如软件启动功能测试用例是其他功能测试用例的前提条件；时间输入检验测试用例可以在EPG时间设定，系统设计时间设定测试用例中复用。
如果需要有测试脚本支持，如何使用测试软件，即测试脚本的界面设计？可以引见附录]
4. 测试数据
说明如何为支持测试而选择（或创建）和恢复数据。] [完成该测试需要何种测试数据？ 测试数据信息是什么？ 应该如何配置这些测试数据？ 可以引见附录]
5. 主要评测方法
[指定将采用何种评测方法来确定测试活动的进展，例如将要使用哪种缺陷计数，如何评测已成功执行的测试用例等。]
[比如通过查看测试代码运行后的测试报告文件来判断测试用例是否通过。通过按照测试用例的步骤进行操作是否达到预期效果来评定测试用例是否通过等]
6. 测试完成标准
[说明推荐使用的完成及评估标准。]
[什么条件算测试完成？ 比如每一条测试用例测试结果与测试计划中描述的希望结果一致。测试结束产品发布的标准是什么：比如>99.995%的测试用例通过测试；所有重要的缺陷得到解决，总的测试缺陷控制在百分之多少以内？]
7. 缺陷管理指南
[说明将如何管理缺陷。]
[测试中发现的缺陷应该如何进行管理？比如通过Bugzilla, 还是书写测试报告单。发现缺陷后开发人员与测试人员应该如何进行交流，什么级别的缺陷应该尽可能在多长时间解决。本版本不解决的缺陷应该如何控制？]
8. 变更管理标准
[确定将如何管理和维护测试工件。]
[描述如何管理此文档的变更及其发生变更应该告诉那些人员以及如何告知？
比如：文档变更应该在头部历史记录中详细注明变更内容，并且将变更文字变更为红色，另外重新建立文件，文件格式为:文件名+YYYYMMDD.doc。通过Email告诉测试计划设计师，测试开发人员。同时也应该告诉测试部门经理，技术总监,以及文档版本管理人员]
文章来源于领测软件测试网 https://www.ltesting.net/