云音乐自研客户端UI自动化项目 - Athena

场景: 验证点击--点击屏幕位置

     当   启动APP[云音乐]

     而且 点击屏幕位置[580,1200]

     而且 等待[5]秒

     那么 全屏截图

     那么 关闭App

如上这段即为一个自然语言描述的例子，自然语言在一定程度上降低了编程门槛，但是自然语言仍然避免不了程序开发调试的过程，所以在效率仍然比较低下；

3. 
   
4. ide 工具等
   

AirTest 则提供了ide工具，利用拖拽的能力降低了元素查找的编写难度，但是仍然避免不了代码编写的过程，而且增加了环境安装、设备准备、兼容调试等也增加了一些额外的负担。

4. 
   
5. 操作即用例
   

完全摒弃手写代码的形式，用所见操作即所得的用例录制方式。此方式没有编程的能力要求，而且录入效率远超其他三种方式，这样的话即可利用测试外包同学快速的将用例进行录入。目前业内开源的solopi即采用此方式。

如上分析，在用例录入维度，也只有录制回放的形式是能满足云音乐的诉求。

• 
  
• 用例执行稳定性
  

即经过版本迭代后，在用例逻辑和路径没有发生变化的情况下，用例仍然能稳定执行。

理论上元素的布局层次或者位置发生变化都不应该影响到用例执行，特别是一些复杂的核心场景，布局层次和位置是经常发生变化的，如果导致相关路径上的用例执行都不再稳定，这将是一场灾难（所有受到影响的用例都将重新录入或者编辑，在人力成本上将是巨大的）。

这个问题目前在业内没有一套通用的行之有效的解决方案，在Android 侧一般在写UI界面时每个元素都会设置一个id，所以在Android侧可以依据这个id进行元素的精准定位；但是iOS 在写UI时不会设置唯一id，所以在iOS侧相对通用的是通过xpath的方式去定位元素，基于xpath就会受到布局层次和位置变化的影响。

• 
  
• 用例执行效率
  

即用例完整执行的耗时，这里耗时主要体现在两方面：

业内部分自动化框架基于webdriver驱动的c/s模型，传输和执行上都是以指令粒度来的，所以这类方式的网络传输的影响就会被放大，导致整体效率较低；

2. 
   
3. 用例中元素定位的效率
   

相当一部分框架是采用的黑盒方式，这样得通过跨进程的方式dump整个页面，然后进行遍历查找；

用例执行效率直接决定了在迭代周期内花费在用例回归上的时间长短，如果能做到小时级别回归，那么所有版本（灰度、hotfix等）均能在上线前走一遍用例回归，对线上版本质量将会有较大帮助。

• 
  
• 用例覆盖度
  

即自动化测试框架能覆盖的测试用例的比例，这个主要取决于框架能力的覆盖范围和用例的性质。比如在视频播放场景会有视频进度拖拽的交互，如果框架不具备拖拽能力，这类用例就无法覆盖。还有些用例天然不能被自动化覆盖，比如一些动画场景，需要观察动画的流畅度，以及动画效果。

自动化框架对用例的覆盖度直接影响了人力的投入，如果覆盖度偏低的话，没法覆盖的用例还是得靠人工去兜底，成本还是很高。所以在UI自动化框架需要能覆盖的场景多，这样才能有比较好的收益，业内目前优秀的能做到70%左右的覆盖度。

• 
  
• 执行成功率
  

即用例执行成功的百分比，主要有两方面因素：

所以一个框架理想的情况下应该是除了用例发生变化导致的执行失败外，其他的用例应该都执行成功，这样人为去验证失败用例的成本就会比较低。

业内主流框架对比

在分析了自动化框架需要满足的这些核心指标后，对比了业内主流的自动化测试框架，整体如下：

注：因用例覆盖度和执行成功率不光和自动化框架本身能力相关，还关联到配套能力的完善度（接口mock能力，测试账号等），所以没有作为框架的对比维度

整体对比下来，没有任何一款自动框架能满足我们业务的诉求。所以我们不得不走上自研的道路。

解决思路

再次回到核心的指标上来：

用例录入成本：我们可以借鉴solopi的方式（操作即用例），Android已经有了现成的方案，只需要我们解决iOS端的录制回放能力即可。

用例执行稳定性：因为云音乐有曙光埋点（自研的一套多端统一的埋点方案），核心的元素都会绑定双端统一的点位，所以可以基于此去做元素定位，在有曙光点的情况下使用曙光点，如果没有曙光点安卓则降级到元素唯一id去定位，iOS则降级到xpath。这样即可以保证用例的稳定性，同时在用例都有曙光点的情况下，双端的用例可以达到复用的效果（定义统一的用例描述格式即可）。

用例执行效率：因为可以采用曙光点，所以在元素定位上只要我们采用白盒的方式，即可实现元素高效的定位。另外对于网络传输问题，我们采用以用例粒度来进行网络传输（即接口会一次性将一条完整的用例下发到调度机），即可解决指令维度传输导致的效率问题。

