在 Agile 开发过程中采用测试驱动开发作为指导原则

　　ClearQuest 的开发采用了 Agile 开发方法③。测试驱动开发 (Test Driven Development)④ 是 Agile 开发过程中的一个核心思想，而自动化测试又是做到测试驱动开发的一个基本条件。有了自动化测试的框架，才能保证测试代码和源代码同时开发，做到测试驱动。

　　由于 Agile 开发本身具有开发迭代周期短，每个迭代的成果都是可使用的特点，这就要求做到如下几点：

　　● 保证所做的开发工作没有偏离用户需求

　　● 在有限的时间内，充分利用有效资源，保证代码质量

　　● 每个迭代中所提交的成果都是后期可用的，尽可能避免重复劳动

　　这些要求决定了自动化测试在 Agile 开发过程中的重要地位。利用自动化测试，在测试框架成型和一个迭代中的设计接口已经确定的情况下，源码和测试代码的开发可以同步进行，在充分利用有效资源的同时，如果开发人员在开发的过程中偏离了用户需求，在进行自动化测试的时候还会发现并纠正这些问题；在重量级软件开发和维护中，手工测试很难每次覆盖所有功能（如果要覆盖所有功能，需要相当长的时间，而且所需的时间随着功能的增多还会逐渐增加），而利用自动化测试，则可以通过测试用例的逐步积累而使得整个测试框架涵盖所有功能（自动化脚本可以在夜间以及节假日运行，不需要耗费人力），所以每次运行自动化测试都相当于运行所有功能的完整的测试，并且都能发现当前迭代中的开发工作是否对以前所有其他的功能是否造成影响；Agile 开发的迭代周期很短，这就要求所有的工作更为有效，自动化测试可以帮助开发人员高效地完成测试工作，不必为每次都花费人力和时间运行重复的人工测试而烦恼；并且自动化测试可以在非工作时间运行，也就是说在测试代码开发完毕之后，其测试工作可以不占用工作中的有效时间。

　　由此看来，Agile 开发过程中，无论从软件的实用性，质量保证还是开发效率的角度，都离不开自动化测试。

　 ClearQuest 开发过程如何结合各种不同自动化测试

　　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 开始被引入，来进行更多更全面的性能测试。系统测试也是在功能基本成型的时候引入的。