1. Introducción a las pruebas de automatización de la interfaz de usuario
Introducción a las pruebas de software
Las pruebas de software nacieron junto con el desarrollo de software.Con el software a gran escala y la estructura compleja, las pruebas de software también se han desarrollado desde la simple "depuración" inicial hasta las pruebas automatizadas de hoy.
¿Qué son las pruebas automatizadas? La prueba automatizada es un proceso de convertir el comportamiento de prueba impulsado por humanos en ejecución de máquina.La prueba automatizada generalmente se basa en ciertas herramientas o marcos. Aunque no puede reemplazar por completo las pruebas manuales, en comparación con las pruebas manuales, las pruebas automatizadas pueden reducir los costos de mano de obra, reducir el trabajo repetitivo y realizar actividades de prueba de manera más rápida y eficiente.
La pirámide de prueba es una estructura de estrategia en forma de pirámide para el proceso de prueba automatizado, que se utiliza para guiar la relación de carga de trabajo de cada capa de prueba en el proceso de desarrollo de software. Fue propuesta por primera vez por Mike Cohn en su libro de 2009 "Scrum Agile Software Desarrollo". Mike Cohn señaló en el libro: La pirámide de prueba se divide en tres capas de arriba a abajo, a saber, prueba de interfaz de usuario, prueba de servicio/interfaz y prueba de unidad. Cuanto más cerca de las actividades de prueba en la parte inferior de la pirámide, mayor será la carga de trabajo. debe poner, es decir, pruebas unitarias. La carga de trabajo es la mayor parte, seguida de la prueba de interfaz y la prueba de UI la menor.
Pruebas de interfaz de usuario
Las pruebas de interfaz de usuario son el tipo de prueba que más se aproxima al comportamiento de los usuarios reales del software. Por lo general, simula el comportamiento de un usuario real que usa el software, es decir, simula varias operaciones del usuario en la interfaz del software y verifica si los resultados correspondientes de estas operaciones son correctos.
Pruebas de interfaz (pruebas de API)
Las pruebas de API, principalmente para las interfaces expuestas por cada módulo, generalmente adoptan el método de prueba de caja gris. Primero, los casos de prueba sobre cómo llamar a la API están diseñados en forma de caja negra, y la tasa de cobertura del código se cuenta durante el proceso de ejecución de la prueba, y luego se complementan cada vez más casos de prueba específicos de acuerdo con la tasa de cobertura del código.
prueba de unidad
Las pruebas unitarias, que pertenecen a la categoría de pruebas de caja blanca, generalmente las realizan los propios ingenieros de desarrollo. Cuanto antes se encuentren los defectos, menor será el costo de reparación.
¿Por qué automatizar la interfaz de usuario?
Con la iteración continua de la versión, se agregan más y más funciones de software nuevas, la demanda de recursos de prueba también aumenta y el tiempo para realizar pruebas manuales es cada vez más largo. La dependencia de las pruebas manuales comenzó a ser complicada, por lo que la gente comenzó a buscar soluciones y entró en juego la automatización de la interfaz de usuario.
Las pruebas manuales tienen las siguientes desventajas:
- Las pruebas de regresión manual tardan mucho tiempo en completarse y los pequeños retrasos pueden poner en riesgo los lanzamientos.
- 发布节奏受到人工回归测试的限制。两天以上的人工回归测试意味着最好的情况下能够一个月发布两次。而且，开发者需要一次性发布所有东西。要么全部发布，要么什么都发布不了，因为需要将所有东西一起测试。
UI 自动化测试存在以下的优点：
-
解放了测试团队针对临时的和探索性案例的测试时间；
-
可以一边开发一边进行回归测试，减少等待时间；
-
可重复性使用，快速进行回归测试；
-
更好的利用资源（周未/晚上的资源空闲时段）。
UI 自动化测试的特点
了解到为什么要选择UI自动化测试之后，我们需要了解UI自动化测试的使用场景。UI 即 User Interface（用户界面）的简称，UI 自动化做的事情就是模拟用户行为进行操作，完成对用户界面的测试。这也就从本质上限制了它的使用场景：
- 软件需求变动不频繁
- 产品更新维护周期长
- 比较频繁的回归测试
- 自动化测试脚本可重复使用
所以在开始之前，我们最好先认识清楚哪些业务场景是可以自动化测试的。
2、Android UI自动化测试工具
UI自动化测试经过多年的发展，也已经涌现出很多优秀的测试工具。下面简单介绍一下Android测试领域内的一些常见的测试工具。
1、Monkey
是Android SDK自带的测试工具，在测试过程中会向系统发送伪随机的用户事件流（如按键输入、触摸屏输入、手势输入等)，实现对正在开发的应用程序进行压力测试，也有日志输出。实际上该工具只能做程序做一些压力测试，由于测试事件和数据都是随机的，不能自定义，所以有很大的局限性。
2、MonkeyRunner
也是Android SDK提供的测试工具。严格意义上来说MonkeyRunner其实是一个Api工具包，比Monkey强大，可以编写测试脚本来自定义数据、事件。Monkeyrunner 足够强大了，但是录制的脚本是以坐标轴来作为定位方式，而安卓设备类型众多，各种分辨率，所以移植性不好。
3、Instrumentation
是早期Google提供的Android自动化测试工具类，虽然在那时候JUnit也可以对Android进行测试，但是Instrumentation允许你对应用程序做更为复杂的测试，甚至是框架层面的。通过Instrumentation你可以模拟按键按下、抬起、屏幕点击、滚动等事件。
Instrumentation是通过将主程序和测试程序运行在同一个进程来实现这些功能，你可以把Instrumentation看成一个类似Activity或者Service并且不带界面的组件，在程序运行期间监控你的主程序。
缺点是对测试人员来说编写代码能力要求较高，需要对Android相关知识有一定了解，还需要配置AndroidManifest.xml文件，不能跨多个App。
4、UiAutomator
也是Android提供的自动化测试框架，基本上支持所有的Android事件操作，对比Instrumentation它不需要测试人员了解代码实现细节（可以用UiAutomatorviewer抓取App页面上的控件属性而不看源码）。基于Java，测试代码结构简单、编写容易、学习成本低，一次编译，所有设备或模拟器都能运行测试，能跨App（比如：很多App有选择相册、打开相机拍照，这就是跨App）。缺点是只支持SDK 16（Android 4.1）及以上，不支持Hybird App、WebApp。
5、Espresso
是Google的开源自动化测试框架。相对于UIAutomator，它的特点是规模更小、更简洁，API更加精确，编写测试代码简单，容易快速上手。因为是基于Instrumentation的，所以不能跨App。
6、Selendroid
基于Instrumentation的测试框架，可以测试Native App、Hybird App、Web App，但是网上资料较少，社区活跃度也不大。
7、Robotium
也是基于Instrumentation的测试框架，目前国内外用的比较多，资料比较多，社区也比较活跃。缺点是对测试人员来说要有一定的Java基础，了解Android基本组件，不能跨App。
8、Appium
Appium 是目前最主流的移动测试自动化框架，不仅支持 Android 应用，而且适用于 iOS、混合和 Web 应用程序。
它底层完全使用了 Selenium 和 WebDriver 的 API，所以如果你之前有用过 selenium, 几乎不需要额外的学习成本就可以使用 appium。appium 通过 uiautomator（API 级别 16 或更高）和 Seledroid（API 级别低于 16）支持 Android，但是你不需要具体懂这两个框架的具体用法，appium 都已经帮你封装成了统一的使用规则。Appium 的优势之一是几乎可以使用任何编程语言（例如 Java、Objective-C、JavaScript、PHP、Ruby、Python 或 C# 等）编写 Appium 脚本。不需要重新编译或改变应用程序来匹配Appium，Appium有一个非常大而活跃的社区。
9、Airtest
是网易出品的一款基于图像识别和poco控件识别的一款UI自动化测试套件，由Airtest框架、poco框架、airtestIDE 组成。是一个跨平台的UI自动化测试框架，适用于游戏和App。用户不需要一行行的去写代码，而是用屏幕截屏的方式，用截出来的图形排列组合成执行的程序。 另外，Airtest也基于poco这个UI控件搜索框架，这个框架也是网易自家的跨平台U测试框架，原理类似于appium，通过控件的名称，id之类的来定位目标控件，然后调用函数方法，例如click(),swip()之类的方法来对目标控件进行点击或者是操作。
虽然Airtest刚开始是为了游戏测试，现在在app测试中也有很大的应用范围。只是进行录制、执行脚本的AirtestIDE没有开源，不方便进行深度定制。
10、Solopi
是蚂蚁金服开源的一款移动端APP测试工具，提供脚本录制、编辑、回放，结果展示以及一机多控（即通过设备间的socket通讯实现1台手机可以控制多台手机执行脚本）等功能，其测试用例的录制和执行等操作均在手机端的一个APP中完成。不需要借助电脑软件与测试设备交互，所以通信结构比Appium简单高效，对元素的识别也是使用类似于appium的控件的方式，并且引入了类似于airtest的图像识别的方式。
3、SoloPi的介绍
以往的性能测试工具，无外乎三种形态：PC 驱动工具、侵入式的测试模块、ROOT 工具。
-
PC 工具：除了 Android Studio 自带的性能测试工具，市面上大多数文档都是介绍命令行方法，而且各家方案存在差异，不少还存在错误，实际成型的工具也不多。
-
侵入式的测试模块：这类工具由于需要侵入到源码中，需要单独打包进行测试，工具本身也可能对性能产生影响。
-
ROOT 工具：首先是需要 Android 系统的 Root 权限，对于权限管控越来越严格的 Android 系统，其路必将越走越窄。
SoloPi提供了一种能够在 Android 手机上不需要 root 也能实现应用提权的方案。可以简单概括为：SoloPi是一种无线化、非侵入、免 Root 的 Android 专项测试方案。
传统的功能测试通常有两种方式：一种是人工手动执行测试，另一种则是编写基于测试框架的自动化脚本。前者成本巨大，为应付不断加速的产品迭代可能需要投入大量人力；而后者则对测试同学的代码能力有不小的要求，这也导致由手动测试转化为自动化测试从而节省人力的进度相对缓慢。
SoloPi将传统上仅能用于 PC 的自动化测试能力移植到了移动平台，并根据手机的使用习惯，开发了一套简单易用且功能强大的自动化测试框架。不需要测试同学有代码能力，降低了使用门槛，更方便推广。
Solopi主要有以下功能：自动化测试-录制回放、兼容性测试-一机多控、性能测试、稳定性测试。
虽然Appium和Airtest都有很大的应用范围，但是Solopi相比于appium和airtest有以下优势：
-
改进的控件匹配算法，更高的匹配成功率；
-
不需要依赖pc端的桌面应用，全部操作都在手机端的app中完成，实现了无线化，随时可测；
-
不需要代码基础，使用人群覆盖范围广；
-
提供性能测试的功能等。
（1）整体架构
这套方案中，底层依赖主要是 “无线 ADB、系统辅助功能、Chrome 调试以及图像识别技术”，后文将会介绍它们具体的应用场景。同时，在底层依赖的基础上，封装了一套核心能力，由 “控件定位、事件驱动、性能采集以及依赖注入” 组成，并在服务层实现了录制、回放、数据处理等公共服务能力。在架构的最顶端，结合界面交互逻辑包装出了各个功能的入口。
（2）录制回放
在录制过程中，SoloPi 会对用户的操作进行拦截，识别用户操作的位置，高亮当前操作的控件，记录用户当前要做的操作类型，在每一步操作后，将操作类型及目标控件的各种信息都记录下来。这里的控件信息包括控件的 ID、文字等基本信息，以及相对布局、截图信息等。
在回放时，SoloPi会逐条解析之前录制的数据，通过智能查找算法，综合各种属性，定位目标控件，找到控件后，就会执行相应的操作，如点击、滑动等。在所有步骤执行后，会展示本次回放的结果，包括日志、截图等信息，作为本次回放的总结。
SoloPi 的录制和回放，基于同一套逻辑，包括控件结构构建、控件定位、事件驱动三个部分。两者的区别主要在于控件定位：
-
在录制过程中，SoloPi 会基于用户的点击行为进行定位；
-
在用例回放时，SoloPi 会根据录制时记录的控件信息，通过 SoloPi 的控件查找算法进行定位。
（3）底层依赖的核心功能
1）基础依赖
下面主要介绍SoloPi的控件查找功能和操作监控功能需要依赖的基础方案：无线ADB方案和AccessiblityService方案。
无线ADB方案
对于 Android 自动化，ADB shell 的执行能力是一切的基础。在 PC 上，通过 Android SDK 提供的ADB client 与同样运行于 PC 中的 ADB server 通信，再由 ADB server 通过 USB 与位于设备中的 Adbd 通信。要实现一套无线化的方案，必须要摆脱对 USB 线的依赖。好在 Android 系统还提供了一种基于 Socket 的 ADB 连接模式，既然是这样，那么只需要按照 ADB 通信协议在端上与本机的 5555 端口进行通信即可获得 ADB shell 的执行能力。
此无线ADB方案是SoloPi区别于其他UI自动化测试框架的核心方案之一，大家可以在其他项目中借鉴这种无线化方案。
AccessiblityService方案
辅助功能（AccessibilityService）其实是一个Android系统提供给的一种服务，本身是继承Service类的。这个服务提供了增强的用户界面，旨在帮助残障人士或者可能暂时无法与设备充分交互的人们。
从开发者的角度看，主要使用两种功能：查找界面元素，实现模拟点击。
UiAutomator（Appium、Airtest使用的方案）和AccessibilityService是有联系的：UiAutomator底层使用的是AccessibilityManagerService，AccessibilityService底层也是使用的AccessibilityManagerService，它们都是通过RPC与AccessibilityManagerService进行交互，获取界面元素和对界面元素进行操作的。区别是：UiAutomator只能在shell环境中执行，AccessibilityService是可以运行在app环境中的，但是需要用户手动开启服务。
2）基础功能
基于以上两种基础能力，下面介绍solopi底层依赖的两种功能：基础控件查找功能、用户操作监控功能。
控件查找功能
随着移动端动态化能力的稳步发展，越来越多的应用采用了 “Native + H5/小程序” 这种混合开发的方案。再考虑到近年来手游行业的飞速发展，手机游戏自动化测试的需求也越来越多。为了尽可能的适配各种场景，SoloPi提供了三种查找模式：
第一种方案的核心就是基于 AccessbilityService 生成当前控件视图树，并记录下id、文字等属性，适用于 Native 场景。
第二种方案基于 Chrome 的调试协议，通过注入js可以获得页面布局以及各元素属性，控件的定位思路与辅助功能这一套方案是一致的。适用于 H5/小程序场景。
第三种方案是图像匹配方案，SoloPi 在端上实现了一套图像比对能力，结合了模板匹配、特征匹配等算法，并做了一定的适配和调优。适用于游戏自动化的场景。
现阶段的开源代码中，native控件和webview中的控件都是使用AccessbilityService生成的控件视图树，断言功能和截图点击功能会使用到图像匹配方案，现阶段基于 Chrome 的调试协议方案未开源。
用户操作监控功能
a、事件获取机制：
关于用于操作监控与控件获取，AccessibilityService 能够获取用户的操作事件并关联对应的控件，可以实现大部分功能。
但 AccessibilityService 也有不足的地方，比如面向 HTML5 场景，辅助功能获取控件会出现延迟从而导致获取的控件结构不够精确；另外，对于部分自定义控件，辅助功能只能获取到对应的控件，但缺乏具体的坐标信息，从而导致控件操作不符合预期。
因此，SoloPi 采取了“结合 Android 系统 getevnet 功能”策略，通过直接解析系统原生事件，获取到用户的操作行为。
简单来说，通过 getevent，SoloPi 可以获取到用户操作屏幕的具体坐标，以及手指落下、抬起的具体时间。不过，getevent 命令的使用需要 SHELL 权限，这限制了普通 Android 应用获取相关数据的能力。SoloPi 通过Android 系统的无线调试功能实现了一套纯端的 SHELL 执行能力，能够在 Android 系统上执行 adb 相关命令。在SoloPi应用中集成了 AdbLib 开源库，包装成一套 ADB 命令执行工具。
通过 getevent 命令，SoloPi 获取到了用户点击的具体坐标，结合 AccessibilityService 获取到当前页面的控件结构树。遍历控件树找到坐标点击位置最上层的控件。
b、事件拦截机制：
在soloPi代码中，当需要拦截事件时，就会设置AccessibilityService进入触摸监控模式（通过此标志位 FLAG_REQUEST_TOUCH_EXPLORATION_MODE）。在此模式下，系统不会在view树中分发事件，各种事件会分发到AccessibilityService的实现类中。此时，soloPi会自己监听get event事件，进行事件的分发和处理。当不需要拦截系统分发事件时，就会重新设置AccessibilityService的标志位。
（4）回放能力的扩展
通过 SoloPi 录制的用例会以 JSON 的形式存储起来，用例不仅可以在设备本地直接回放，还可以通过 SoloPi 的解析器将用例转换为 Appium等目前主流自动化测试框架的脚本，轻松打通云测平台。另外，得益于文本抓取和图像识别能力，SoloPi还实现了在 Android 端录制一遍用例，生成的脚本能够同时在 Android、iOS 双端回放的能力。
（5）脚本编辑
SoloPi también proporciona funciones de edición de casos de uso, como insertar, eliminar y modificar pasos de casos de uso, lo que puede reducir efectivamente el costo de mantenimiento de los casos de uso. Además, SoloPi también presenta capacidades de control de procesos, como bucles y condiciones.Si los casos de uso se organizan correctamente, se pueden implementar fácilmente secuencias de comandos de herramientas que requieren operaciones repetidas o secuencias de comandos de prueba de estabilidad que requieren reproducción violenta.
(6) Una máquina con múltiples controles
Entre todos los tipos de pruebas especiales, las pruebas de compatibilidad son las que requieren más tiempo y trabajo. Los probadores deben prestar atención a las distintas versiones del sistema, los principales fabricantes de teléfonos móviles, los distintos tipos de pantallas, etc. a través de pruebas manuales puras El costo de calidad de las pruebas de compatibilidad es muy alto.
SoloPi implementa un conjunto de soluciones de prueba de compatibilidad basadas en las capacidades de grabación y reproducción. En el escenario de grabación y reproducción, las operaciones del usuario se graban primero en un dispositivo y luego se reproducen en cualquier dispositivo. Si la escena se extiende a varios dispositivos, es posible controlar varios dispositivos a través de un dispositivo. Esta función se denomina "controles múltiples para una máquina". Específicamente, el host establece una conexión de socket con el esclavo y luego envía la operación del usuario a cada esclavo en tiempo real en el host y completa la reproducción de la operación en el esclavo.
Un entorno de múltiples controladores con una máquina es más flexible.Después de instalar SoloPi en el teléfono móvil en cuestión, la implementación se puede completar a través de una simple operación de conexión. Una máquina con múltiples controles es compatible con los principales modelos y ROM del mercado, y encapsula algunas funciones rápidas para mejorar la eficiencia de las pruebas, como la instalación de aplicaciones, la limpieza de datos, la visualización de información del dispositivo y más.
(7) Prueba de rendimiento - recopilación de datos
Los datos de rendimiento se pueden medir a mano y los informes se pueden generar localmente de forma automática. La recopilación de datos admite dos modos de activación, manual y de transmisión, que es fácil de combinar con la automatización.
Lo anterior solo presenta brevemente las funciones de SoloPi. Para una introducción detallada de las funciones, puede consultar la introducción de la biblioteca oficial de código abierto de SoloPi:https://github.com/alipay/SoloPi
Referencias: