第 25 卷第 1 期 2005 年 1 月 　 计算机应用 Computer Applications 　 Vol. 25 No. 1 Jan. 2005 文章编号 :1001 - 9081(2005) 01 - 0088 - 03 自动化回归测试在 Java 项目中的实现 尤永康 ,刘乃琦 (电子科技大学 计算机科学与工程学院 ,四川 成都 610054) (youyongkang @sina. com) 摘 　要 :回归测试是软件测试中一种重要的测试 。软件开发过程中出现的各种变化可能会给软 件的质量带来副作用 。回归测试就是用来监控软件的变化 ,及时反馈由变化带来的结果 。回归测试 的自动化可以提高较大规模软件测试的质量和效率 。文中首先介绍了软件自动化测试和回归测试的 概念 ,然后以一个用 Java 语言开发的项目 CADS(Cross Architecture Development Suite) 为例 ,详细阐述了 如何在 Java 项目中实现回归测试的自动化 ,最后总结了自动化回归测试的优点及其适用范围 。 关键词 :软件测试 ;回归测试 ;自动化回归测试 ;Java 中图分类号 : TP311. 56 　　文献标识码 :A Automation regression testing in Java project YOU Yong kang , LIU Nai qi (College of Computer Science and Engineering , University of Electronic Science and Technology of China , Chengdu Sichuan 610054 , China) Abstract : Regression testing is an important part in Software Testing. When software has some changes , Regression Testing needs to check if the changes have affected the software quality. These changes include bugs fixing , functionality changes , build process changes , configurations added etc. Changes to one part of software often impact of other working parts and impair the whole system s quality and functionality. Regression Test can monitor these changes and report the test results to the developer in time. Automation Regression Testing can improve efficiency and quality of Regression Testing. This paper firstly introduces the conceptions of Software Testing and Regression Testing. Secondly it gives an example of a Java project CADS (Cross Architecture Development Suite) to introduce how to design Automation Regression Testing in Java project. At last it summarizes the advantages of the Automation Regression Testing and its scope. Key words : software testing ; regression testing ; automation regression testing ; Java 1 　自动化测试 软件测试是人们利用自己所能想到的方法 ,来尝试发现软 件产品中可能存在的错误和不足的过程。它的目标既不是要找 到所有的错误 ,或者找出某一代码段里存在具体错误的数量 ,也 不是证明某个软件的设计是否正确 ,而是要使被测试的软件产品 能够正常发挥出它的功能 ,达到客户的需求。测试包括查证 (verification) 和验证(validation) 两个方面。查证用于评估软件产品 的计划、文档、代码、说明书等内容中是否存在错误或者矛盾 ,验 证用于检验软件是否满足软件说明书的要求。 软件测试可以按照层次关系划分成三种不同的测试 :测 试功能模块内部代码的单元测试 ;测试功能模块之间联系的 集成测试 ;针对整个软件产品整体功能的系统测试 。它还可 以按照不同的要求划分成许多具体的测试类型 。例如可以根 据软件具体的功能要求 ,进行功能测试 ;也可以根据软件需要 满足的性能需求 ,来进行性能测试 。回归测试则是利用已有 的测试方法来测试最新的软件改变是否会产生影响 。 随着软件开发的深入 ,软件测试的任务量也会随之增加 ,特 别是到了软件开发的后期 ,不仅需要运行大量的测试用例 ,而且 还会集成不同类型的测试。如果只依靠手动来完成它们 ,不仅会 花费大量的时间 ,而且人为的因素也很难保证测试的准确性。如 果测试能够自动化 ,那么就可以提高它的质量和效率。 事物总是具有两面性 ,同样测试过程自动化也有不足 。 其一 ,实现测试自动化 ,并把测试用例集成进自动化框架的过 程就需要花费许多额外的时间 。其二 ,测试过程的自动化也 可能会隐藏掉一些软件的错误 。再者一部分测试还没有办法 自动化实现或者自动化实现的代价太大 ,例如检查软件的版 权声明 ,一般只需要在软件的 Alpha 版本手动检查一下即可 。 因此是否采用自动化测试需要根据具体的测试对象来进行选 择 。如果被测的程序模块比较多 ,需要经常测试 ,而且比较容 易集成进一个测试框架 ,那么就可以选择自动化方式 。相反 , 如果某项功能只需要很少几次的测试 ,自动化的过程又比较 复杂而且自动化测试的结果不够准确 ,那么就可以不采用自 动化测试 。 图 1 　自动测试与手动测试比较 图 1 比较了在一个软件变化比较频繁 、需要经常测试的 项目中 ,自动化测试和手动测试在执行效率上对软件开发的 影响 。其中横坐标是时间进度 ,V n 则代表了软件第 n 次更新 　　收稿日期 :2004 - 06 - 23 ;修订日期 :2004 - 12 - 16 　　作者简介 :尤永康 (1980 - ) ,男 ,上海人 ,硕士研究生 ,主要研究方向 :软件工程 ,系统与网络安全 ; 　刘乃琦 (1950 - ) ,男 ,教授 ,主要研究方 向 :系统与网络安全. © 1994-2011 China Academic Journal Electronic Publishing House. All rights reserved. http://www.cnki.net 

