知乎移动端云测试平台实践(三)—— 自动化测试方案设计和实现_移动_陈康康

生成式AI领域的最新成果都在这里！抢 QCon 展区门票了解详情 



 写点什么

背景

为了充分利用云测试平台维护的设备，提升空闲设备使用率，开展自动化测试替代部分回归测试、重复性测试和多设备兼容测试，同时满足如下几种类型的自动化测试需求：

随机测试（monkey、随机操作指令）：

在多设备执行的基础上完成安装、启动、覆盖安装、monkey 测试 / 随机指令、卸载等一系列操作。

遍历测试（深度遍历、智能探索）：

在 monkey 测试 / 随机指令的基础上，对执行步骤进行改造，将随机操作替换为 app 内部页面的深度遍历，设计算法策略在一定程度上对被测 app 进行智能探索操作。

UI 自动化测试（appium）：

在自动化测试框架支持的基础上，提供多设备脚本运行能力，测试开发人员只需要编写符合规则的测试脚本即可以在云测试平台上选择多个设备进行测试，获得测试结果。

在以上自动化测试的同时，测试报告中需要体现如下内容：

实时生成测试报告、测试结果数据
实时获取设备的日志并有对应的分析结果
可控的自动化测试过程
执行过程中设备页面截图或录制视频
测试结果中设备类型数据分析

在上面背景说明中，介绍了几种测试类型需求，前两种的设计流程比较简单，也不需要外部人员的参与，第三种测试类型设计比较复杂，后续文章说明也以第三种测试类型为主。

自动化执行框架设计

自动化框架

在

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

中自动化框架调研对比和各大云测试平台的使用，选择了在各方面都具有一定优势的自动化测试框架 appium 作为自动化测试的执行控制层，本地启动 appium hub 的方式接收脚本执行请求，这里就不多加赘述了。

脚本语言和执行框架

云测试平台是由 Java + kotlin 开发，客户端控制都是基于 Java 实现，这里自然选择 Java 作为脚本语言，后续的脚本、流程说明也是以 Java 语言实现为主，但是在脚本语言选择上这里不是强制要求，同样可以选择 Ruby、Python、PHP,、JavaScript 和 C#，只是后续的实现需要平台多做一步兼容而已。

在脚本执行方面没有使用类似 junit、testng 等第三方的运行框架，主要是为了保持在运行过程中对脚本运行的控制和运行数据的交互，如下是脚本运行实现方案：

由平台提供一定限制范围的脚本编写能力

主要是指运行过程的脚本编写，以及如何提供类似截图、步骤日志、检查点等公用方法，对于 Java 来说可以将一些公共的方法抽象出来放到脚本的父对象中，通过继承将脚本编写能力赋予给脚本本身，Python 也可以统一一个标准的类库，通过引入的方式使用。

运行时由 agent 动态编译编写完成的脚本，反射实例化脚本对象

运行时处理脚本需要区分动态语言和非动态语言，还是以 Java、Python 为例，由于没有借用第三方的测试框架，触发脚本运行对于 Java 来说需要进行编译，也就是标题中说到的动态编译，然后通过反射实例化对象运行，这里有两个要求，首先脚本编写需要在云测试平台限定的包内，其次脚本运行、继承的方法需要符合约定的规则。对于 Python 来说先将脚本内容以 IO 的方式写到内存中，然后反射通过字符串的形式，导入模块、去模块寻找约定函数执行。

使用反射实例对象运行脚本，并调用实例中的方法和脚本进行数据、强控制交互

实例化脚本后开始运行脚本，运行前需要将所需要的运行资料注入到实例中，例如： appium 的 appiumDriver，运行同时可以随时调用实例化对象中的约定方法对脚本运行进行控制，比如获取执行步骤、日志、图片，传递参数，控制脚本暂停、运行、停止等交互，这也是为什么没有使用一些第三方框架来触发测试的原因。

通过上述过程基本上实现了用例到执行的基本过程，如图：

也就是说只要提供了符合规范的脚本，就可以利用框架的通用性将脚本运行在任何 appium 支持的设备上，在架构上也剥离了自动化测试最关键的工作部分即：脚本编写，也为脚本管理、数据模板结合等用例的功能丰富提供更多可能性。

流程设计

如下是脚本自动化测试完整的业务执行方案：

自动化测试 UI 代码以 git 工程的方式托管在公司的 git 服务器上，在工程基础上编写脚本，调试脚本通过之后合并入 git 工程，在 gitlab 上每一个脚本都会有一个唯一的地址，通过这个地址可以获取到指定脚本，然后通过接口 / 表单的方式提交脚本运行测试，运行完成得到质量报告。

值得说明一下的是，在自动化测试过程中，公共方法、selenium / appium 公共 page object 等脚本数据会随着自动化测试的深入越发庞大，所以需要图中的公共方法抽取过程，这样带来的好处是由于脚本的抽取、复用会使脚本的编写效率会越来越快。

如下是脚本执行流程结构图，包含脚本执行的流程和结果收集：

脚本执行数据、执行交互设计方案：

这里主要体现的是脚本和运行平台间的数据交互、执行能力交互，比如脚本执行时需要使用到 appium 的 driver，而这个 driver 是通过平台的设备参数来决定的，在运行时平台动态生成 driver 然后通过协议类的方式注入 driver 到脚本内部，运行过程中通过协议类的停止、暂停、等待、销毁等方法进行控制，运行完成后通过协议类获取到运行结果。在脚本需要一些特定的功能时，也可以通过协议类引入接口方法，然后运行平台通过接口代理的方式动态注入实现类的方式实现。

在实施的过程中发现有两个难点，主要如下：

类和第三方包引用管理引起的脚本编译问题
在自动化测试脚本编写过程中，不可避免需要使用一些引入包，比如一些方便的工具类使用包等，对于 JAVA 脚本来讲更新类、包引入等都需要重新编译部署才可以运行使用，测试平台不可能会因为脚本类、包的变化重新编译部署平台，而脚本的编写绝大部分都是类引入的变化，包引入变化的比例很小，所以在类的变化上使用 Java 动态编译技术解决类的动态引入，第三方的包引入更新则通过平台工程的发版提前引入这些包升级完成。
协议类和包更新的自动化更新过程
在云平台和脚本工程中间是通过协议类进行数据交互，而定义的这个协议类和包发生之后按照上面的方案来说是需要云平台重新部署才可以的，在实践中发现脚本的能力建设和扩展等都需要通过协议类的修改才能实现，这就决定了这个协议类会频繁的发生变更，所以 Agent 工程中在动态编译前，手动校验了服务器上的协议类版本，如果发现了新版则下载新版的协议类 jar，在动态编译时替换到 -classpath 的协议类版本参数，这样就做到了指定协议类内容的动态更新和自动化部署。