From afce85f07d48419c26ca1b2c9874e970deab1cd2 Mon Sep 17 00:00:00 2001 From: mikigo Date: Tue, 23 Jan 2024 16:09:08 +0800 Subject: [PATCH] fix: update Description: Log: --- docs/.vitepress/config.mts | 6 +- docs/release.md | 7 ++ ...71\346\257\224\350\260\203\347\240\224.md" | 31 +++--- "docs/\346\212\225\347\250\277.md" | 27 ----- .../RPA\346\265\213\350\257\225.md" | 99 +++++++++++-------- 5 files changed, 78 insertions(+), 92 deletions(-) diff --git a/docs/.vitepress/config.mts b/docs/.vitepress/config.mts index 4319bf68..d1fdb13b 100644 --- a/docs/.vitepress/config.mts +++ b/docs/.vitepress/config.mts @@ -41,9 +41,9 @@ export default withMermaid( { text: '规范文档', link: '/规范文档/流程规范/测试单驱动自动化' }, { text: '读书笔记', link: '/读书笔记/OpenStack系统架构设计实战' }, { text: '常见问题', link: '/常见问题/Wayland下sniff报错' }, - { text: '✌更多', items:[ - { text: '𓀠留言', link: '/comments' }, - { text: '📝投稿', link: '/投稿' }, + { text: '✌ 更多', items:[ + { text: '💬 留言', link: '/comments' }, + { text: '📝 投稿', link: '/投稿' }, { text: '更新记录', link: '/release' }, ] }, ], diff --git a/docs/release.md b/docs/release.md index 74217ed6..15d96c17 100644 --- a/docs/release.md +++ b/docs/release.md @@ -2,6 +2,13 @@ --- +::: timeline 2024-01-23 + +- 修改，技术文档/技术调研-[《Avocado和YouQu对比调研》](/技术文档/技术调研/Avocado和YouQu对比调研) +- 修改，自动化技术/自动化思想-[《RPA测试》](/自动化技术/自动化思想/RPA测试) + +::: + ::: timeline 2024-01-22 - 新增，自动化技术/自动化思想-[《PageObjects》](/自动化技术/自动化思想/PageObjects) diff --git "a/docs/\346\212\200\346\234\257\346\226\207\346\241\243/\346\212\200\346\234\257\350\260\203\347\240\224/Avocado\345\222\214YouQu\345\257\271\346\257\224\350\260\203\347\240\224.md" "b/docs/\346\212\200\346\234\257\346\226\207\346\241\243/\346\212\200\346\234\257\350\260\203\347\240\224/Avocado\345\222\214YouQu\345\257\271\346\257\224\350\260\203\347\240\224.md" index 4b11b1cf..8e30921e 100644 --- "a/docs/\346\212\200\346\234\257\346\226\207\346\241\243/\346\212\200\346\234\257\350\260\203\347\240\224/Avocado\345\222\214YouQu\345\257\271\346\257\224\350\260\203\347\240\224.md" +++ "b/docs/\346\212\200\346\234\257\346\226\207\346\241\243/\346\212\200\346\234\257\350\260\203\347\240\224/Avocado\345\222\214YouQu\345\257\271\346\257\224\350\260\203\347\240\224.md" @@ -1,9 +1,8 @@ --- Author: mikigo -comment: true --- -# Avocado和YouQu对比调研（待评审） +# Avocado和YouQu对比调研 Avocado 是一个基于 Linux 的自动化测试框架，使用 Python 语言编写构建，具有许多特色功能；YouQu 也是基于 Linux 的自动化测试框架，同样也是使用 Python 语言编写构建。 @@ -33,19 +32,19 @@ youqu manage.py run 这里申明，YouQu 在设计时绝对没有参考 Avocado ，纯属巧合，只能说英雄所见略同。 - YouQu 除了 `run` 子命令，还支持其他的其他的子命令，如： `remote, pmsctl, csvctl, startapp` ； + YouQu 除了 `run` 子命令，还支持其他的子命令，如： `remote, pmsctl, csvctl, startapp` ； 详细用法情况查看：[http://youqu.uniontech.com/框架功能介绍/执行管理器/](http://youqu.uniontech.com/框架功能介绍/执行管理器/) ### 小结 -驱动方式都采用了类似的功能设计，都支持自定义扩展驱动功能，没毛病。 +驱动方式都采用了类似的功能设计，都支持自定义扩展驱动功能。 ## 多种格式的测试报告 ### Avocado -Avocado 默认支持 XML、JSON 格式的测试报告，至于 HTML 格式的测试报告需要按照插件 `avocado-framework-plugin-result-html`； +Avocado 默认支持 XML、JSON 格式的测试报告，至于 HTML 格式的测试报告需要安装插件 `avocado-framework-plugin-result-html`； Avocado 的 HTML 报告是这样的： @@ -71,7 +70,7 @@ Avocado 官方是这样评价它的 HTML 报告的： ::: -沉默。。😅 +。。😅 我只能说 Avocado 这个报告还有很大的进步空间，尊重并祝福。 @@ -165,7 +164,7 @@ CSV 文件标签示例： ### 小结 -Avocado 这样的标签管理方式是非常难以维护的，因为标签分布在各个脚本的注释中，如果后期要进行批量的修改，维护者将会非常痛苦而且非常耗时，你可以想象一下，在几千各 py 文件中，挨个打开修改一个注释，人都麻了。我只能说非常的 Old school，skr~skr。 +Avocado 这样的标签管理方式是非常难以维护的，因为标签分布在各个脚本的注释中，如果后期要进行批量的修改，维护者将会非常痛苦而且非常耗时，你可以想象一下，在几千各 py 文件中，挨个打开修改一个注释，人都麻了。我只能说非常的 Old school。 而 Avocado 的用例筛选执行方式，官方文档用了大量的篇幅和示例来介绍其用法，基本能满足业务使用要求，但是使用比较麻烦，参数传递不够优雅。 @@ -173,8 +172,6 @@ YouQu 的用例标签化管理是独有的专利方案，所有的标签在一 基于此标签化管理方案，YouQu 支持灵活的用例组织方式，而且标签参数支持使用 `and/or/not` 逻辑组合，非常符合语义，根本不需要对使用方法做大量文档说明，使用者就能立马 get 到它的用法。 -所以，此功能 YouQu 之于 Avocado 几乎是云泥之别，高下立判。 - ## 高级日志记录功能 ### Avocado @@ -187,9 +184,7 @@ YouQu 的用例标签化管理是独有的专利方案，所有的标签在一 ### 小结 -这点咱们就不客气了哈。 - -Avocado 的日志模块看似平平无奇，实则司空见惯，而 YouQu 的日志系统，试问阁下何曾见过如此高级的全自动日志系统。 +Avocado 的日志模块看似平平无奇，实则司空见惯，而 YouQu 的日志系统，全自动输出日志系统。 ## 配置 @@ -279,13 +274,13 @@ Avocado 对于依赖项的处理是用字符串硬编码，分布在各个用例 | 对比功能点 | Avocado | YouQu | | ---------------- |:--------:|:------:| | 驱动方式 | 😄 | 😄 | -| 测试报告 | ✗ | ✓ 降维打击 | +| 测试报告 | ✗ | ✓ 略胜三筹 | | 收集系统数据 | 😄 | 😄 | -| 批量运行用例 | ✗ | ✓ 降维打击 | -| 高级日志记录功能 | ✗ | ✓ 降维打击 | +| 批量运行用例 | ✗ | ✓ 略胜三筹 | +| 高级日志记录功能 | ✗ | ✓ 略胜三筹 | | 配置 | 😄 | 😄 | -| 自定义依赖 | ✗ | ✓ 降维打击 | -| 插件 | ✗ | ✓ 降维打击 | +| 自定义依赖 | ✗ | ✓ 略胜三筹 | +| 插件 | ✗ | ✓ 略胜三筹 | Avocado 基于 unitttest 来管理和驱动用例执行，YouQu 基于 Pytest 来管理和驱动用例执行，Pytest 比 unittest 本身具有技术优势，从技术上讲 YouQu 是天然兼容 Avocado 的用例的，反之则不然，再加上 YouQu 在此之上加入了许多自研功能，比如：用例标签化管理方案、全自动日志系统、用例失败录屏，在整体技术架构上不能说是更胜一筹，只能说是属于两个时代的产品。 @@ -294,5 +289,3 @@ Avocado 还支持一些内置插件和三方插件，但插件这块且不提 Yo Avocado 主打 Linux CLI 测试这块，底层方法模块在 Linux 内核、命令这块确有独到之处，底层方法基于 Python 与 Linux 进行交互，易于移植，但框架技术架构上没有任何优势； YouQu 主打在 Linux 操作系统桌面应用 UI、接口自动化这块，添加一些 Linux CLI 相关底层功能很容易，在框架技术架构、 以及各功能方面几乎是**全面碾压 Avocado**。 - - diff --git "a/docs/\346\212\225\347\250\277.md" "b/docs/\346\212\225\347\250\277.md" index 39aad8e5..95954421 100644 --- "a/docs/\346\212\225\347\250\277.md" +++ "b/docs/\346\212\225\347\250\277.md" @@ -289,30 +289,3 @@ pnpm run dev ``` 即可在本地启动一个在线服务，可以在浏览器中预览效果； - -## 投稿激励（待评审） - -### 明确的激励机制 - -- 设立稿费或积分制度，根据文章的质量、阅读量等因素支付稿费或积分。 -- 对优秀投稿者给予奖金或奖励，可以是金钱奖励，也可以是实物奖品或证书。 - -### 认可与表彰 - -- 定期评选优秀投稿者和最佳文章，并进行公开表彰。 -- 在平台上设立“作者墙”或“名人堂”，展示优秀投稿者的照片和简介。 - -### 投稿指导与支持 - -- 提供投稿指南和写作支持，帮助团队成员提高写作质量和投稿成功率。 -- 定期举办写作工作坊或研讨会，提高团队的写作技能和知识分享能力。 - -### 灵活的投稿要求 - -- 设定多样化的投稿主题和格式要求，让不同兴趣和专长的团队成员都能找到适合自己的投稿方向。 -- 对于不同的内容类型（如文章、视频、图表等），提供不同的投稿指导和评价标准。 - -### 宣传与推广 - -- 测试中心自己的微信公众号、掘金、TesterHome、CSDN 等平台账号，利用平台的资源和渠道，对优秀投稿者的作品进行宣传和推广。 -- 鼓励投稿者在个人社交媒体上分享自己的作品，平台可以提供分享指南和支持。 diff --git "a/docs/\350\207\252\345\212\250\345\214\226\346\212\200\346\234\257/\350\207\252\345\212\250\345\214\226\346\200\235\346\203\263/RPA\346\265\213\350\257\225.md" "b/docs/\350\207\252\345\212\250\345\214\226\346\212\200\346\234\257/\350\207\252\345\212\250\345\214\226\346\200\235\346\203\263/RPA\346\265\213\350\257\225.md" index 75866732..54a6834a 100644 --- "a/docs/\350\207\252\345\212\250\345\214\226\346\212\200\346\234\257/\350\207\252\345\212\250\345\214\226\346\200\235\346\203\263/RPA\346\265\213\350\257\225.md" +++ "b/docs/\350\207\252\345\212\250\345\214\226\346\212\200\346\234\257/\350\207\252\345\212\250\345\214\226\346\200\235\346\203\263/RPA\346\265\213\350\257\225.md" @@ -1,10 +1,9 @@ --- Author: mikigo -comment: true --- -# RPA测试（待评审） +# RPA测试 ## RPA是什么 @@ -12,29 +11,31 @@ RPA（Robotic Process Automation，机器人流程自动化）是一种技术理 RPA 是一个很泛的概念，一句话讲清楚就是：`把一切能手工执行的任务交给自动化来执行`。至于具体使用哪种自动化技术，我只能说不确定，因为这是需要 `因需制宜` 的。 -在 RPA 这个概念提出来之前（大概是90年代），财务人员能使用 Excel 进行财务计算，就已经是在践行 RPA 了，毕竟以前都是用算盘在做，稍微先进点的用直呼归零的计算器，不仅需要投入大量的人力，而且还容易出错，Excel 里面的公式能自动处理大量的数据，工作效率是一个飞跃，再到后来出现财务管理软件出现，又在 Excel 的基础上进一步提高的自动化程度。 +在 RPA 这个概念提出来之前（大概是90年代），财务人员能使用 Excel 进行财务计算，就已经是在践行 RPA 了，毕竟以前都是用算盘在做，稍微先进点的用计算器，不仅需要投入大量的人力，而且还容易出错，Excel 里面的公式能自动处理大量的数据，工作效率是一个飞跃，再到后来出现财务管理软件出现，又在 Excel 的基础上进一步提高的自动化程度。 -你看，在不同的时期，RPA 技术用到的具体技术或工具是不同的，在不同的行业也是这样，文案工作者从最开始一个本子一支笔，再到用 Word，再到用 GPT 自动生成。 +在不同的时期，RPA 技术用到的具体技术或工具是不同的，在不同的行业也是这样，文案工作者从最开始一个本子一支笔，再到用 Word，再到用 GPT 自动生成。 所以说，`RPA 是一种技术理念，一种将一切行为自动化的理念`，凡是可以替代人工的技术或工具，都可以称之为 RPA 技术。 ## RPA测试的由来 -前面咱们理清了 RPA 核心就是自动化，那 RPA 测试也就是自动化测试，这节我来简单的介绍下自动化测试的由来； +前面咱们理清了 RPA 核心就是自动化，那 RPA 测试即自动化测试是 RPA 的一个子集，这节我来简单的介绍下自动化测试的由来； -软件测试行业在刚开始的时候，所有的测试人员都是手工测试； +软件测试行业在刚开始的时候，所有的测试人员都是手工测试，互联网行业飞速发展，快速迭代发布，主打的就是一个快，现实的情况是每次迭代测试时间不够、人力不够，维护成本太高。 -互联网行业飞速发展，快速迭代发布，主打的就是一个快；这个时候有测试小伙伴就想了，每次迭代都讲测试时间不够、人力不够、睡眠不够，这么搞谁顶得住； +有机智的测试小伙伴就想，每次迭代都是那些活，这些事情能不能自动化来执行，我在旁边喝咖啡就行了，于是直接上网查资料一看，还真有技术能做这些活。 -这时候机智的测试小伙伴就想到了，每次迭代都是那些活，这些事情能不能自动化来执行，我在旁边喝咖啡就行了，于是直接上网冲浪一看，还真有技术能做这些活； +要想替代人工测试，最直接最容易想到的就是替代人工做点击输入类的动作，这类称为 **UI 自动化测试**；UI 自动化测试是最接近于真实用户的自动化测试类型，早期的自动化测试工具如：QTP、Selenium 等很快流行起来。 -要想替代人工测试，最直接最容易想到的就是替代人工做点击输入类的动作，这类称为 **UI 自动化测试**，UI 自动化测试是最接近于真实用户的自动化测试类型，早期的自动化测试工具如：QTP、Selenium 等很快流行起来； +但自动化测试项目稍微一落地运行就会发现，太难维护了，前端功能界面一天变三回，测试工程师维护用例脚本的投入太大。 -但自动化测试项目稍微一落地运行就会发现，太难维护了，前端功能界面一天变三回，人都麻了； +既然是前后端分离的系统，只管后端接口的输入输出正常岂不方便许多，又上网查资料找到一个 Requests 的库能做接口请求，于是开始搞**接口自动化测试**了；发现接口自动化测试投入产出比高，效果很好，靠着口口相传，测试圈内刮起了一股浩浩荡荡的接口自动化测试风潮。 -找开发稍微一合计，既然是前后端分离的系统，只管后端接口的输入输出正常岂不方便许多，又上网冲浪找到一个 Requests 的库能做接口请求，于是开始搞**接口自动化测试**了，发现投入产出比挺高，效果还可以，靠着口口相传，测试圈内刮起了一股浩浩荡荡的接口自动化测试风潮。 +后来，在接口自动化测试基础上又衍生出了**性能自动化**，因为高并发的场景如果靠人工来测试几乎是不可能的，而利用多线程并发做接口请求可以轻松做到。 -在接口自动化测试基础上又衍生出了**性能自动化**，因为高并发的场景如果靠人工来测试几乎是不可能的，而利用多线程并发做接口请求可以轻松做到。 +测试全面接入 RPA 之后**优势**很明显，提高了测试效率、减少了人力投入、以及频繁的人工操作可能导致的错误。 + +但 RPA 测试也**不尽完美**，也存在一些局限性，比如 RPA 测试不能完全替代人工测试，它主要做一些重复性的任务，还有就是面对复杂流程或频繁变动时对 RPA 测试工具可维护性、灵活性提出考验。 ## RPA测试技术 @@ -42,7 +43,7 @@ RPA 是一个很泛的概念，一句话讲清楚就是：`把一切能手工执 ### 开发阶段 -这个阶段开发还在疯狂的新增和修改代码，适合做的只有**单元测试自动化**； +这个阶段开发还在疯狂的新增和修改代码，适合做的只有**单元测试自动化**。 圈内有个很有名的黑话叫**测试驱动开发**（TDD，Test Driven Development），说的是在编写某个功能代码之前要求先编写测试代码，这里的测试代码实际指的是单元测试代码。据观察，测试同学写应用单元测试代码的情况，还比较少的，这里面主要有学习、沟通成本等问题。 @@ -52,11 +53,11 @@ RPA 是一个很泛的概念，一句话讲清楚就是：`把一切能手工执 到这个阶段说明开发至少交付了一个版本，但是又还没有稳定下来，各功能、界面等还有可能会改动，因此这个阶段适合做**接口自动化**。 -无论是从业务上还是技术上讲，接口自动化都属于是比较容易开展起来的自动化类型； +无论是从业务上还是技术上讲，接口自动化都属于是比较容易开展起来的自动化类型： -业务上，互联网行业都在流行微服务架构，服务端接口小修小补很正常，无非是些参数的增删改，整个接口大改还是少有的，毕竟前期经过了多轮次评审，因此后端服务接口是相对稳定的； +- 业务上，互联网行业都在流行微服务架构，服务端接口小修小补很正常，无非是些参数的增删改，整个接口大改的情况少，毕竟前期经过了多轮次评审，因此后端服务接口是相对稳定的。 -技术上，自动化测试只要有一个能做接口请求的工具，就可以开展起来，这类工具以 Requests 、Postman 为代表，且不论工程化等方面，使用 `unittest + requests` 能做接口请求，能组织用例跑起来，就能快速的把接口自动化开展起来。 +- 技术上，自动化测试只要有一个能做接口请求的工具，就可以开展起来，这类工具以 Requests 、Postman 为代表，且不论工程化等方面，使用 `unittest + requests` 能做接口请求，能组织用例跑起来，就能快速的把接口自动化开展起来。 因此，业务接口稳定，技术门槛低，接口自动化很自然的就能很顺利落地。 @@ -64,9 +65,9 @@ RPA 是一个很泛的概念，一句话讲清楚就是：`把一切能手工执 `Pytest + Requests + Allure` -- Pytest 用于驱动用例批量执行；如果对测试用例过程管控没有太多需求，使用 unittest 足矣； -- Requests 用于做接口请求； -- Allure 用于生成测试报告；如果对测试报告UI效果要求不高，不用 Allure 也行，Pytest 或 unittest 驱动用例跑完之后终端也会有简易的结果展示； +- Pytest 用于驱动用例批量执行；如果对测试用例过程管控没有太多需求，使用 unittest 足矣。 +- Requests 用于做接口请求。 +- Allure 用于生成测试报告；如果对测试报告UI效果要求不高，不用 Allure 也行，Pytest 或 unittest 驱动用例跑完之后终端也会有简易的结果展示。 此技术路线是比较通用的，当然不同的人使用这些工具做出来的效果也是不同的，需要有一些框架设计，这里不做赘述； @@ -74,31 +75,31 @@ RPA 是一个很泛的概念，一句话讲清楚就是：`把一切能手工执 `HttpRunner` -实际上也是基于 `用例驱动工具 + 接口请求工具 + 测试报告工具` 进行封装，以框架级服务提供功能，让使用者能专注于接口用例的维护，而不用关心其他的。 +`HttpRunner` 实际上也是基于 `用例驱动工具 + 接口请求工具 + 测试报告工具` 进行封装，以框架级服务提供功能，让使用者能专注于接口用例的维护，而不用关心其他的。 ----------------- -此外，**性能自动化测试**也开始在这一阶段介入，常用的性能测试工具：JMeter、Locust； +此外，**性能自动化测试**也开始在这一阶段介入，常用的性能测试工具：JMeter、Locust。 ### 验收维护阶段 此阶段系统各方面功能已经趋于稳定，适合做 **UI 自动化**。 -UI 自动化是从功能的层面模拟手工操作进行自动化测试，核心内容是 `元素定位` 和 `元素操作` ，看起来很简单对吧，但实际上 UI 自动化是所有自动化测试类型中最难的。 +UI 自动化是从功能的层面模拟手工操作进行自动化测试，核心内容是 `元素定位` 和 `元素操作` ；看起来很简单对吧，但实际上 UI 自动化是所有自动化测试类型中最难的。 为什么这么说？ -UI 自动化是从用户视角进行自动化测试，测试的对象是客户端，而客户端又分布在不同的平台设备上； +UI 自动化是从用户视角进行自动化测试，测试的对象是客户端，而客户端又分布在不同的平台设备上。 ![](/rpa/rpa-2.png) #### Web -Web UI 自动化就是基于浏览器的 UI 自动化测试；不同的浏览器用到的底层驱动是不同的，但由于一些自动化工具封装了统一的 API 接口（如 Playwright），在编码上并没有特别大的区别。 +Web UI 自动化就是基于浏览器的 UI 自动化测试；不同的浏览器，自动化测试用到的底层驱动是不同的，但由于一些自动化工具封装了统一的 API 接口（如 Playwright），在编码上并没有特别大的区别。 难点在于网速、浏览器、脚本的健壮性和测试环境等因素都会导致 UI 自动化测试的失败，产品迭代的过程中维护性差，维护成本高。 -常用到的工具：Selenium、Playwright、Cypress、Puppeteer、TestCafe； +常用到的工具：Selenium、Playwright、Cypress、Puppeteer、TestCafe。 #### App @@ -127,13 +128,11 @@ YouQu 自动化测试框架的定位是一个全功能的自动化测试框架 ![](https://pic.imgdb.cn/item/64f054c4661c6c8e54ff4948.png) -YouQu 在整合上述底层技术基础上，进行了工程化的框架设计，并对底层的工具进行了二次开发，使得上层测试用例能非常方便轻松的进行调用，大幅减少了自动化测试用例编写的难度，并且我们还针对 UI 自动化维护性差的问题，做了很多的功能开发及优化； - -比如：自研了基于 UI 相对位移的元素定位方案、用例标签化管理、自动生成日志系统、用例失败录屏、全流程超时管控等等。 +YouQu 在整合上述底层技术基础上，进行了工程化的框架设计，并对底层的工具进行了二次开发，使得上层测试用例能非常方便轻松的进行调用，大幅减少了自动化测试用例编写的难度，并且我们还针对 UI 自动化维护性差的问题，做了很多的功能开发及优化，比如：自研了基于 UI 相对位移的元素定位方案、用例标签化管理、自动生成日志系统、用例失败录屏、全流程超时管控等等。 详细情况请查看：http://youqu.uniontech.com/ ； -YouQu 目前累计已经支撑公司 `40+` 自动化测试项目落地运行，累计下载使用 `12k+` 次。 +YouQu 目前累计已经支撑公司 `40+` 自动化测试项目落地运行，累计下载使用 `13k+` 次。 ### CI/CD @@ -147,21 +146,27 @@ YouQu 目前累计已经支撑公司 `40+` 自动化测试项目落地运行， ![](/guifan/at.drawio.png) -目前冒烟测试单能实现零人工投入，新需求测试单或回归测试单也能减少 30% 的人工投入。 +目前冒烟测试单能实现零人工投入，新需求测试单或回归测试单也能减少 `30%` 的人工投入。 + +### 性能自动化测试 + +针对 App 启动类场景的性能测试，我们自研了基于视频流 + 设备分离技术方案的性能自动化测试框架 [AIPerf](http://youqu.uniontech.com/%E6%99%BA%E8%83%BD%E5%8C%96%E6%80%A7%E8%83%BD%E6%B5%8B%E8%AF%95/)，性能测试的效率提高超 100 倍。 + +![](https://pic.imgdb.cn/item/64f054cb661c6c8e54ff5034.png) ## RPA测试+AI RPA 测试与 AI 的结合主要从前面提到的几个方面的痛点（学习成本高、维护成本高、兼容性问题）入手。 -结合当前深度学习领域的发展，RPA 测试可以从一下方面进行结合： +结合当前深度学习领域的发展，RPA 测试可以从以下方面进行结合： ### LLM LLM（大语言模型，Large Language Model）要解决的问题是降低测试工程师编写脚本的难度，只需要描述一个业务场景，就能自动生成并执行自动化测试用例。 -目前类似 ChatGPT 这样的通用大语言模型已经能做到这种效果，像文件管理器这种用例场景比较复杂的自动化用例，一个用例脚本写几十上百行属于正常，这还是在基于 YouQu 框架封装程度比较高的情况下能做到如此； +目前类似 ChatGPT 这样的通用大语言模型已经能做到这种效果，像文件管理器这种用例场景比较复杂的自动化用例，一个用例脚本写几十上百行属于正常，这还是在基于 YouQu 框架封装程度比较高的情况下能做到如此。 -结合大语言模型，能实现只需要使用自然语言描述一个具体的业务场景，它就能对自然语言进行识别，进而生成对应的自动化用例操作步骤； +结合大语言模型，能实现只需要使用自然语言描述一个具体的业务场景，它就能对自然语言进行识别，进而生成对应的自动化用例操作步骤。 比如描述一个用例场景：在桌面新建一个 Word 文档，然后把它复制到下载目录下。 @@ -184,23 +189,23 @@ LLM（大语言模型，Large Language Model）要解决的问题是降低测试 ### OCR -OCR （光学字符识别，Optical Character Recognition）通俗讲就是识别文字，在各行各业已经有比较成熟的运用，比如：车牌识别、证件识别、OCR扫描等； +OCR （光学字符识别，Optical Character Recognition）通俗讲就是识别文字，在各行各业已经有比较成熟的运用，比如：车牌识别、证件识别、OCR扫描等。 -目前统信 RPA 测试已经运用了基于深度学习的 [PaddleOCR](https://github.com/PaddlePaddle/PaddleOCR)，PaddleOCR 是百度飞桨团队开源的一个 OCR 解决方案，在中文识别领域首屈一指； +目前统信 RPA 测试已经运用了基于深度学习的 [PaddleOCR](https://github.com/PaddlePaddle/PaddleOCR)，PaddleOCR 是百度飞桨团队开源的一个 OCR 解决方案，在中文识别领域首屈一指。 YouQu 框架将 PaddleOCR 进行功能整合，可用于文本类元素定位和断言，我们使用 RPC 技术进行封装部署，并独立发布到 [PyPI](https://pypi.org/project/pdocr-rpc/)，经过两年多的落地运用，识别准确度超过 99.9%。 -[YouQu OCR 应用详细文档说明](http://youqu.uniontech.com/框架功能介绍/OCR识别/#41) +[《YouQu OCR 应用详细文档说明》](http://youqu.uniontech.com/框架功能介绍/OCR识别/#41) ### 目标检测 -目标检测（Object Detection）通俗讲就是在图像中识别某个特定的元素，在人脸识别、车辆识别等方面有大量运用； +目标检测（Object Detection）通俗讲就是在图像中识别某个特定的元素，在人脸识别、车辆识别等方面有大量运用。 -流行的目标检测模型如：YOLO 系列、R-CNN 系列、RetinaNet 等； +流行的目标检测模型如：YOLO 系列、R-CNN 系列、RetinaNet 等。 -流行的目标检测框架如：MMDetection、Detectron2、SimpleDet 等； +流行的目标检测框架如：MMDetection、Detectron2、SimpleDet 等。 -其中，MMDetection 来此商汤科技 [OpenMMLab](https://openmmlab.com/) 团队，在国内成名已久，MMDetection 也是 OpenMMLab 的明星开源项目，几乎支持了所有的模型，有丰富的开发文档能让使用者快速上手。 +其中，MMDetection 来自商汤科技 [OpenMMLab](https://openmmlab.com/) 团队，在国内成名已久，MMDetection 也是 OpenMMLab 的明星开源项目，几乎支持了所有的模型，有丰富的开发文档能让使用者快速上手。 RPA 测试结合深度学习目标检测的目的是从计算机视觉的角度识别某些元素，并且能达到两个效果：一是在环境改变（主题、背景、颜色、分辨率等）时能准确的识别出来；二是联想找图，就是能自动识别出类似的图标。 @@ -208,7 +213,7 @@ RPA 测试结合深度学习目标检测的目的是从计算机视觉的角度 一是，需要大量的人工标注训练素材，业内有句调侃的话：`有多少人工就有多少智能`，几百上千张图片人工标注很简单，但 10W、100W 。。。的图片就很不简单了，需要投入大量的人力。 -二是，目标检测所训练的素材是有限的，我们不可能穷举出各种环境下、各种各样的元素图标，因为使用环境和 UI 界面是带灵感和创造性的，是不可穷举的，这就是为什么不可能达到 100%。 +二是，目标检测所训练的素材是有限的，我们不可能穷举出各种环境下、各种各样的元素图标，因为使用环境和 UI 界面是带灵感和创造性的，是不可穷举的，这就是为什么识别率不可能达到 100%。 因此，如何以有限的人力、有限的训练素材，实现用户场景下的稳定识别，是需要我们解决的问题，也是努力的方向。 @@ -218,6 +223,14 @@ RPA 是一种自动化的技术理念，RPA 测试的核心是将过去手工测 统信 RPA 测试从很早之前就被公司领导提出并落地运行，经过多年的技术发展演进，无论是在 RPA 测试框架体系的开发、维护、演进，还是在 RPA 测试流程落地运用，都已经达到了一定的成熟度； -但统信 RPA 测试仍然存在许多问题和挑战，如：学习成本高、维护成本高、兼容性问题等问题，目前我们也在积极的和外部团队（清华）展开 AI 方面的技术合作，未来我们将努力尝试通过 RPA 测试 + AI 的方式持续优化现有的 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》](https://www.ibm.com/blog/fact-vs-fiction-business-users-can-easily-build-software-robots-using-rpa-tools/) + +[《What is robotic process automation (RPA)》](https://www.ibm.com/topics/rpa) - \ No newline at end of file +[《RPA百年发展简史》](https://developer.aliyun.com/article/818647) \ No newline at end of file