第 1 期 尤永康等 :自动化回归测试在 Java 项目中的实现 　　　　 98 的过程 (从开始修改到发布) 。 在图中可以看出 ,当软件处于 V2 到 V4 这段频繁变化的 时期内 ,手动测试的结果比软件下一个版本的发布还要晚得 到 ,这对于软件质量的保证是非常不利 。而自动化测试却能 够把上一个版本存在的问题及时地反馈给开发人员 ,这样开 发人员就可以在下一个版本中及时地改进软件 。 2 　回归测试 软件开发是一个不断变化的过程 。这些变化可能是软件 缺陷的修复 ,软件功能的改变 ,软件配置的改变或者是编译过 程的改变 。它们可能会增加一些功能并修复一些老的错误 , 但是也可能会在软件的新版本中产生老版本未曾发生的问 题 。而回归测试的目的就在于及时地监控这些变化是否会影 响软件质量 。回归测试紧跟这些变化 ,验证软件原有的功能 是否正常 、原有的错误是否被修复 、或者已经修复的错误是否 会再发生 。 回归测试由可重用的测试库以及测试的数据和结果构 成 。可重用的测试库包含许多测试集 ,每一个测试集通常代 表对某一功能块的测试 ,包含可反复执行的测试用例 。测试 库如果包含所有类型的测试集 ,那么就是全回归测试 ;如果按 照需求只包含一些功能块的测试集 ,就是部分回归测试 。测 试的数据和结果则用于比较和分析回归测试 ,控制软件质量 。 测试库既要包含此次测试之前测试失败的测试用例 ,也 需要包含测试成功的测试用例 。这是因为软件中一部分的改 变 ,可能会影响到其他部分的质量和功能 。之前能够通过测 试的部分 ,不能保证在软件发生改变之后也一定能够通过测 试 。图 2 说明了回归测试需要包含所有测试用例的原因 。图 中的测试用例 1、2、3 分别测试软件中 3 个不同的功能 ,A、B 、C 代表 3 次回归测试 , E、F 代表开发中的两次改变 。如果回归 测试 B 依照 A 的结果 ,它的测试库不包含用例 1 和用例 3 ,那 么就会遗漏由 E 改变而产生的功能 3 的错误 ,从而无法及时 保证软件产品的质量 。然而开发时间的增加对于软件来说就 意味着成本的上升 。由此可见回归测试的测试库必须要包含 之前所有已经测试过的测试用例 。 图 2 　回归测试示例图 每当软件变化并推出一个测试版本 ,回归测试都需要重 新进行 ,而且回归测试库的测试用例也随软件功能的增加而 增多 。如果不能实现自动化的回归测试 ,回归测试就有可能 无法及时的反馈测试结果 ,而且频繁而重复的手动测试还会 浪费大量的资源 。当回归测试自动化之后 ,它就可以尽可能 的与软件变化的过程保持同步 。一旦软件版本发生了新的改 变 ,无需测试人员的干预 ,回归测试就可以自动完成 ,并及时 反馈结果 。 下面以一个具体项目 CADS(Cross Architecture Development Suite) 为例 ,介绍如何在 Java 项目中实现自动化的回归测试 。 3 　CADS 项目对回归测试的需求 CADS 是基于 Eclipse 平台 ,用 Java 语言开发的跨平台软 件系统的开发工具 。它由许多相互关联的 Eclipse 插件构成 。 CADS1. 0 版本的开发周期约有 1 年 ,软件开发人员分别在中 国 、美国和爱尔兰 。由于时差关系 ,开发人员开发代码的时间 都相对独立 ,任何一方的改动都可能在一天中的任意时间形 成一个 CADS 的测试版本 。如果不能及时的运行回归测试 , 发现改动后的错误 ,就会影响其他开发人员的正常开发 ,对软 件质量和开发进度产生消极影响 。因此 CADS 项目非常需要 有一套自动化的回归测试 ,用它来随时跟踪每一个软件测试 版本的出现 。 在 CADS 项目的质量控制过程中 ,除了需要全回归测试 外 ,还需要运行一种特殊的部分回归测试 。它要求找出在回 归测试之前所有曾经发现过的软件错误 ,并重新运行发现这 些错误的测试用例 ,来验证这些错误在新的测试版本中的状 态 。这种部分回归测试可以很好地掌握软件错误的情况 ,发 现哪些错误是容易反复发生的 ,并进行有效地控制 。 4 　回归测试在 CADS 中的自动化实现 4. 1 　自动化测试框架的设计 由于软件测试自动化会带来额外的代价 ,因此在自动化 框架设计之初就需要进行周全的考虑 ,既要尽量降低代价 ,也 要确保自动化过程能够顺利进行 。最好的办法是在设计自动 化框架前 ,定义一套自动化测试的规范 ,并使得之后测试用例 的开发以及测试过程都依照这套规范来进行 。 首先需要规范化测试用例 。规范化的测试用例包括统一 的命名规则 ,以及统一的输入和输出格式 。自动化框架通过 测试用例的名字来调用它们 ,如果测试用例的命名不统一 ,那 么自动化框架的执行就可能遇到许多麻烦 ,同时测试人员也 不易管理测试用例 。在 CADS 中 ,测试用例的名字由三部分 构成 ,每一部分都有三位 ,并用下划线进行分割 。例如“BLD- API-001”, 其中第一部分代表被测试的模块 ,“BLD”表示编译 模块 ;第二部分代表测试的内容 ,“API”表示测试应用程序接 口 ;第三部分则是测试用例的序号 ,按照顺序从 001 开始递 增 。输出规范化的好处在于可以产生统一的测试结果 、简化 分析和统计的工作量 。CADS 测试的输出也有统一的格式 ,每 一个测试输出都由测试用例名和测试结果组成 。它们不需要 再进行加工就可以通过网页显示出来 。 其次 ,自动化框架需要有软件版本控制软件来辅助管理 测试库 。测试用例的开发人员可能会根据软件随时更新测试 库的内容 。如果没有统一的版本控制软件来管理测试库 ,就 不能保证每一次自动化框架运行的测试用例是最新的 ,有可 能产生 错 误 的 测 试 结 果 。CADS 项 目 采 用 CVS ( Concurrent Versions System) 进行软件的版本控制 。CVS 的功能强大 ,要求 严格 ,可以很好的管理测试用例 。 最后 ,自动化框架需要和软件错误管理工具进行合作 。 当一次回归测试结束之后 ,可能发现成百上千的错误 ,包括原 有的和新发现的 ,错误的状态也会有很多种 ,因此需要一个错 误管理工具来集中管理 。错误管理工具并不是专门为自动化 测试服务的 ,软件质量控制也需要它 。CADS 项目中的错误管 理工具采用在 Linux 系统中工作的 Bugzilla。Bugzilla 的功能完 善 ,不仅能够管理错误的不同状态 ,还能把错误的情况及时通 过电子邮件报告给需要的人员 。 4. 2 　自动化全回归测试系统的实现 CADS 项目的自动化回归测试利用了 Java 语言的反射机 制来动态调用需要运行的测试用例 。反射机制是 Java 语言 中一种很有特色的机制 ,它可以在程序运行态获取类的信息 , 并通过类名和类的方法名来动态地调用它们 。反射机制大大 © 1994-2011 China Academic Journal Electronic Publishing House. All rights reserved. http://www.cnki.net 

