背景

在云测试平台设计中，Agent 的设计一般来讲需要考虑如下一些场景：

移动设备的交互控制是否需要 PC 设备的支持

和移动端设备进行数据交互，主要有两种方式，一是通过常规官方建议的 PC - Mobile 的调试方式，使用公共协议如：adb、usbmuxd 进行数据交互，二是直接在 Mobile 中植入代码，通过代码调用系统 API 和服务端进行交互，省去 PC 的中转环节

移动设备在测试任务执行上如何隔离

设备在使用过程中还需要考虑到它会执行哪个 APP 、哪一种类型的 APP、哪一组人员、哪一种测试类型等的业务测试，所以在设计时需要考虑单个设备的「原子性」

设备如何做到动态运维和自动化程度

设备的维护对于服务端来讲一般都会以设备池的方式运行，这样就需要考虑到增加、删除设备对设备池带来的影响，同时如果设备的维护在公共实验室或者在远端的机房，那对应的操作就需要远程完成，所以设备的维护、重置、监控等相关的操作也需要提供远程 API

自动化框架选择和运行环境

自动化测试是云测试的主要目的，自动化框架的选择会影响自动化测试能力的扩展范围，所以需要选择一款合适的「基础」自动化测试框架

系统选型

知乎云测平台采用利用 PC 作为维护移动设备的服务器，交互模式为服务端 - PC 端 - 移动设备交互的方式，PC 端部署与服务端进行交互的 agent 代码，采用 socket 进行通信确保即时性，同时通过 http 主动消费服务端维护的任务池，执行完毕之后返回数据并循环进行，在自动化任务执行上采用 Appium 做为「基础」自动化测试框架。系统选型主要基于如下几点：

大部分自动化框架的运行都基于 Mobile 挂载 USB 对应的 PC 上，同时 Agent 服务、自动化框架、硬件运维、异常处理等都需要稳定的 PC 运行环境
Netty Socket 框架可以提供稳定的即时数据交互
任务数据的处理在精度上要求更高，所以采用 Http 请求任务池的方式
自动化框架选取在各方面都具有一定优势的 Appium，「主要是社区比较活跃」，同时设备执行测试任务的隔离也主要由 Appium 来进行控制，如下是对比图：

Agent 模块组成

Agent 模块在云测试平台中主要负责设备控制、维护的功能，主要包括三大模块如下：

实时任务

基于 Netty Socket

实时交互如下图展示：

移动端设备控制

在这里移动端设备控制是方便使用者可以在远端通过一定的方式远程控制设备的操作，同时看到设备的实时显示画面，经过各种调研、测试、实验选取 openstf [https://github.com/openstf/stf] 开源的两款工具 minicap / minitouch 来完成这部分功能。stf 是一款可以远程调试移动手机、手表、Pad 的 web 工具，使用效果如图：

参考 stf 的 nodejs 源码中 minicap / minitouch 这两款工具的使用方式，由于 Agent 平台使用 java / kotlin 编写，而 minicap / minitouch 是用 c/c++ 编写，所以采用将手动编译完成的 minicap / minitouch 运行程序内置到 Agent 中提供调用。

minicap

github 地址： https://github.com/openstf/minicap

当设备接入时 minicap 初始化线程会分为如下几个步骤对设备初始化和启动：

minitouch

github 地址： https://github.com/openstf/minitouch

当设备接入时 minitouch 初始化线程也会分为如下几个步骤对设备进行初始化：

Agent minitouch / minicap 和 pc 交互图如下:

定时任务

定时任务，主要是自动化测试任务的数据交互，云测试平台的优势在于可以动态的调用多个设备进行测试，而每个设备的运行又是独立的，所以任务的运行设计最小粒度以单个设备运行为准，那么无论是兼容性测试、安装测试、自动化脚本测试、性能测试等都会在服务端拆为单个的任务，以任务池的方式存放到多维队列中，Agent 只需要在交互时拿到对应设备的队列任务运行即可。与设备远程控制要求交互的即时性不一样，远程控制要求指令必须在毫秒级以内完成数据的下发和返回，自动化任务交互可以容忍一定的延迟，所以在与服务端交互上采用了 Http 轮询方式：

Http 轮询

轮询的详细过程如下图示：

设备维护

Agent 部署完成之后，会主动监听当前 adb / usb 的设备连接状态，当有新的设备接入、已有设备移除时会执行图中的相应步骤来维护设备的连接状态，做到移动设备的自动化接入和移除。

同时在设备的任务执行、远程控制、离线上线等过程中都会和服务端进行数据维护交互，同步设备的状态到服务端，为服务端的任务处理、排队策略、动态任务分配等提供判断依据

遇到的问题和处理

1. minicap / minitouch 设备兼容问题？

由于后面设备类型的未知性，只是在 Agent 内部对指定的机型设备做了特殊兼容处理，除了几款 stf 天然不支持的设备类型，并未发现有大量的兼容问题。

2. 设备图片传输实时性问题？

目前大部分任务处理都是在公司内网环境，目前只是做了图片数据级的压缩，可以预见在网络环境较差的情况下，可能需要图片像素级的压缩处理。

图片处理是远端控制的重要环节，主要处理方式如下：

我们从目前比较主流移动设备拿到的单个图片的大小应该在 1M 左右，如果是高分辨率的设备或者 iPad、AndroidPad 等设备可能会更大，做纯数据压缩最多只能做到百 KB 大小的级别。

在上面的前提下，我们可以牺牲一部分图片的清晰度来换取操作的流畅度和网络性能，如图所示我们先将原图按照比例等比压缩到一定大小，然后将压缩后的图片在页面上渲染到和设备同样大小，

这样丢失的清晰度和压缩的比例有直接关系，在数据传输的过程中可以根据网络质量的好坏动态修改图片压缩的比例。

经过图片压缩和数据压缩，图片的传输量级可以缩小到十 KB 大小的级别，经过调整大部分设备图片数据的大小传递都在 20 KB 上下浮动，并且同时具有较好的清晰度。

3. 设备维护线程、自动化处理线程稳定性问题？

针对线程运行、本地环境不稳定，添加了一些页面手动控制操作，当 Agent 运行过程中发现设备假死、卡顿、超时等问题会直接通过 IM 发送报警，运维可以通过页面操作重新初始化设备相关线程及时发现和处理问题。

本文转载自知乎技术专栏。

原文链接：

https://zhuanlan.zhihu.com/p/83373208

创作场景

知乎移动端云测试平台实践 (二)—— Agent 设计和实现