Funny DocsRPA测试技术
相关术语
| 术语 | 全称 | 描述 |
|---|---|---|
| Selenium | / | 一个开源的 Web UI 自动化测试工具，提供了基础的操作 Web 页面元素的方法。 |
| QTP | / | 一个商用的 UI 自动化测试工具，支持 Web、桌面自动化测试。 |
| Requests | / | 一个基于 Python 实现的网络接口请求的工具。 |
| Postman | / | 一款流程的接口调试工具，特点就是使用简单，测试人员都可以使用它进行接口调试或测试。 |
| YouQu | / | 统信自研的自动化测试基础框架，使用简单，功能强大。 |
RPA是什么
RPA（Robotic Process Automation，机器人流程自动化）是一种技术理念，其核心是将一些人工重复性的任务使用自动化的手段来执行。可以提高企业的运行效率，降低人工投入。
RPA 是一个很泛的概念，一句话讲清楚就是：把一切能手工执行的任务交给自动化来执行。至于具体使用哪种自动化技术，我只能说不确定，因为这是需要 因需制宜 的。
在 RPA 这个概念提出来之前（大概是90年代），财务人员能使用 Excel 进行财务计算，就已经是在践行 RPA 了，毕竟以前都是用算盘在做，稍微先进点的用计算器，不仅需要投入大量的人力，而且还容易出错，Excel 里面的公式能自动处理大量的数据，工作效率是一个飞跃，再到后来出现财务管理软件出现，又在 Excel 的基础上进一步提高的自动化程度。
在不同的时期，RPA 技术用到的具体技术或工具是不同的，在不同的行业也是这样，文案工作者从最开始一个本子一支笔，再到用 Word，再到用 GPT 自动生成。
所以说，RPA 是一种技术理念，一种将一切行为自动化的理念，凡是可以替代人工的技术或工具，都可以称之为 RPA 技术。
RPA测试的由来
前面咱们理清了 RPA 核心就是自动化，那 RPA 测试即自动化测试是 RPA 的一个子集，这节我来简单的介绍下自动化测试的由来；
软件测试行业在刚开始的时候，所有的测试人员都是手工测试，互联网行业飞速发展，快速迭代发布，主打的就是一个快，现实的情况是每次迭代测试时间不够、人力不够，维护成本太高。
有机智的测试小伙伴就想，每次迭代都是那些活，这些事情能不能自动化来执行，我在旁边喝咖啡就行了，于是直接上网查资料一看，还真有技术能做这些活。
要想替代人工测试，最直接最容易想到的就是替代人工做点击输入类的动作，这类称为 UI 自动化测试；UI 自动化测试是最接近于真实用户的自动化测试类型，早期的自动化测试工具如：QTP、Selenium 等很快流行起来。
但自动化测试项目稍微一落地运行就会发现，太难维护了，前端功能界面一天变三回，测试工程师维护用例脚本的投入太大。
既然是前后端分离的系统，只管后端接口的输入输出正常岂不方便许多，又上网查资料找到一个 Requests 的库能做接口请求，于是开始搞接口自动化测试了；发现接口自动化测试投入产出比高，效果很好，靠着口口相传，测试圈内刮起了一股浩浩荡荡的接口自动化测试风潮。
后来，在接口自动化测试基础上又衍生出了性能自动化，因为高并发的场景如果靠人工来测试几乎是不可能的，而利用多线程并发做接口请求可以轻松做到。
测试全面接入 RPA 之后优势很明显，提高了测试效率、减少了人力投入、以及频繁的人工操作可能导致的错误。
但 RPA 测试也不尽完美，也存在一些局限性，比如 RPA 测试不能完全替代人工测试，它主要做一些重复性的任务，还有就是面对复杂流程或频繁变动时对 RPA 测试工具可维护性、灵活性提出考验。
RPA测试技术
自动化测试始终是贯穿于软件开发过程周期的，在不同的阶段介入，做不同的自动化测试：
开发阶段
这个阶段开发还在疯狂的新增和修改代码，适合做的只有单元测试自动化。
圈内有个很有名的黑话叫测试驱动开发（TDD，Test Driven Development），说的是在编写某个功能代码之前要求先编写测试代码，这里的测试代码实际指的是单元测试代码。据观察，测试同学写应用单元测试代码的情况，还比较少的，这里面主要有学习、沟通成本等问题。
单元测试往往是由开发同学自己写，在国内这个情况是比较普遍的，因此这里就不过多描述。
集成交付阶段
到这个阶段说明开发至少交付了一个版本，但是又还没有稳定下来，各功能、界面等还有可能会改动，因此这个阶段适合做接口自动化。
无论是从业务上还是技术上讲，接口自动化都属于是比较容易开展起来的自动化类型：
业务上，互联网行业都在流行微服务架构，服务端接口小修小补很正常，无非是些参数的增删改，整个接口大改的情况少，毕竟前期经过了多轮次评审，因此后端服务接口是相对稳定的。
技术上，自动化测试只要有一个能做接口请求的工具，就可以开展起来，这类工具以 Requests 、Postman 为代表，且不论工程化等方面，使用
unittest + requests能做接口请求，能组织用例跑起来，就能快速的把接口自动化开展起来。
因此，业务接口稳定，技术门槛低，接口自动化很自然的就能很顺利落地。
最流行的接口自动化组合套装
Pytest + Requests + Allure
- Pytest 用于驱动用例批量执行；如果对测试用例过程管控没有太多需求，使用 unittest 足矣。
- Requests 用于做接口请求。
- Allure 用于生成测试报告；如果对测试报告UI效果要求不高，不用 Allure 也行，Pytest 或 unittest 驱动用例跑完之后终端也会有简易的结果展示。
此技术路线是比较通用的，当然不同的人使用这些工具做出来的效果也是不同的，需要有一些框架设计，这里不做赘述；
一条龙的工具
HttpRunner
HttpRunner 实际上也是基于 用例驱动工具 + 接口请求工具 + 测试报告工具 进行封装，以框架级服务提供功能，让使用者能专注于接口用例的维护，而不用关心其他的。
此外，性能自动化测试也开始在这一阶段介入，常用的性能测试工具：JMeter、Locust。
验收维护阶段
此阶段系统各方面功能已经趋于稳定，适合做 UI 自动化。
UI 自动化是从功能的层面模拟手工操作进行自动化测试，核心内容是 元素定位 和 元素操作 ；看起来很简单对吧，但实际上 UI 自动化是所有自动化测试类型中最难的。
为什么这么说？
UI 自动化是从用户视角进行自动化测试，测试的对象是客户端，而客户端又分布在不同的平台设备上。
Web
Web UI 自动化就是基于浏览器的 UI 自动化测试；不同的浏览器，自动化测试用到的底层驱动是不同的，但由于一些自动化工具封装了统一的 API 接口（如 Playwright），在编码上并没有特别大的区别。
难点在于网速、浏览器、脚本的健壮性和测试环境等因素都会导致 UI 自动化测试的失败，产品迭代的过程中维护性差，维护成本高。
常用到的工具：Selenium、Playwright、Cypress、Puppeteer、TestCafe。
App
App UI 自动化可能涉及到多平台设备，如 Android、IOS、Windows、Linux，不同的平台设备上用到的自动化测试工具是不同的，下面简单的列举一些：
- Android 自动化测试：Appium、UIAutomator、UIAutomator2；
- IOS 自动化测试：XCUITest、Appium、facebook-wda；
- Windows 自动化测试：UIautomation、WinAppDriver；
- Linux 自动化测试：Dogtail、LDTP；
可以看到，App UI 自动化涉及的工具多，学习门槛高，且相比于 Web UI 自动化维护难度翻倍；
统信RPA测试应用
自动化测试框架—YouQu
统信的主要产品是基于 Linux 的操作系统。
首先，操作系统提供了一些 DBus 接口、Gsetting 接口、命令行接口等，能做接口自动化测试；然后，操作系统桌面 App 也可以做 UI 自动化 和 性能自动化。
列举一些主要用到的技术：
YouQu 自动化测试框架的定位是一个全功能的自动化测试框架，能支持公司所有类型的自动化测试类型。
YouQu 在整合上述底层技术基础上，进行了工程化的框架设计，并对底层的工具进行了二次开发，使得上层测试用例能非常方便轻松的进行调用，大幅减少了自动化测试用例编写的难度，并且我们还针对 UI 自动化维护性差的问题，做了很多的功能开发及优化，比如：自研了基于 UI 相对位移的元素定位方案、用例标签化管理、自动生成日志系统、用例失败录屏、全流程超时管控等等。
详细情况请查看：http://youqu.uniontech.com/ ；
YouQu 目前累计已经支撑公司 40+ 自动化测试项目落地运行，累计下载使用 13k+ 次。
CI/CD
针对每日构建的新镜像，CI/CD 每日会使用 Jenkins 流水线分别对新镜像进行自动化测试，保障每日镜像系统的质量。
测试单驱动自动化测试
针对子项目测试单，使用流水线配合相关爬虫技术，实现项目经理提测后快速进行自动化测试；
目前冒烟测试单能实现零人工投入，新需求测试单或回归测试单也能减少 30% 的人工投入。
性能自动化测试
针对 App 启动类场景的性能测试，我们自研了基于视频流 + 设备分离技术方案的性能自动化测试框架 AIPerf，性能测试的效率提高超 100 倍。
RPA测试+AI
RPA 测试与 AI 的结合主要从前面提到的几个方面的痛点（学习成本高、维护成本高、兼容性问题）入手。
结合当前深度学习领域的发展，RPA 测试可以从以下方面进行结合：
LLM
LLM（大语言模型，Large Language Model）要解决的问题是降低测试工程师编写脚本的难度，只需要描述一个业务场景，就能自动生成并执行自动化测试用例。
目前类似 ChatGPT 这样的通用大语言模型已经能做到这种效果，像文件管理器这种用例场景比较复杂的自动化用例，一个用例脚本写几十上百行属于正常，这还是在基于 YouQu 框架封装程度比较高的情况下能做到如此。
结合大语言模型，能实现只需要使用自然语言描述一个具体的业务场景，它就能对自然语言进行识别，进而生成对应的自动化用例操作步骤。
比如描述一个用例场景：在桌面新建一个 Word 文档，然后把它复制到下载目录下。
模型识别之后就可以解析为用例步骤：
1. 在桌面右键；
2. 点击右键菜单新建文档；
3. 点击右键菜单办公文档；
4. 桌面右键点击文档；
5. 点击右键菜单复制；
6. 点击任务栏文件管理器图标；
7. 点击文件管理器中侧边栏下载目录；
8. Ctrl + V 粘贴；在此基础上，每个用例步骤可以继续理解生成对应要执行的方法代码。
测试工程师维护的是自然语言的脚本，相比于传统的用例脚本，维护难度将大幅减低。
OCR
OCR （光学字符识别，Optical Character Recognition）通俗讲就是识别文字，在各行各业已经有比较成熟的运用，比如：车牌识别、证件识别、OCR扫描等。
目前统信 RPA 测试已经运用了基于深度学习的 PaddleOCR，PaddleOCR 是百度飞桨团队开源的一个 OCR 解决方案，在中文识别领域首屈一指。
YouQu 框架将 PaddleOCR 进行功能整合，可用于文本类元素定位和断言，我们使用 RPC 技术进行封装部署，并独立发布到 PyPI，经过两年多的落地运用，识别准确度超过 99.9%。
目标检测
目标检测（Object Detection）通俗讲就是在图像中识别某个特定的元素，在人脸识别、车辆识别等方面有大量运用。
流行的目标检测模型如：YOLO 系列、R-CNN 系列、RetinaNet 等。
流行的目标检测框架如：MMDetection、Detectron2、SimpleDet 等。
其中，MMDetection 来自商汤科技 OpenMMLab 团队，在国内成名已久，MMDetection 也是 OpenMMLab 的明星开源项目，几乎支持了所有的模型，有丰富的开发文档能让使用者快速上手。
RPA 测试结合深度学习目标检测的目的是从计算机视觉的角度识别某些元素，并且能达到两个效果：一是在环境改变（主题、背景、颜色、分辨率等）时能准确的识别出来；二是联想找图，就是能自动识别出类似的图标。
主要的难点有两方面：
一是，需要大量的人工标注训练素材，业内有句调侃的话：有多少人工就有多少智能，几百上千张图片人工标注很简单，但 10W、100W 。。。的图片就很不简单了，需要投入大量的人力。
二是，目标检测所训练的素材是有限的，我们不可能穷举出各种环境下、各种各样的元素图标，因为使用环境和 UI 界面是带灵感和创造性的，是不可穷举的，这就是为什么识别率不可能达到 100%。
因此，如何以有限的人力、有限的训练素材，实现用户场景下的稳定识别，是需要我们解决的问题，也是努力的方向。
总结
RPA 是一种自动化的技术理念，RPA 测试的核心是将过去手工测试的工作使用自动化的手段来执行，各种 RPA 测试技术也随着行业技术的发展层出不穷，日新月异。
统信 RPA 测试从很早之前就被公司领导提出并落地运行，经过多年的技术发展演进，无论是在 RPA 测试框架体系的开发、维护、演进，还是在 RPA 测试流程落地运用，都已经达到了一定的成熟度；
除了功能测试转自动化测试的业务场景运用外，还有 DBus、 Gsetting、命令行等接口测试，App 性能自动化方面我们也自研了智能化性能测试框架；我们不仅在践行 RPA 测试的理念，还在对 RPA 测试所用到的技术做持续的探索、优化、创新，如 YouQu 自动化测试框架的插件化设计、统一名称空间导入、脚手架功能等等都是我们为提高脚本编写效率、提高可维护性等做的创新实践。
但统信 RPA 测试仍然存在许多问题和挑战，如：学习成本高、维护成本高、兼容性问题等问题，目前我们也在积极的和外部团队（清华）展开 AI 方面的技术合作，未来我们将努力尝试通过 RPA 测试 + AI 的方式持续优化现有的 RPA 测试框架技术体系，以尽量为用户提供更简单的端到端解决方案，持续为公司产品质量提供保障。
参考文献
《Fact vs. Fiction: Business Users Can Easily Build Software Robots Using RPA Tools》