持续集成在移动中的应用

       互联网越来越红火，更多的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%了。这样还有一个额外的好处是，开发人员可以用自己喜欢的方式去做测试了，做开发的一半都很懒，特别讨厌做重复，简单，粗暴的工作了，设计自动化框架和编写自动化测试是一个新方向。对于测试人员来说也是一个学习编程的好机会，会写程序的测试才是好测试（个人见解）。