RUP迭代测试计划模板

RUP迭代测试计划模板
<Company Name>
<项目名称>
迭代测试计划
版本 <1.0>
[注意:以下模板供与 Rational Unified Process(RUP)一起使用，且设计目的是与 RUP 内提供的详细指导信息结合使用。

与 RUP 随附的大多数模板一样，应对该模板进行定制以使其适合所用特定项目的环境。

]
[注:如您当前阅读的文本一样，包含在方括号中以蓝色斜体(style=InfoBlue)显示的文本用于向作
者提供指导，在发布文档之前应将这些文本删除。

在此样式之后输入的段落将自动设置为正常
(style=Body Text)。

]
,属性”然后在“标[要在 Microsoft Word 中定制自动字段(选定时显示灰色背景)，请选择“文件,题”、“主题”和“公司”字段填入本文档的相应信息。

关闭对话框后，可以通过选择“编辑”“全选”(或 Ctrl-A)然后按 F9 键，让整个文档中的自动字段更新，或者只需单击字段然后按 F9 键。

此操作必须对页眉和页脚分开进行。

Alt-F9 将在显示字段名称和显示字段内容之间切换。

关于处理字段的更多信息，请参阅 Word 帮助。

]
<项目名称> 版本: <1.0> 迭代测试计划日期:<dd/mmm/yy> <文档标识> 修订历史记录
日期版本描述作者 <dd/mmm/yy> <x.x> <详细信息> <名称>
机密 ,<Company Name>, 2011 第 2
<项目名称> 版本: <1.0> 迭代测试计划日期:<dd/mmm/yy> <文档标识> 目录
1. 简介 5
1.1 目的 5
1.2 范围 5
1.3 目标读者 5
1.4 文档术语和首字母缩写 5
1.5 参考资料 5
1.6 文档结构 6
2. 评估任务和测试动机 6
2.1 评估任务 6
2.2 测试激发因素 6
3. 目标测试项 6
4. 计划测试的大纲 6
4.1 测试包含内容大纲 6
4.2 其他可能包含的候选内容的大纲 7
4.3 测试排除内容大纲 7
5. 测试方法 7
5.1 评测测试范围 7
5.2 识别和解释测试 7
5.3 进行测试 7
6. 入口和出口标准 8
6.1 迭代测试计划 8
6.1.1 迭代测试计划入口标准 8
6.1.2 迭代测试计划出口标准 8
6.1.3 暂挂和继续标准 8
6.2 测试周期 8
6.2.1 测试周期入口标准 8
6.2.2 测试周期出口标准 8
6.2.3 测试周期异常终止 8
7. 可交付工件 8
7.1 测试评估摘要 8
7.2 报告测试覆盖率 8
7.3 理解的质量报告 8
7.4 事件日志和变更请求 9
7.5 冒烟测试套件和支持测试脚本 9 8. 测试工作流程 9 9. 环境需要 9 机密 ,<Company Name>, 2011 第 3
<项目名称> 版本: <1.0> 迭代测试计划日期:<dd/mmm/yy> <文档标识> 基本系统硬件 9 9.1
9.2 测试环境中的基本软件元素 9
9.3 生产力和支持工具 10
9.4 测试环境配置 10 10. 职责、人员配备和培训需要 10
10.1 人员和角色 10
10.2 人员配备和培训需要 12 11. 关键迭代里程碑 12 12. 迭代计划风险、依赖关系、假定和约束 13 13. 管理流程和过程 14
13.1 核准和签字结束 14 机密 ,<Company Name>, 2011 第 4
<项目名称> 版本: <1.0> 迭代测试计划日期:<dd/mmm/yy> <文档标识> 迭代测试计划
1. 简介
1.1 目的
<项目名称><完整生命周期，特定阶段> 迭代测试计划的目的是:
, 提供中心工件，用于管理测试工作的计划和控制。

它定义了将用于测试软件和评估测试结果的
一般方法，并且是管理者将用来管理和指导详细测试工作的最高级别规划。

, 当在测试工作中需要对管理测试工作的各方面进行全面的关注，并且那些项目干系人适合来批
准计划时，为项目干系人提供可见性。

