概述
　　客户端测试包括很多工作，测试工作有功能测试、稳定性测试、代码静态检查、性能测试、兼容性测试和安全测试等，辅助工作有用例管理、设备管理、项目管理等，还有很多其他工作。工程师们往往花了很多时间在做一些重复性工作，没有过多的精力投入到产品质量的深挖上去。地图客户端测试效率提升思路是不定期得组织版本耗时分析，将耗时较长工作缩短、将耗时少工作变为零耗时，从而释放人力做更多探索测试。比如：
　　事例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套数据。