2 2 2 2 2 2 2 2 2 2 2 2 09　　　　 计算机应用 2005 年 提高了 CADS 回归测试的自动化程度 。通过它 ,我们不必在 测试之前把每一个需要运行的测试用例都写进自动化测试框 架中 ,而只需要编辑配置文件 ,让配置文件来控制具体需要运 行的测试用例 。自动化框架只要在进行测试前读取配置文件 就可以自动化地完成回归测试 。 图 3 　自动化回归测试 图 3 是自动化回归测试系 统的框图 。回归测试之前 ,测 试人员在 CVS 中准备好测试 库和配置文件 。回归测试开始 后 ,自动化测试框架会从 CVS 中获取最新的测试库以及配置 文件并开始自动测试 。测试结束以后 ,自动化测试框架会记 录并发布测试结果 。测试人员可以根据测试的结果以及测试 的日志来更新 Bugzilla 中的错误信息 。在整个回归测试中 ,除 了需要手动编辑配置文件以及向 Bugzilla 报告错误外 ,其余的 过程都是全自动完成的 。需要特别指出的是 ,在 Bugzilla 中报 告的每一个错误 ,它们的标题都需要包含相应测试用例的名 字 ,这是 4. 3 节中需要的配置文件的来源 。 4. 3 　特殊的部分回归自动化测试 CADS 在一些项目节点 ,除了要进行全回归测试外 ,还需 要运行一种特殊的部分回归测试 。这种部分回归测试要求测 试在此之前曾被发现的所有错误 。它更关注软件的变化对于 已经发现过的错误产生的影响 。对 CADS 项目而言 ,它需要 知道软件新版本是否能修复原有的错误 ,或者已被修复的软 件错误是否重新发生 。它与全回归测试的不同之处在于测试 框架的配置文件 。全回归测试的配置文件包含所有的测试用 例 ,而部分回归测试只需要包含在错误管理软件中记录过的 错误的测试用例 。 图 4 是这种特殊需求的部分回归测试的自动化框图 。可 以 看出它和图3不同的是 ,部分回归测试多了来自Bugzilla的 (上接第 87 页) 过激活的执行监控和用户反馈机制来获取 QoS 标准的值 。限 于篇幅 ,有关 QoS 最优化机制在此不作详细讨论 。 3 　结语 本文针对跨企业级的企业业务流程的过程重组中传统工 作流技术绑定过死问题和目前系统集成技术中紧耦合 、高成 本以及灵活性差等问题 ,从整体规划的角度 ,结合现有的工作 流技术和 Web 服务技术 ,为系统开发人员给出了一种以全局 的角度来调用 Web 服务来实现业务流程管理系统的模型 ,提 出了 Web 服务与工作流活动的动态绑定技术 、自动和半自动 执行技术 ,以及 Web 服务的 QoS 最优化选择机制 。 按照动态程度的递增 ,业务流程自动化的动态性分为三 个级别 : 第一级 , Web 服务本身技术特性提供的动态性 ,如 UDDI 的运行时态查询 、WSDL 的动态解析绑定等特性 ;第二 级 ,依据工作流节点中绑定的时机和策略的选择 ,动态地选择 参与者 (Web 服务应用实例) ,即每次执行过程中参与角色的 具体实例可以不同 ;第三级 ,Web 服务工作流不仅可以动态选 择参与者 ,业务流程本身也可动态选择 ,并且可引入支持最新 发布的基于 WSRF 的网格服务来以 工 作 流 方 式 协 同 共 享 Internet 上所有资源 。本文重点讨论了第二级动态性实现机 制 ,下一步重点将集中开展第三级动态性机制的研究与实现 。 参考文献 : 1 ] 　IBM , Microsoft , Bea. SAP Business Process Execution Language For 图 4 　特殊的自动化回归测试 输入 。这个输入用来生成特定的配置文件 。在测试开始之 前 ,测试框架首先向 Bugzilla 数 据库获取所有记录过的错误 。 由于测试用例命名规范 ,而且 在每个软件错误的标题中均有 与之对应的测试用例名 ,因此自动化框架可以容易地提取这 些测试用例名 ,重新生成配置文件 ,用新生成的配置文件替换 掉原有文件 。自动化框架不需要额外改动 ,就可以完成这种 特殊要求的部分自动化回归测试了 。最后的测试结果也一样 通过网页显示 ,并手动更新 Bugzilla 中错误的状态 。 5 　结语 自动化的测试大大减少了测试人员的人为失误 ,提高了测 试效率。Java 语言的反射机制以及规范化的开发自动化测试框 架 ,使得全回归和部分回归测试都能使用同一平台 ,提高了开发 自动化平台的效率。自动化回归测试虽然需要额外的前期投入 , 但是可以及时地反馈软件版本的质量 ,帮助开发人员迅速发现错 误 ,随着软件开发的不断前进 ,实际上反而大大节省了资源。实 践证明自动化回归测试对于保证 CADS 项目的质量起了非常好 的作用。综上所述 ,自动化回归测试非常适合于开发周期长 ,而 且开发人员比较多的大型软件开发项目。 参考文献 : 1 ] 　KANER C , FALK J , NGUYEN HQ . Testing Computer Software M . Canada : Wiley Computer Publishing , 1999. 2 ] 　ECKEL B. Thinking in Java M . 京京工作室 , 译. 北京 : 机械工 业出版社 ,1999. 3 ] 　BARNSON MP. The Bugzilla Guide - 2. 16. 5 Release EB/ OL . http :/ / www. bugzilla. org/ documentation. html , 2004 - 3 - 21. 4 ] 　Cederqvist P , et al . Version Management with CVS EB/ OL . http :/ / www. cvshome. org/ docs/ manual/ , 2004 - 5 - 1. Web Services 1. 1 EB/ OL . http :/ / www works/ webservices/ library/ ws bpel , May 2003. 106. ibm. com/ developer 2 ] 　Web Services Flow Language (WSFL) Version 1. 0 EB/ OL . http :/ / com/ software/ solutions/ webservices/ pdf/ WSFL. pdf , ibm. 3. www 2002. 3 ] 　XLANG: Web Services for Business Process Design EB/ OL . http :/ / www. gotdotnet. com/ team/ xml wsspecs/ xlang c/ default. htm , 2002. 4 ] 　OASIS. Universal Description , Discovery and Integration of Bunsiness for the Web - Specifications EB/ OL . http :/ / www. uddi. org/ specifica tion. html. 5 ] 　WSDL EB/ OL . http :/ / www. w3. org/ TR/ wsdl. html 6 ] 　Workflow Management Coalition. Published on Web (2003) EB/ OL . http :/ / www. wfmc. org. 7 ] 　QoS4WS Understanding quality of service for Webservices EB/ OL . http :/ / www 106. ibm. com/ developerworks/ library/ wsquality. html. 8 ] 　RAN S. A Model for Web Services Discovery With QoS J . ACM SIGecom Exchanges , 2003 , 4 (1) :1 - 10. 9 ] 　AL ALI R , RANA O , WALKER D , et al . G QoSM: Grid service dis covery using QoS properties J . Computing and Informatics Journal , Special Issue on Grid Computing , 2003 , 21 (5) . 10 ] SHAIKHALI A , RANA OF , AL ALI R , et al . UDDIe : An Extended Registry for Web Services A . Workshop on Service Oriented Comput ing : Models , Architectures and Applications at SAINT Conference C . IEEE Computer Society Press. Florida , US , January 2003. 11 ] AL ALI RJ , RANA OF , WALKER DW. G Quality of Service Management A . Proc UK e Hands MeetingC . Cox SJ , ed. Nottingham , UK, 2003. QoSM: A Framework for Grid Science Programme All 12 ] ZENG L , BENATALLAH B , DUMAS M , et al . Quality Driven Web Services Composition. In Proceedings of the 12th international confer ence on World Wide Web ( WWW) , Budapest , Hungary M . ACM Press , May 2003. © 1994-2011 China Academic Journal Electronic Publishing House. All rights reserved. http://www.cnki.net