概述
　　客户端测试包括很多工作，测试工作有功能测试、稳定性测试、代码静态检查、性能测试、兼容性测试和安全测试等，辅助工作有用例管理、设备管理、项目管理等，还有很多其他工作。工程师们往往花了很多时间在做一些重复性工作，没有过多的精力投入到产品质量的深挖上去。地图客户端测试效率提升思路是不定期得组织版本耗时分析，将耗时较长工作缩短、将耗时少工作变为零耗时，从而释放人力做更多探索测试。比如：
　　事例1：设备管理这块，没有一个公共的地方记录设备在哪位工程师手上，工程师借出还入操作比较繁琐，导致在设备调度这块耗时很长。
　　解决方式：开发一个设备管理App，工程师只需要打开设备做借入还出操作；搭建设备管理平台，用于方便查看设备是否空闲以及归属。
　　事例2：地图客户端大框检索业务逻辑复杂，用例繁多，耗时很长（预计115分钟）
　　解决方式：高工对大框检索业务进行代码解读。通过业务分享、用例梳理，用例自动化转化等方式，最终该业务执行耗时降低86%，预计15分钟完成。
　　地图客户端通过对测试效率得不断迭代，得到明显的效果也积累了一些经验值：
　　监控开发工程师每次提交代码质量，触发核心功能验证。
　　功能自动化率最高时达到40%，集成测试一轮时间从22小时缩短至6小时。
　　基于自动化持续集成的前提，集成测试阶段Android地图客户端做到daily灰度，保证代码时刻处于可法办状态。
　　接下来，主要介绍地图客户端自动化是如何搭建的。
　　基础准备
　　很多团队做自动化之前，都可能碰上这样的问题，测试开发人员将框架等都搭建完毕后，转化手工用例时，发现手工用例无法转化，导致自动化工作开展缓慢，且效果不好量化。地图在前期自动化方案也碰到这样的问题，产生的场景就是用例编写人员按照自己的理解编写自动化用例步骤，而实际验证点与期望验证点相差甚远。
　　自动化工作开展前，务必保证现有的用例可自动化，便于后续用例自动化转化和自动化效果考量。用例的要求有三点：
　　用例目的要明确
　　一个用例只有一个验证点 （没有主观体验）
　　给出一个GOOD Case：
　　测试目的：起点或终点以我的位置发起搜索
　　测试步骤：
　　点击路线按钮
　　起点为“我的位置”
　　终点为“西直门”
　　点击所搜按钮
　　2.2   自动化工具
　　地图客户端分为Android和iPhone两个端，关于两个平台app自动化工具有很多，结合地图客户端的特点，我们对工具的选型如下：
　　Android 端
　　自动化事件管理工具：Robotium
　　管理用例执行：adb +bat
　　代码语言：java
　　iPhone 端
　　自动化事件管理工具：UIAutomation（地图是多团队并行开发，组件以库形式提交，所以选择非注入式框架）
　　管理用例执行：tuneup-js+ shell
　　处理崩溃信息：MobileDevice
　　代码语言：javascript
　　2.3   自动化框架
　　前面提到自动化工具选型，关于UI元素定位、事件触发等都是基础library，自动化用例脚本的落地形式很重要。就脚本可读性和后期维护性而言，地图最终选择的脚本形式是关键字驱动型，代码形式如下：

　　我们的脚本最终落地是纯业务化的，数据和用例是分开管理。
　　接口业务化的好处是即使后续替换底层事件管理工具，我们仅重新实现业务化接口，自动化脚本可以复用。地图是针对所有可自动化的功能系统做业务接口拆分，作为自动化接口暴露出去，手工用例自动化转化时使用这些业务接口拼装用例。
　　数据和用例分离的好处是我们可以定义多套数据对应一个用例和便于数据的更新。地图这边核心功能是POI检索、路线检索，接口均由服务端返回，多次请求可能返回结果不同，为了保证用例的稳定性，我们是给每个用例配3套数据。

　　所以我们的自动化框架结构Android 和iPhone两个平台基本类似，只是在framework层封装不同。框架截图如下：

　　报告呈现：

　　如何实施
　　3.1   用例管理
　　在自动化框架那部分有提到地图自动化脚本是关键字驱动，对于用例的规范性已经有很强的约束性，但两个端自动化依然是两套代码，脚本编写和维护依然有不同步的现象。为了方便接口和用例维护，我们搭建了用例管理平台，平台上一次录入，自动生成双平台自动化用例，测试工程师可以轻松得新增维护自动化用例。
　　用例呈现状态：

　　用例编辑状态：

　　3.2 用例编辑状态：
　　各方面专项自动化能力有了，需要和项目有效结合起来，利器就是持续集成。
　　持续集成是什么？也就是每天软件的代码更新都会对该软件的功能进行集成验证一次，这样保证迭代的功能的正确性，及时暴露迭代过程中的问题。人工方法进行持续集成的打包和验证显然行不通，这样会耗费大量的人力和资源，因此自动化就成为进行持续集成的基础。地图组的持续集成测试如图包含这样几类：自动化打包、准入测试、Daily自动化、安全测试等。

　　百度地图持续集成统一采用Jenkins持续集成系统，自动化持续的构建和测试。
　　自动化打包：打测试包是自动化测试的基础，打包分成两类：一类是被测的地图apk，一类是测试apk，通过gradle脚本指令进行apk自动编译。其中被测的地图apk打包的方式是：每三分钟监控一次svn的变化，如果地图包的svn有任何代码的变动就会触发自动打包编译，产出地图的包供测试使用。
　　准入测试：作为RD提交代码的第一道关卡，将重要问题卡在最前端。供测试用的地图包一旦产出就会触发准入测试的job，准入测试的job一共做了两件事：第一件事是产出测试apk，也就是将准入测试的自动化case打包成测试apk并安装进手机里，第二件事是运行准入的自动化用例，如果自动化用例运行失败则立刻触发报警，提示RD及时纠正错误的代码，有效的保障了地图apk包的准入质量。
　　Daily自动化：按天运行的集成自动化用例，包含集成测试中所有的自动化用例，用例量大，运行时间久，因此每天运行一次，并将结果自动整理发送邮件周知给项目负责人，由项目负责人分析失败的用例，将集成测试才会集中暴露问题的风险提前。
　　安全测试：用于定时扫描app中的安全漏洞，提早发现app的安全问题。
　　百度地图通过这几种持续集成的自动化测试方法形成了一套完整的线下测试持续集成方案，有效的保障了地图app持续集成的稳定性，将质量风险尽可能前置。
　　3.3 用户体验馆
　　用户体验馆是手机地图实施自动化的另一个成功案例。简而言之，用户体验馆为核心用户群提供一站式服务的移动测试平台，包含为核心用户提供App测试包下载、自动化测试插件下载和用户中心功能，其中自动化测试插件提供了一种新的自动化运行模式，它以插件的形式嵌入地图体验馆中，可以随时云端进行更新和下载自动化用例，用户只需根据提示下载最新的自动化用例，手工操作运行即可，运行结果将在联网的情况下自动回传给云端进行整合分析。
　　通过用户体验馆的实施解决了测试中用户体验反馈少、UI兼容性测试缺失、新功能用测验证不足和运营成本高的问题，补充了整体的测试方案。