用例覆盖度&执行成功率：在框架能力之余，我们需要支持很多的周边能力，比如首页是个性化推荐，对于这类场景我们需要有相应的网络mock能力。一些用例会关联到账号等级，所以多账号系统支持也需要有。为了方便这些能力，我们在用例的定义上增加了前置条件和后置动作和用例进行绑定。这样在执行一些特定用例时，可以自动的去准备执行环境。

在分析了这些能力都可以支持之后，我们梳理了云音乐所有的用例，评估出来我们做完这些，是可以达到70%的用例覆盖，为此云音乐的测试团队和大前端团队合作一起立了自动化测试项目- Athena；

设计方案

用例双端复用，易读可编辑

首先为了达到双端用例可复用，设计一套双端通用的用例格式，同时为了用例方便二次编辑，提升其可读性，我们采用json的格式去定义用例。
eg：

Android端设计

因为 Solopi 有较好的录制回放能力，并且有完整的基于元素id定位元素的能力，所以这部分我们不打算重复造轮子，而是直接拿来主义，基于 Solopi 工程进行二次开发，集成曙光相关逻辑，并且支持周边相关能力建设即可。因为 Solopi 主要依赖页面信息，基于 Accessibility 完全能满足相关诉求，所以 Solopi 是一个黑盒的方案，我们考虑到曙光相关信息透传，以及周边能力信息透传，所以我们采用了白盒的方式，在 app 内部会集成一个 sdk，这个 sdk 负责和独立的测试框架 app 进行通讯。
架构图如下：

iOS 端设计

iOS 在业内没有基于录制回放的自动化框架，并且其他的框架与我们的目标差距均较大，所以在 iOS 侧，我们是从 0 开始搭建一整套框架。其中主要的难点是录制回放的能力，在录制时，对于点击、双击、长按、滑动分别 hook 的相关 api 方法，对于键盘输入，因为不在 app 进程，所以只能通过交互工具手动记录。在回放时，基于 UIEvent 的一些私有 api 方法实现 UI 组件的操作执行。

在架构设计上，iOS 直接采用 sdk 集成进测试 app 的白盒形式，这样各种数据方便获取。同时在本地会起一个服务用于和平台通讯，同时处理和内嵌 sdk 的指令下发工作。

双端执行流程

整体的录制流程如下：

回放流程：

录制回放效果演示：

接口mock能力

对于个性推荐结果的不确定性、验证内容的多样性，我们打通了契约平台（接口 mock 平台），实现了接口参数级别的方法 mock，精准配置返回结果，将各个类型场景一网打尽。主要步骤为，在契约平台先根据要 mock 的接口配置相应参数和返回结果，产生信息二维码，再用客户端扫码后将该接口代表，在该接口请求时会在请求头中添加几个自定义的字段，网关截获这些请求后，先识别自定义字段是否有 mock 协议，若有，则直接导流到契约平台返回配置结果。

mock 方案：

平台

saturn 平台作为自动化操作的平台，将所有和技术操作、代码调度的功能均在后台包装实现，呈现给用户的统一为交互式操作平台的前端。包括用例创建更改、执行机创建编辑、执行机执行、自定义设备、定时执行任务等功能；

问题用例分析效率

在用例执行时，我们会记录下相应操作的截图、操作日志以及操作视频为执行失败的用例提供现场信息。通过这些现场信息，排查问题简单之极，提缺陷也极具说服力，同时在问题分析效率上也极高。

私有化云机房建设

云音乐通过参考 android 的 stf、open-atx-server 等开源工程，结合自身业务特点，实现了即可在云端创建分发任务、又即插即用将设备随时变为机房设备池设备的平台，对 android 和 iOS 双端系统都支持云端操作，且具备去中心化的私有化部署能力。

私有化机器池：

整体架构

落地情况

在框架侧，我们的录入效率对比如下：

用例执行效率：

目前在云音乐中，已经对客户端 P0 场景的用例进行覆盖，并且整体覆盖率已经达到 73%。双端的执行成功率超过 90%。

具体覆盖情况：

具体召回的用例情况：

对于迭代周期中，之前 1.5天 大概投入 15人日 进行用例归回，现在花 0.5天，投入约 6人日，提效超过 60%。

现在 Athena 不光用在云音乐业务用例回归，在云音乐的其他业务中也在推广使用。

总结

本文介绍了云音乐在UI自动化测试上的一站式解决方案，采用录制的方式解决录制门槛高、效率低下的问题，在回放过程中前置准备用例执行环境以及结合曙光埋点提升用例执行的稳定性，并且会保留执行过程中的现场信息以便后续溯因。最后通过私有云部署，在云端即可统一调度Android和iOS设备来执行任务。目前该套方案在云音乐所有业务线均已覆盖，我们未来会在自动化测试方面继续探索和演进，争取积累更多的经验与大家交流分享。