在上一篇文章，“Rational
ClearQuest 的开发过程如何结合各种不同的自动化测试”中，我们对 Rational ClearQuest
开发过程中如何结合各种自动化测试做了介绍，其中讲到了在 Rational ClearQuest 开发的各个阶段，对各种不同的自动化测试的应用以保证开发质量。在本篇中，我们将用两种不同的场景和案例来介绍各种自动化测试是如何帮助
Rational ClearQuest 开发人员实际地解决开发中遇到的各种问题的。同时，我们还会对 Rational
ClearQuest 的开发配置管理环境进行简要介绍，并且也会讲述这些开发配置管理环境与单元测试环境是如何在应用中紧密和有效地结合的。
在上一篇“Rational ClearQuest 的开发过程如何结合各种不同的自动化测试”中我们对 ClearQuest
开发过程中如何结合各种自动化测试做了介绍，其中讲到了在 ClearQuest 开发的各个阶段，对各种不同的自动化测试的应用以保证开发质量。在本篇中，我们将用两种不同的场景和案例来介绍各种自动化测试是如何帮助
ClearQuest 开发人员实际地解决开发中遇到的各种问题的。同时，我们还会对 ClearQuest
的开发配置管理环境进行简要介绍，并且也会讲述这些开发配置管理环境与单元测试环境是如何在应用中紧密和有效地结合的。
在这一章节中，我们将把焦点集中在项目开发阶段，从对开发中应用的配置管理环境的介绍开始，给大家列举出开发中遇到的几种实际问题，并详细介绍在项目开发阶段，开发团队和成员是如何利用自动化测试来解决遇到的各种问题的。
ClearQuest 项目开发阶段中应用的配置管理环境
ClearQuest 开发中在开发阶段所应用的配置管理环境，是目前所有自动化单元测试和部分功能测试的应用环境。虽然不是所有的自动化测试都与配置管理环境相关，但是在整个开发过程的开发阶段，单元测试贯穿整个开发周期的始终，它是从开发者的角度保证质量的关键，而配置管理环境与自动化单元测试之间的紧密配合，也是确保整个开发过程顺利进行的必要条件。
ClearQuest 的开发阶段中采用了 Rational ClearCase①作为版本管理工具。在开发的过程中，由于采用了
Agile 开发模式，整个开发的过程被分为几个迭代。对每一个迭代，都建有相应的开发流；而每个相应迭代的开发流下面，各个开发人员会各自创建自己的开发流，整体结构如下图（在应用
ClearCase 作为版本管理工具的项目开发过程中，基本上都会遵循这样的结构）：
图 1. Rational ClearQuest 开发阶段应用的开发流结构
相对于每个开发人员自己的开发流来说，每个迭代所对应的开发流称为主开发流（也可称为集成开发流 -Integration
Stream），而最上层的开发流则被称为产品开发流。开发流的层次可以灵活定制，在主开发流下面，也可以根据不同的开发功能再创建其各自的主开发流，让开发人员在根据功能创建的开发流上创建各自的个人开发流等等。
每个开发人员管理自己的开发流，他们需要在自己的开发流上确认自己的开发工作没有问题后，将修改提交到主开发流上。所谓没有问题，是指开发人员首先要保证自己开发的部分可以正常工作，并且能够和其他开发人员新近提交的修改成功整合在一起并正常工作。也就是说开发人员在每次提交自己的修改之前，都需要先将主开发流上最新的内容同步到自己的开发流上，然后再运行相应的测试，并保证其通过。
对主开发流的管理是这样的，每一个主开发流都有相应的管理员，每隔一段时间（2-3 天或者一周，视开发的阶段而定），管理员需要对该主开发流进行整理，检查所有子开发流上提交的工作是否出现问题，并将内容与上层开发流同步。每天主开发流都会在各个平台上自动进行
build、运行自动化测试和创建新的开发流基线（baseline）②，其
build 和 Harness Test 运行的结果自动发送到相关开发人员的邮箱。一旦 build 和
Harness Test 的结果出现问题，整个主开发流的内容将不能提交到上层开发流上，以防止问题进一步扩大。而此时所有同一个主开发流下面的开发人员的代码都需要等待问题解决后，才能继续提交修改。
图 2. Rational ClearQuest 开发阶段配置管理和自动化测试结合的开发流程图
ClearQuest 整个开发过程中通常遇到的几类问题
目前在 ClearQuest 的开发过程中经常遇到的几类主要的问题，可以归结如下：
- 新的功能的实现导致现存功能的失效
在上一篇的第一个章节对
ClearQuest 的介绍中已经提到，ClearQuest 发展至今，其代码量几乎可以用 GB 来衡量。在这样庞大的系统中做一些升级性的功能开发，很可能由于底层代码的修改而导致现存功能出现问题。而一旦出现问题，就可能会影响到整个
ClearQuest 团队的开发和测试工作的正常进行。
- 内存泄漏和内存初始化问题
由于 ClearQuest 底层 Core 部分的代码是 C++ 编写，所以尤其需要关注内存泄漏和内存初始化问题的出现。
- 开发的结果与最初的要求不符
有些模块开发的工作所持续的时间比较长，在整个开发的过程中，会涉及到需求的变更，设计的变更，而且要求团队中的成员间紧密合作和有效沟通，一旦其中的某个环节出现问题，就可能导致开发结果偏离正确方向，导致返工。
- 性能问题
ClearQuest 的结构复杂。从源码的角度，它涉及到了不同编程语言的协同工作，如 C++，Java，Perl
和 VB；从用户的角度，ClearQuest 支持服务器，客户端和浏览器。这个复杂的架构还在不断地升级，新的功能还在不断地加入进来。因此，除了客户对性能要求不断提高的问题以外，由于其本身不断的升级，新的性能问题也难免不断被引入。
上面这些问题，通过在开发过程中引入各种不同的自动化测试，在不同的阶段可以得到解决。
与配置管理环境相结合在
ClearQuest 开发阶段应用自动化单元测试和功能测试解决实际问题
在本文上一节中提到的开发中遇到的几类问题，不仅仅与代码开发阶段相关，而且涉及到了如需求、设计和测试等阶段，需要各种不同角色的人员配合各种自动化测试来解决这些问题。其中前三个问题（新的功能的实现导致现存功能的失效，内存泄漏和内存初始化问题，开发的结果与最初的要求不符），在代码开发阶段
(Construction Phase) 可以利用自动化单元测试和功能测试得到有效的控制。在 ClearQuest
开发中，我们将自动化单元测试和功能测试与 ClearQuest 配置管理环境紧密结合，根据配置管理环境来适当地运用自动化单元测试和功能测试。
下面我们将在 ClearQuest 配置管理环境的基础上，讲述在 ClearQuest 开发过程中的开发阶段是如何利用自动化单元测试和部分功能测试来解决本文第一章中前三个问题的。
- 防止新功能的实现导致现存功能失败
在大型软件的开发中，这是经常遇到的问题，回归测试是解决这种问题的方案。所有的自动化测试都具备做回归测试的能力。
作为一个开发人员，感受最深的就是 Harness Test/JUnit 单元测试在开发阶段所起到的重大作用。在
ClearQuest 的开发过程中，只要有代码的修改和提交，就会引入单元测试，也就是说单元测试在 ClearQuest
的整个开发阶段，贯穿始终。
以 Harness Test 为例，在 CQ Core 代码的开发阶段，每隔一段时间，也就是一个过程或者一部分功能开发完毕，开发人员都会在几个平台上把整个
Harness Test 完整地运行一遍，然后检查所有的运行结果，查看自己所做的修改是否对现存的功能产生影响（Harness
Test 本身具有统计结果的功能，开发人员可以轻松地知道每次运行的测试中成功和失败的测试用例）。跑完一个完整的
Harness Test 虽然需要很长时间，但是由于是自动化测试，它可以运行在非工作时间，所以几乎不会占用正常的工作时间。
在 ClearQuest 配置管理环境的基础上，我们可以想象一下下面的两种场景：
- 在 ClearQuest 的开发中完全不应用自动化测试，所有的开发人员都在修改并且通过了自己的单元测试之后就提交自己的代码。
在这种情况下，所有的开发人员都无法知道自己的修改是否会影响到 ClearQuest 的现存功能，这时候又会有两种不同的情况发生：
①刚好有其他的开发人员在被影响到的功能上进行开发工作
该开发人员的工作将会受到阻碍，不得不停下本职的工作，查找导致该问题的原因，但是由于该开发人员对前面提交修改的开发人员所做的工作并不熟悉，无法很快定位并解决问题，导致需要花费很多不必要的时间和精力。
在 ClearQuest 的庞大的开发团队中，如果频繁发生这种情况，所有的工作将陷入一片混乱。
②没有任何其他的开发人员直接工作在被影响到的功能上
被影响到的功能在中间某个阶段的版本测试中才会被发现，但是这时该版本已经包含有很多的代码修改，要定位问题可能需要所有提交过修改的人都对自己所做的工作进行检查，花费更多的时间和人力。
- 有的开发人员自己没有良好的习惯，在开发结束后，只做自己的单元测试就提交代码。
这种情况比前一种情况要稍好一些，因为在上一层的开发流上会有自动化测试进行质量控制。当上一层开发流的管理员发现问题的时候，就会查找问题出现的原因，但由于自动化测试是周期性执行的，所以管理员很容易找到此次的问题可能出在哪些提交的代码中，并通知相应人员对自己的代码进行检查。虽然定位问题和解决问题的时间比前一种情况少了很多，但是由于主开发流出现了问题，导致其他的开发人员在这一段时间内无法提交自己的代码，仍然会浪费很多不必要的时间和精力。
不同的自动化测试在开发过程中运行在不同的阶段，如，GUI 自动化测试和 ATE 测试这样的功能测试，除了新的功能测试运行在一个迭代的结束以外，在迭代的开发阶段也被定期运行以帮忙发现很多功能测试上的回归问题。目前功能测试是运行在安装版本上，而不是在开发流上，它可以防止将一个迭代中的问题遗留到后面的迭代中。事实上，如果能在开发人员的开发流上运行功能测试作为回归测试，能够使得开发人员提交的代码更为安全，但这种方式也会带来成本上的增加，需要针对不同的情况来权衡是否需要采用这种方法，通常在大型软件开发中还是必要的。在
ClearQuest 的 Harness test 中，包括了一部分简单的功能测试。无论这些自动化测试运行在哪个阶段以及对应哪些测试的对象，它们都包括了回归测试的功能，都有效地保证了
ClearQuest 开发工作的顺利进行。
- ClearQuest 中内存泄漏和内存初始化问题
内存问题虽然不像功能问题那么直观，但却会产生严重的后果，导致整个产品处于不稳定的状态或无法运行。ClearQuest
Core 的代码是 C++ 编写的，所以对内存的检查十分必要。这种问题的检查不仅需要在单元测试和功能测试阶段引入，在后续的其他测试阶段也会包含相关的检查。但是，单元测试和功能测试是检查内存相关问题的两个重要阶段。
在 ClearQuest 开发阶段，Harness test 是 ClearQuest Core 中应用的单元测试，在运行
Harness Test 的同时，开发人员可以选择是否运行 Purify 来进行内存检查。也就是说，Harness
Test 为开发人员提供了在单元测试进行的同时使用 Purify 来进行内存检查的功能。
除此之外，还有其他的方法来进行内存检查，但由于它们与 ClearQuest 配置管理环境无关，我们会在后面的章节进行介绍。
- 开发的结果与最初的要求不符
对于这个问题，从很大程度上我们要从测试驱动开发的角度来进行说明。在上一篇
2.3 节中我们已经提到，自动化测试在测试驱动开发中具有重要的地位。自动化测试框架的引入，使得我们可以在确定了需求和接口之后，同时进行源代码和测试代码的开发。
在 ClearQuest 的开发阶段，单元测试阶段避免这种问题的最佳实践就是在接口确定的条件下，单元测试代码和源代码分别由不同的开发人员同时开发，然后在提交之前运行单元测试，就能从代码最底层发现此类的问题。在这一时期发现的问题，通常是由于开发人员在开发过程中偏离了方向，或错误地理解了功能需求引起的。
但是，在这个问题上，由于 Harness Test 和 JUnit 单元测试都是产品源代码开发团队进行开发的，所以它们的优势不是那么明显，一些需求上的变更以及团队间沟通带来的问题通常很难通过单元测试检查出来。而
ClearQuest 中的 GUI 和 ATE 这两种功能测试，是解决此类问题的更好的方法。由于 GUI
和 ATE 的运行目前也与 ClearQuest 配置管理环境无关，所以我们也将在后面的章节中进行介绍。
除了与配置管理环境结合的这些自动化测试之外，ClearQuest 还有很多在安装环境下，也就是在移交阶段（Transition
Phase）运行的自动化测试，它们在 ClearQuest 开发过程中也同样能够有效地帮助控制和解决开发中遇到的问题。在后面的内容中将对这些自动化测试进行简要描述。
在本文 1.2
节中，我们列举出了在 ClearQuest 开发过程中遇到的各种问题，并详细描述了在开发阶段中自动化单元测试和部分功能测试是如何解决实际问题的，在本章节中我们将介绍那些运行在
ClearQuest 安装环境下的自动化测试对解决 ClearQuest 开发中遇到的各种问题所起到的重要作用。
- 防止新功能的实现导致现存功能失败
所有的自动化测试都具备回归测试的功能，所以除了前面提到的在 ClearQuest 配置管理环境下运行的自动化单元测试以外，其它所有的自动化测试在解决这一问题上都能起到重要的作用。
- ClearQuest 中内存泄漏和内存初始化问题
前面我们提到，在 ClearQuest Core 的开发中用到的单元测试 Harness Test 中包含了
Purify 的运行，可以有效地帮助解决内存问题。但是由于在开发配置管理环境下运行的 Harness Test，是运行在
Debug 版本（也就是开发人员在开发过程中为进行代码调试生成的版本）上的，用 C++ 开发的产品，Debug
版本和正常发布的版本中内存初始化行为有所不同，所以通常我们还需要在安装环境下运行 Harness Test
以及功能测试来进一步对内存问题进行检查。
- 开发的结果与最初的要求不符
ClearQuest 开发过程中应用的 GUI 和 ATE 这两种功能测试，对检查此类问题具有绝对的优势。在
ClearQuest 开发过程中，开发设计确定以后，开发人员会提交自动化测试开发的申请。然后，自动化测试团队会根据申请中描述的需求进行自动化测试用例的开发。当一个迭代结束的时候，各种自动化功能测试就会在这一阶段被引入，这时也就会发现源代码的修改和自动化测试开发的结果不符，这通常可能因为几种情况：
①开发人员在开发的过程中偏离了方向，或错误地理解了功能需求
②功能需求在开发过程中出现了变化，开发人员没有及时更新最初提交的自动化测试申请信息
③自动化测试人员与开发人员之间沟通不够，导致测试代码偏离方向（不排除这种可能）
这些问题的发生，使得开发人员和自动化测试人员可以及时进行调整，达成一致意见，保证工作按照正确的方向顺利进行。
- 性能问题
通常大家可能会认为性能的问题是在开发的后期才被发现和解决，事实上性能的问题通常涉及到的不仅仅是代码质量，而是软件设计本身的问题，这种问题如果遗留到后期，会造成设计、编程的部分返工，大规模增加软件开发的成本、延长开发周期等，所以需要及早引入性能测试和及早发现问题。
ClearQuest 的开发中，性能测试在功能测试可以被执行的时候，就及早被引入进来（即使只有部分测试可以被执行），以便提早发现性能问题，当然不排除有些性能问题需要随着功能的不断完善或者测试数据量的不断增加才能暴露出来，但是早期引入通常可以发现一些比较重大的问题。
目前，ClearQuest 有专门的人员来负责运行和维护在安装环境下的自动化测试。这些自动化测试有效地帮助解决了开发中遇到的各种问题，对保障
ClearQuest 的开发质量起到了至关重要的作用。
在实际的开发过程中有效地将自动化测试和配置管理环境相结合，可以帮助开发人员更方便、快速地发现并解决软件开发过程中遇到的很多实际问题，与在安装环境下运行的各种自动化测试一起，从软件的不同方面和软件开发的不同阶段保证了产品开发的顺利进行。通过在
ClearQuest 开发中应用自动化测试解决各种问题的实践，我们总结出了下面的一些经验和建议，以供大家参考。
- 在开发过程中，根据开发所使用的配置管理环境，合理、有效地将各种自动化测试与配置管理环境相结合；
- 在开发过程中，虽然每次都运行完整的单元回归测试会耗费一定的时间，但从项目整体角度来说，这是保证一个团队开发、尤其是一个大型项目开发的必不可少的部分；为了提高效率而节省回归测试的时间会因小失大，造成后期更大的损失；
- 根据项目的情况权衡对自动化测试框架的投入（自动化测试框架的开发需要在前期有所投入，但是没有前期的投入就意味着后期要花费人力来进行大量、重复性的手动测试）；
- 自动化测试保证了大型软件的可持续开发，是整个项目或产品开发中的宝贵资产；
- 应用测试驱动开发，有助于清楚地理解所解决的问题和防止开发和需求之间的偏离；
- 尽可能早地引入各种测试，提早发现问题，也就是说测试框架的开发在很多情况下需要和源码一起甚至比源码的开发更早入手。
综合第一篇和本篇中对自动化测试在开发各个阶段的应用及其在开发中如何解决实际问题的描述，相信已经让读者了解到了自动化测试在软件产品开发中所起到的重要作用，保证开发质量是软件开发中一个永久不变的目标，而自动化测试正是保证我们达到这一目标的有力工具。
①Rational ClearCase: 通过提供版本管理、工作空间管理、并行开发支持以及 build
审查的解决方案来提高生产率的工具。
②开发流基线（Baseline）：基线是项目存储库中每个工件版本在特定时期的一个“快照”。它提供一个正式标准，随后的工作基于此标准，并且只有授权后才能变更这个标准。建立一个初始基线后，以后每次对其进行的变更都将记录为一个差值，直到建成下一个基线。它是软件文档或源码的一个稳定版本，它是进一步开发的基础。
学习
获得产品和技术
讨论
| 
