【20221114每日面经】app自动化 - Appium原理

  • 考察点:app自动化
  • 难度: 中等
  • 题目:在做安卓手机自动化时,使用Appium框架是怎样和安卓手机进行交互的?对应的Appium原理是什么?
    ps:每周一公布上周所有题目答案
1 Like

我先来个简单版本的:
appium属于c/s架构的框架,第一次运行测试代码的时候,会向appium server发送请求,传递一个DesireCapability对象,告诉server被测设备的一些信息,第一次请求完成以后,会创建一个session对象, 随后会使用这个session对象完成对设备的相关操作。

1 Like

appium client发送自动化指令给appium server,server把这些指令转为移动端可识别的指令发送给移动端,并对移动端进行操作

概念

客户端 / 服务器 架构
Appium 的核心一个是暴露 REST APIWEB 服务器。它接受来自客户端的连接,监听命令并发送指令到移动设备上执行,返回 HTTP 响应来描述执行结果。

Appium 客户端
客户端程序库,各种语言实现的 Appium-client API,是 AppiumWebDriver 协议的扩展。这些库封装了标准的 Selenium 客户端,提供了所有 JSON Wire protocol 指定的常规 selenium 命令,并额外添加操控移动设备相关的命令,例如 多点触控手势屏幕方向

Appium 服务器
Appium 是一个用 Node.js 写的服务器,可以放在本机,也可以放在云端。主要负责两件事情:

  • 默认开启 4723 端口,监听来自客户端的 HTTP 请求
  • 本地开启 4724 端口,将请求转发给移动端

预期能力(Desired Capabilities)
它告诉服务器我们想要启动什么类型的自动化会话,本质上是一个 key-value 形式的对象。脚本通过请求以 json 格式发送测试设备信息给服务端,服务端来完成该类型会话的创建。

会话(Session)
自动化测试始终在一个会话的上下文中执行,客户端程序库以各自的方式发起与服务器的会话,但最终都会发给服务器一个 POST /session 请求,请求中包含一个被称作「预期能力」的 JSON 对象。这时服务器就会开启这个自动化会话,并返回一个用于发送后续命令的会话 ID。

Session 对象存储特定用户会话所需的属性及配置信息,对应到这里其实就是 Desired Capabilities 中的配置信息参数。

Appium Desktop

Appium 界面版本,打包了 Appium 服务器运行需要的所有东西。提供 Inspector 查看应用程序的层级结构。

各平台测试引擎列表:

框架介绍

客户端发送请求到服务端,服务端将请求转为可执行指令发送到设备,执行操作后返回结果。

以 Android 端为例

  • 启动 Appium Server,监听 4723 端口的请求;
  • 运行代码,clientserver 发送带有设备信息的 HTTP 请求,server 监听到该设备信息;
  • 初始化移动设备,安装 bootstrap.jar 并自动开启设备的 4724 端口;
  • server 开启 4724 端口用于和 bootstrap.jar 通信,等待客户端连接;
  • server 根据监听到的 client 请求生成对应的自动化会话,并返回 SessionIDclient
  • client 将脚本转化为请求并携带 SessionID 发送给 server
  • server 将请求解析后,通过 4724 端口转发给 bootstrap.jar,这时的 Appium server 转变为客户端;
  • bootstrap.jar 将请求信息转化为 uiautomator 指令,让 uiautomator 进行处理并执行;
  • 执行后的请求响应原路返回给脚本,脚本再进行下一次的请求;
  • 代码执行 quit 后,关闭 session 和进程,测试结束。

Appium Server 作为服务端,同时也是客户端,是一个双向通信连接实现数据交换的过程。

总体来说,Appium Server 既扮演着 server 的角色又扮演着 client 角色。

当它面对代码脚本的时候是一个 server,接收脚本发送的请求指令;

当它面对在终端设备上部署的原生代理(Android → bootstrap.jar | iOS → wda)时又是一个client,把接收到的网络指令以规定的形式发出去,不同平台的代理将请求解析为原生语言指令,通过原生测试框架操作 APP,这就是 appium 实现跨平台的方式。

原理:appium就是个缝合怪!基于各平台已有的自动化框架,做了系列封装,通过自己的方式进行通讯,让你用appium的api,最终调用其他自动化框架完成对应平台的操作。

过程:以安卓手机(Android 4.3+)的u2自动化为例

  1. 本地或远程PC,启动 Appium Server 一个 RESTful API 服务器,监听 4723 端口
  2. client端(各语言实现的Appium库),编写的测试脚本中包含的「Desired Capabilities」信息,指定被测设备信息和AndroidDriver信息(其中automationName为 UIAutomator2)
  3. 测试脚本执行,服务端监听到请求,建立一个会话,返回sessionId给客户端,作为后续操作的标识
  4. appium server 调用appium-uiautomator2-driver,为被测匹配的测试设备安装两个Apk:
    • 一个负责启动server,和PC端进行通讯
    • 一个负责执行 handlers,调用Android系统的UiAutomator V2去执行指定操作
  5. 测试机上启动appium-uiautomator2-server 监听4724,来监听自动化命令——至此初始化完成
  6. client 发送一条ui操作指令给Appium Server,
    Appium Server通过appium-uiautomator2-driver发送JWP协议的请求到测试机的appium-uiautomator2-server,
    appium-uiautomator2-server调用UiAutomator V2操作被测应用,
    操作后返回命令执行结果给appium-uiautomator2-driver,
    再由Appium Server返回给client

参考: How Server module works

解答思路

1 Like
关闭