持续集成工作总结

image

2017年8月开始接手做持续集成平台的工作，该平台包含打包发布，每日构建，稳定测试。做这个的初衷是为了能够提早的暴露出问题，同时使开发在打包上尽可能少出错，提高效率。

首先收集现状，源码管理混乱，底层打包空间共用，apk打包在本地，没有稳定性测试，专项测试。需求整理，需要做源码管理，分离底层共用的空间，打包统一使用服务器打包，增加自动化测试，稳定性测试，专项测试。

下面说下我们的每日构建和稳定性测试：

　　1. 客户端每日构建

image

　　1.1 单元测试

单元测试主要是由开发负责编写的，主要是因为开发对产品更加的了解，同时测试开发团队人太少了，要做的事情好多，优先做其他的。关于框架选择，最初想要使用的方案是robolectric + junit4 + mockito + dagger2，然后被项目经理及总监否定了，选择了android自带的测试框架，主要原因相对与互联网公司我们公司的平台也是自己开发的，所以更需要在真机上执行测试。

执行过程，每天的凌晨会有定时任务去svn 上check out代码，连接设备，然后使用gralde命令执行测试生成测试报告。

1.2 集成测试

在这里我们的集成测试跟单元测试很像，在用例设计上主要是是按业务流程去执行的单元测试。

对于集成测试，可以加入ui自动化测试，比较喜欢的一个自动化测试是macaca。

　1.3 静态代码分析

静态分析的话会在服务器上安装sonar-scanner，执行扫描后将结果上传到sonaerqube上，代码规则的的配置会在sonarqube上，最初开始做静态代码分析不建议开启很多的规则项，需要给开发团队适应的过程，规则如果一开始就开很多，开发估计就直接不改了吧，而且自带的规则会有一定的误报率，需要人工筛查。

1.4 报告邮件通知

执行失败或者成功都回给开发测试发送邮件通知。

2、客户端稳定性测试

image.gif

稳定性测试主要是为了暴露apk的性能问题，提高产品的稳定性。

执行流程，凌晨定时任务会去拉取svn上的代码，代码更新好后，会使用脚本sed命令去把leakcannary加入到代码当中，接着执行apk打包，固件打包，将生成的固件通过OTA升级，(ota升级：将包放到指定的服务器，在通过接口配置由哪个版本到哪个版本的升级，应用本身有个server去检查，从而实现升级）。执行monkey命令，第二天去查看monkey日志，oom日志，已经是否存在.prof文件该文件是leakcannary生成的，拿到prof文件后可以使用MAT或者Android Studio去分析。

对于性能测试需要关注网络，io，流量，内存，cpu，而对于我们的产品更加的关注内存，对于其他的指标我们会在功能测试的时候去关注这块。

　3、服务端每日构建

对于服务端的每日构建主要是做部署，接口测试，静态代码分析。服务端使用的语言是php，它的部署较为简单，只需要从使用git pull就可以，部署完成后执行接口测试，静态代码分析。接口测试我们使用的是robotframework+requestlibrary，封装出公共的关键字，写testcase的时候使用该关键字。静态代码分析使用sonar-scanner，扫描结果在sonarqube上展示。最后发送邮件测试报告给开发/测试。

4、其他

　　4.1 不足

• 对于我们的整个流程缺乏ui方面的自动化

• 静态代码分析规则不够完善

• 单元测试用例太少了

• 稳定性测试缺乏cpu，io，网络等的监控

• 部分接口业务无法覆盖（eg：支付）

4.2 躺过的坑

• 旧的服务器谁都能上去改东西...

• 同个服务器使用多个版本的gradle打包

• 底层源码（sdk）管理混乱，开发随意更新源码

• 不支持接口更新ota配置

• 源码管理混乱，分支无规范，非主干开发

在做持续集成的工作中，开始做流程的优化，优化功能测试流程，自动化流程；接触了较多的工具，开始做方案的分析，去做整体的架构设计跟实现，去跟项目经理沟通，沟通是一个很大的学问，当中你可能会遇到脾气好的同时也会遇到脾气差的，遇到脾气不好的告诉自己多笑笑，多找他几次也许问题就能解决。开始更加关注代码的质量，去了解专项测试。

---

qrcode_for_gh_b52573ca6d2e_258.jpg