2017年8月开始接手做持续集成平台的工作，该平台包含打包发布，每日构建，稳定

测试

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

自动化测试

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

1.客户端每日构建　　1.1、单元测试

　　单元测试主要是由开发负责编写的，主要是因为开发对产品更加的了解，同时测试开发团队人太少了，要做的事情好多，优先做其他的。关于框架选择，最初想要使用的方案是robolectric + junit4 + mockito + dagger2，然后被项目经理及总监否定了，选择了

android互联网

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

　1.2、集成测试

　　在这里我们的集成测试跟单元测试很像，在

用例设计

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

　1.3、静态代码分析

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

　1.4、报告邮件通知

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

　2、客户端稳定性测试

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

　　执行流程，凌晨定时任务会去拉取svn上的代码，代码更新好后，会使用脚本sed命令去把leakcannary加入到代码当中，接着执行apk打包，固件打包，将生成的固件通过OTA升级，(ota升级：将包放到指定的服务器，在通过接口配置由哪个版本到哪个版本的升级，应用本身有个

server

　　对于

性能测试功能测试

　3、服务端每日构建

　　对于服务端的每日构建主要是做部署，

接口测试

4、其他　　4.1、不足

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

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

　　单元测试用例太少了

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

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

　4.2、躺过的坑

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

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

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

　　不支持接口更新ota配置

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

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