【QCon分享】携程无线App自动化测试实践

背景

近年来，携程的业务急剧增长如2015年第一季度交通票务预订量同比增长104%，而在携程所有的业务中约70%来自于无线，App累计下载量超过7亿（截至2015年6月），这些都迫切的要求提高App测试的效率以保证App的质量。

而在无线App自动化测试（以下简称无线测试）方面，目前还面临很多挑战：

• 框架方面，现在还没有比较成熟的开源框架支持多平台；

• 多设备调度方面，传统的Selenium Grid，在无线测试方面几乎不可用；

• 在各种手机适配方面，又会遇到形式各样的权限，GPS定位，充电满等等一堆的弹框问题。

正是基于这样的一个背景，携程开始了无线app的自动化之旅...

Mobile Testing Infrastructure

无线测试的基础首先需要搭建基础设施。

• 真机与模拟器的选择

模拟器的优点在于可以节省大量经费以及系统本身的开放性与统一性；其缺点也非常突出，在普通机械硬盘的系统中模拟器的运行速度非常慢，可以考虑购入固态硬盘以提高模拟器的运行速度，另一个缺点是模拟器无法模拟真机环境。由于携程迫切的是在真机的环境上测试，因此选择真机。

• 设备类型的选择

设备类型选择的方式也有多种，可以针对市场热销机型采购，也可以针对易出问题的机型采购，或者采用访问App最多设备采购。每一种方式都有优缺点，携程采用的是访问携程App最多的设备类型进行采购，这样可以保证大部分用户没有问题，其他机型可以由各个产线各自再进行测试。

• 设备的调度方式及并行运行

携程主要采用Master/Slave的方式，通过CI来调度分配Job。

可考虑的方案有Selenium Grid的方式，然而由于其特性导致每执行一次用例均会安装App，开源框架支持的力度还不够等问题，最终舍弃。像TestDroid也是自己实现一层Appium Broker。而我们则是使用最为节省的方式，利用Jenkins Master Slave 方式，这样既解决了资源竞争排队的问题，又不用每次运行都需要安装app。每一个Jenkins Job只会打在一个slave上，而每一个Slave上挂载两台设备（可以考虑挂多台）来实现并行运行。 这样设计架构的复杂度不高，设备的复用度以及测试用例的执行效率的问题也迎刃而解。

• 设备的监控

随着设备数量的不断增加，必须加强对各个设备状态的监控，比如wifi的断开（wifi的断开有多重情况导致，比如monkey测试关掉等情况），充电满等，这些会严重影响自动化测试用用例执行的情况必须报警以及远程控制的能力。携程使用的是开源软件Smartphone Test Farm，并在此基础上定制了需要的功能。

截至到2015年10月，我们搭建的手机实验室设备数达到100+。

Automation Platform as a Service（APS）

APS是经过自动化框架到平台慢慢演化而来，最终成为了包含从初始化项目、运行测试用例、查看测试结果等整个测试项目生命周期功能的平台。

自动化测试框架是直接与用户接触的APS平台的核心部分，主要基于testng与nappium来构建的，负责预处理、设备初始化、测试用例的并行执行以及环境的清理，报告生成等工作。其流程如图1所示。

图1

大部分厂商出产的设备都是定制过的Android系统，其中包含一些会影响设备自动化测试用例的设备。比如魅族的设备在打开App的时候会弹出GPS定位权限的要求，小米在安装应用时会有弹框要求用户确认等情况，同时为了保证真实的用户场景，所有设备都不能root，在这些条件下，需要对这些有特殊行为的设备做预处理：比如在解决魅族GPS 弹框问题时：我们会先尝试用adb 来安装一次，然后再用appium来安装打开。

对于并行部分尤其需要注意appium的处理，其本身并没有明确表示提供并行运行的能力，因此需要做一些处理，一个是对于其使用的多个端口需要指定为不同的端口号，另一个是appium会访问一些共享文件，可以通过修改appium的源码来处理。

最后是报表生成，我们是借助于DB，把各种设备的运行报告放在一起｀。最终统一在portal上进行展现。

然而，仅仅只有自动化框架是不够的，随着框架的推广很快会遇到各式各样的问题，大部分集中在搭建环境，CI如何使用等问题，设备如何选择。因此需要一个平台—APS来简化各个环节的操作，APS包括项目初始化项目，测试调度，测试执行，报告生成，监控等功能。其中红色部分为核心的自动化框架部分，其主要功能是驱动设备执行测试用例。如图2所示：

图2

• 初始化项目

对于大部分的新工具，如何开始都会成为一个难题，这也会直接影响到一个新工具推广的难易度。因此APS提供了初始化项目，包括初始化自动化框架运行环境以及生成Demo项目的功能。

• 测试调度

这是为了保证CI Jenkins对用户透明，以减低用户学习成本的功能。

• 测试执行

测试执行是有自动化框架完成。

• 报告生成

针对每一次运行均保存运行设备、结果以及用例的日志。

• 监控

包括测试用例的运行状态，可用设备的状态

APS对于用户的流程如图3所示，在一个平台上可以完成项目的创建初始化，测试用例的执行，测试报告的查看等工作。

图3

Mobile App Testing in Ctrip

随着基础设施与APS的构建完善，在此基础上诞生了一系列的自动化产品。

1. Continues Integration（CI）

• 背景

伴随着业务的增长，App的发布周期缩短到2周一次发布，10+个BU需要在1周内完成集成测试，这导致一些列问题发生频繁的编译失败，应用安装失败，各个页面频道无法进入导致各个BU测试人员无法测试，App Size过大，各项指标未能达到预期等问题。

• 解决方案

为此，我们专门打造了携程无线持续打包平台，无缝把持续打包跟持续检测对接起来。通过CI持续编译解决编译失败问题，对于每一个sit包通过安装测试、冒烟测试、专项测试、App Size分析、可达性测试和安全测试来尽早发现上述问题。其流程如图4所示：

图4

2. 冒烟测试

• 背景

由于携程包发布频繁，BU数量多，各个BU集成测试时间短，导致经常出现各个频道页面无法进入，等到BU的测试人员发现问题，再次重新编译出包会额外花费不少时间。

• 解决方案

在出包之后，首先对各个频道的首页冒烟测试以提前发现问题。测试脚本采用页面元素个数以及图像识别的方式来判断一个页面是否有问题，页面元素低于一定阈值时则认为页面有问题，或者页面出现特定图像比如白屏，一直加载等情况也同样认为有有问题。

为了降低各个设备本身不稳定导致测试结果有问题的情况，会对所有设备上运行的结果聚合（一个通过即为通过）生成一个整体的通过率以提高测试的准确度。

页面的结果呈现为错误结果在前，真确结果在后的排序方式，方便结果的查验。

平均每一个发布周期运行白屏80+次，发现20+个页面出现问题的情况。

3. 专项测试

• 目的

专项测试是为了度量一个应用质量的基本依据之一，可以帮助项目管理人员了解一个版本的应用是否已经达到预期并足以发布的依据之一。

• 实施方案

专项测试一方面提供应用基本数据的测量，另一方面提供了与竞品以及历史包的对比。

基本的测试包括以下测试：

■ 安装卸载测试

主要测试应用是否能够正常安装卸载

■ 冷热启动测试

测试应用第一次启动的时间以及关闭后再次启动的时间

■ 崩溃测试

通过monkey测试压测应用并保存日志

■ 性能指标

包括应用占用空间大小，缓存大小，耗电，网络流量等数据