模板
教程
环境
性能
功能
管理
软件测试 > 测试技术 > 软件测试工具 > Rational软件测试工具 > TestManager >
[原创]以IBM Rational TestManager为核心的测试管理2
发表于：2008-04-07来源：作者：点击数：
标签：
[原创]以IBM Rational TestManager为核心的 测试管理 2 作者：aken 1 、 TestManager 简介 TestManager 是一个开放的、可扩展的框架，它将所有的 测试工具 、工件和数据组合在一起，帮助团队制定并优化其 质量 目标。其工作流程主要支持 测试计划 、测试设计
[原创]以IBM Rational TestManager为核心的测试管理2
作者：aken
1、TestManager简介
TestManager是一个开放的、可扩展的框架，它将所有的测试工具、工件和数据组合在一起，帮助团队制定并优化其质量目标。其工作流程主要支持测试计划、测试设计、测试实现、测试执行和测试评估等几个测试活动。
图1
从图1中，我们可以看到TestManager可以创建和运行测试计划、测试套和测试脚本，可以插入测试用例目录和测试用例，进行测试用例设计，对迭代阶段、环境配置和测试输入进行有效的关联。可以创建和打开测试报告，其中有测试用例执行报告、性能测试报告，而且很多其他类的报告，还可以创建SoDA的Word格式的文档。
除此以外，TestManager还有很多辅助的设置，其中包括：创建和编辑构造版本、迭代阶段、计算机、计算机列表、配置、配置属性、数据池、数据类型、测试输入类型、测试脚本类型等等，还可以定制系统需要的属性。
2、测试流程比较关于软件测试流程，网上大家讨论得也很多，我们来看一个最简单和常用的测试流程：根据软件需求规格说明（Word格式）文档，书写（Word格式）测试计划，设计（Word或Excel格式）测试用例，根据软件Build的版本执行测试用例，记录（Word或Excel格式）执行结果，发现并提交（Word或Excel格式）缺陷报告给开发人员，跟踪所有缺陷直至解决，提交最终（Word格式）测试分析报告。
那么IBM Rational的软件测试流程是否就有很多独到之处那？我们还是先来看看吧。从图2中可以清楚看到，IBM Rational将所有的需求作为测试输入，根据测试输入来制定测试计划，整个测试计划的核心就是规划、组织和设计测试用例，通过手工测试和自动化测试两种方式来实现测试用例，然后进行测试用例执行，记录测试用例执行结果，并将发现的缺陷提交到缺陷管理系统中，最后对测试结果进行评估。
表面上看，IBM Rational的测试流程和我们常用的测试流程并没有太大的区别，但是详细的研究和应用之后，你会发现TestManager将需求、测试计划、测试用例设计、测试执行、测试报告和测试缺陷全部集成，通过相互的关联关系，更体现了其强大的自动化管理的功能。所以说，TestManager是非常适合我们日常测试管理应用的工具。
图2
3、测试输入（系统功能需求）计划测试工作的第一步就是验证测试的输入。测试输入就是测什么的问题，以及哪些需要验证。测试输入帮助我们对什么需要测试作决定，而且帮助我们确定当开发过程的基线发生变化时，那些测试需要改变。在迭代开发过程中，由于各种变更非常频繁，所以这点非常重要。
TestManager内置了三种测试输入类型，即：IBM Rational RequisitePro中的需求、IBM Rational Rose中的可视化模型和Microsoft Excel电子表格中的数据。 其主要目的是将输入的测试需求与相应的测试用例、测试执行关联，便于对需求进行跟踪确认。
本次测试实例是测试时代Bug管理系统，是一个小型的缺陷管理系统，基本流程是：测试人员提交新的Bug，然后进行分配，开发人员处理相应的Bug，最后测试人员验证修复的Bug直至关闭。界面如图3
图3
测试输入的实例是测试时代Bug管理系统的一份Excel的需求文档和一份受控于RequisitePro的Word格式的需求文档。如图4和图5
图4
图5
我们通过TestManager中的测试输入的属性将Excel格式的需求导入到TestManager中，通过选择将RequisitePro中的需求关联，这样测试输入就设置好了，我们可以开始制定测试计划。详细如图6
图6
测试计划书写测试计划要解决以下几个问题：第一个，What和Where？主要是通过需求、可见的模型、和其它测试输入来告诉你哪些需要测试，在哪里测试；第二个，Why？测试输入可以告诉我们为什么要在某些地方进行测试，即通过需求的优先级逐级的对系统需求进行验证；第三个，When？迭代计划可以告诉我们什么时候进行测试，什么时候必须通过测试。第四个，Who？测试计划、迭代计划、或者项目计划告诉我们谁去执行这些测试活动。
那么，明确了这些，而且系统功能需求已经作为测试输入导入到了TestManager中，这样我们就可以开始制订测试计划。
我们在日常的测试工作中，测试计划文档通常都是比较详细的，RUP测试计划模板中一般会包括：简介（目的，背景，范围，项目标识）、测试需求、测试策略、测试类型（数据和数据库完整性测试，功能测试，业务周期测试，用户界面测试，性能评价，负载测试，强度测试，容量测试，安全性和访问控制测试，故障转移和恢复测试，配置测试，安装测试）、工具、资源（角色，系统）、项目里程碑、可交付工件（测试模型，测试日志，缺陷报告）、附录A：项目任务等等。
那么TestManager中的测试计划是否就是我们传统的测试计划文档那？其实不然，传统的测试计划在这里可以作为一个项目的总体测试计划，而TestManager中的测试计划主要是将总体测试计划细化，针对系统功能和性能部分，进行规划、组织和详细设计测试用例，其中包含几个主要的任务：收集和标识测试输入（需求）、建立测试计划、创建测试用例文件夹、创建测试用例、定义测试配置、定义迭代阶段等。在TestManager中可以外部关联整体测试计划文档。其实TestManager最擅长是对系统的功能和性能测试的管理，所以通常我们将这部分计划用TestManager来管理和跟踪，而测试进度这部分可以由类似于微软的Project工具来管理和跟踪。
下面我们通过实例说明在TestManager中如何制定测试计划。首先新增加一个测试计划，计划名称为“功能测试”，具体操作：点击菜单File > New Test Plan；接着创建两个测试用例文件夹：“登录系统测试”和“Bug管理流程测试”；最后我们将总体测试计划外部关联。在TestManager中的具体表现形式如图7。
图7
在TestManager中，这种标签形式的测试计划不方便预览，所以转化成我们最熟悉的表格的形式来看。如表1
表1
测试计划制定完成后，接下来我们要进行测试用例设计。
那么IBM Rational的软件测试流程是否就有很多独到之处那？我们还是先来看看吧。从图2中可以清楚看到，IBM Rational将所有的需求作为测试输入，根据测试输入来制定测试计划，整个测试计划的核心就是规划、组织和设计测试用例，通过手工测试和自动化测试两种方式来实现测试用例，然后进行测试用例执行，记录测试用例执行结果，并将发现的缺陷提交到缺陷管理系统中，最后对测试结果进行评估。
表面上看，IBM Rational的测试流程和我们常用的测试流程并没有太大的区别，但是详细的研究和应用之后，你会发现TestManager将需求、测试计划、测试用例设计、测试执行、测试报告和测试缺陷全部集成，通过相互的关联关系，更体现了其强大的自动化管理的功能。所以说，TestManager是非常适合我们日常测试管理应用的工具。
图2
3、测试输入（系统功能需求）计划测试工作的第一步就是验证测试的输入。测试输入就是测什么的问题，以及哪些需要验证。测试输入帮助我们对什么需要测试作决定，而且帮助我们确定当开发过程的基线发生变化时，那些测试需要改变。在迭代开发过程中，由于各种变更非常频繁，所以这点非常重要。
TestManager内置了三种测试输入类型，即：IBM Rational RequisitePro中的需求、IBM Rational Rose中的可视化模型和Microsoft Excel电子表格中的数据。 其主要目的是将输入的测试需求与相应的测试用例、测试执行关联，便于对需求进行跟踪确认。
本次测试实例是测试时代Bug管理系统，是一个小型的缺陷管理系统，基本流程是：测试人员提交新的Bug，然后进行分配，开发人员处理相应的Bug，最后测试人员验证修复的Bug直至关闭。界面如图3
图3
测试输入的实例是测试时代Bug管理系统的一份Excel的需求文档和一份受控于RequisitePro的Word格式的需求文档。如图4和图5
图4
图5
我们通过TestManager中的测试输入的属性将Excel格式的需求导入到TestManager中，通过选择将RequisitePro中的需求关联，这样测试输入就设置好了，我们可以开始制定测试计划。详细如图6
图6
测试计划书写测试计划要解决以下几个问题：第一个，What和Where？主要是通过需求、可见的模型、和其它测试输入来告诉你哪些需要测试，在哪里测试；第二个，Why？测试输入可以告诉我们为什么要在某些地方进行测试，即通过需求的优先级逐级的对系统需求进行验证；第三个，When？迭代计划可以告诉我们什么时候进行测试，什么时候必须通过测试。第四个，Who？测试计划、迭代计划、或者项目计划告诉我们谁去执行这些测试活动。
那么，明确了这些，而且系统功能需求已经作为测试输入导入到了TestManager中，这样我们就可以开始制订测试计划。
我们在日常的测试工作中，测试计划文档通常都是比较详细的，RUP测试计划模板中一般会包括：简介（目的，背景，范围，项目标识）、测试需求、测试策略、测试类型（数据和数据库完整性测试，功能测试，业务周期测试，用户界面测试，性能评价，负载测试，强度测试，容量测试，安全性和访问控制测试，故障转移和恢复测试，配置测试，安装测试）、工具、资源（角色，系统）、项目里程碑、可交付工件（测试模型，测试日志，缺陷报告）、附录A：项目任务等等。
那么TestManager中的测试计划是否就是我们传统的测试计划文档那？其实不然，传统的测试计划在这里可以作为一个项目的总体测试计划，而TestManager中的测试计划主要是将总体测试计划细化，针对系统功能和性能部分，进行规划、组织和详细设计测试用例，其中包含几个主要的任务：收集和标识测试输入（需求）、建立测试计划、创建测试用例文件夹、创建测试用例、定义测试配置、定义迭代阶段等。在TestManager中可以外部关联整体测试计划文档。其实TestManager最擅长是对系统的功能和性能测试的管理，所以通常我们将这部分计划用TestManager来管理和跟踪，而测试进度这部分可以由类似于微软的Project工具来管理和跟踪。
下面我们通过实例说明在TestManager中如何制定测试计划。首先新增加一个测试计划，计划名称为“功能测试”，具体操作：点击菜单File > New Test Plan；接着创建两个测试用例文件夹：“登录系统测试”和“Bug管理流程测试”；最后我们将总体测试计划外部关联。在TestManager中的具体表现形式如图7。
图7
在TestManager中，这种标签形式的测试计划不方便预览，所以转化成我们最熟悉的表格的形式来看。如表1
|
Name |
功能测试 |
Owner |
测试时代 |
|
Descrition |
导入Excel格式的测试需求或导入RequisitePro中管理的测试需求，设计测试用例，并进行测试覆盖和测试跟踪。 | ||
|
Created by |
测试时代 |
Modified on |
2003-9-18 13:00:00 |
|
Modified by |
测试时代 |
Modified on |
2003-9-18 13:00:00 |
|
Iterations-
Configurations |
集成测试阶段，系统测试阶段 |
External Documents |
测试计划.doc |
|
Custom |
Test Phase：系统测试 Tester：测试时代 Schedule：2003-9-1 到 2003-9-10 | ||
测试计划制定完成后，接下来我们要进行测试用例设计。
