百度智能小程序，是 H5 和 Native 技术联合的产物，运行在百度 APP、爱奇艺等反对百度智能小程序运行的宿主 APP 上。因而，很难用既有的端自动化测试工具（如，Appium 等）、或者 H5 自动化测试工具（如，Selenium 等）进行百度智能小程序的自动化测试。
为了解决这个问题，百度智能小程序测试中台团队，出品了一款名为 smartapp-automator 的自动化测试框架，以便于业务发展智能小程序的自动化测试。
本文的主题，就是针对该自动化测试框架的架构原理进行深刻分析。
01 智能小程序架构设计
既然是对智能小程序自动化测试框架的分析，免不了先得聊聊智能小程序的架构设计。
如图所示便是智能小程序的一个简要的架构设计图：
运行设施指的是咱们平时应用的 android 或者 iOS 手机，宿主 APP 指的是 百度 APP 以及其它智能小程序开源联盟合作伙伴 APP，如爱奇艺、wifi 万能钥匙等。
当然智能小程序有一个独特的个性，能够为开发者主动生成一个 H5 状态的小程序，反对间接运行在浏览器上的，这时候运行设施指的就是咱们的个人电脑 / 手机，而宿主 APP 指的就是浏览器了。
当咱们用手机关上百度 APP 上的某个小程序的时候，百度 APP 会为这个小程序独自开启一个过程，并在这个过程里开启一个 Logic 线程和多个 View 线程。
小程序的所有业务逻辑都集中在 Logic 线程，而 View 线程就是咱们所看到的小程序的各个页面，Logic 线程和 View 线程通过宿主 APP 集成的小程序框架 SDK（swan sdk）提供的 eventBus 进行双向通信。
举个例子，咱们看到的小程序的首页（页面 A），其实是一个 View 线程（view1），当咱们点击下面的一个按钮的时候，点击事件会经 eventBus 由 swan sdk 传回到 Logic 线程，Logic 线程依据开发者绑定的解决函数调用 swan.navigateTo 办法触发跳转页面 B，页面调整指令由 Logic 线程传递到 swan sdk，swan sdk 创立一个新的 View 线程（view2）渲染页面 B 并将 view 推至前台展现在用户背后，最初通过 eventBus 告知 Logic 线程页面创立结束，实现一次点击事件的解决。
这里的 Logic 线程，随着宿主 APP 的实现不同，承载实现的容器可能是 webview，也可能是 v8 或 Jsc。而 View 线程则有可能是 webview，或者 native 的嵌套计划。
上述，其实只是提及了智能小程序框架架构设计一个大略，为了不便大家了解，抹平了很多细节上的货色。
在根本理解了智能小程序的架构设计后，让咱们一起来看看 smartapp-automator 自动化测试框架的架构设计。
02 自动化测试框架架构设计
如图所示便是 smartapp-automator 的一个全局架构图：
化繁为简来说的话，其实整个设计就蕴含了两个局部：对智能小程序运行时的自动化操控局部，和对各类设施的自动化操控局部，咱们别离开展来看看。
03 智能小程序的自动化操控
从刚刚智能小程序架构设计的分析中，咱们能够发现，智能小程序的架构设计不同于 H5/Native，是多种技术的混合产物，因而很难用 Appium、Selenium 等现成工具组合后对智能小程序进行操控。
因而，咱们参考 selenium 1.0 及 chrome debug protocol，设计实现了智能小程序测试引擎，通过智能小程序测试引擎，将智能小程序的自动化操控能力给外透了进去。
智能小程序测试引擎的整体架构设计长这样：
从图中能够看到，智能小程序测试引擎蕴含 4 个局部：
- 位于智能小程序运行时 Logic 线程内的 batEngineLogic 模块
- 位于智能小程序运行时 View 线程内的 batEngineView 模块
- 同 batEngineLogic 经由 websocket 进行双向通信的 bat-agent 模块
- 同 bat-agent 经由 websocket 进行双向通信的 bat-driver 模块
在小程序调试模式开启后，咱们去关上一个智能小程序，Logic 和 View 线程都会在框架初始化的时候别离动静扩大 batEngineLogic 和 batEngineView。
batEngineLogic 模块是一个 websocket client，在加载后会被动寻找 bat-agent（websocket server）并进行连贯。
bat-agent 会在 smartapp-automator 实例化后启动，它接管来自运行设施上 batEngineLogic 的连贯，同时接管 bat-driver 的连贯，负责将 bat-driver 的指令申请转发到 batEngineLogic 同时接管 batEngineLogic 音讯反馈给 bat-driver。
bat-driver 定义了一套 API，供 smartapp-automator 调用，指令经 bat-agent 传达到 batEngineLogic 执行，而后再经 bat-agent 取得后果反馈，从而达到操控小程序的目标。
batEngineLogic 模块和 batEngineView 模块之间通过 eventBus 双向通信，如果咱们想要获取页面理论的渲染状况 / 间接对页面进行管制，则需经 batEngineLogic 模块将指令转发到 batEngineView 模块。
根据上述形容，大家能够发现，整个架构设计充斥了双向通信。双向通信给咱们的程序实现带来了复杂性，但也给咱们测试框架的利用前景带来了更多的可能性。
举个简略的例子，有了这三层双向通信，咱们便能够在 smartapp-automator 层对真机设备层小程序页面的点击或其它事件进行监听及信息捕捉，基于这个个性，咱们最终设计实现了基于真机操作的 UI 用例录制回放工具，解放了 UI 类自动化用例编写的老本。
04 设施的自动化操控
设施有很多种类型，比方 Android 手机、iOS 手机、PC 机、Android 开发板、百度云 Android 云手机、IOT 设施等。
针对这些设施，业界或多或少都积淀了一系列可用的工具，比方，Android 手机 / 开发板能够用 adb 工具、Uiautomator2 操控，iOS 手机能够用 wda 操控，PC 机上的 Chrome/Chromium 浏览器能够用 puppeteer，百度云云手机提供了 bacagent 工具。
如果让 smartapp-automator 的用户，依据设施类型的不同去自行选用对应的设施操控工具，那用户的应用老本将会十分微小。
因而，如图所示，咱们在 smartapp-automator 提供了一套对立的设施操控 API，在这层 API 之下，咱们应用不同的操控工具对各类型设施操控能力进行了封装。这样，用户无需思考设施类型 / 对应的操控工具，间接应用 smartapp-automator 提供的对立操控 API 便可实现对设施的操控。
在设施操控能力具体的实现上，这里排列下咱们针对不同设施类型的一个选型：
- Android:
- Adb: https://developer.android.goo…
- Atx-Agent: https://github.com/openatx/at…
- iOS:
- Wda: https://github.com/openatx/fa…
- Chrome/Chromium
- Puppeteer: https://github.com/puppeteer/…
因为 smartapp-automator 是基于 NodeJS 编写的，而上述工具所应用的语言各不相同，所以广泛采取了自行封装驱动层的做法来接入应用。
05 总结
百度智能小程序自动化测试框架次要由两个局部组成，一个是对智能小程序运行时的自动化操控局部，一个是对各类型设施的自动化操控局部。它通过小程序测试引擎将小程序运行时操控能力外露进去，而通过对不同设施类型自动化操控工具的封装和对立 API 的提供，不便了用户应用。
举荐浏览【技术加油站】系列：
百度程序员开发避坑指南（Go 语言篇）
百度程序员开发避坑指南（3）
百度程序员开发避坑指南（挪动端篇）
百度程序员开发避坑指南（前端篇）
百度工程师教你疾速晋升研发效率小技巧
百度一线工程师浅谈突飞猛进的云原生
【技术加油站】揭秘百度智能测试规模化落地
【技术加油站】浅谈百度智能测试的三个阶段