浅谈持续集成构建在互联网软件测试项目中应用与分析
摘要：本文将介绍持续集成在互联网软件项目中的应用及案例分析，主要针对互联网行业软件项目过程中的软件测试效率和质量的研究与实践；在当前Web2.0时代，笔者抓住互联网行业的软件测试特性，在软件项目的开发过程中运用持续集成构建的思想来统一规范、流程和管理，不仅提升项目在提测之前的软件版本质量，也有利于软件项目过程的效率和质量风险控制。在浅谈持续集成及工具在项目中的应用同时，也结合笔者从事互联网软件测试的工作经验，进一步阐述与总结在软件测试过程的持续集成带来的益处与不足。
笔者会先介绍当前互联网的软件测试与传统的软件测试区别与联系，然后针对互联网软件测试的特性再结合持续集成工具思想的运用，后将比较详细的介绍Hudson持续集成构建平台在项目中的实践与分析，从而解决了在多个项目并行开发的软件项目中应该如何应用持续集成以保持项目整理开发过程的高质量和高效率问题。
关键词：软件测试；持续集成；自动化测试；
一、引言
在互联网信息时代，随着Internet的快速增长及Web应用的不断发展，使其快速渗透到商业、电子商务、军事、工业、教育等领域和个人生活的各个方面，对我们的生活及工作产生了深远的影响。在当今市场需求和Internet技术进步的不断推动下，Web应用日益增加，互联网的软件规模不断扩大，复杂性增加，操作易用性降低，面对互联网的用户也越来越多，因此软件的质量越来越成为人们共同关注的问题，作为保证软件质量和可靠性的重要手段，软件测试已成为互联网软件项目开发过程的重要环节。
在整个软件生命周期中每个环节都存在软件测试的活动，软件测试伴随着软件开发，以检验每一个阶段性的成果是否符合质量要求和达到预先定义的目标，尽可能早的发现问题并修复问题已成为当前互联网时代软件开发与测试过程的目的，也孕育了要提高上游软件质量，发挥测试工程师在软件项目需求、设计阶段参与的重要性。互联网的信息和产品更新速度较传统软件产品是非常之快的，保证好软件系统的质量和稳定性，运用敏捷的测试思维、测试工具来改变传统的测试方法和测试观念，正是在互联网软件实施过程中必须面对的。针对互联网软件开发的特点，笔者结合多年的软件测试经验与测试策略、工具，总结一些比较适用的方法、流程和工具综合运用到互联网软件开发与测试过程中，综合运用持续集成构建的思想进一步保证软件质量和提升开发效率。
二、 现状分析
目前在互联网软件开发测试过程中，存在效率低下、质量不高的情况，具体可以总结成以下几个方面：
第一、RD编写的代码质量不高
开发工程师在编码阶段，经常犯一些比较低级的错误，致使提测版本的代码质量较低，如空指针异常、重复犯错及违背编码规范等，常常会被在冒烟测试阶段退回而重新开发，增加提测版本质量和效率的风险，也影响到项目整体开发进度。
第二、单元测试流程不规范，质量和覆盖率较低
为了提高上游代码质量，在开发过程增加了单元测试流程和规范，各部门产品线统一推广与执行，实施一段时间后发现流程在各产品线执行执行的比较混乱，存在一些流程和规范细节问题，执行出现脱节，导致单元测试的代码质量与代码覆盖率下降，在某些项目过程中暴露的非常明显，较严重地影响了项目进度和质量。
第三、测试方法单一，测试策略陈旧，测试过程的效率和质量低下
项目过程，测试工程师从立项前的需求讨论到立项后的需求、DEMO、设计评审和TC编写几乎全程参与，一定程度提升测试工程师在项目研发过程的地方和影响力，另外也带来了测试方法单一和测试策略陈旧的问题，全靠手工测试已成为项目测试过程的瓶颈，往往导致项目、需求排队现象，进一步分析说明了我们的测试产出比低下，效率不高。
必须改变整个项目过程的测试方法，引入新的测试工具和测试策略，必须发挥自动化的力量缓解手工测试的瓶颈和解决效率低下的问题。
第四、上线后出现故障频繁，bugfix需求增多
项目和小需求在互联网行业中更新非常快，如果过程没有更好的控制软件风险的话，上线后的需求会出现很多故障，导致用户大量投诉，后续修复的工作量将投入很多资源去支持，一定程度上浪费了精力和物力，降低了生成率。
尤其是在大项目和新增需求发布上线后，故障的频繁让开发、测试心惊胆战，不仅要处理手中新的需求，还要跟进线上故障的bugfix需求，使工程师的精力分散，增加了质量的风险。如何把故障减少下来，如何提升测试阶段和开发前期的质量，已摆在工程师及主管们面前。
第五、无数据支撑来度量和评估开发和测试人员的质量和效率
软件过程度量目前实施的还不规范，无基本度量的数据来支撑说明存在的问题，只能通过某阶段某现象说明有问题存在，但无法给一个标准去度量和评估，这样给软件开发和测试过程的质量和效率评估带来很多不便，如何收集过程数据，如何制定度量标准，还需要进一步在软件开发过程进行分析与梳理。软件过程度量也是为保证软件质量的纽带，其实这个专题研究的内容也是比较广的，从软件工程上来讲，测试过程改进有很多模型参考，这里不展开说明。
三、互联网软件测试特性
在基于互联网软件系统开发过程中，通常是以Web系统为基础，按照B/S的访问方式为主，包含客户端浏览器、Web应用服务器、数据库服务器的软件系统，首先从技术实现上来说，一般的Web系统结构，不论是.NET还是J2EE框架，都是多层框架设计，有用户操作界面层、业务逻辑层、数据驱动层；其次从结构上来讲，都是有客户端部分、传输网络部分和服务端部分。
1、系统架构
一个比较典型的互联网软件系统的结构示意图如图-1，前端的用户浏览器，通过网络访问应用服务器及数据库服务器传回的数据。
2、互联网软件测试特点
1）不断创新，改变易用性，留住用户
在互联网软件开发过程中，我们往往关注点会集中在用户体验、软件的创新及能为用户带来的价值，所以必须建立在用户体验基础上进行创新，留住用户，改变易用性，是互联网软件开发与测试的首要特点。
2）采用敏捷的开发测试思维，快速实现新功能，快速修复线上bug
基于创新的思维决定了我们在互联网行业的软件开发过程中，必须采取小步快走、版本微创新和快速获取用户反馈，只有这样才能体验客户第一，改变软件服务的对象观念。第二个互联网软件开发测试的特点是快，行业觉得要快速实现新功能并快速发布，快速修复线上存在的问题。
在很多互联网公司，开发和测试团队往往是技术团队的主力军，信息更新快捷和项目需求发布的频繁，很多程度上与传统软件开发和测试过程分离开来，组成比较小的团队进行软件开发与测试，这样有利于处理需求的响应速度的提升，也有利软件开发过程的风险和资源管理。
3）采用的工具协助敏捷开发测试过程，提出了自动化测试
大家知道，如果缩短软件开发和测试过程的时间，在保证需求质量的前提下，我们必须提供我们的过程效率，那么如何提高呢？这里引起在互联网软件项目中的自动化测试，尤其在软件测试过程，自动化测试不仅仅是测试技能的提升，更是能给测试工程师乃至整个研发团队带来质的价值和创新，是真正提高了整个研发过程的效率。自提出自动化测试以后，工程师不断研究与实践，发现自动化脚本与更新维护成本非常大，久而久之维护的工作量已超出预期评估时间，这样导致要花大量的资源投入自动化维护，增加成本，经过大量项目实践与分析，在互联网行业的自动化不能是单纯的基于页面UI功能自动化，必须基于架构进行分层设计自动化，深化自动化技术和平台化的服务，做到持续集成才更有效。
3、敏捷测试思维
通过了解互联网系统架构和软件开发测试过程，我们必须改变以往的测试思维和测试策略，抓住Web软件测试的特点综合选取更适合的方法去运用，直到提出持续集成构建，才在项目中慢慢推广应用起来，其实是采用敏捷的开发过程和测试思维相结合，把软件开发整个过程质量控制提到上游。
四、持续集成介绍
1、持续集成是什么
大师Martin Fowler对持续集成是这样定义的： 持续集成是一种软件开发实践，即团队开发成员经常集成它们的工作，通常每个成员每天至少集成一次，也意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发内聚的软件。
在敏捷开发与测试中，持续集成是极限编程十二实践之一（1999年Kent Beck编写的《解析极限编程》），初被使用极限编程方法的开发人员所推捧，并在过去的几年中得到广泛应用，成为业界广为人知的软件开发实践。该实践用于解决软件开发过程中一个具体且重要的问题，即“确保当某个开发人员完成新的功能或修改代码后，整个软件仍旧能正常工作。”
简单来说，持续集成是频繁、持续的在多个团队成员的日常工作中进行集成、验证并反馈。一个典型的持续集成周期基本包含如下几个步骤：
1）持续集成服务器不断从版本代码库的服务器上检查代码状态，看代码是否有更新；
2）若发现代码有新的提交，集成服务器会从版本代码库服务器下载新的代码；
3）等代码完成更新结束后，持续集成服务器调用自动化编译脚本进行代码编译；
4）运行所有的自动化测试；
5）进行代码分析
6）输出可执行的软件，提高给测试人员进行后的测试与验证
7）通过测试工程师的测试与验证，后发布集成到发布
通过上面的持续集成构建步骤我们不难知道，其实持续集成是一个循环、多次运用、统一检查的过程，如图-2所示描述
2、持续集成模式
根据持续集成在项目中的运用与分析，从基础搭建模式到企业级的解决方案模式，基本可以分成下面三种模式，它们分别是递增的关系，在软件开发中随着系统的复杂度和测试件的可测性不断改进的过程，理想的持续集成达到是统一化、流程化和服务化的过程。
1）基础模式
目前，有很多种持续集成工具，其中不乏开源产品，如Maven、Hudson平台。项目伊始，我们可以建立自己的持续集成服务器，整个项目的持续集成基础结构如图-3所示：
并发多个工程师进行代码开发，每个工程师有独立的开发环境和开发分支，然后统一提交到中央代码库，后进行统一集成编译。
2）阶段式模式
在基础模式的框架基础上，我们增加软件开发过程单元测试、静态代码检查、UI功能自动化检查，如图-4
阶段模式的持续集成较集成提升了很多，在集成server中增加了很多构建套件，综合利用持续集成的特点进行统一管理。
3）管道模式
阶段式持续集成重复任务多，而过程化集成的管理复杂性太高了，任何过程化上的变化都要修改已经写好的脚本，而这些脚本维护比较困难。既然以上两种模式都不灵了，所以引出了高级模式是管道式的持续集成模式。
管道式持续集成形式上与过程化持续集成相类似，但却在概念上有显著不同。在管道式持续集成中，所有的过程单元都运行在同一管道的上下文中，即各单元所使用的原材料都是完成相同的，即代码基线相同。当持续集成服务器发现有新的代码时，会创建新的一个管道，所有的过程单元都在这一个管道中运行，包含编译打包、单元测试、功能测试、性能测试和自动化测试。而每个单元产生的产物也在该管道中有效。如图-5所示：
不难看出管道模式的持续集成综合了基础模式和阶段模式的优点，在管道式中，每次构建都会试图从管道的一端走到另一端。因此，你不会遗漏任何一个版本的成功产品代码，基本上可以使项目研发过程全部自动化了。
3、持续集成流程
一般在互联网软件开发和测试过程中，增加了持续集成构建，在开发和测试环节会进行多次集成与构建，做的比较好的公司，如google，微软等，可以集单元测试、功能自动化测试等集成在一起构建，做到分支代码变更脚本通知一条龙智能流程化和服务化，可见下图-6流程所示。
4、持续集成优点
通过上述概念和模式的阐述，让读者很容易发现持续集成大的优点是降低风险，提高项目研发过程的效率和质量，迎合在互联网时代信息快速更新的现象。持续集成本身并不能帮助开发工程师找到bug，它是通过不断的测试和反馈来尽早的发现缺陷，问题发现的越早处理问题的成本越小越容易解决，由于无法证明通过了测试的代码是无bug存在的，所以持续集成中的测试非常重要，好的测试能够更多更快的发现当前版本中的错误。
往往在开发和测试过程中，软件的缺陷是累积性的，当缺陷很多时，很难发现它们，利用持续集成构建的思想，在项目过程中可以尽早的发现缺陷，大限度的降低了我们在项目后期发现缺陷的可能性和偶然性。
每成功构建运行一次意味着之前做的代码提交可以成功集成，没有与他人提交的分支代码发生冲突，没有带来新的缺陷，有利于开发人员对项目保持自信心和提高工程师的工作激情。
持续集成在项目中的频繁部署将会使终部署的难度降到小，用户能够看到频繁上线的软件，并做及时的沟通反馈，有助于增强互联网模式下用户的信心和动力，也有助于Web产品化和服务化朝着正确的方向快速发展。
5、持续集成构建分析及工具
在敏捷的软件开发和测试团队中，我们所要做的只不过是：不断的回顾、找出问题与瓶颈、不断地重构。通过不断重构持续集成基础结构以及自动化构建脚本，使其达到我们对“反馈时间”和“判断质量准确性”的要求。另外，我们已将“持续集成”扩展到整个软件开发周期，涵盖了持续部署及发布。在上面的配置文件中，不难看出在管道模式中的两个Stage分别名为 “UAT”测试和交付的“Production”，它们一个用于部署新版本到我们自己的持续集成服务器，另一个用于部署新版本到一个公用的持续集成服务器。部署 ‘UAT’的频率为两天到一周之间，‘Production’的频率基本都是一周。这样，我们可以得到快速反馈，改进自己的产品，同时其它团队可以尽早地使用我们开发的新功能。
目前业界主流的持续集成工具主要有：Apache Continuum，CruiseControl，Hudson，Maven，LuntBuild等等，开源工具使用的比较多是Hudson框架。
五、Hudson介绍
1、Hudson简介
是一个功能强大的持续集成框架，可以持续构建和测试软件项目，并监控持续集成中生成的报告，属于开源框架，可以进行多元化插件开发与集成。
框架的优点是基于WAR包，安装部署非常简单，提供了功能完善的Web管理界面和强大的报告输出功能，另外是有丰富的插件支持，并支持自动化安装，便于维护。
2、核心应用
由于是开源框架，在项目实践中可以不断完善我们持续集成过程存在的问题，可以集成更多的插件解决我们想要自助的集成模式。
目前在笔者参与的项目中的核心应用主要有几个部分：
1）静态代码检查（Findbugs工具）
2）单元测试（Junit）
3）代码覆盖率检查（Cov）
3、安装与配置
开源框架，有便利的安装指南，安装起来非常快捷，主要步骤有：
● 下载Hudson WAR包
● 部署到Jboss服务中
● 安装Html Report Plugin插件
● 安装Cobertura Plugin插件
● 安装Findbugs Plugin插件
● 创建分组视图和用户权限
配置也比较简单，主要配置插件和SVN代码及环境相关的条件，我们先看下配置插件，见下图所示：
Cobertura配置（图-7）
Findbugs的配置（图-8）
在Hudson持续集成平台中创建一个Job（图-9）
下面是配置代码库，以Svn代码库代码管理为例（图-10）
后续进行配置定制执行任务和执行shell脚本，然后完成生成单元测试报告和生成代码覆盖率报告的配置，后完成生产bug扫描报告和自动发生邮件提醒的配置，当然也开源插件集成到自动发到手机提醒。都配置完成后可以进行build 运行查看配置信息的报告，如果都通过自己在项目中需求的话，基本配置完成了，后续在项目中能发挥Hudson平台进行持续集成带给我们价值。
六、 Hudson在项目中的应用
可以看出，持续集成的关键在于完成的自动化、完成的流程化，需要借助相关工具和平台才能完成，所以持续集成环境的搭建需要花费比较大的精力，但是环境一旦搞定后，只需要花费很短的时间去维护，而且可以给我们项目开发和测试的效率带来很大的回报。根据持续集成的重要实践，下面以笔者工作中的实例，主要是在Hudson平台进行持续集成进行应用和分析，在项目中的持续集成流程，详见下图-11说明
下面以当前正在开发的一个项目（项目名称为Campaign）为例说明Hudson在项目中的应用及分析，如图-12所示：
从Hudson持续平台上截图中可以看到，目前这个项目并行有5条分支（应用）在开发，平台上很清晰的记录了每个应用开发过程构建集成的记录信息，如成功、失败和持续的Time，图中s列颜色分别代表了：蓝色-集成构建通过，黄色-集成构建（冒烟失败）不通过，还有一种红色-集成构建过程编译失败或发生错误。
下面分别拿不通过和通过的两个应用分支来看（Campaign-Bss和Campaign-Settle）
（一）先看Campaign-Bss（图-13）分支集成情况：
图-13中标红圈起来的我们一一说明和分析下：
● 左侧表示：持续集成的历史记录，可以看出有红色编译失败或错误阶段到黄色冒烟失败的build history记录
● 右侧表示：插件集成后检查，如Findbugs（静态代码）检查、静态代码检查，单元测试和UI自动化覆盖率检查。图-13中覆盖率的图很明显随着Build次数覆盖率是提高的，也是说后的Build覆盖率肯定比前一次要好，质量要高，直到达到约定的提测条件时且主干无failed的情况下才通过（主干无failed是只单元测试脚本在研发过程中可能有变更，如添加、修改和删除，有运行失败的风险，所以要求研发工程师要保证单元测试脚本每次Build后必须是Pass）
图-14
● 进一步查看Coverage Report 我们不难发现更详细的信息展现在我们眼前，如图-14所示，比较详细的输出了工程包摘要，如Lines（代码行覆盖）这里统计代码行共计525行，完成覆盖245行，所以结果统计是Lines为47%
● 分析下下面圈起的信息是显示代码框架中（接口）实现类、方法的名称（如dao层和bo业务的接口实现类等信息），其中com.ali.bp.bss.activity.dao.impl 在Conditionals为N/A（说明开发还未提交代码集成），可以通过下面名称详细查看代码覆盖率覆盖的情况
（二）再看Campaign-Settle（图-15）分支集成情况：
Campaign-Settle分支集成通过后，总体无Findbugs增加，Lines覆盖率为63%，从图-15和图-16中不难看出比Campaign-Bss分支集成后的质量要好。
通过这个项目的案例我们来做个小结与分析，从上面（一）和（二）持续集成分析报告来看，（二）的结果终是集成成功且冒烟通过，而（一）被测试退回重新修复问题再等待集成验证。我们通过Hudson这样的一个持续集成平台，规范了研发过程的集成测试流程，让测试协助开发一起提升整个研发过程的质量和效率，提高软件系统的上游质量。
很明显目前我们在项目中运用的持续集成还没有到达管道模式的一体化平台，像UI功能自动化当前是在另外一个系统上运行，如果没有通过在Hudson平台配置的话，在持续集成平台中是看不到运行结果报告的，另外还有一些插件有待后续进一步研究与实践，像在C++框架模式如何实现Hudson持续集成目前还是调试实践中，当然业绩也有很多好的关于持续集成的平台与案例学习与借鉴，还是希望能通过项目实践证明持续集成能真正解决当前互联网行业软件开发模式存在的一些问题。
七、结束语
结合笔者在互联网行业工作经验，浅谈了在前端基于java应用的软件测试过程中，我们运用敏捷的开发和测试思想，采用Hudson持续集成构建平台，整体打破了传统测试思维，经过多个项目的实践证明，采用持续集成提升了软件开发和测试过程的质量和效率，提高了互联网软件生产效能。
我们说持续集成并不是一蹴而的工作，要想真正做到管道的持续集成构建模式，需要在项目过程中不断积累经验来提升与改进，当然实施持续集成也是需要根据团队的实际情况来实施，但这并不能成会“偷赖”的另一个说法。俗语道“没有做不到，只有想不到”，只要不断反思、重构与实践总结，在互联网软件测试过程中创新每天都会出现。
