老板们不知道的秘密：开启自动化测试，让我们一起以逸待劳

Android UI 自动化测试

我认为所有的UI自动化测试都分成基本的三个步骤：定位元素，操作元素和执行断言。大家在做UI自动化不同的主要是方案的选型，封装优化的方式不同。目前移动App的更新迭代速度非常快，所以优先以稳定的流程进行自动化测试脚本编写。

开展Android UI 自动化测试

1、调研现有的UI自动化框架： Robotium, Appium和 Android Espresso 等主流框架。 最终选择了较为稳定的并可以脱离服务运行的Roboitum。

2、通过开展内部分享培训，让所有的移动测试工程师能够快速的使用Robotium 和 uiautomatorviewer 等工具进行脚本编写。

3、脚本编写和执行: 我们使用虚拟机Genymotion和STF进行管理的实体机进行脚本执行。

• Genymotion: 安卓模拟器在开发过程和测试过程中有着重要的作用，可以帮助工程师进行代码的运行调试，也可以帮助测试人员执行测试用例，模拟不同的场景。所以一个强大的模拟器能够提高开发和测试的效率，而Genymotion就是安卓模拟器中的翘楚。
• Genymoiton能够和自动化进行结合，得益于它可以通过命令行启动： A、配置环境变量Path或Hard Code可执行的路径，这里需要使用的两个可执行文件是genyshell和player。 B、以下是不同操作系统下可执行文件的路径： · genyshell在MacOS下的路径是/Applications/Genymotion Shell.app/Contents/MacOS · genyshell在Linux下的路径是/genyshell · genyshell在windows下的路径是程序安装目录下，例如：C:\Program Files\Genymobile\Genymotion · player在MacOS下的路径是/Applications/Genymotion.app/Contents/MacOS · player在Linux下的路径是/player · player在windows下的路径是程序安装目录下，例如C:\Program Files\Genymobile\Genymotion C、通过命令获取模拟器列表，并启动模拟器 · genyshell -c "devices list" · player --vm-name "<virtual device name>" D、以下是示例的展示：

HTC-One模拟器成功的运行：

这就是在自动化测试中常常用到的命令行模式启动。

4、分发和执行测试用例: Genymotion作为优秀的模拟器，能够帮助我们进行基本的用例执行和调试。但是在不同的实体机上执行UI测试用例更加有意义，功能测试的同时能够对不同ROM，不同屏幕大小和分辨率， 不同Android版本等进行兼容性测试。所以我们使用了STF

Android H5内容测试监控

目前很多App中通过嵌入H5的方式展现和丰富功能和内容，我们选择了Selenium + Python的方式来对要加载的H5页面进行UI自动化测试和监控。这里以7Fresh为例，我们通过脚本编写：覆盖首页所有监控点，以及主流程。详细和直观的报告，及时的邮件通知能够帮助我们迅速定位问题：

• 邮件展示：

• 报告中的Bug定位和描述：

我对UI自动化的认识

理论上说移动App的快速迭代，UI自动化的开发维护成本在直线上升，尤其是目前部门的业务以电商为主，更多的是内容展示和复杂的交互流程， 在这个前提下我认为并不适合将大量的精力放在UI自动化上。所以通过元素的监控，和基础交互流程的脚本覆盖我认为就足以保证UI部分的自动化工作。

我们应该将精力放在回报比例更高的接口测试上，下面将介绍下我们是如何进行接口测试的。

Android 接口自动化测试

接口方案的选型

在接口部分，往往会有以下几个主流的方案：

1. Postman轻量级工具，实现手工+自动化执行
2. 通过JMeter的GUI来配置接口测试，编写BeanShell脚本满足特殊的断言
3. 自行编写框架，读取Excel或者数据库等数据存储来进行数据驱动测试
4. 其他，比如通过Web进行用例管理等

在选择方案的时候，我认为有以下几个准则，仅供参考：

1. 一切方案的选型都是以能够成功落地为根本目的，以保证质量为根本目的。
2. 方案应该有较低的学习成本或者较高的产出比，这个可以举个例子：我们选择了JMeter作为借口测试工具，因为它通过內建的菜单就可以满足基础测试。JMeter作为业内的主流测试工具之一，大家学习后对个人的职业发展帮助比较大。
3. 快，是做自动化的一个核心标准。快意味着更低的投入，更快的回报，也意味着更容易响应变化，所以避免重复造轮子。

如何做接口测试

1. 使用Git进行代码管理，所有项目进行统一归档。

1. 在测试用例中标注ERP，后续可以进行方便进行用例的统计和邮件通知的直达。

1. 拆分测试用例至： 预发环境和线上环境。不同的测试环境用户的权限不同，我们的核心宗旨是： 不污染线上环境，测试/监控更多的主流程接口。
2. 维护接口测试用例和统计覆盖率。每个Release都有可能修改或者增加接口，所以我们统计并维护了一个接口用例列表：

1. 邮件通知以及报告展示：

我对接口自动化的认识

我还是要强调一下，一切自动化的核心目的是提升质量提升工作效率。为了达到最大的收益，有以下几个Best Practices:

1. 对接口测试脚本定期进行Review以及维护。
2. 通过接口脚本的执行实现监控服务状态的目的。
3. 通过脚本数量的统计，量化每个人的工作量和脚本分布，为后续的优化提供数据依据。
4. 监控接口的问题邮件定向发送，提升接口异常的响应速度。

自动化测试的分布执行

目前自动化测试的脚本主要是以UI和接口为主。其中UI中使用Robotium部分的脚本可以通过STF连接真机以及模拟器进行运行，Web部分和接口部分可以使用Docker进行分布执行。这里重点介绍Web部分，接口部分也类似。

