围绕 IBM Rational Quality Manager 构建测试自动化架构

技术狂人

' m# s! q3 j$ E& W2 Z
引言
# a+ ^0 Y5 ^+ s2 m% G6 ]; bIBM® 拥有一系列的产品，可以满足任意公司和团队的自动化需要。面临的挑战是，将它们聚集到一起以创建一个功能强大的方案。现在 IBM 记录了不仅仅使用已存在标准产品的架构，而且提供了可再用的构件，以创建一个功能强大，可定制并且可使用的自动化架构。该架构的目的不在于转变方向，而是使用已存在的构件和基础。本文中所介绍的架构提供了测试自动化的一个完整画面。公司和团队可以根据他们的需要与偏好来使用一部分的方案。

---

% f" m+ j# A$ y5 M0 }

测试自动化幻想与事实
) V) F- {' g3 E' Z  \2 p. Z, T8 Y在解释架构之前，很重要的一点在于，测试团队要能理解关于测试自动化的一些不符合实际的幻想。今天，大多数的测试团队会理解测试自动化的需要；随着时间增长测试自动化变得越来越普遍。有了测试进程的动态和不可预知的本质，以及最小化测试日程的需要，Quality Assurance（QA）管理员也意识到了测试自动化的更大需要。但是大多数的测试团队相信一些不切实际的幻想，包括：

• 所谓的测试自动化就是一系列的行动： 测试团队会将测试自动化考虑为一个接着一个执行的操作行动。但是，在实际的环境中，执行一个测试操作组成了一个复杂而又内联的事件，很多时候测试执行的本质就取决于它。手动测试可以轻松检测到复杂系列的事件，并决定测试执行的方向。不是“煮沸整个海洋”（一次完成所有操作），而是首先您要关注于，只去自动化那些让它们自身变得简单和直接的自动化程序。对很小一部分的测试步骤执行自动化，而不是对所有的步骤执行自动化。
  

• 每一次手动的测试都可以自动化： 将每一次手动的测试想成可以且应该转化为自动化的步骤，显然是不现实的。在开发自动化方案之前，估计一些将每一次测试步骤转化为自动化的步骤，成本与收益状况如何。如果自动化的步骤对节省成本的贡献并不显著，那么将手动步骤转化为自动化步骤就是不现实的。作为一个 QA 管理员，您必须就哪些步骤应该得到最大化，以及哪些步骤应该手动执行之间做出权衡。
  

• 测试自动化总是会节省成本： 大多数的团队会将开发，维护和操作自动化工具的成本，都算作自动化方案的总体成本，但是理论上行得通的在现实中不一定可行。在估计成本时，您可能会忽略测试步骤的动态及不可预测的本质。测试步骤中一个小小的改变，会许多次导致自动化工具上的显著更改，因此使得成本变得更高。其他重要的因素（就像训练测试团队，记录测试用例，以及测试自动化中所涉及到的成本）很少在考虑范围之内。
  

• 测试自动化只是购买“正确”框的事情： 团队很多次会购买大量的工具来完成他们的自动化需求，并将其作为方案的末期处理。但是很少会出现这种情况。购买一个工具，只是自动化测试步骤的第一步。团队需要分清，记录测试步骤，以及培训测试团队，哪些测试应该是自动化的，哪些应该是手动完成的。同样，只是购买一种工具，就能满足购买团队的所有需要。在工具可以完全部署之前，丢失的特性必须得到调整。预期价值与交付价值之间的差距，会导致客户的不满情绪，使得测试自动化过程失败。
  0 \3 O0 C8 `5 j3 n

---

1 \$ t* l7 g& A& E

5 _$ T: m1 @8 w6 K) s+ R' ^常见的错误
" Z5 A) K! e# @3 X. l2 @尽管您意识到上面所介绍的情况，但是有些测试团队和 QA 管理员还是会设计和开发一个测试特定团队的自动化工具。在大多数情况下，架构中有很多种的基本型错误，会导致对资源的不适当运用，开发与维护成本上升，测试自动化失败等等，测试自动化团队中所面临的这些常见的错误，列于下面：

• 非扩展性的自动化架构： 这就是在设计一个工具时，自动化开发团队最常犯的一个错误。在大多数的场景中，自动化开发团队都会设计只满足一个测试团队需求的工具。就算工具的有些特性可以被其他的测试团队使用，但是非扩展性的架构还是会阻止新测试团队采用工具。这样的一种情况，使得其他的团队去开发一个相似的工具。
  + I$ a, ]% K4 F: S3 u0 g1 J- u4 o

• 双倍的努力： 双倍的自动化努力是另一个主要的问题所在，它阻止了不同公司之间测试自动化方案的成功。正如上面介绍的那样，大多数的测试自动化方案都有一个非扩展性的架构，该架构创建了一个可重复使用的构件。您应该搜索已存在的方案和产品，以在继续开发新的项目之前进行权衡。
  " r8 p* M. D( i) O0 e; W" Z  i! `' I

• 通用工具的泛滥： 许多的测试自动化工具都是从头开始开发的。但是在很多种情况下，相同的工作流程可以通过一个已存在的产品，或者一个带有一些扩展的已存在产品来直接完成。IBM 拥有一系列的您可以直接使用的测试自动化产品，或者您可以使用它来满足大多数测试自动化团队的需求。这种方法不仅降低了完成自动化测试所需要的付出，而且促进了不同测试团队之间的标准化情况。您应该花很多时间，去研究已存在的工具，并找到一个适合具体环境的架构。
  

• 团队之间没有足够的交流或者共享： 就算团队避免了以前所提到过的那些错误，测试团队之间缺乏交流，会降低可扩展和可使用架构的有效性。对于您来说很重要的一点在于，扩展关于已存在自动化工具的词语，以增加您对它们的知识与了解，并最终最小化测试努力，并降低测试所付出的努力。
  

---

9 o5 }5 g* p2 {& m, U
" [$ }6 f3 B# R6 s' t) r6 ?+ ^测试自动化架构
5 }. b: R8 h- e, z, [2 @本段中所描述的产品，提供了一个灵活可扩展自动化架构的构件。IBM® Rational® Quality Manager 是一种基于网络中心化的测试管理环境，该环境为测试规划，工作流程控制，测试追踪以及工具报告提供了一个协作性和可定制的方案。它是架构的核心，并提供了与其他构件之间的集成点。
图 1 显示了测试自动化架构的一个完整视图，以及不同产品之间的交流。
" P9 Q- G6 s1 b' `4 Z
图 1. IBM 的测试自动化架构

; v- c4 F. z& m' M6 T
1 S" i! s! n3 B# ]$ u! _接下来，本文将会列出不同的测试自动化功能，以及用于满足这些功能需求的 IBM 产品。
注意： 该架构中还有一些双倍功能的实例，其中两个或者多个产品实施了相同的功能。最明显的选择强调显示了出来，而使用所选择功能的原因将会在下面进行介绍。

! g; U9 i* {( N/ ?. F测试管理：Rational Quality Manager
6 ~5 O' R* x# q1 ?2 ]Rational Quality Manager 是测试活动的枢纽。它对其他工具提供了系列的特性和集成，来帮助将以下的功能进行流线化和自动化：
+ _* \4 a% h% i8 l- s

• 规划测试的努力程度
• 管理需求
• 开发测试用例，测试系列，以及测试执行记录
• 开发手动测试脚本
• 管理测试资源
• 管理实验室资源
• 管理产品构建
• 执行和监视自动化测试脚本
• 交付和追踪缺陷
  7 ]6 ]: T, W1 x

使用一个 Representational State Transfer（RESTful）接口架构，Rational Quality Manager 提供了与外部性产品（例如 IBM® Rational® Requirements Composer 以进行需求管理）之间的集成，以及与接下来章节中所描述的其他产品相集成。
Rational Quality Manager 还以这样一种方式来设置了 RESTful 接口，您可以出于不同的目的考虑来编写可以读可以写 Rational Quality Manager 资源的通用适配器。举个例子就是您可以将已存在的测试自动化框架与 Rational Quality Manager 服务器集成起来，这样您对 Rational Quality Manager 的部署就可以是一个渐次的过程，而不会是“淘汰并替换”（一次完成）。
. |+ a' e( r$ U( a
& Q! w; a9 W' }$ N4 V5 ZRational Quality Manager 中的报告
) w7 Y3 g, w6 \; T* e有了 Rational Quality Manager，您还可以得到一个企业类报告方案，与 IBM® Rational® Insight 产品。许多的标准数据项目和测试报告已经提供，以与 Rational Insight 一起使用。使用 Rational Insight 开发工具，您就可以指定其他的数据，来在 Rational Insight Data Warehouse 构件之中进行收集操作，发布特定的数据仓库元数据来简化报告授权机制，而授权大量的通用报告以及操作板。Rational Insight 还支持报告区域或者服务器。
) ~; g) X9 H) W1 c+ u7 K! ?与 Rational Team Concert 集成的创建缺陷
+ a! l0 k+ I/ P$ G! t/ k( }. j3 Y您可以将 Rational Quality Manager 与 IBM® Rational Team Concert™ 集成起来，以允许您来使用 Rational Team Concert 作为缺陷提供者，并使用 Rational Quality Manager 来将缺陷与其他的工作项进行同步化。在创建该集成之后，您就可以追踪 Rational Quality Manager 之中的工作项了，就算工作项是在 Rational Team Concert 中维护的也是这样。

