持续集成在移动中的应用

? ? ? ?互联网越来越红火,更多的App,更快的迭代,更多软件的更新甚至到了一周一更新,苦逼的程序员们要面对更多的加班。开发,测试,报bug,修bug,测试,发布,在这种无休止中恶心循环。时间紧迫,为了减少开发和测试的沟通成本,很多公司的开发以及开始承担一部分测试工作了,劳动强度可见一斑 。那么问题来了,如何轻松完成开发测试工作?

? ? ? ?不得不说说持续集成了,持续集成也叫做CI(continous Integration)。感觉持续集成天生就是为Scrum(有的地方也叫敏捷)而生的。现在很多公司已经在内部使用Scrum的管理方式了,形成Scrum Team,以一周,两周或者四周为一个迭代。那么在这一个迭代里面,我们要完成新功能的开发,测试和交付。对应的工作有,开发或者修改bug,提交代码,功能测试,回归测试(不同的Sprint可能具体任务不同)。那么持续集成是如何在这些工作中发挥作用的呢?

? ? ?现在代码写好了,要存到代码仓库, 比如Git/SVN/CVS/CC,等等很多。如何保证提交的代码正确和有效?我们一般需要通过编译和打包去验证。如何保证开发的新功能或者修好了BUG? 需要去执行Unit case (当然还是会有部分手工测试的,后面再说)。如何保证新的修改不能影响到以前的功能?需要去执行回归测试。有这么多的工作,一定会花很多时间吧?其实不然, 我们可以好好利用持续集成去做这些事情,根本不需要你动手,只需收收邮件,查看一下测试结果就好了。那么持续集成是怎么做到的呢?

? ? ?首先说一下持续集成的架构,现在有很多开源的产品来支持它了。比如Jenkins(以前叫做Hudson),它是一种master/slave架构的软件,安装在Master的机器上,可以不断添加机器作为它的slave,分配不同的任务给不同的slave去执行。还可以和许多软件一起集成工作,比如Gerrit/Sonar/Docker/.... ?,随着支持的插件越来越多,集成的软件也越来越多。

? ? ?有了它,我们工作就变成另外一种场景了。提交代码到Gerrit, 触发verify job去执行代码检查任务(自带的活着第三方的工具,如Sonar),编译,打包,执行Unit 测试或者功能测试。中间有任何问题,关注的人可以收到邮件的提醒和通知。每天晚上定时执行自动化测试的任务,第二天早上,打开邮箱就可以看到测试报告,可以相应做出工作安排和调整。等到软件发布的时候,点击一个按钮,自动化编译,打包成可执行的软件,交付给用户。这种工作是不是很惬意?

? ? ?其实要想轻松,还远没有那么简单,很明显测试用例的自动化率是一个前提。只有提高了测试用例的自动化率才能够做到真正的轻松。那么如何提高呢?这个问题也是长期困扰我的。我是做TV客户端,有很多平台,PC /Mac /Mobile(Android/iPhone/Pad)等等,客户端是一个portal,不同的平台的解决方案也是不一样的,要写自动化的测试用例是很困难的。我们的策略是,对于公共的部分,我们提取公共的接口,对接口进行测试,对于不同的测试用例,我们按照实现的难易程度去实现自动化。公共接口部分完全使用了自动化,自动39%。剩下的测试用例,难以实现的原因是有一部分是需要人工操作和识别判断的,后来我们发现,这部分我们可以使用脚本来实现,主要是python的脚本,识别和判断的部分,我们使用MIT的开源工具Sikuli去做,这样自动化率就可以提高到69%了。这样还有一个额外的好处是,开发人员可以用自己喜欢的方式去做测试了,做开发的一半都很懒,特别讨厌做重复,简单,粗暴的工作了,设计自动化框架和编写自动化测试是一个新方向。对于测试人员来说也是一个学习编程的好机会,会写程序的测试才是好测试(个人见解)。

? ? ?

郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。