基础软件

1、获取最新的hub和浏览器node, 浏览器选择debug版本，这样可以通过VNCViewer来进行连接查看。

# 获取各个浏览器的debug版本
docker pull selenium/node-chrome-debug
docker pull selenium/node-firefox-debug
# 获取Selenium Hub
docker pull selenium/hub

2、执行命令docker images查看是否下载成功

3、启动hub实例，以及各个浏览器实例，并将浏览器实例link到hub上。

# 使用4444做本地端口映射来启动selenium hub, 并将该实例命名为selenium-hub
docker run -d -p 4444:4444 --name selenium-hub selenium/hub
# 启动浏览器实例，并link到启动的hub上
docker run -d -P -p 5901:5900 --link selenium-hub:hub selenium/node-chrome-debug
docker run -d -P -p 5902:5900 --link selenium-hub:hub selenium/node-firefox-debug

4、输入网址http://127.0.0.1:4444/查看Selenium-hub挂载状态。

5、安装VNC Viewer可以连接Docker实例，查看实际的运行情况。

至此， Docker环境的基本部署已经完成。

Node配置

中文支持

1. 默认的docker对中文支持并不好，可以使用命令或者在dockerfile中添加如下代码： RUN cd /usr/local/share/fonts/ \ && wget "https://github.com/googlei18n/noto-cjk/blob/master/NotoSansCJKsc-Medium.otf?raw=true" \ && fc-cache -f -v
2. 使用docker commit commitID来保存修改

多浏览器支持

1. Chrome 在dockerfile中配置Chrome版本的安装

通过配置不同的dockerfile来实现不同版本浏览器的镜像生成。当然也可以在一个镜像中安装不同的浏览器，通过不同的容器运行不同版本的浏览器，但是这样容易造成测试环境的污染。

1. Firefox 在dockerfile中有关于Firefox版本的参数化。

可以通过脚本中的URL找到目前官网上存在的Firefox版本：

Selenium RemoteDriver

基本调用

1. 通过配置版本和浏览器类型来初始化RemoteWebDriver.

1. 通过获取挂载在Selenium Hub上的不同浏览器版本来配置DesiredCapabilities, 实现在不同版本不同类型的浏览器上执行测试用例。项目中目录结构如下：

代码的优化

Python RemoteDriver

这个网址有关于Python调用Selenium的API使用方法： http://selenium-python.readthedocs.io/api.html

移动专项测试助力

移动端的测试有别于传统的测试技术，因为涉及到用户使用过程中的体验，比如耗电，性能以及安全等。下面简单介绍下，我们团队是如何进行专项测试的：

• 代码覆盖率 代码覆盖率是指在执行测试过程中执行case时调用代码在代码总和中所占的比例，一定程度反映了测试的质量。 代码覆盖率能够帮助我们对手工测试和自动化测试的效果进行代码级别的衡量。比如，我们在了解某功能涉及的java文件之后，在手工测试该功能期间采集代码的覆盖率，能够帮助我们定位测试是否充分，是否应该对用例进行查缺补漏。 Gradle已经默认集成了代码覆盖率工具Jacoco，所以只需要在文件build.gradle中添加代码testCoverageEnabled = true即可。
• 内存泄露测试 内存泄露我们使用开源的工具LeakCanary（ https://github.com/square/leakcanary）。不过，为了和自动化更好的结合，我们对该项目做了一点修改， 在发生内存泄露的时候统一将数据发送到服务器，这样可以更方便的统计，展示和追踪内存泄漏。 如果想在前端能够展示内存泄露的历史信息，需要在服务器上创建一个数据库用来存储这些数据。那么表结构如何设计呢？ 这取决于LeakCanary能记录哪些信息，阅读源代码之后发现该库可以记录以下几个重要信息：

在明确了表结构之后，只需要在Django后台的Model中创建表即可：

编写好接口后进行调用，成功写入数据库：

之后对DisplayService进行数据上传操作，即可实现当发生内存泄露的时候，把数据写入到数据库之中。

• 性能测试 使用Android自带的工具TraceView即可，但是在之前要生成trace文件。所以我们需要在代码中添加： Debug.startMethodTracing(“test”); 以及停止追踪的代码： Debug.stopMethodTracing(); 之后使用adb命令拿到数据即可。如果使用Android Studio 可以省略这个步骤，具体的细节可以在网上找到文档，这里就不赘述了。
• 电量/流量测试 我们使用腾讯的开源SDK： GT来进行测试。具体文档在官网有详细描述：

• 安全测试 我们编写了Android安全测试的App用来进行安全测试, 它可以进行基础的安全测试，如Activity, Sevice, 敏感信息等:

Export Activity, Service,Broadcast 以及启动或者发送服务广播等

SQLite内容敏感测试：

文件内容敏感测试：

高危权限测试：

• 自助打包平台 为了提升打包的效率，我们搭建了自助打包平台，能够实现自助的iOS/Android的安装包编译，邮件通知，打包完成后的自动化测试(安全测试，Crash测试，内存泄露测试，UI自动化测试等) 编译打包，扫码安装/下载，一键测试：

邮件通知打包人员，包含必要的打包信息：

总结

这是移动测试避坑指南系列文章的最后一篇，因为篇幅所限所以很多知识点没法详细介绍。对于测试技术本身而言，每一个测试点都有很多的方案可以选择，希望通过这片文章传播更多的是： 为什么选择这个方案，而不仅仅是选择了什么方案。

写文档本身是将所积累的知识系统梳理的一个过程，对我而言边写边学受益匪浅，也鼓励大家平时多多记录。比写更难的是如何清晰的表达让其他人能理解学懂，所以也鼓励大家多多分享，共同进步！

---------------------END---------------------