T ClearQuest 连接
6 k) v4 O, Y5 x您可以使用 ClearQuest 连接来将 Rational Quality Manager 与 IBM® Rational® ClearQuest® 缺陷追踪系统集成起来。ClearQuest 连接使得您可以从 Rational Quality Manager 环境下直接处理 ClearQuest 记录。您可以创建，查看，并编辑 ClearQuest 记录，运行 ClearQuest 查询，并将 ClearQuest 记录与 Rational Quality Manager 执行结果联系起来。ClearQuest 连接并不需要创建和维护同步化规则，或者在多个存储库之间复制数据；它直接与 ClearQuest 数据相联系。
测试资源提供：Tivoli Provisioning Manager
) Z) E. e  L! s# ^$ d9 p3 P( s& J& aIBM Tivoli Provisioning Manager 就是用于自动化数据中心提供活动的 IBM 企业类构件。它提供了大量的功能，其中包括：
( G# f0 l2 d0 W% R2 P

• IT 资源的探索
• 操作系统，软件包，存储以及网络资源的提供
• 可以在一个测试实验室内呈现所有 IT 资源的具体数据中心模型
• 一个强大的自动化包开发环境来创建和定制自动化包
• 一个自动化引擎用于在远程电脑上执行和监视自动化包
• 可以用作通用工作流程范例的自动化包库
• 软件一致性管理和许可证管理
  7 X1 L" X) K5 L  @

Tivoli Provisioning Manager 提供了一个 SOAP（简单开放源访问协议）接口，促进了与其他软件构件之间的集成。使用这个接口，外部性的构件就能够请求操作（例如，探索或者交付工作项流程的执行），或者从数据中心模型那里获取信息。
在测试自动化架构之中，Rational Quality Manager 开发员通过它的集成接口，向 Tivoli Provisioning Manager 提供了任务。该集成使得可以在 Rational Quality Manager 的实验室管理子系统直接看到 Tivoli Provisioning Manager 资源以及自动化包。作为测试工程师，您可以请求对一个或者更多的实验资源执行自动化项目。Rational Quality Manager 接口简单地请求 Tivoli Provisioning Manager 执行一个自动化项目，然后显示结果可知时的自动化项目的结果。
3 |. z4 H) n3 M- m/ L: L2 \) jTivoli Provisioning Manager 的大量特性可以产生复杂性，因为您可以对每一个想象到的自动化任务使用它。与之相反，我们的注意力在于那些 Tivoli Provisioning Manager 单独处理的特性：这就是，在测试实验室基础上管理复杂的任务。例如，使用它来管理所有需要平台上操作系统的提供。简单一点的自动化任务可以由一般目的工作流程引擎，IBM® Rational® Build Forge®，轻松地处理。
: O. c  I0 W. |, H& B
/ v" x- M3 \& u* w) T  A/ z每一个站点一般意义上都有 Tivoli Provisioning Manager 的一个单个产品实例，但是还是可能会有一些特殊的环境，那里 Tivoli Provisioning Manager 服务器要判断不止一个产品。
; n5 s: L: D, q2 V+ Y' x
$ {; G$ b- ~2 M8 ?/ q4 S# \一般目的自动化引擎：Rational Build Forge
) J  k& n4 J0 E" V$ VRational Build Forge 是架构之中的工作流程引擎。它是能让您指定包含有执行步骤项目的直接产品。其中的步骤可能是一个命令，也可能是多个，要在测试基础上在一个选中的服务器上执行。Rational Build Forge 自动化项目可以以一种它们能够嵌入到大型项目的方式写入。它为您提供了一个简单的机理，以使用一个测试良好，较低层次构建块项目的联合体，来部署非常复杂的自动化过程。
1 d% b1 n8 u" D$ _( F. J# A! f# L
2 k% \- [; d5 _2 M0 kRational Build Forge 为项目步骤失败时的错误检测和恢复机制提供了一个内构的机理。您可以指定在一个错误发生时接下去执行另一个项目。该项目可以在失败之后，继续自动化过程之前清除掉。这也是环境的概念，使得自动化逻辑能够在运行时建立价值。

Rational Build Forge API，与 Java™ 和 Perl 绑定，呈现了来自用户界面（UI）的大多数特性。有了它，您就可以创建扩展了，例如来自一个外部性规格的动态构筑测试项目。例如，您可以创建一个降级测试项目，该项目由一些与特定发布代码相关的降级测试。它支持对关注点进行分割，这样决定执行什么测试的责任，就位于 Rational Build Forge 的关注点之外了，它只对准备测试环境，并根据自己的环境之下测试负责。
# e4 |5 z* X# K. z在测试自动化架构之中，Rational Quality Manager 会通过它的集成接口来向 Rational Build Forge 分配自动化任务。有了该集成，Rational Build Forge 服务器以及项目就可以出现在 Rational Quality Manager 的实验室管理子系统之中了。您可以选择对一个或者多个实验室资源执行一个自动化项目。而且，复杂的测试场景可以在 Rational Quality Manager 中构筑，它包含了一个创建阶段，一个自动化的测试系列执行阶段，以及一个分解阶段。测试创建和分解可以在 Rational Build Forge 之内进行自动化。Rational Quality Manager 接口只是简单地请求 Rational Build Forge 执行一个自动化项目，并在继续到下一步之前等待结果。
% h; O# T8 n# |. n) L
; y6 {2 h2 H5 M, S4 o. v; n可能有一些 Rational Build Forge 的产品实例：预期每一个产品测试区域有一个。
UI 自动化工具：Rational Functional Tester
您的团队可以使用 IBM® Rational® Functional Tester 来执行您的 UI 自动化测试。您使用 Rational Functional Tester 所测试的 UI 程序的类型包括以下内容：

• 基于网络的程序
• Microsoft® .Net 程序
• Java 程序（例如，SWT（Eclipse）或 Swing）
• Applications for 3270（IBM® zSeries®）以及 5250（IBM® iSeries®）
• Siebel 程序
• SAP 程序
• Flash 程序
  

一些重要的 Rational Functional Tester 特性有：

• 生命周期追踪性：Rational Functional Tester 提供了 IBM® Jazz™ 集成，以支持协作性的程序生命周期管理。Jazz Eclipse Client 2.0 版本集成提供了 Rational Functional Tester 对 Rational Team Concert 和 Rational Quality Manager 中工作项的访问途径。另行改进的 SCM（软件配置管理器）与 Rational Team Concert 之间的集成支持测试资源的管理和共享。
• 流线化 GUI 测试自动化的关键字测试：Rational Functional Tester 提供了定义和自动化可以在功能性测试和手动测试中重用的关键字。这可以促进脚本的重用，并使得手工测试员轻松且有选择地使用手动测试周期内自动化的功能。
• Java 或者 Visual Basic .NET 之间测试编辑语言的选择：测试脚本定制是强制性的，以执行大多数的基本测试。Rational Functional Tester 给您提供了一个选项，一个功能强大主流的脚本语言，来使得这一切成为可能。两个选项都可以与所有支持的用户界面技术一起使用。
• 对 Microsoft® Internet Explorer，Firefox 与 Adobe® PDF 的支持： Internet Explorer V8.0，Firefox V3.0 与 Adobe PDF V7.0 和 V8.0 中对 HTML 程序的功能性测试支持。您还可以测试 HTML 页面，该页面会载入到 Internet Explorer 之中的多项。
  & L5 k0 m7 ]$ ]6 U: ^' E

