RUP测试指南

司格特

测试指南

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. 变更管理标准

[确定将如何管理和维护测试工件。]

[描述如何管理此文档的变更及其发生变更应该告诉那些人员以及如何告知？