持续集成与敏捷开发

     身为Scrum Master以Scrum开发方式去开发系统已经快1年了。团队人手资源都还算丰富，所以一直都没有很关心测试那一块的问题。而是把绝大多数的时间用于简化架构从而简化开发，重构，新人技术培训(由于外包人员较多，所以团队不稳定)，加强代码规范，日常项目进度管理，以及解决开发人员遇到的所有问题，以及外交工作。所以在排满的工作量的情况下，真的很难去关注持续集成的问题。并且在推荐引入Selenium的方案被锯后更是几乎放弃了关注自动化这一块。可是最近测试方面的问题却弄得我不得不关注持续集成。

 

    故事是这样子的，项目进入了质量提升的阶段，开发任务不多，以优化为主，但仅仅核心系统测试评估给出的Man-day大大超出了我的预料，多达1000个man-day，而且非常愚蠢的是这只是一次运行Case所需使用的时间。那我想知道如果中间发现Bug怎么办？你还回归之前测好的Case吗？你不回归你怎么保证AD在改你发现的bug时不会在其他代码上弄出新的BUG？但如果你回归了，你的man-day可就是大的没底了。所以我再一次提及自动化测试的重要性，测试组的确也有用watij做了500多个自动化测试Case，但经常Fail结果无法让人信服。当然这个是核心系统，我目前参与的不多，别人怎么做我也不想评论。但让我不爽的是我负责的项目只开发了3个月却也有300个man-day的测试计划。300个man-day足够我再做这么一个系统了！所以我决心要改变这种荒唐的测试方式。从而也是把测试人员从无聊的点击页面中解放出来。测试人员应该做更高层次的测试流程定义工作！

 

   所以我要做的持续集成流程是这样的：

1. 开发人员的每一次代码提交，都自动地编译整个项目(已经实现)

2. 每天晚上12点定时把集成流的代码发布到开发环境中(已经实现)

3. 发布完成后自动运行单元测试以及冒烟自动化测试(Selenium或watij无所谓)(todo)

4. 把测试结果，测试覆盖率报告发给相关人员，并记录测试结果以及发布结果。以备于历史查询。(todo)

5. 自动回归测试并生成质量报告。(TODO)

 

这样就能保证每天系统都会有一个回归。电脑回归的速度是人手工无法比拟的。所谓几百man-day的手工测试对于电脑来说也只是几小时的运行时间而已。这样做的最大好处是减少项目风险，减少手动过程，增强项目参与人员的信心和安全感。确保项目质量。

 

使用工具：

CruiseControl用于每次Checkin后的代码编译，以及每日发布开发环境。

TestNG，JUnit，Selenium，watij，JWebUnit，easymock等等用于测试。

checkstyle用于代码规范检查

EMMA，JCoverage，TestNG-xslt用于代码覆盖率统计以及测试报告生成。

 

评论

3 楼 maqujun 2011-01-20  

编译时间过长可以考虑定时编译的方式。
比如你每次编译3小时，那么你就设置成每3小时编译整个项目一次。

2 楼 dashjim 2010-12-21  

1. 开发人员的每一次代码提交，都自动地编译整个项目(已经实现)

如果每次编译都要3个小时该怎么办呢？

1 楼 ngn9999 2010-10-08  

我们用Topo做了持续集成，效果可以，不过测试脚本还是需要自己写，也是用Selenium写的脚本。