有了 Rational Functional Tester，您需要决定 Rational Functional Tester 的记录回馈功能是否适合于您的自动化测试。如果测试下的程序（ABT）是一个短期内的项目（单个版本），或者它的 GUI 更改在不同的版本之间受到了限制，那么使用记录回馈机制也许是合适的。否则，您应该有计划地实施 GUI 自动化测试步骤，并且只将记录回馈作为脚本的帮助使用。
您应该将测试脚本写成，在 AVT 中应该测试什么，以及怎样在 UI 内以单独的类方法来完成它。这就是说，您的测试脚本应该包含有一系列的方法调用，此时每一种方法都表现为在 AVT 中实施给定的任务和功能。UI 中操作的隔离就是降低不同版本之间降低维护成本的关键所在。

实验室资源管理：Tivoli Application Dependency Manager 与 Tivoli Change 和配置管理数据库
您可以使用 IBM® Tivoli® Application Dependency Discovery Manager（TADDM）来搜索 IT 资源，以及这些资源之间的附属。使用 TADDM 无代理探索技术来识别主机，存储以及网络构件，例如路由器，切换器，以及数据中心中的防火墙，还有程序，中介以及数据库。TADDM 会探索构件之间的关系，以及每一个构件是如何配置的，以及识别它们随着时间如何变化。TADDM 还会发现 IBM 或者其他 Storage Resource Manager 产品中所定义的资源，例如，IBM TotalStorage® Productivity Center。
  q3 r- j6 B0 r8 T' ~TADDM 拥有一个 Java API，它支持与其他软件构件之间的集成。有了这个 API，外部性的构件就能够请求探索，并获取关于探索资源的信息了。
