持续集成与敏捷开发

     身为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用于代码覆盖率统计以及测试报告生成。

 

你可能感兴趣的:(项目管理)