个人对持续集成的理解和实践
2012-05-02 15:50
295 查看
目前团队人数很少,也没有真正意义上的测试人员,那么如何保证代码质量呢?最近看了《持续交付——发布可靠软件的系统方法》很受启发,突然也想通了很多集成开发工具的设计理念,并做了一些实践,特别记录下来与众人分享。
如何保证代码质量
我觉得根本就是持续集成,确保代码服务器上的版本始终是可运行的。粗粒度上就是把功能分阶段做,每个阶段的功能是完整可发布的,这样有很多好处,尽早看到效果来调整、尽早发现bug、有成果可以鼓舞士气等等;细粒度上就是把每次提交的东西进行测试,让问题尽早暴露尽早修复。
如何达到这个目标呢?原则就是让重复的工作自动化,让测试频繁进行。具体来说就是自动化测试、自动化打包、自动化部署。
自动化测试就是为了能够经常反复的测试才能更早的发现问题。为了让开发人员勤于测试,所以测试的运行时间必须要够短。持续集成推崇的方式是每次提交执行一次测试,这里只做单元测试以确保速度,这也是为什么grails里面把unit单独拿出来鼓励测试。
自动化打包我没用高级的工具,就是利用ant+Ivy写的打包脚本,并借用Grails的思想,通过不同的打包参数可以打出dev、test、prod的包,这样就大大减少人工打包出错的概率。
自动化部署目前我用sae倒是平台就已经支持了,直接上传war包以后,部署都是自动进行的。但是sae的问题就是你本地测试通过的东西,那个环境却不一定行,无比尴尬。
测试种类与分工
测试种类的名词有很多,且最后用的都有很多歧义,特别是集成测试更是有多种含义。我觉得最好理解的划分就是:功能测试(单元测试,组件测试,验收测试)和非功能测试(探索性测试、性能测试、容量测试)。只要能做成自动化的就是开发人员做的;没有办法自动化的就是测试人员做的。
其中,单元测试是不依赖外部只测试某一个类的,为了达到这个效果还有挺多工作的,外部依赖的类要用Mock来模拟,并且尽量不连接数据库这些外部依赖。组件测试就是要有这些外部依赖了,也可以说成是功能测试。验收测试就是模拟用户行为做一系列操作,这个是在最终发布的时候做一次,确保用户使用的正确性。
但注意,每个测试间要做到互相独立,否则会大大增加维护难度。
我期望的效果
单元测试是好东西,但是其实我觉得组件测试是涵盖单元的功能,只是运行时间更长一点而已,但为了减轻测试代码的工作量,我想省去单元测试而全部采用组件测试。组件测试有一个棘手问题就是用到数据库,而数据库是一个有状态的,测试运行的先后顺序都会影响测试结果,所以最好的办法是让每个测试执行完进行回滚。
验收测试是个刚学习到的理念,就是把用户对某个功能的一系列操作放在一起进行功能效果验收。虽然会有很大维护量,但是可以有效模拟用户行为,对功能效果进行完整的测试,达到回归测试的效果。
总结一下,就是利用组件测试达到频繁测试的效果,用验收测试达到回归测试效果。
测试框架
为了达到以上效果有什么好的框架,我查了一圈资料,也试了几个框架。Junit4还是被公认最简单有效的框架,并且有众多的扩展插件和IDE支持,但缺点就是自身功能过于简单。要实现每次测试完的回滚需要结合dbunit,要和spring集成也要自己实现,用到mock也有很多工具可选择。
最后发现一个整合的测试框架Unitlis,它不但整合了以上需求,还简化了配置操作,同时还实现了数据库升级文件的版本管理。试用以后感觉很不错,非常有爱。官方主页是http://unitils.sourceforge.net/summary.html。
我觉得Unitils有以下几个比较显著的优点:
1. 基于反射的断言非常强大,自动过滤掉null和空值,对数组也无视顺序,真的是基于内容本身的比较。
2. 集成了spring管理,都是用注解来声明,非常清楚简洁。
3. 集成dbunit,配置简化了很多配置,特别对事务回滚配置也很灵活、简单。
4. 自带的Mock很好用,语法很漂亮,虽然暂时没打算用。
参考资料:
1. unitils cookbook: http://unitils.sourceforge.net/cookbook.html
2. 开发测试的那些事儿: http://stamen.iteye.com/blog/1466145
3. 测试整合之王Unitils: http://stamen.iteye.com/blog/1480316
4. 使用unitils测试Service层: http://stamen.iteye.com/blog/1485837
5. 《持续交付——发布可靠软件的系统方法》
如何保证代码质量
我觉得根本就是持续集成,确保代码服务器上的版本始终是可运行的。粗粒度上就是把功能分阶段做,每个阶段的功能是完整可发布的,这样有很多好处,尽早看到效果来调整、尽早发现bug、有成果可以鼓舞士气等等;细粒度上就是把每次提交的东西进行测试,让问题尽早暴露尽早修复。
如何达到这个目标呢?原则就是让重复的工作自动化,让测试频繁进行。具体来说就是自动化测试、自动化打包、自动化部署。
自动化测试就是为了能够经常反复的测试才能更早的发现问题。为了让开发人员勤于测试,所以测试的运行时间必须要够短。持续集成推崇的方式是每次提交执行一次测试,这里只做单元测试以确保速度,这也是为什么grails里面把unit单独拿出来鼓励测试。
自动化打包我没用高级的工具,就是利用ant+Ivy写的打包脚本,并借用Grails的思想,通过不同的打包参数可以打出dev、test、prod的包,这样就大大减少人工打包出错的概率。
自动化部署目前我用sae倒是平台就已经支持了,直接上传war包以后,部署都是自动进行的。但是sae的问题就是你本地测试通过的东西,那个环境却不一定行,无比尴尬。
测试种类与分工
测试种类的名词有很多,且最后用的都有很多歧义,特别是集成测试更是有多种含义。我觉得最好理解的划分就是:功能测试(单元测试,组件测试,验收测试)和非功能测试(探索性测试、性能测试、容量测试)。只要能做成自动化的就是开发人员做的;没有办法自动化的就是测试人员做的。
其中,单元测试是不依赖外部只测试某一个类的,为了达到这个效果还有挺多工作的,外部依赖的类要用Mock来模拟,并且尽量不连接数据库这些外部依赖。组件测试就是要有这些外部依赖了,也可以说成是功能测试。验收测试就是模拟用户行为做一系列操作,这个是在最终发布的时候做一次,确保用户使用的正确性。
但注意,每个测试间要做到互相独立,否则会大大增加维护难度。
我期望的效果
单元测试是好东西,但是其实我觉得组件测试是涵盖单元的功能,只是运行时间更长一点而已,但为了减轻测试代码的工作量,我想省去单元测试而全部采用组件测试。组件测试有一个棘手问题就是用到数据库,而数据库是一个有状态的,测试运行的先后顺序都会影响测试结果,所以最好的办法是让每个测试执行完进行回滚。
验收测试是个刚学习到的理念,就是把用户对某个功能的一系列操作放在一起进行功能效果验收。虽然会有很大维护量,但是可以有效模拟用户行为,对功能效果进行完整的测试,达到回归测试的效果。
总结一下,就是利用组件测试达到频繁测试的效果,用验收测试达到回归测试效果。
测试框架
为了达到以上效果有什么好的框架,我查了一圈资料,也试了几个框架。Junit4还是被公认最简单有效的框架,并且有众多的扩展插件和IDE支持,但缺点就是自身功能过于简单。要实现每次测试完的回滚需要结合dbunit,要和spring集成也要自己实现,用到mock也有很多工具可选择。
最后发现一个整合的测试框架Unitlis,它不但整合了以上需求,还简化了配置操作,同时还实现了数据库升级文件的版本管理。试用以后感觉很不错,非常有爱。官方主页是http://unitils.sourceforge.net/summary.html。
我觉得Unitils有以下几个比较显著的优点:
1. 基于反射的断言非常强大,自动过滤掉null和空值,对数组也无视顺序,真的是基于内容本身的比较。
2. 集成了spring管理,都是用注解来声明,非常清楚简洁。
3. 集成dbunit,配置简化了很多配置,特别对事务回滚配置也很灵活、简单。
4. 自带的Mock很好用,语法很漂亮,虽然暂时没打算用。
参考资料:
1. unitils cookbook: http://unitils.sourceforge.net/cookbook.html
2. 开发测试的那些事儿: http://stamen.iteye.com/blog/1466145
3. 测试整合之王Unitils: http://stamen.iteye.com/blog/1480316
4. 使用unitils测试Service层: http://stamen.iteye.com/blog/1485837
5. 《持续交付——发布可靠软件的系统方法》
相关文章推荐
- 谈谈个人对持续集成CI的理解
- 用TravisCI持续集成自动部署Hexo博客的个人实践
- 持续集成理论和实践的新进展
- 一步一步构建iOS持续集成:Jenkins+GitLab+蒲公英+FTP 字数2382 阅读28677 评论48 喜欢149 什么是持续集成 持续集成是一种软件开发实践,即团队开发成员经常集成它们的工
- 持续集成(Continuous Integration)基本概念与实践
- 持续集成 最佳实践 研讨会(1月25日 广州)
- 持续集成实践:使用Visual Studio 2010 Coded UI Test 制作能自动安装/卸载UI应用的程序
- 持续集成DailyBuild实践
- 持续集成案例分析系列(2)——大规模项目团队持续集成实践之一二
- Flex 持续集成(CI)实践(Hudson)
- Hudson配置个人持续集成服务器
- 持续集成,持续部署,持续交付的理解
- docker结合jenkins、gitlab实现.netcore的持续集成实践
- Azure云中Web应用的持续集成实践 推荐
- Maven实战(四)——基于Maven的持续集成实践
- 安卓集成融云即时通讯云的个人理解(集成sdk,登录)
- 持续集成之jenkins实践教程:基础篇(4): 集成redmine
- 来自京东、宅急送对微服务编排、API网关、持续集成的实践分享(下)
- Maven实战(四)——基于Maven的持续集成实践
- 最简方法搭建个人开发持续集成(CI)环境