下面分别拿不通过和通过的两个应用分支来看（Campaign-Bss和Campaign-Settle）

　　（一）先看Campaign-Bss（图-13）分支集成情况：

图-13

　　图-13中标红圈起来的我们一一说明和分析下：

　　● 左侧表示：持续集成的历史记录，可以看出有红色编译失败或错误阶段到黄色冒烟失败的build history记录

　　● 右侧表示：插件集成后检查，如Findbugs（静态代码）检查、静态代码检查，单元测试和UI自动化覆盖率检查。图-13中覆盖率的图很明显随着Build次数覆盖率是提高的，也就是说最后的Build覆盖率肯定比前一次要好，质量要高，直到达到约定的提测条件时且主干无failed的情况下才通过（主干无failed是只单元测试脚本在研发过程中可能有变更，如添加、修改和删除，有运行失败的风险，所以要求研发工程师要保证单元测试脚本每次Build后必须是100%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）分支集成情况：

图-15

图-16

　　Campaign-Settle分支集成通过后，总体无Findbugs增加，Lines覆盖率为63%，从图-15和图-16中不难看出比Campaign-Bss分支集成后的质量要好。

　　通过这个项目的案例我们来做个小结与分析，从上面（一）和（二）持续集成分析报告来看，（二）的结果最终是集成成功且冒烟通过，而（一）被测试退回重新修复问题再等待集成验证。我们通过Hudson这样的一个持续集成平台，规范了研发过程的集成测试流程，让测试协助开发一起提升整个研发过程的质量和效率，提高软件系统的上游质量。

　　很明显目前我们在项目中运用的持续集成还没有到达管道模式的一体化平台，像UI功能自动化当前是在另外一个系统上运行，如果没有通过在Hudson平台配置的话，在持续集成平台中是看不到运行结果报告的，另外还有一些插件有待后续进一步研究与实践，像在C++框架模式如何实现Hudson持续集成目前还是调试实践中，当然业绩也有很多好的关于持续集成的平台与案例学习与借鉴，还是希望能通过项目实践证明持续集成能真正解决当前互联网行业软件开发模式存在的一些问题。

　　七、结束语

　　结合笔者在互联网行业工作经验，浅谈了在前端基于java应用的软件测试过程中，我们运用敏捷的开发和测试思想，采用Hudson持续集成构建平台，整体打破了传统测试思维，经过多个项目的实践证明，采用持续集成提升了软件开发和测试过程的质量和效率，提高了互联网软件生产效能。

　　我们说持续集成并不是一蹴而就的工作，要想真正做到管道的持续集成构建模式，需要在项目过程中不断积累经验来提升与改进，当然实施持续集成也是需要根据团队的实际情况来实施，但这并不能成会“偷赖”的另一个说法。俗语道“没有做不到，只有想不到”，只要不断反思、重构与实践总结，在互联网软件测试过程中创新每天都会出现。