该迭代测试计划也支持以下特定目标:
• [明确测试以什么为目标。

• 明确覆盖测试区域出于什么动机以及背后包含什么构想。

• 概括将使用的测试方法。

• 确定必需的资源并提供测试工时的估计值。

• 列出测试项目的可交付元素。

]
1.2 范围
[定义该迭代测试计划针对的测试类型(例如功能性、可用性、可靠性、性能和可支持性)，如果有必
要的话，还可定义测试级别(例如集成或系统)。

总体指出要从覆盖范围中排除哪些重要元素同样至
关重要，否则目标读者就可能会合情合理地认为包含那些元素。

注意:不要在此重复表述您会在以下两节中定义的详细信息: 3节, 目标测试项和第 4节计划测试的
大纲中定义的详细信息。

]
1.3 目标读者
[提供撰写迭代测试计划所面向的读者的简短描述。

这样能帮助文档的读者判别本文档是否旨在供他们
使用，并且能帮助防止本文档被不适当地利用。

注意:文档样式和内容通常要根据目标读者的不同而发生变化。

本节长度应该只有大约 3 到 5 个段落。

]
1.4 文档术语和首字母缩写
[本子节提供所有术语、首字母缩写和缩写的定义，这些术语、首字母缩写和缩写对于正确解释迭代测
试计划是必需的。

请避免列出通常适用于整个项目的项和已经在项目词汇表中定义过的项。

在“引
用”一节中包含对项目词汇表的引用。

]
1.5 参考资料
[本子节提供在迭代测试计划内的其他地方引用到的文档的列表。

用标题、版本(或报告号，如适
用)、日期、出版组织或原作者确定每份文档。

避免列出有影响力但却没有直接引用的文档。

指定可
从中获得“官方版本”参考资料的来源，例如内部网 UNC 名称或文档参考码。

可以通过引用附录或其
他文档来提供此信息。

]
机密 ,<Company Name>, 2011 第 5
<项目名称> 版本: <1.0> 迭代测试计划日期:<dd/mmm/yy> <文档标识>
1.6 文档结构
[本子节概括了迭代测试计划的剩余部分包含哪些内容，并介绍文档的剩余部分是如何组织的。

如果使
用目录，本节可以去除。

2. 评估任务和测试动机
[概述在本迭代中将执行的测试任务和测试动机。

]
2.1 评估任务
[提供一个简要声明，该声明定义了计划范围内的测试任务和评估工作。

适用任务声明可以包含以下一
项或多项内容:
, 找出尽可能多的错误
, 找出重要问题，评估察觉到的质量风险
, 对察觉到的项目风险提出建议
, 按照标准进行验证
, 验证规范(需求、设计或声明)
, 对产品质量提出建议，令项目干系人满意
, 对测试提出建议
, 履行流程要求
, 等等
每个任务为测试工作提供不同的环境，并且改变了执行测试的方法。

]
2.2 测试激发因素
[概述将在本迭代中激发测试工作的关键项。

测试将由许多事项激发 , 质量风险、技术风险、项目风
险、用例、功能需求、非功能需求、设计元素、疑似失败或错误类型(错误模型)、变更请求等等。

列出每个适用类别的特定项，这些特定项将在本迭代中激发测试，而且报告也会针对这些特定项。

] 3. 目标测试项
以下列表标识了已确定为测试目标的那些测试项(软件、硬件和支持产品元素)。

该列表表示将测试哪
些项。

[提供主要目标测试项的列表。

该列表应包含直接由项目开发小组生成的项和那些产品所依赖的项;例
如基本处理器硬件、外围设备、操作系统、第三方产品或组件等等。

请考虑按照类别对列表分组并对
每个特定测试激发因素指定相对重要性。

]
4. 计划测试的大纲
[本节提供将对迭代执行的测试的大纲。

本大纲表示目标和测试类型或质量风险之间的相交部分。

它通
常同样可以用表格或电子表格的格式来表示。

本节中的大纲表示将执行的测试和将特别排除的测试的概览。

4.1 测试包含内容大纲
[提供为当前迭代规划的主要测试大纲。

请注明将在计划中包含什么，同时在以下标题的节中不包含机密 ,<Company Name>, 2011 第 6
<项目名称> 版本: <1.0> 迭代测试计划日期:<dd/mmm/yy> <文档标识> 什么: 测试排除内容大纲中定义的详细信息。

]
4.2 其他可能包含的候选内容的大纲
[单独概述您猜测可能对调查和评估有用、但还没有充分研究是否有跟踪必要的测试区域。

] 4.3 测试排除内容大纲
[针对可能执行但被明确排除在本计划之外的潜在测试提供大纲。

如果一种类型的测试不会实施和执
行，则在一句语句中指明该测试不会实施或执行，同时指明理由，例如: , 这些测试对于完成评估任务没有帮助。

摂
, 没有足够的资源来进行这些测试。

摂
, 由于 xxxx 进行的测试，这些测试已经没有必要。

”
作为渐进方法，如果您觉得虽然受众成员之一期待包含测试的某个方面是合理的，但是却没有或无法
做到这一点，则应该声明该排除情况:如果团队认为该排除情况是显而易见的，那么您可能就不用列
出该情况了。

]
5. 测试方法
[测试方法提供针对分析、设计、实施和执行所要求测试的建议策略的概述。

第 3节目标测试项和第
4节计划测试的大纲明确将测试哪些项以及将执行哪些类型的测试。

本节描述如何实现测试。

当您识别方法的每个方面时，您应该更新第 10节职责、人员配备和培训需要以记录测试环境配置和
实施每个方面需要的其他资源。

在某些情况下您使用的策略将贯穿于整个项目周期。

因此，策略可以记录在一个或多个不同的测试策
略工件或主测试计划中，然后跨多个迭代复用。

这样操作之后，在本节中只要引用哪些工件会包含将
使用的策略即可(既可以在本节主标题下，也可以在相应的子标题下)。

] 5.1 评测测试范围
[描述将使用何种策略来评测测试工作的进度。

决定评测策略时，很重要的一点是考虑 Cem Kaner,
2000 中的以下建议“错误记数度量仅仅反映测试组一小部分的工作和进度。

很多备用项都与必须进行
和已经进行的操作很类似。

通常这些方法更有用并且比错误记数度量的副作用更小。

”
一个好的测量策略会报告多个方面的情况。

请考虑以下维，然后选择适用于您项目上下文的子集:有
效范围(针对产品和,或针对计划)、工作、结果、障碍、风险(在产品质量和,或测试质量中)、
历史趋势(跨迭代和,或跨项目)。

]
5.2 识别和解释测试
[描述如何识别特定测试并考虑将它们包含在本策略所涵盖测试工作的范围中。

这样做是为了让项目干
系人了解本计划，因为计划本身通常不会列出所有详细测试:这些详细内容会在其他测试工作产品中
提供。

针对将进行的特定测试提供用来刺激,驱动识别和选择的资源的列表，例如初始测试构想目录、需求
文档、用户文档和,或其他参考来源。

测试构想目录的示例可在 RUP 随附的流程组件中找到。

] 5.3 进行测试
测试方法的主要方面之一就是解释测试如何进行，包括选择将针对的质量风险区域或测试类型以及将
使用的相关技术。

如果要维护包含这些内容的单独测试策略工件，只要列出该计划将针对的测试类型
或质量风险区域，然后参考测试策略工件了解详细信息即可。

如果没有单独的测试策略工件，则您应机密 ,<Company Name>, 2011 第 7
<项目名称> 版本: <1.0> 迭代测试计划日期:<dd/mmm/yy> <文档标识>
该在此提供如何针对每种技术进行测试的大纲:如何进行测试的设计、实施和
执行，以及了解技术既
有用又可成功的标准。

对于每种技术提供该技术的描述，同时通过简要概述该技术如何帮助实现评估
任务来定义为何该技术是测试方法中的重要一部分。

6. 入口和出口标准
6.1 迭代测试计划
6.1.1 迭代测试计划入口标准
[指定将用来确定迭代测试计划是否可以开始执行的标准。

]
迭代测试计划出口标准 6.1.2
[指定将用来确定迭代测试计划的执行是否完成或继续执行没有意义的标准。

] 暂挂和继续标准 6.1.3
[指定用来确定测试是否应当在计划完全执行之前过早暂挂或结束以及在何种
标准下继续测试的标准。

] 6.2 测试周期
6.2.1 测试周期入口标准
[指定将用来确定该迭代测试计划下一个测试周期的测试工作是否可以开始的
标准。

]
测试周期出口标准 6.2.2
[指定将用来确定该迭代测试计划当前测试周期的测试工作是否已经足够的标准。

]
测试周期异常终止 6.2.3
[指定用来确定当前测试周期的测试是否应该过早暂挂或结束，或者待测试的
候选目标构建是否必须改
变的标准。

]
7. 可交付工件
[在本节中列出了测试工作将创建的各种工作产品，这些工作产品是对测试工作的各项目干系人有用的
可交付工件。

不要列出所有工作产品;仅列出对项目干系人提供直接切实益处的工作产品，以及您想
要用来衡量测试工作是否成功的工作产品。

注:本节可以整体或部分代表测试策略或主测试计划工件，在该情况下本节只需注明任何调整或被删
除。

]
7.1 测试评估摘要
[简要概述测试评估摘要的格式和内容，并指出生成频率。

]
7.2 报告测试覆盖率
[简要概述用于评测测试范围的报告的格式和内容，并指出生成频率。

指明用来记录、评测和报告测试
范围的方法和工具。

]
7.3 理解的质量报告
[简要概述用来评测产品察觉质量的报告的格式和内容，并指出生成频率。

指明用来记录、评测和报告机密 ,<Company Name>, 2011 第 8
<项目名称> 版本: <1.0> 迭代测试计划日期:<dd/mmm/yy> <文档标识> 察觉产品质量的方法和工具。

您可以在测试覆盖率中包含事件和变更请求的一些分析。

7.4 事件日志和变更请求
[简要概述用来记录、跟踪和管理测试事件、关联变更请求及其状态的方法和工具。

] 7.5 冒烟测试套件和支持测试脚本
[简要概述测试资产，这些测试资产将被用来支持正在进行的对后继产品构建的回归测试，从而帮助检
测产品质量的退步。

]
8. 测试工作流程
[概述工作流程，测试团队在本迭代测试计划的开发和执行中将遵循该工作流程。

]
对于迭代测试计划，我们建议仅将本节作为例外，同时注明与主计划工作产品中所概述的工作流程的
任何偏差或更改。

注:如果在不同于本迭代测试计划的位置独立而集中地记录过程和详细计划信息，必须管理由于具有
相同信息的重复副本而产生的问题。

为避免团队成员引用过时的信息，我们建议在该情况下将最低数
量的过程和计划信息放在迭代测试计划内，从而使得正在进行的维护更简单，并且只需引用“主”源
材料。

]
9. 环境需要
[本节说明迭代测试计划所必需的非人力资源。

注:本节可以整体或部分代表测试策略工件，在该情况下本节只需注明任何调整或被删除。

] 9.1 基本系统硬件
下表阐明了本迭代测试计划中提到的测试工作的系统资源。

[测试系统的特定元素可能在较早的迭代中没有完全理解，因此预期本节随着时间推移而完善。

我们建
议系统模拟生产环境，同时在条件许可的情况下降低并发访问和数据库大小等等。

]
[注意:适当地添加或删除项。

]
系统资源
资源数量名称和类型
9.2 测试环境中的基本软件元素
以下基本软件元素在本迭代测试计划的测试环境中是必需的。

[注意:适当地添加或删除项。

]
机密 ,<Company Name>, 2011 第 9
<项目名称> 版本: <1.0> 迭代测试计划日期:<dd/mmm/yy> <文档标识> 软件元素名称版本类型和其他注释
9.3 生产力和支持工具
迭代测试计划的测试过程。

以下工具将用来支持本
[注意:适当地添加或删除项。

]
工具类别或类型工具品牌名称供应商或公司内部版本
9.4 测试环境配置
需要为本项目提供并支持以下测试环境配置。

配置名称描述在物理配置中实施
10. 职责、人员配备和培训需要
[本节说明针对迭代测试计划中概述的测试工作所必需的资源 , 主要职责及那些资源所要求的知识或
技能集
注:本节可以整体或部分代表测试策略工件，在该情况下本节只需注明任何调整或被删除。

] 10.1 人员和角色
该表显示了测试工作的人员配备假定。

[注意:适当地添加或删除项。

]
人力资源
角色建议的最低级别资源特定职责或注释
(分配的全职角色数量)
机密 ,<Company Name>, 2011 第 10
<项目名称> 版本: <1.0> 迭代测试计划日期:<dd/mmm/yy> <文档标识> 人力资源
特定职责或注释角色建议的最低级别资源
(分配的全职角色数量)
测试经理提供管理监督。

职责包括:
, 计划和后勤
, 同意任务
, 确定激发因素
, 获取适当的资源
, 提出管理报告
, 提倡测试利益
, 评估测试工作的成效测试分析人员识别和定义要进行的特定测试。

职责包括:
, 确定测试构想
, 定义测试详细信息
, 确定测试结果
, 记录变更请求
, 评估产品质量测试设计人员定义测试工作实施的技术方法。

职责包括:
, 定义测试方法
, 定义测试自动化体系结构
, 验证测试技术
, 定义可测性元素
, 组织测试实施测试员实施和执行测试。

职责包括:
, 实施测试和测试套件
, 执行测试套件
, 记录结果
, 分析测试失败并从中恢复
, 记录事件
测试系统管理员确保测试环境和资产得到管理和维护。

职责包括:
, 管理测试管理系统
, 安装和支持对测试环境配置和测试实验室
的访问及其恢复数据库管理员确保测试数据(数据库)环境和资产得到管理和维护。

职责包括:
, 支持测试数据和测试平台(数据库)的管
理。

机密 ,<Company Name>, 2011 第 11
<项目名称> 版本: <1.0> 迭代测试计划日期:<dd/mmm/yy> <文档标识>
人力资源
特定职责或注释角色建议的最低级别资源
(分配的全职角色数量)
设计人员识别和定义测试类的操作、属性和关联。

职责包括:
, 定义支持测试团队定义的可测性需求所必
需的测试类
实施者对测试类和测试程序包进行实施和单元测试。

职责包括:
, 创建为支持设计人员定义的可测性需求所
必需的测试组件
10.2 人员配备和培训需要
本节概述如何进行项目测试角色的人员配备和培训。

[进行人员配备和培训的方法根据项目而变化。

如果本节是迭代测试计划的一部分，则您应该指出在项
目生命周期中的哪些点需要不同技能和人员数。

如果这是迭代测试计划，则应该将重点主要放在迭代
过程中的哪些地方会出现哪些培训。

考虑您的培训需要，然后根据“正好及时”(JIT)方法制定计划 , 培训通常都会提前进行，因为那
时测试团队明显比较空闲，但培训内容距离实际使用还有很长时间。

这样做会引入一种风险，就是在
真正需要时培训内容已经被遗忘。

寻找机会将生产力工具的购买与那些工具培训结合起来，然后安排供应商将培训延迟到需要的时候。

如果有足够的总人数，请考虑让培训根据您定制的方式进行，可以在您所在的地点。

测试团队通常需要其他团队成员的支持和技能，而这些团队成员并不直接是测试团队的一部分。

确保
在您的计划中安排系统管理员、数据库管理员和开发人员相应地可用，这些人员是支持测试工作必需
的。

]
11. 关键迭代里程碑
[识别用于设置测试工作环境的关键进度安排里程碑。

避免重复太多在针对整个项目的计划中已经记录
过的详细信息。

]
里程碑计划开始日实际开始日计划结束日实际结束日
期期期期迭代启动同意迭代测试计划验证测试方法第一次构建交付测试机密 ,<Company Name>, 2011 第 12
<项目名称> 版本: <1.0> 迭代测试计划日期:<dd/mmm/yy> <文档标识> 里程碑计划开始日实际开始日计划结束日实际结束日
期期期期第一次构建 BVT 通过并接受进入测试
第一次构建测试周期结束 [不会测试构建 2] 第三次构建交付测试第三次构建 BVT 通过并接受进入测试
第三次构建测试周期结束第四次构建交付测试第四次构建 BVT 通过并接受进入测试
迭代评估复审迭代结束
12. 迭代计划风险、依赖关系、假定和约束
[列出可能影响本迭代测试计划成功执行的任何风险，然后识别每种风险的缓解策略和紧急情况策略。

同时为风险发生的可能性和如果发生风险将产生的影响，评定一个相对的等级。

]
风险缓解策略紧急情况(已意识到风险)
[列出在本迭代测试计划的制订中所确定的下列依赖关系，如未遵循这些依赖关系，则它们可能影响迭
代测试计划的成功执行。

通常这些依赖关系与关键路径上的活动有关，这些活动是一个或多个先行的
(或后继)活动的先决条件或后决条件。

您应该考虑所依赖的测试工作外部的其他团队或工作成员的
职责，包括其他计划任务的完成、时机选择和依赖关系，以及对所生产某些工作产品的依赖性。

依赖关系依赖关系的潜在影响所有者
[列出本迭代测试计划的制订过程中作出的下列假定，如这些假定被证明是错误的，则可能影响迭代测
试计划的成功执行。

假定可能与您认为其他团队正在进行的工作、一些期望值(产品或环境的某些方
面是稳定的)等等有关。

有待证实的假设假设不正确的影响所有者机密 ,<Company Name>, 2011 第13
<项目名称> 版本: <1.0> 迭代测试计划日期:<dd/mmm/yy> <文档标识> 有待证实的假设假设不正确的影响所有者
[列出对本迭代测试计划进行的方法有消极影响的测试工作的任何约束。

] 约束对象约束对测试工作的影响所有者
13. 管理流程和过程
[概述对主测试计划中定义的流程和过程的所有改进，这些流程和过程将在测试工作发生问题时使用。

如果没有涉及这些过程的主测试计划或基本开发计划，请在迭代测试计划中定义需要的计划。

] 13.1 核准和签字结束
[概述核准过程，并列出必须首先核准计划并在计划圆满执行后签字的工作职务(以及当前在职者的姓
名)。

]
机密 ,<Company Name>, 2011 第 14。