/ H1 ^& Y" [5 J. e/ i( E在测试自动化架构内，Rational Quality Manager 会与 TADMM 相集成，以提供一个良好的方式，去实现实验室管理子系统中的资源。您可以使用 TADMM，以及来自 Tivoli Provisioning Manager 和 Rational Build Forge 探索的电脑资源来实现 Rational Quality Manager Lab Manager。另外，TADMM 可以自动维护所有可用资源的具体清单，以进行测试，并简单地共享高价值的实验室资源。
7 s+ R2 H5 b' r7 W每一个站点一般都有 TADMM 的单个产品实例。这些 TADDM 的站点实例可以集成到公司端的 CCMDB 实例，以提供实验室资源的企业视图。

---

7 L1 M/ d, j) k- ~IBM 的测试自动化策略带来的优势
& }( h- {/ H' S3 [使用以上描述的架构，测试自动化团队就可以降低测试的费用了，改进测试的层次与质量，并降低部署新测试自动化功能所需要付出的努力。使用该架构交付的生产力，会鼓励您的的公司进行更频繁和更完整的测试。除了消除 常见错误 部分中所提到过的错误，IBM 的测试自动化策略对您的测试团队带来了以下的优势：
& `% A$ e1 k' t, A7 j5 X6 v

• 时间因素：有许多测试自动化效果得到了通用的开发，这就使得开发和维护的成本上升。使用已存在的产品作为新测试自动化基础，改变了集成的关注点，而不是开发的关注点。测试自动化团队并不会突然转变方向。这就意味着更短的开发迭代时间。产品投入实用之前的时间因此得到降低，而最终产品也将会更快地发布到市场上。
  

• 可得的更高技巧：使用一般的测试自动化构件以及标准的产品，意味着有技巧测试自动化开发员可以更容易地达到了。测试自动化团队将会意识到标准产品与对它们的使用。另一方面，测试团队可以更多地关注于测试开发，更深地开发，综合地开发以测试产品。通过将手动测试员从执行相关任务之中解放出来，测试自动化就可以使得它们关注使用他们的创造力，知识，以及本能来更加有效地进行测试。
  

• 生产力：许多的测试团队会花很多的时间，去开发自动化工具，而不是仅仅去测试。通过重用已存在的产品，创建固定的测试自动化开发团队，测试员就可以关注测试了。他们不需要关注开发和维护测试自动化构件了。这将会再次促进更好的测试，以及交付更稳定的产品。
  

• 低成本：集成而不是开发，将会降低开发的周期。通过在不同的测试团队之间使用相同系列的产品和自动化构件，开发的成本就会得到进一步的降低。
  0 P1 v/ R2 y' p; a

• 标准化：测试团队所面对的一个主要问题在于不能集成化的，不能共享的自动化构件。缺乏在测试自动化努力中的标准，是导致这个问题的主要因素。在可重用构件中使用已存在的产品并考虑测试自动化，将会产生一个测试自动化工具，可以进行更轻松的集成和重用。
  4 I; V4 r5 X  R+ L* _9 w

---

8 R- v1 n+ Z  o3 W( q; D" {
8 _$ ]% u8 D0 T1 Y, S8 }
您学到了什么
* S! i$ E' J/ p% a$ \本文展示了测试自动化的架构。使用这个架构，鼓励您去设计和开发自动化工具，该工具会直接使用已存在自动化产品的功能。您可以创建工具设计，该设计是可扩展的并且可以由其他的测试团队使用，并最终促进标准化。通过这种方式，您就可以全面意识到测试自动化的威力了。

技术狂人

原文地址：http://www.ibm.com/developerwork ... -manager/index.html