本文主要介绍在 IBM Rational ClearQuest 的开发过程中，如何在开发的各个阶段应用各种不同的自动化测试保证开发质量。
IBM Rational ClearQuest 是 Rational 家族产品中的核心成员。它可以在整个应用程序开发生命周期中提供灵活的缺陷和变更跟踪功能。
目前，ClearQuest 产品还处于不断升级和维护中。如，对 ClearQuest 本地化的支持，向
Eclipse 平台的移植，ClearQuest Web 的升级，自身功能的升级，以及与 Jazz 的集成等等。
产品的质量和实用性决定了其在客户眼中的地位，ClearQuest 也不例外，质量对于 ClearQuest
的开发和升级至关重要。ClearQuest 发展至今，其代码量几乎可以用 G 来计算；并且其中包括了各种各样的组件，如
ClearQuest 的核心部分、Windows 本地客户端部分，ClearQuest 支持的 Eclipse
平台以及 Web 等等。ClearQuest 的开发团队和测试团队分布于美国的 Lexington、Raleigh、中国和印度。在这样超大重量级的产品开发中，加上遍布各地的庞大的开发团队，如何保证开发质量成为了一个至关重要的问题。
ClearQuest 开发过程中的质量保证环节包括各种阶段交付内容（包括各种文档、设计、代码）的审查、优化的开发流程的应用、各种测试（单元测试、功能测试、性能测试、系统测试等）的引入以及对开发相关人员的培训等等；质量保证中应用到的工具包括软件配置管理工具
ClearCase，缺陷跟踪管理工具 ClearQuest（在 ClearQuest 的开发过程中，ClearQuest
本身也作为质量保证工具来使用）、各种自动化测试工具及其框架等等。
本文主要介绍在 ClearQuest 的开发过程中，如何在开发的各个阶段应用各种不同的自动化测试保证开发质量。
我们在开发的过程中采用了自动化测试技术及测试驱动开发的方法。运用这两项技术，使得整个开发团队能够在产品开发过程中获得更高的效率，并更有效地保证了软件产品开发的质量。自动化测试和测试驱动开发贯穿
ClearQuest 开发过程的始终，是整个开发周期中不可缺少的重要环节。
自动化测试及其优点
一般我们谈到的自动化测试，其实是有两种说法，一种是 Test Automation，翻译过来叫测试自动化，侧重说明将测试用自动化设计和实现的过程；另外一种是
Automated Testing/Test，翻译过来叫自动化测试，侧重说明自动的测试软件，可以是自动测试软件的功能或者性能等。在本文中提到的自动化测试，是一个整体的概念，包括了以上两种。
随着计算机技术的发展，自动化测试工具的广泛应用为开发和测试人员提供了最优的质量成本。我们在软件开发过程中应用自动化测试，也正是在追求软件质量成本和收益间的最佳平衡点。
自动化测试的应用，需要开发和测试人员进行很多前期的工作，如自动化测试框架的设计和实现，自动化测试用例的实现等，而且，目前即使是应用现成的自动化测试工具，也无法避免这些工作。在这种情况下，自动化测试又是如何能够保证质量成本和收益间的平衡呢？下面列举出的自动化测试的优点很好地回答了这个问题。
计算机在执行功能测试脚本的时候比人快得多，因此在有限的时间里能测试的更多，可以按时完成更多的工程
自动测试可以在非工作时间和节假日自动进行。
执行测试脚本，用自动化的工具对不断变化的应用和环境做回归测试，要比手工测试容易得多。
自动化测试鼓励测试团队规范化他们的过程，以得到更高的一致性和更好的文档记录。
测试一旦脚本化，开发人员可以使用和重用这些脚本，没有必要为每个应用的相同功能而重新创建脚本。
开发人员在等待测试人员测试出错误的时候，通常需要很多时间。事实上在迭代周期很短的开发模式中，这种问题更为严重，但自动化测试可以解决其中的主要矛盾。
总之，自动化测试通过自动执行测试脚本，使得人们能够用最短的时间完成更多的测试，并且可以用更高的频率执行测试，从而有效降低测试成本、提高测试效率。这就是自动化测试的优点和最终目的。
自动化测试的类型
在软件开发过程中，无论是 Agile 还是其它开发模式，都会在开发的不同阶段引入相应的测试，如单元测试，功能测试，性能测试；并且针对软件的不同部分，也会有不同的方法进行测试，如
GUI 测试，底层 API 测试等等。
目前，软件工作者们正在努力把这些不同类型的测试进行自动化，将自动化测试的优点应用在软件开发过程中的各个阶段以及软件的需要测试的各个部分。
当前软件开发中主要用到的自动化测试类型有以下几种：
单元测试是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。
用户界面测试，属于功能测试的一种。
功能测试是从用户的角度编写的测试。这种测试确保系统执行用户期望它执行的工作。
用来测试软件在集成系统中的运行性能。
在 ClearQuest 的开发项目中，包括了上面提到的各种自动化测试。ClearQuest 中应用到的各种自动化测试如下：
ClearQuest Core 部分的单元测试以及一部分简单的功能测试
- ATE（Automation Test Environment）
针对 CQ Perl API 和 COM 的简单的功能测试
ClearQuest Windows Client 的用户界面测试
CQEclipse 和 CQWeb 的单元测试
包括 CQEclipse GUI 和 CQWeb GUI 自动化测试
ClearQuest Core 中用于检测内存泄漏。可以在运行 harness test 的时候一起执行。
- RPT（Rational Performance Tester）自动化性能测试
目前的 ClearQuest 开发中利用 RPT 来做自动化性能测试，包括自动录制的脚本和手动开发的测试用例。
不同的自动化测试被应用于不同的层次和组件上。那么，我们就需要从 ClearQuest 的结构出发来看一下这些不同的自动化测试的应用。按照测试所对应的编程语言来分类，Harness
Test，PurifyPlus 和 Windows GUI 用于 C++ 代码，RFT 自动化测试和 JUnit
应用于 Java，ATE 应用于 CQ Perl API 和 COM。下面的图表可以帮助我们更清楚地理解
ClearQuest 的架构层次以及各个部分所用到的自动化测试的种类。
图 1：ClearQuest 在 Windows 上安装的架构层次图
表 1：自动化测试与 ClearQuest 各个部分之间的对应关系
| |
Windows Client |
CQ Eclipse |
CQ Web |
CQ Core |
CQ Perl API |
COM |
| Harness Test |
|
|
|
X |
|
|
| ATE |
|
|
|
|
X |
X |
| Windows Client GUI Automation Test |
X |
|
|
|
|
|
| JUnit Test |
|
X |
X |
|
|
|
| RFT（BLUETA） |
|
X |
X |
|
|
|
| PurifyPlus Memory Check |
|
|
|
X |
|
|
在后面的章节中，我们将详细地介绍 ClearQuest 的开发过程是如何结合这些不同的自动化测试的。
在 Agile
开发过程中采用测试驱动开发作为指导原则
ClearQuest 的开发采用了
Agile 开发方法③。测试驱动开发
(Test Driven Development)④ 是 Agile 开发过程中的一个核心思想，而自动化测试又是做到测试驱动开发的一个基本条件。有了自动化测试的框架，才能保证测试代码和源代码同时开发，做到测试驱动。
由于 Agile 开发本身具有开发迭代周期短，每个迭代的成果都是可使用的特点，这就要求做到如下几点：
- 保证所做的开发工作没有偏离用户需求
- 在有限的时间内，充分利用有效资源，保证代码质量
- 每个迭代中所提交的成果都是后期可用的，尽可能避免重复劳动
这些要求决定了自动化测试在 Agile 开发过程中的重要地位。利用自动化测试，在测试框架成型和一个迭代中的设计接口已经确定的情况下，源码和测试代码的开发可以同步进行，在充分利用有效资源的同时，如果开发人员在开发的过程中偏离了用户需求，在进行自动化测试的时候还会发现并纠正这些问题；在重量级软件开发和维护中，手工测试很难每次覆盖所有功能（如果要覆盖所有功能，需要相当长的时间，而且所需的时间随着功能的增多还会逐渐增加），而利用自动化测试，则可以通过测试用例的逐步积累而使得整个测试框架涵盖所有功能（自动化脚本可以在夜间以及节假日运行，不需要耗费人力），所以每次运行自动化测试都相当于运行所有功能的完整的测试，并且都能发现当前迭代中的开发工作是否对以前所有其他的功能是否造成影响；Agile
开发的迭代周期很短，这就要求所有的工作更为有效，自动化测试可以帮助开发人员高效地完成测试工作，不必为每次都花费人力和时间运行重复的人工测试而烦恼；并且自动化测试可以在非工作时间运行，也就是说在测试代码开发完毕之后，其测试工作可以不占用工作中的有效时间。
由此看来，Agile 开发过程中，无论从软件的实用性，质量保证还是开发效率的角度，都离不开自动化测试。
ClearQuest 开发过程中对各种自动化测试的应用，主要取决于两个因素：ClearQuest 本身的结构和开发过程中的开发阶段。本文
2.2 节中，从 ClearQuest 本身的结构出发描述了各种不同的自动化测试的应用。而本节将从 ClearQuest
开发过程的角度出发，来描述各种不同的自动化测试的应用。
ClearQuest 开发过程采用了 Agile 开发方法，在 Agile 的每一个迭代中，根据 ClearQuest
本身的结构和每个迭代开发过程中的各种不同需要，应用了上一个章节中所列举出的各种自动化测试。我们将结合 ClearQuest
的一个模拟开发实例，描述各种不同的自动化测试在一个 Agile 的迭代过程中被引入的具体阶段和具体场景。
在 ClearQuest 的各个开发阶段中，对各种不同的自动化测试，如单元测试、功能测试等，又会有不同的侧重。图
2 从整体上对 ClearQuest 开发过程中对各种自动化测试的应用做了描述。
图 2：各种自动化测试在开发过程中各个不同阶段应用的频率
在图中我们可以看到，单元测试从开发过程的开始阶段就被引入，并且贯穿整个开发过程的始终，因为只要有代码的变动就会有单元测试的发生，但随着开发过程进入后期，代码修改量逐渐变少，单元测试应用的频率也会逐渐降低。功能测试中包括的新的测试，在每个迭代结束的时候发生，而之前在每个迭代中期，由于不停地有代码修改，但是新的功能测试的用例还未开发完毕，所以需要周期性地做回归测试，随着后期代码修改逐渐减少，功能回归测试的频率也会随之降低。性能测试在功能测试开始的时候就尽可能被引入以便发现一些设计上的问题，而在开发过程的后期，由于整个功能已经集成起来，更多的性能测试的用例可以被执行，并发现更多的问题。
让我们以一个 CQ Eclipse 的新功能的开发为例，来更形象地说明这个问题。
该功能涉及以下两个部分：
- CQ Eclipse GUI 和相应事务逻辑
- 在 CQ Core 中实现新的 API，该 API 需要被应用于 perl 和 Java
从前面的表 1 可以看出来，这个案例中，除了 Windows Client GUI 自动化测试以外，其他的自动化测试将全部在此功能的开发中有所应用。该功能的开发总体计划模拟甘特图如下图。图中仅仅给出了开发最初的
4-5 个月内的总体计划，但足以说明各种自动化测试的作用。
图 3：模拟 ClearQuest 中一个新功能开发计划的前期甘特图
（查看大图）
甘特图中的几个主要的任务包括：ClearQuest Eclipse GUI 原型开发和测试，CQ Core
API 的开发以及 ClearQuest Eclipse GUI 和 CQ Core API 的整合。
绿色的字体标记的任务即为各种自动化测试的开发和运行。
红色的方框圈起来的部分可以视为一个迭代完成的任务，在图中列出的所有任务中，任务 1，8，10，13，19
及其各自的子任务即为 Agile 开发过程中的各个迭代（在后面的描述中我们将按照任务的 ID 来命名各个迭代过程，如，ID
为 1 的任务所对应的迭代为迭代 1。）每个迭代的过程中又包括不同的阶段，如，代码开发阶段，功能测试阶段等等。
蓝色的方框圈起来的部分为源代码和它所对应的单元测试。
上面给出的甘特图的 ClearQuest 的各种自动化测试中，由于各种自动化测试被应用在不同的编程语言开发的组件上或者应用在不同的功能部件上，并且也不是每一个迭代都包括所有部件的开发，所以不是所有的自动化测试都会被应用在每一个迭代中。但是一个迭代基本上会涉及到所有的开发阶段，所以针对开发过程中的不同阶段的自动化测试，在一个迭代中几乎都会被应用到。如，除了迭代
10 以外，其他所有的迭代中都引入了单元测试、功能测试和性能测试；迭代 1 中在代码开发阶段用到了 JUnit
单元测试，功能测试阶段应用了 CQ Eclipse GUI 自动化测试；在迭代 13 中，代码开发阶段用到了
Harness 单元测试，功能测试阶段用到了 ATE 测试。
由于采用了 Agile 测试驱动开发，所以测试代码和源代码的开发基本上是同步进行的，如，迭代 1 中的任务
3、4、5，任务 3 为源代码的开发，任务 4 为单元测试代码的开发，任务 5 为功能测试代码的开发，在任务
2 的设计确定下来之后，这三个任务同时进行。单元测试本身也是源代码开发过程中用于进行代码调试的辅助工具，所以单元测试代码开发和执行的任务整体都是与源代码开发的任务同步进行的。功能测试则不同，只有其代码的开发是和源代码开发同步进行，而其运行就需要等到源代码开发完成之后才能执行。甘特图中将相应的源代码和
Harness Test/Junit 的开发和执行（包括 PurifyPlus 的执行）的任务用蓝色的方框标记出来，可以看到每一对任务都是同时并发完成的。例如，迭代
1，迭代 13 和迭代 18；而功能测试对应的任务，如，任务 5 和任务 6，其中任务 5 是功能测试代码的开发，任务
6 为功能测试的执行，任务 6 是在任务 5 完成之后才被执行的。另外，如任务 7、任务 18 和任务
23 对应的性能测试，任务 7 和任务 8，也就是部分性能测试，在整体功能尚未成型但是功能测试可以开始执行的时候，就被引入，以便提早发现性能上的问题，因为性能问题通常牵扯到软件本身的设计问题，所以及早引入可以避免后期由于设计引来的大规模返工；当整体功能基本成型的时候，任务
23 开始被引入，来进行更多更全面的性能测试。系统测试也是在功能基本成型的时候引入的。
归结起来，在 ClearQuest 中对自动化测试应用有以下几点：
- 只要有源代码开发的环节，就会应用到自动化单元测试
- 每个迭代中源代码开发完毕的时候，引入新的功能测试
- 在开发过程中结合不同的自动化测试，做到测试的全面性
- 在开发的过程中需要定期利用各种自动化测试进行回归测试
- 自动化测试的代码与源代码的开发同步进行
- 及早引入性能测试，以避免设计上的问题被遗留到后期带来的问题
总之，在较大规模产品的开发过程中，针对所开发的产品的不同的层次结构，以及产品开发中所采用的开发方法的特点，及时、合理地在开发的各个阶段应用各种不同的自动化测试，让自动化测试与开发过程紧密地结合起来，可以更为有效并且更为精确地发现产品中存在的问题，最大限度地将问题修正带来的花销降到最小。
在 ClearQuest 的开发过程中，应用到了多种不同的自动化测试，这些不同的自动化测试贯穿了整个开发周期的始终，从软件的不同方面保证了重量级产品的成功开发。ClearQuest
发展至今，其各种自动化测试脚本和框架已经成为了 ClearQuest 中不可缺少的一部分，集中了很多优秀工程师们的智慧和劳动。
本篇的介绍主要集中地描述了自动化测试在 ClearQuest 的开发过程中是如何在各个阶段和场景被引入的，也就是自动化测试和
ClearQuest 开发过程的结合。在下一篇中，我们将较为详细地描述 ClearQuest 开发中自动化测试的具体应用方法，以及自动化测试是如何与
ClearQuest 开发的配置管理互相配合，使得产品开发的质量和效率达到最佳平衡的。
① Harness 测试
该术语是泛称，代表我们为了检验软件的某部分而编写的测试代码以及用来运行这些测试代码的代码，它可以作为一个自动化测试的工具运行在一个系统或者程序的核心部分。在本文中，Harness
测试是一个专门为了测试 ClearQuest Core 的底层逻辑代码的自动化测试及其框架。
② BLUE Test Automation - Business Logic Utilities Environment
Test Automation
由 IBM Rational CRM Test Automation Team 开发的一套测试框架，目前主要应用于
ClearCase 和 ClearQuest 的开发中。
BLUE Test Automation 包括：
- 支持一般的测试自动化开发的可复用类库
- 支持特定的 GUI 领域 Dojo 和 Eclipse 的可复用类库
- 基于业务逻辑的特定应用程序测试自动化的开发方法
- 便于利用 Java 为 GUI 和 API 应用程序构造自动化测试的框架
③ Agile（敏捷式开发）是一种迭代、循序渐进的开发方法。在 Agile 开发中，通过不断地获取用户的反馈信息和进行方向调整，来使得所开发的软件具有更高的质量和更高的实用性。用
Agile 开发过程，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。简言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并在每个迭代过程中分别完成，并且保证每个迭代过程的成果一直处于可使用状态
④ 测试驱动开发（Test Driven Development）不仅仅是一种测试方法，它是一种软件设计的方法，是
Agile 开发方法实践的核心。其工作的流程如下：
- 添加一个测试用例
- 运行所有的测试用例并确定新添加的测试用例运行失败
- 用最简单的代码来使得新加的测试用例由失败变为成功
- 运行所有的测试用例，并确定新添加的测试用例通过
- 细化代码
- 重复以上各个步骤
测试驱动开发带来的优点如下：
- 提高代码质量。从测试做起可以让测试覆盖所有的代码。
- 测试是对整个系统功能的描述。通过阅读测试代码就可以清楚整个系统的功能。
- 让开发人员更有自信。当代码作性能调整的时候，可以很快发现问题。
- 尽早发现问题。
- 让软件模块化做的更好，更为灵活和具备更好的可扩充性。因为开发人员需要想尽方法让软件中的各个功能更为独立地进行测试并且更为容易地集成起来。
- 代码必须做到可测试，强制开发人员做好的设计
学习
获得产品和技术
讨论
| 
