fix: update docs

Description: Log:
2024-04-20 11:29:31 +08:00 · 2024-04-20 11:29:31 +08:00 · 76f2c09dd1
parent df8d85f77a
commit 76f2c09dd1
26 changed files with 218 additions and 320 deletions
--- a/README.md
+++ b/README.md
@ -70,8 +70,6 @@
    </ul>
 </details>

-
-
 ## 安装使用

 从 PyPI 安装:
@ -83,7 +81,6 @@ $ sudo pip3 install youqu

 创建项目:

-
 ```shell
 $ youqu-startproject my_project
 ```
@ -92,11 +89,9 @@ $ youqu-startproject my_project

 安装依赖:

-
-
-
 ```shell
 $ cd my_project
+
 # 使用的默认密码是 1 ，您可以修改配置文件 setting/globalconfig.ini 里面的 PASSWORD 配置项
 $ bash env.sh

@ -321,12 +316,10 @@ $ sudo systemctl enable ssh
 $ youqu manage.py remote -a ... --parallel no
 ```

-## 贡献者
+## 贡献

 [贡献文档](https://github.com/linuxdeepin/youqu/blob/master/CONTRIBUTING.md) 

--8<-- "docs/contributors.html"
-

 ## 开源许可证

--- a/docs/.vitepress/config.mts
+++ b/docs/.vitepress/config.mts
@ -65,6 +65,7 @@ export default withMermaid(
                            {text: "属性定位", link: "/指南/元素定位/属性定位"},
                            {text: "OCR识别", link: "/指南/元素定位/OCR识别"},
                            {text: "相对坐标定位", link: "/指南/元素定位/相对坐标定位"},
+                            {text: "去干扰识别", link: "/指南/元素定位/去干扰识别"},
                        ]
                    },
                    {
@ -78,12 +79,12 @@ export default withMermaid(
                    },
                    {
                        text: "特色功能",
-                        collapsed: false,
+                        collapsed: true,
                        items: [
                            {text: "标签化管理", link: "/指南/特色功能/标签化管理"},
+                            {text: "标签自动同步", link: "/指南/特色功能/标签自动同步"},
                            {text: "全自动日志", link: "/指南/特色功能/全自动日志"},
                            {text: "失败录屏", link: "/指南/特色功能/失败录屏"},
-                            {text: "标签自动同步", link: "/指南/特色功能/标签自动同步"},
                            {text: "Wayland适配", link: "/指南/特色功能/Wayland适配"},
                            {text: "重启类场景", link: "/指南/特色功能/重启类场景"},
                            {text: "数据回填", link: "/指南/特色功能/数据回填"},
@ -91,7 +92,7 @@ export default withMermaid(
                    },
                ],
                "/框架设计/": [
-                    {text: "AT应用库设计方案", link: "/框架设计/自动化测试架构设计v1.0"},
+                    {text: "自动化测试架构设计规划", link: "/框架设计/自动化测试架构设计v1.0"},
                    {text: "AT基础框架设计方案", link: "/框架设计/AT基础框架设计方案"},
                    {text: "AT应用库设计方案", link: "/框架设计/AT应用库设计方案"},
                ]
--- a/docs/FAQ.md
+++ b/docs/FAQ.md
@ -1,9 +1,4 @@
---
-hide:
-    - navigation
---
-
-## 1. 提交代码时提示邮箱或者名称不对
+## 提交代码时提示邮箱或者名称不对

 重新配置邮箱或者名称，然后重置生效：

@ -13,7 +8,7 @@ git commit --amend --reset-author

 ---------------

-## 2. 怎么回滚到之前的版本
+## 怎么回滚到之前的版本

 (1)查询历史提交记录

@ -39,7 +34,7 @@ git reset --hard ${hash}

 ---------------------------

-## 3. 解决 git status 中文显示的问题
+## 解决 git status 中文显示的问题

 ```shell
 git config --global core.quotePath false
@ -47,7 +42,7 @@ git config --global core.quotePath false

 ---------------------

-## 4. `apps` 目录下颜色有些是黄色的
+## apps 目录下颜色有些是黄色的

 在 `Pycharm` 中 `apps` 目录下应用库文件是黄色的，编辑器识别不到代码新增和修改；

@ -61,7 +56,7 @@ git config --global core.quotePath false

 ------------------------------

-## 5. 执行 `env.sh` 报错 `$'\r':未找到命令`
+## 执行 `env.sh` 报错 `$'\r':未找到命令`

 出现这个问题你应该是在 windows 上打开或编辑过 `env.sh` 脚本，windows下的换行是回车符+换行符，也就是`\r\n`，而 `Linxu` 下是换行符 `\n`，`Linux` 下不识别 `\r`，因此报错。

@ -74,7 +69,7 @@ sudo sed -i 's/\r//' env.sh

 ---------------------------

-## 6. 怎样为单独某一条用例配置执行超时时间
+## 怎样为单独某一条用例配置执行超时时间

 在用例脚本中添加装饰器，如下：

@ -86,7 +81,7 @@ def test_xxx_001():

 -----------------------

-## 7. 如何修复子仓库 master 分支游离头（detached head）
+## 如何修复子仓库 master 分支游离头（detached head）

 修复所有子仓库默认master 分支游离头

--- a/docs/指南/元素定位/OCR识别.md
+++ b/docs/指南/元素定位/OCR识别.md
@ -1,10 +1,10 @@
-## OCR识别
+# OCR识别

-### 1. 背景
+## 背景

 传统的 OCR 方案大多采用谷歌 OCR（`Tesseract`）方案，但是它对于中文的识别非常差，经过大量的调研，我们使用 `PaddleOCR`，它是一个开源的基于深度学习的 OCR 识别工具，也是 `PaddlePaddle` 最有名的一个开源项目，感兴趣的可以点[这里](https://github.com/PaddlePaddle/PaddleOCR)了解，多的不说了，你只需要知道它就是中文识别的天花板。

-### 2. 实现原理
+## 实现原理

 安装它是个很麻烦的事情，虽然操作很简单，但其实安装包有点大，我们并不希望直接在 `env.sh` 中加入它，这会让整个自动化环境变得非常臃肿；

@ -16,7 +16,7 @@ RPC 的调用逻辑：

 这样我们只需要在服务端部署好 OCR 识别的服务，然后通过 RPC 服务将功能提供出来，框架里面只需要调用对应的 RPC 接口就行了。

-### 3. 使用说明
+## 使用说明

 框架代码示意（Client）：

@ -120,11 +120,11 @@ if __name__ == "__main__":
        self.assert_ocr_exist("取消收藏")
 ```

-### 4. 服务端部署
+## 服务端部署

 我们目前是将 `OCR` 服务部署机器性能较一般，如果你觉得现有的 `OCR` 识别性能不够好，恰好你有更好的机器，可以考虑将其私有化部署。

-#### 4.1. 环境安装
+### 1. 环境安装

 推荐使用 `pipenv` 进行环境搭建；

@ -157,7 +157,7 @@ pipenv install "paddleocr>=2.0.1" -i https://mirror.baidu.com/pypi/simple

 不出意外，这样就把依赖安装好了。

-#### 4.2. 启动服务
+### 2. 启动服务

 将基础框架中的 `scr/ocr/pdocr_rpc_server.py` 文件拷贝到 `ocr_env` 目录，后台执行它就好了：

@ -166,7 +166,7 @@ cd ocr_env
 nohup pipenv run python pdocr_rpc_server.py &
 ```

-#### 4.3. 配置开机自启
+### 3. 配置开机自启

 你肯定不想每次机器重启之后都需要手动启动服务，因此我们需要配置开机自启。

--- a/docs/指南/元素定位/去干扰识别.md
+++ b/docs/指南/元素定位/去干扰识别.md
@ -1,12 +1,12 @@
-## 去干扰识别
+# 去干扰识别

 以右键菜单来讲解此方案；

-### 1. 现有右键菜单定位的方案及问题
+## 现有右键菜单定位的方案及问题

 右键菜单的元素定位是一个难点，过去我们调研和使用过的元素定位操作方法有 4 种：

-#### 1.1. 步长操作法
+### 1. 步长操作法

 在右键菜单呼出来之后，通过键盘的 `up`、`down` 按键，进行选择菜单选择，选中目标之后 `enter` 即可；比如：在桌面点击右键菜单之后，按 1 次 `down` ，会出现下图：

@ -26,7 +26,7 @@

 也就是说你得经常去维护菜单选项的步长，一个选项现在的步长是 3，下个迭代可能就是 4 或者 5。

-#### 1.2. 常规图像识别法
+### 2. 常规图像识别法

 把每个菜单选项单独截图保存，图片中仅包含一个菜单选项，如下图所示：

@ -36,7 +36,7 @@

 这种方式不用担心菜单选项的顺序或位置，但是需要保存大量的图片，且容易受到字体 UI 变更类需求的影响，比如：字体大小、字体间距等等需求变更都会影响，每次变更之后就需要进行大量图片资源的重新截图替换，是个比较麻烦的事情；

-#### 1.3. 相对位移法
+### 3. 相对位移法

 鼠标点击右键的时候，鼠标的当前坐标是可以获取到的，菜单选项的宽（ w ）一般是固定的，变化的是菜单的长度（ h ），可以通过某个选项相对于鼠标的距离在确定菜单选项的坐标，如下图所示：

@ -51,11 +51,11 @@

 基于以上两个原因，我们并不推荐这种操作方案。

-#### 1.4. 属性定位
+### 4. 属性定位

 有同学说干嘛不通过属性定位呢，其实，我们最开始想到的方案就是通过属性定位，但是在属性的 DOM 树里怎么也找不到，无法定位到，我们也联合研发同学一起解决此问题，但最终还是没能解决，非常遗憾；

-### 2. 去干扰识别
+## 去干扰识别

 由于右键菜单选项几乎都是文本，那么通过 OCR 识别，几乎是最优的方案：

--- a/docs/指南/元素定位/图像识别.md
+++ b/docs/指南/元素定位/图像识别.md
@ -1,10 +1,10 @@
-## 图像识别
+# 图像识别

 图像识别在 `UI` 自动化中是不可缺少的，市面上甚至有完全基于图像识别的自动化测试框架，比如 `Airtest`、`Sikuli` 等，在游戏等特定领域也有不错的效果，这些工具实际上也是用的 `OpenCV` 进行了封装，`YouQu` 框架基于 `OpenCV` 开发了自己的图像识别功能，它可以方便的用于界面元素的定位和断言；

 `YouQu` 的图像识别功能几乎满足了你的所有要求，我们在长时间的思考和摸索中，针对常规场景及一些特殊场景探索出了一些实用且有效的方案，且听我慢慢道来。

-### 1. 常规识别
+## 常规识别

 【背景】

@ -126,7 +126,7 @@ def find_image(



-### 2. 气泡识别
+## 气泡识别

 【背景】

@ -176,9 +176,9 @@ def get_during(



-### 3. 不依赖 OpenCV 的图像识别方案
+## 不依赖 OpenCV 的图像识别方案

-#### 3.1. 自研图像识别技术 
+### 1. 自研图像识别技术 

 【原理】

@ -272,7 +272,7 @@ class ImageRgb:

 整体识别效果来讲，我认为还是可以接受的，也希望有志之士能一起优化此方案，一起技术报国。

-#### 3.2. 基于 RPC 服务实现图像识别
+### 2. 基于 RPC 服务实现图像识别

 在远程服务器上部署 OpenCV 的环境，并将其部署为 RPC 服务，测试机上不用安装 OpenCV 依赖，而是通过请求 RPC 服务的方式进行图像识别；

@ -357,7 +357,7 @@ except OSError as exc:



-### 4. 动态图像识别
+## 动态图像识别

 【背景】

--- a/docs/指南/元素定位/属性定位.md
+++ b/docs/指南/元素定位/属性定位.md
@ -1,6 +1,6 @@
-## 属性定位
+# 属性定位

-### 1. 背景
+## 背景

 传统的 UI 自动化大多都是基于浏览器的，核心是在网页的 DOM 树上查找元素，并对其进行定位操作；

@ -10,9 +10,7 @@ Linux 桌面应用大多是采用 Qt 编写的，在 Qt 中也是从最顶层的

 借助开源工具 `dogtail` 我们可以对元素进行获取，从而进行定位操作。`dogtail` 的项目介绍可以[猛戳这里](https://gitlab.com/dogtail/dogtail/)。

-### 2. 使用方法
-
-#### 2.1. sniff（嗅探器）使用
+## sniff（嗅探器）使用

 在终端输入 sniff 启动 AT-SPI Browser

@ -40,7 +38,7 @@ mikigo@mikigo-PC:~$ sniff

 ![](https://pic.imgdb.cn/item/64f054ca661c6c8e54ff4f0b.png)

-#### 2.2. 元素操作
+## 元素操作

 获取应用对象

@ -117,7 +115,7 @@ element.typeText(string)
 element.keyCombo(comboString)
 ```

-#### 2.3. 框架封装
+## 框架封装

 代码示例：

--- a/docs/指南/元素定位/相对坐标定位.md
+++ b/docs/指南/元素定位/相对坐标定位.md
@ -1,12 +1,12 @@
-## 相对坐标定位
+# 相对坐标定位

-### 1. 背景
+## 背景

 相对坐标定位方案是是一种基于 UI 的元素定位方案，是我们自研的一个使用简单，且效率极高、稳定性好的元素定位方案，基于元素按钮在应用中的相对位置，动态获取元素在当前屏幕中的位置，适用于各种屏幕分辨率（包括高分屏、宽屏、带鱼屏），当元素按钮位置相对于应用界面位置发生修改之后，只需要根据 UI 设计图上的源数据修改对应坐标数据就好，维护非常的方便。

 此类元素定位方案适用于一些元素位置相对与应用界面比较固定的应用，比如音乐（99% 的元素定位采用这种，效果非常好），不适用于界面不固定的应用，比如截图录屏，很明显不适用于这类元素定位方案。这种全新的元素定位方案有它的适用条件，如果你发现使用常规的（属性定位、图像定位）不好做时，不妨考虑使用这种，其效果一定能惊讶到你，并且迅速爱上他。

-### 2. 实现原理
+## 实现原理

 在 UI 设计图中我们是可以获取到元素按钮相对于应用边框的距离的，然后我们可以通过技术手段获取到应用界面在当前屏幕中的位置及应用窗口的大小，示意图如下：

@ -56,7 +56,7 @@ position = [int(i.strip()) for i in conf.get(btn_name, "location").split(",")]

 根据应用窗口在屏幕中的位置大小、元素按钮相对于应用窗口边界的位置大小，使用一定的算法即可计算出元素按钮在当前屏幕中的位置（中心坐标）。

-### 3. 使用方法
+## 使用方法

 【配置方法】

--- a/docs/指南/框架必备/执行管理器.md
+++ b/docs/指南/框架必备/执行管理器.md
@ -1,8 +1,8 @@
-## 执行管理器-manage.py
+# 执行管理器 - manage.py

 `YouQu` 的执行管理器 `manage.py` 提供了丰富的配置和命令行参数，可用于本地用例驱动执行、远程用例驱动执行、`CSV` 文件管理、`PMS` 与本地 `CSV` 文件标签关联管理、脚手架等功能；

-### 1. 如何使用
+## 如何使用

 **【命令行使用】**

@ -10,26 +10,20 @@

 你可以使用 `-h` 或 `--help` 查看它的帮助：

-<div class="termy">

-```console
+```shell
 $ youqu manage.py -h
 ```

-</div>
-
 这样可以查看它支持的子命令；

 然后再通过子命令 `-h` 或 `--help` 查看子命令的帮助，以子命令 `run` 举例：

-<div class="termy">

-```console
+```shell
 $ youqu manage.py run -h
 ```

-</div>
-
 这样可以查看到子命令支持的各项参数及参数使用说明。

 **【配置文件】**
@ -45,19 +39,16 @@ $ youqu manage.py run -h

 下面介绍两个常用的用例执行的功能：

-### 2. 本地执行
+## 本地执行

 本地执行子命令为：`run`

-<div class="termy">

-```console
+```shell
 $ youqu manage.py run
 ```

-</div>
-
-#### 2.1. 命令行参数
+### 1. 命令行参数

 通过命令行参数配置参数

@ -115,17 +106,14 @@ $ youqu manage.py run

 在一些 `CI` 环境下使用命令行参数会更加方便：

-<div class="termy">

-```console
+```shell
 $ youqu manage.py run --app autotest_deepin_music --keywords "xxx" --tags "xxx"
 ```

-</div>
-
 `--app` 入参还支持 `apps/autotest_xxx` 写法，方便在输入命令的过程中使用补全，下面的远程执行功能同样支持。

-#### 2.2. 配置文件
+### 2. 配置文件

 通过配置文件配置参数

@ -137,29 +125,23 @@ $ youqu manage.py run --app autotest_deepin_music --keywords "xxx" --tags "xxx"

 配置完成之后，直接在命令行执行 `manage.py` 就好了。

-<div class="termy">

-```console
+```shell
 $ youqu manage.py run
 ```

-</div>
-
-### 3. 远程执行
+## 远程执行

 远程执行就是用本地作为服务端控制远程机器执行，远程机器执行的用例相同；

 使用 `remote` 命令：

-<div class="termy">

-```console
+```shell
 $ youqu manage.py remote
 ```

-</div>
-
-#### 3.1. 多机器分布式异步执行
+### 1. 多机器分布式异步执行

 ![](https://pic.imgdb.cn/item/64f6d3c0661c6c8e549f8ca5.png)

@ -179,7 +161,7 @@ $ youqu manage.py remote

 <div class="termy">

-```console
+```shell
 $ youqu manage.py remote
 ```

@ -212,7 +194,7 @@ $ youqu manage.py remote

 <div class="termy">

-```console
+```shell
 $ youqu manage.py remote -a autotest_deepin_music -c uos@10.8.13.xx/uos@10.8.13.xx -k "xxx" -t "xxx"
 ```

@ -224,7 +206,7 @@ $ youqu manage.py remote -a autotest_deepin_music -c uos@10.8.13.xx/uos@10.8.13.

 <div class="termy">

-```console
+```shell
 $ youqu manage.py remote -a autotest_deepin_music -c uos@10.8.13.xx/uos@10.8.13.xx -k "xxx" -t "xxx" -e
 ```

@ -234,7 +216,7 @@ $ youqu manage.py remote -a autotest_deepin_music -c uos@10.8.13.xx/uos@10.8.13.

 <div class="termy">

-```console
+```shell
 $ sudo systemctl restart ssh
 $ sudo systemctl enable ssh
 ```
@ -243,7 +225,7 @@ $ sudo systemctl enable ssh

 配置文件其他相关配置项详细说明，请查看配置文件中的注释内容。

-#### 3.2. 多机器分布式异步负载均衡执行
+### 2. 多机器分布式异步负载均衡执行

 多机器分布式异步负载均衡执行也是用本地作为服务端控制远程机器执行，但远程机器执行的用例不同，而是所有远程机器执行的用例之和，为你想要执行的用例集；

@ -257,7 +239,7 @@ $ sudo systemctl enable ssh

 <div class="termy">

-```console
+```shell
 $ youqu manage.py remote -a autotest_deepin_music -c uos@10.8.13.xx/uos@10.8.13.xx -k "xxx" -t "xxx" --parallel no
 ```

--- a/docs/指南/框架必备/测试报告.md
+++ b/docs/指南/框架必备/测试报告.md
@ -1,4 +1,6 @@
-### 1. 目录结构
+# 测试报告
+
+## 目录结构

 执行时会在根目录下动态生成 `report` 目录，所有的报告相关的文件会统一存放在里面，示例：

@ -30,7 +32,7 @@

 默认情况下同时生成 html、xml、json三种形式的报告。

-### 2. 定制报告
+## 定制报告

 我们对 `allure` 报告进行了一系列的定制：

@ -43,7 +45,7 @@

 报告 `UI` 效果会持续优化；

-### 3. 查看报告
+## 查看报告

 - **本地执行**

--- a/docs/指南/框架必备/键鼠操作.md
+++ b/docs/指南/框架必备/键鼠操作.md
@ -1,12 +1,12 @@
-## 键鼠操作
+# 键鼠操作

 `YouQu` 键鼠操作模块集成了多个键鼠操作的方案：`PyAutoGUI`、`Xdotool`、`wayland_autotool`；

-有同学肯定要问，我之前就只用 `PyAutoGUI` 也都挺好的，好像用不到这么多键鼠操作的东西吧~；
+有同学肯定要问，我之前就只用 `PyAutoGUI` 也都挺好的，好像用不到这么多键鼠操作的东西吧；

 任何模块当然是希望越简洁通用越好，但问题是没有一种方案是通用的，它们都有自己存在的问题或者说不适用的场景，如果你还没有遇到，只能说使用的场景还不够多。

-### 1. 常规键鼠操作
+## 常规键鼠操作

 `YouQu` 的键鼠操作模块主要有两个：`MouseKey`、`ShortCut`

@ -40,7 +40,7 @@ ShortCut.ctrl_c()

 我们**推荐第一种**使用方法，因为你写用例层肯定是会导入方法层出口类的，你不需要有额外的导入代码即可使用到所有的方法。

-### 2. 特殊场景键鼠操作
+## 特殊场景键鼠操作

 一些特殊场景下，无法使用上述的键鼠工具，比如在注销登录界面（没有进入系统），调用上述方法会报错，我们提供了另外一种解决方案：`ydotool`

--- a/docs/指南/特色功能/Wayland适配.md
+++ b/docs/指南/特色功能/Wayland适配.md
@ -1,4 +1,4 @@
-## Wayland 适配
+# Wayland 适配

 `Wayland` 下自动化主要问题是 `X11` 下的键鼠操作方法无法使用，比如 `Xdotool`、 `PyAutoGUI`、`Xwininfo` 等等；

--- a/docs/指南/特色功能/全自动日志.md
+++ b/docs/指南/特色功能/全自动日志.md
@ -1,6 +1,6 @@
-## 日志系统
+# 全自动日志

-### 1. 背景
+## 背景

 基于 `YouQu` 自动化测试框架操作方法封装写法，通常是这样的：类里面一个函数只包含一个操作或多次调用的一系列可合并的操作；

@ -24,7 +24,7 @@ class XXXWidget:

 基于此“天真”的想法，我们设计出了 `YouQu` 的日志系统。

-### 2. 实现原理
+## 实现原理

 核心原理：

@ -35,7 +35,7 @@ class XXXWidget:
 1. 通过 ```inspect.getmembers``` 获取被装饰的类下所有函数，包含静态方法，类方法，实例方法；
 2. 通过 ```setattr(类, 方法, _trace）``` 的方式，给符合条件的函数，动态添加日志装饰器；

-### 3. 日志配置
+## 日志配置

 ```ini
 [log_cli]
@ -55,7 +55,7 @@ CLASS_NAME_CONTAIN = ShortCut
 # ==============================================
 ```

-### 4. 使用方法
+## 使用方法

 在应用库 `widget` 方法库里面，只需要在出口文件加上**类装饰器**，就可以实现自动输出日志了；

--- a/docs/指南/特色功能/失败录屏.md
+++ b/docs/指南/特色功能/失败录屏.md
@ -1,4 +1,4 @@
-## 失败录屏
+# 失败录屏

 录屏其实是一种视频形式的日志，因为很多时候我们在查看日志之后仍然无法准确的定位到用例失败的具体原因，因此用例的录屏能让我们看到用例在执行过程；

--- a/docs/指南/特色功能/数据回填.md
+++ b/docs/指南/特色功能/数据回填.md
@ -1,8 +1,8 @@
-## PMS数据回填
+# PMS数据回填

 测试单关联的用例，自动化测试对应的去跑这些关联的用例，并且将执行的结果回填的测试用例的状态里面。

-### 1. 本机执行时回填
+## 本机执行时回填

 PMS 数据回填主要有三种方式：

@ -75,7 +75,7 @@ APP_NAME =
 youqu manage.py pms --send2task yes
 ```

-### 2. 远程执行时回填
+## 远程执行时回填

 远程执行需要控制多台测试机同时执行用例，也就是说同一条用例会在多台机器上同时执行，但是执行结果可能不一致；

@ -89,7 +89,7 @@ youqu manage.py remote -c uos@10.8.13.xx/uos@10.8.13.yy -a apps/autotest_xxx -u

 执行结束之后在 `report` 目录下会有 `pms_xxx` 开头的目录，里面保存了所有远程测试机的测试结果，以及汇总的结果；

-### 3. 可能遇到的“严重问题”
+## 可能遇到的“问题”

 有同学可能会发现，怎么回填一次之后，后面想再次回填就不生效了；

--- a/docs/指南/特色功能/标签化管理.md
+++ b/docs/指南/特色功能/标签化管理.md
@ -1,19 +1,19 @@
-## 标签化管理
+# 标签化管理

-### 1. 标签说明
+## 标签说明

 根据现有业务需要，用例需要添加的标签有：

- ==脚本 ID== ：自动化用例脚本/函数 ID；
- ==PMS用例ID== ：`PMS` 上对应的用例 ID（用例库 ID）；默认使用用例库 ID，对于暂时没有使用用例库管理用例的项目，可以使用产品库用例 ID；
- ==用例级别== ：对应 `PMS` 上用例级别，分别用 `L1、L2、L3、L4` 表示；
- ==用例类型== ：`FUNC`（功能）、`PERF`（性能）、`STR`（压力）、`SEC`（安全）、`CTS`（兼容性）、`API`（接口）、`BASELINE`（基线-预留）
- ==设备类型== ：`PPL`（依赖外设的用例）、`COL`（依赖主控机的用例）
- ==一二级bug自动化== ：`BUG`（由 `Bug` 转的用例）
- ==上线对象== ：`CICD`，表示上线到 `CICD` 流水线的用例，后续可一键生成 `case_list.csv` 文件，用于导入到明道云 AT 用例列表中控制 `CICD` 跑测范围；
- ==跳过原因== ：`skip-XXX`，用于控制用例是否执行；
- ==确认修复== ：`fixed-XXX`，用于标记用例的修复状态（后面详细讲解用法）；
- ==废弃用例== ：`removed-已废弃`，用于标记已经废弃的用例，此用例标签不会被添加，也不会被执行；
+- 脚本 ID ：自动化用例脚本/函数 ID；
+- PMS用例ID ：`PMS` 上对应的用例 ID（用例库 ID）；默认使用用例库 ID，对于暂时没有使用用例库管理用例的项目，可以使用产品库用例 ID；
+- 用例级别 ：对应 `PMS` 上用例级别，分别用 `L1、L2、L3、L4` 表示；
+- 用例类型 ：`FUNC`（功能）、`PERF`（性能）、`STR`（压力）、`SEC`（安全）、`CTS`（兼容性）、`API`（接口）、`BASELINE`（基线-预留）
+- 设备类型 ：`PPL`（依赖外设的用例）、`COL`（依赖主控机的用例）
+- 一二级bug自动化 ：`BUG`（由 `Bug` 转的用例）
+- 上线对象 ：`CICD`，表示上线到 `CICD` 流水线的用例，后续可一键生成 `case_list.csv` 文件，用于导入到明道云 AT 用例列表中控制 `CICD` 跑测范围；
+- 跳过原因 ：`skip-XXX`，用于控制用例是否执行；
+- 确认修复 ：`fixed-XXX`，用于标记用例的修复状态（后面详细讲解用法）；
+- 废弃用例 ：`removed-已废弃`，用于标记已经废弃的用例，此用例标签不会被添加，也不会被执行；

 示例：

@ -21,13 +21,13 @@
 | :----: | :-------: | :------: | :------: | :------: | :-------------: | :------: | :------: | :-------: | :------------: | ---- |
 | 679537 |  679537   |    L1    |   FUNC   |   PPL    |       BUG       |   CICD   | skip-XXX | fixed-XXX | removed-已废弃 | ...  |

-### 2. 操作步骤
+## 操作步骤

-2.1、在子项目目录下新建 `csv` 文件，用于保存用例标签，以 ==用例脚本的 py 文件去掉首字符串 "test_" ，去掉用例序号后的字符串，取中间的名称作为 csv 文件的文件名== 。
+2.1、在子项目目录下新建 `csv` 文件，用于保存用例标签，以 用例脚本的 py 文件去掉首字符串 "test_" ，去掉用例序号后的字符串，取中间的名称作为 csv 文件的文件名 。

 例如:

- ==相册的用例文件为 `test_album_xxx.py`，xxx 表示用例的ID（也可以是自定义的数字代表用例序号），此时 `csv` 文件名就应为 `album.csv`== ；
+- 相册的用例文件为 `test_album_xxx.py`，xxx 表示用例的ID（也可以是自定义的数字代表用例序号），此时 `csv` 文件名就应为 `album.csv` ；

 对于用例规模比较大的应用，比如文件管理器，建议分模块，每个模块建立一个 `csv` 文件，所有 `csv` 文件建议放在一个 `tags` 目录下。

@ -35,15 +35,13 @@

 2.2、第一列为脚本 ID，从第二列开始及之后的列，每一列都是一个用例标签；后续需要新增用例标签，可以直接在 `csv` 文件里面添加对应的列即可；用例标签可以无序。

-### 3. 增加说明
-
-#### 3.1. 跳过用例
+## 跳过用例

 传统跳过用例的方式是在用例脚本里面给用例添加装饰器(`@pytest.mark.skip`)，解除跳过时将装饰器代码删掉，这种方式需要修改用例代码，而通过 `csv` 文件来管理跳过用例则会方便很多;

 将跳过用例操作也整合进入用例标签，在 `csv` 文件中新增一列为“跳过原因”；

-##### 3.1.1. 固定跳过
+### 1. 固定跳过

 示例：

@ -54,7 +52,7 @@
 - 如果应用受到新需求影响需要跳过，则在此列备注具体的跳过原因。跳过的原因统一标签开头为 “`skip-XXX`”；
 - 用例执行时判断 `csv` 文件里面跳过原因列是否存在跳过标签，存在跳过标签则用例也不会被执行，最终的用例状态会被标签为 `SKIPED`。

-##### 3.1.2. 条件判断跳过
+### 2. 条件判断跳过

 示例：

@ -85,7 +83,7 @@

 - 若需要多个 skipif 条件判断组合，使用 `&&` 符号将两个方法分开，比如：skipif_platform-aarch64&&skipif_xdg_type-wayland ；

-#### 3.2. 确认修复
+## 确认修复

 针对于某些用例修复后，但不能立即删除跳过原因（`skip-XXX`）的用例，新增一列标签名为 “`确认修复`”，作为标记该用例是否已经修复，固定填入字段为 “`fixed-已修复`”。这样这条用例即使同时标记了 `skip-XXX` 也会正常执行。

@ -119,7 +117,7 @@ python3 manage.py run --ifixed yes

 这就是“确认修复”这个标签的背景，需要各位看官稍微品一品。

-#### 3.3. 废弃用例
+## 废弃用例

 针对某些用例，由于需求变更，环境影响或评估不再适用于自动化测试时，用例需要废弃，则新增一列标签名为 “废弃用例”，该列存在 “removed-{废弃原因}”，则用例不会执行。

@ -131,11 +129,11 @@ python3 manage.py run --ifixed yes



-### 4. 设计思路
+## 设计思路

 上面介绍 `Pytest` 框架提供的标签功能 mark，使用时需要为每一个用例添加标签装饰器，则操作复杂，可维护性差，其根本问题就是标签分散在每一条用例的装饰器上，难以集中维护；于是乎将所有标签使用 `csv` 文件进行集中管理，并通过 `Pytest` 的钩子函数，读取 `csv` 文件，动态添加标签到用例中。

-### 5. CSV文件格式
+## CSV文件格式

 此配置文件需要维护大量的标签数据，且要方便能使用 `Excel` 打开进行编辑查看，更重要的是我们不想引入三方依赖，`CSV` 文件几乎是唯一能满足所有的要求的文件格式。

--- a/docs/指南/特色功能/标签自动同步.md
+++ b/docs/指南/特色功能/标签自动同步.md
@ -1,6 +1,6 @@
-## 标签自动同步
+# 标签自动同步

-### 1. 自动同步脚本ID到CSV文件
+## 自动同步脚本 ID 到 CSV 文件

 支持自动同步脚本 `ID`（用例 `py` 文件的 `ID`）到 `CSV` 文件；

@ -36,7 +36,7 @@ youqu manage.py csvctl -p2c

 每次操作会将 `CSV` 文件先备份到 `report/pyid2csv_back` 目录下；

-### 2. 从PMS自动同步标签到CSV
+## 从 PMS 自动同步标签到 CSV

 用于自动同步 `PMS` 用例标签数据至本地 `CSV` 文件；

--- a/docs/指南/特色功能/重启类场景.md
+++ b/docs/指南/特色功能/重启类场景.md
@ -1,10 +1,10 @@
-## 重启类场景
+# 重启类场景

 对于重启类场景的用例需要解决的核心问题是，重启之后如何让用例能继续重启前的步骤继续执行，`YouQu` 集成了自研的 [letmego](https://linuxdeepin.github.io/letmego/) 技术方案；

 详细技术方案、实现细节、Demo可以看 [letmego](https://linuxdeepin.github.io/letmego/) 官方在线文档；

-### 1. 使用方法
+## 使用方法

 使用方法很简单，只需要给应用方法层的唯一出口类加一个装饰器（`@letmego.mark`）即可：

@ -16,7 +16,7 @@ class DeepinMusicWidget(WindowWidget, TitleWidget, PopWidget):
    """音乐业务层"""
 ```

-### 2. 用例注意事项
+## 用例注意事项

 这类用例相对特殊，这里主要介绍写用例的时候注意事项：

@ -61,7 +61,7 @@ class DeepinMusicWidget(WindowWidget, TitleWidget, PopWidget):
        os.system("echo '1' | sudo -S reboot")
 ```

-### 3. 驱动执行
+## 驱动执行

 因为重启类场景需要注册自启服务以及对用例执行过程的处理，驱动执行的时候加 `--autostart yes` :

@ -69,6 +69,6 @@ class DeepinMusicWidget(WindowWidget, TitleWidget, PopWidget):
 youqu manage.py run --autostart yes
 ```

-### 4. 执行环境
+## 执行环境

 默认使用虚拟环境执行，也就是说如果您是部署自动化环境是用的 `env_dev.sh` 是无法使用此技术方案的，解决方法也很简单，执行一下：`bash env.sh`，以此激活虚拟环境即可。
--- a/docs/指南/特色功能/静态代码扫描.md
+++ b/docs/指南/特色功能/静态代码扫描.md
@ -1,7 +1,7 @@
 静态代码扫描
 --------------

-### 1. 提前解决代码问题
+## 1. 提前解决代码问题

 为了帮助开发者统一代码风格，`Python` 社区提出了 `PEP8` 代码编码风格，`Python` 官方同时推出了一个检查代码风格是否符合 `PEP8` 的工具，名字也叫 `PEP8`。

@ -25,7 +25,7 @@ black ${CheckPath}

 使用这个工具格式化之后，代码会被自动调整，刚开始你可能会觉得调整得很夸张，没关系坚持看，习惯之后，你会觉得很优雅，没错，这就是 `Pythonic Code` 的核心，请保持优雅～。

-### 2. 代码扫描工具
+## 2. 代码扫描工具

 使用根目录下 `pylint.sh` 扫描代码，在 `report` 目录下查看代码扫描报告，如果有代码问题请提前解决之后再提交。

@ -43,13 +43,13 @@ bash pylint.sh

 代码提交需通过 `git review` 提交到 `gerrit` ，人工 `Code Review` 通过之后合入代码。

-### 3. 安装依赖
+## 3. 安装依赖

 ```shell
 sudo apt install git-review
 ```

-### 4. 提交模板
+## 4. 提交模板

 在 `~` 目录下新建文件，并命名为 `gitcommit_template` 

@ -89,7 +89,7 @@ git config --global commit.template ~/gitcommit_template
 - `commit type` 冒号后面加**空格**。
 - `Description` 必要的情况下需要进行详细说明，比如对功能进行大改等。

-### 5. 推送代码
+## 5. 推送代码

 首先添加 `commit` 信息

--- a/docs/指南/环境/全局配置.md
+++ b/docs/指南/环境/全局配置.md
@ -1,6 +1,6 @@
-## 全局配置-setting.conf
+# 全局配置 - setting.conf

-### 1. 配置文件
+## 配置文件

 全局配置模块 `setting` 包含了以下配置文件：

@ -14,7 +14,7 @@

 一些支持人工修改或自定义的配置项都在 `ini` 配置文件里面，`py` 文件是不需要人工去修改的；

-### 2. 配置对象获取
+## 配置对象获取

 导入全局配置对象

@ -28,11 +28,7 @@ from setting import conf
 conf.PASSWORD
 ```

-这样可以获取到 `globalconfig.ini` 配置文件中 `PASSWORD` 配置的值。
-
-```ini
--8<-- "setting/globalconfig.ini"
-```
+这样可以获取到 [globalconfig.ini](https://github.com/linuxdeepin/youqu/blob/master/setting/globalconfig.ini) 配置文件中 `PASSWORD` 配置的值。

 除了上面这种导入方式，还可以这样导入：

@ -42,7 +38,7 @@ from setting.globalconfig import GlobalConfig

 `GlobalConfig` 也是全局配置对象，实际上 `conf` 是 `GlobalConfig` 的别名，你可以根据自己喜欢选择用哪个；

-### 3. 应用库配置对象
+## 应用库配置对象

 所有应用库配置对象都是继承框架的全局配置类的:

--- a/docs/指南/环境/环境部署.md
+++ b/docs/指南/环境/环境部署.md
@ -1,6 +1,6 @@
-## 环境部署-env.sh
+# 环境部署 - env.sh

-### 1. 安装
+## 安装

 项目根目录下运行 `env.sh` 即可。

@ -10,9 +10,9 @@ $ bash env.sh
 ```


-### 2. 定制依赖
+## 定制依赖

-#### 2.1. 新增依赖
+### 1. 新增依赖

 如果应用库还需要其他 `Python` 依赖库，只需要在应用库根目录下保存一个 `requirement.txt` 文件；

@ -51,7 +51,7 @@ autotest_xxx
 python3-pyaudio
 ```

-#### 2.2. 裁剪依赖
+### 2. 裁剪依赖

 在某些情况下，可能你只需要安装一些最最基础的依赖，其他的都不需要，比如纯接口自动化的项目，它不需要 `UI` 自动化相关的依赖。

@ -68,7 +68,7 @@ autotest_xxx

 `裁剪依赖` 和 `新增依赖` 是不冲突的，可以同时使用。

-### 3. 开发环境部署-env_dev.sh
+## 开发环境部署 - env_dev.sh

 在开发过程中，如果你想直接部署在本机上：

@ -82,7 +82,7 @@ $ bash env_dev.sh
 $ python3 manage.py run
 ```

-### 4. 虚拟环境解释器
+## 虚拟环境解释器

 YouQu 默认采用虚拟化部署，虚拟环境实际安装的位置是在 `$HOME/.local/share/virtualenvs/youqu-oHTM7l7G` 目录下；其中，

@ -90,7 +90,7 @@ YouQu 默认采用虚拟化部署，虚拟环境实际安装的位置是在 `$HO

 在远程机器上定位问题的时候，如果使用 `Pycharm` 调试执行，就将解释器指定到这个目录的就行了；

-### 5. 激活虚拟环境
+## 激活虚拟环境

 在开发过程中有可能需要在终端激活虚拟环境，以便进行一些开发调试；

@ -102,7 +102,7 @@ $ youqu-shell

 即可在终端激活当前虚拟环境。

-### 6. 原则
+## 原则

 `YouQu` 的环境依赖一直坚持 2 个原则：

--- a/docs/指南/简介/YouQu是什么.md
+++ b/docs/指南/简介/YouQu是什么.md
@ -1,36 +1,42 @@
+# YouQu 是什么？

 有趣（YouQu）是深度公司开源的一个用于 Linux 操作系统的自动化测试框架，支持多元化元素定位和断言、用例标签化管理和执行、强大的日志和报告输出等特色功能，同时完美兼容 X11、Wayland 显示协议，环境部署简单，操作易上手。

-## 有趣（YouQu）能做什么
+## YouQu 能做什么？

- [x] Linux 桌面应用 UI 自动化测试
- [x] Linux 桌面应用 D-Bus/Gsettings 接口自动化测试
- [x] 命令行自动化测试
- [x] HTTP 接口自动化测试
- [x] Web UI 自动化测试
- [ ] Linux 桌面应用性能自动化测试
+☑ Linux 桌面应用 UI 自动化测试

-<details>
-	<summary style="color: #FF9933">点击查看爱上 “有趣（YouQu）” 的 N 个理由</summary>
-	<ul>
-        <li>无处不在的代码补全，让编写自动化测试用例成为一种享受；</li>
-        <li>核心库提供了统一的接口，编写方法时只需要导入一个包就可以使用到核心库提供的所有功能；</li>
-        <li>除了常用的属性定位、图像识别以外，我们还提供基于 UI 的元素定位方案，其使用简单且高效，效果一定能惊讶到你；</li>
-        <li>对属性定位的方法进行了二次封装，将编写属性定位的方法变得简单而优雅；</li>
-        <li>对图像识别定位技术进行功能升级，除了支持单个坐标返回，还支持同一界面下多个相同元素返回多个坐标的功能；</li>
-        <li>提供用例标签化管理、批量跳过和批量条件跳过的功能，你想不到一个 csv 文件原来能干这么多事情；</li>
-        <li>提供了功能强大的执行器入口，让你可以方便的在本地执行任何用例集的用例，其丰富的自定义配置项，满足你对执行器所有的幻想；</li>
-        <li>提供远程执行的功能，可以控制多台机器并行跑，或者分布式跑，这种付费功能现在免费给你用；</li>
-        <li>提供自动输出日志的功能，你再也不用为每个方法单独写输出日志的代码，一切我们给你搞定了，日志输出不仅内容丰富，颜值也绝对在线，我们还自己设计了一款终端输出主题叫《五彩斑斓的黑》；</li>
-        <li>提供一键部署自动化测试环境的功能，让你再也不用为环境部署而烦恼；</li>
-        <li>提供自动生成多种报告的功能，你想输出什么报告形式都行，而且我们在报告中还加入了失败录屏和失败截图的功能；</li>
-        <li>对断言进行了二次封装，提供更友好化的错误提示，让定位问题精准高效；</li>
-        <li>不仅支持单条用例超时控制，而且还支持动态控制用例批量执行的总时间，确保 CI 环境下能顺畅运行；</li>
-        <li>支持本地文件测试套执行、PMS 测试套执行、标签化执行方案，满足你各种场景下的执行需求；</li>
-        <li>支持基于深度学习的 OCR 功能，可定位可断言，中文识别的天花板；</li>
-        <li>完美兼容 Wayland  和 X11，真正做到一套代码，随处执行；</li>
-        <li>支持多种方式的数据回填功能，其中异步回填的方案，完美解决了数据回填的耗时问题；</li>
-        <li>支持重启交互场景用例的执行，使用方法优雅简洁；</li>
-    </ul>
-</details>
+☑ Linux 桌面应用 D-Bus/Gsettings 接口自动化测试

+☑ 命令行自动化测试
+
+☑ HTTP 接口自动化测试
+
+☑ Web UI 自动化测试
+
+□ Linux 桌面应用性能自动化测试
+
+## 爱上 YouQu 的 N 个理由
+
+- 无处不在的代码补全，让编写自动化测试用例成为一种享受；
+- 核心库提供了统一的接口，编写方法时只需要导入一个包就可以使用到核心库提供的所有功能；
+- 除了常用的属性定位、图像识别以外，我们还提供基于 UI 的元素定位方案，其使用简单且高效，效果一定能惊讶到你；
+- 对属性定位的方法进行了二次封装，将编写属性定位的方法变得简单而优雅；
+- 对图像识别定位技术进行功能升级，除了支持单个坐标返回，还支持同一界面下多个相同元素返回多个坐标的功能；
+- 提供用例标签化管理、批量跳过和批量条件跳过的功能，你想不到一个 csv 文件原来能干这么多事情；
+- 提供了功能强大的执行器入口，让你可以方便的在本地执行任何用例集的用例，其丰富的自定义配置项，满足你对执行器所有的幻想；
+- 提供远程执行的功能，可以控制多台机器并行跑，或者分布式跑，这种付费功能现在免费给你用；
+- 提供自动输出日志的功能，你再也不用为每个方法单独写输出日志的代码，一切我们给你搞定了，日志输出不仅内容丰富，颜值也绝对在线，我们还自己设计了一款终端输出主题叫《五彩斑斓的黑》；
+- 提供一键部署自动化测试环境的功能，让你再也不用为环境部署而烦恼；
+- 提供自动生成多种报告的功能，你想输出什么报告形式都行，而且我们在报告中还加入了失败录屏和失败截图的功能；
+- 对断言进行了二次封装，提供更友好化的错误提示，让定位问题精准高效；
+- 不仅支持单条用例超时控制，而且还支持动态控制用例批量执行的总时间，确保 CI 环境下能顺畅运行；
+- 支持本地文件测试套执行、PMS 测试套执行、标签化执行方案，满足你各种场景下的执行需求；
+- 支持基于深度学习的 OCR 功能，可定位可断言，中文识别的天花板；
+- 完美兼容 Wayland  和 X11，真正做到一套代码，随处执行；
+- 支持多种方式的数据回填功能，其中异步回填的方案，完美解决了数据回填的耗时问题；
+- 支持重启交互场景用例的执行，使用方法优雅简洁；
+
+## 开源许可证
+
+YouQu 在 [GPL-2.0-only](https://github.com/linuxdeepin/youqu/blob/master/LICENSE) 下发布。
--- a/docs/指南/简介/快速开始.md
+++ b/docs/指南/简介/快速开始.md
@ -1,54 +1,43 @@
+# 快速开始

-## 安装使用
+## 安装

 从 PyPI 安装:

-<div class="termy">

-```console
+```shell
 $ sudo pip3 install youqu
---> 100%
 ```

-</div>
-
 创建项目:

-<div class="termy">

-```console
+```shell
 $ youqu-startproject my_project
---> 100%
-The project: [my_project],has been created by youqu-x.x.x
 ```

-</div>
-
 如果 `youqu-startproject` 后面不加参数，默认的项目名称为：`youqu` ；

 安装依赖:

-<div class="termy">

-```console
+```shell
 $ cd my_project
-// 使用的默认密码是 1 ，您可以修改配置文件 setting/globalconfig.ini 里面的 PASSWORD 配置项
+
+# 使用的默认密码是 1 ，您可以修改配置文件 setting/globalconfig.ini 里面的 PASSWORD 配置项
 $ bash env.sh
---> 100%
-// 也可以使用 -p 选项传入密码
+
+# 也可以使用 -p 选项传入密码
 $ bash env.sh -p ${my_password}
---> 100%
 ```

-</div>
-
-------------------------------
+## 创建工程

 **【APP工程】**

 如果您已经有一个可用的 `APP` 工程，将应用库放到基础框架下 `apps` 目录下，像这样：

-```shell hl_lines="3"
+```shell
 my_project
 ├── apps
 │   ├── autotest_deepin_music  # 应用库
@ -57,19 +46,13 @@ my_project

 如果您还没有 `APP` 工程，建议使用框架提供的脚手架功能创建一个全新的 `APP` 工程。

-## 创建工程
-
 创建一个 APP 工程：

-<div class="termy">

-```console
+```shell
 $ youqu manage.py startapp autotest_deepin_some
---> 100%
 ```

-</div>
-
 这样在 `apps` 目录下会创建一个子项目工程 `autotest_deepin_some`，同时新建好工程模板目录和模板文件：

 ```shell
@ -113,36 +96,27 @@ apps

 ### 2. 本地执行

-<div class="termy">

-```console
+```shell
 $ youqu manage.py run
 ```

-</div>
-
 #### 2.1. 命令行参数

 通过命令行参数配置参数，使用 `-h` 或 `--help` 可以查看所有支持的命令行参数：

-<div class="termy">

-```console
+```shell
 $ youqu manage.py run -h
 ```

-</div>
-
 在一些 CI 环境下使用命令行参数会更加方便：

-<div class="termy">

-```console
+```shell
 $ youqu manage.py run --app apps/autotest_deepin_music --keywords "xxx" --tags "xxx"
 ```

-</div>
-
 更多参数请查看【[命令行参数](https://linuxdeepin.github.io/youqu/%E6%A1%86%E6%9E%B6%E5%8A%9F%E8%83%BD%E4%BB%8B%E7%BB%8D/%E6%89%A7%E8%A1%8C%E7%AE%A1%E7%90%86%E5%99%A8/#21)】

 #### 2.2. 配置文件
@ -159,14 +133,11 @@ $ youqu manage.py run --app apps/autotest_deepin_music --keywords "xxx" --tags "

 使用 `remote` 命令：

-<div class="termy">

-```console
+```shell
 $ youqu manage.py remote
 ```

-</div>
-
 #### 3.1. 远程多机器分布式异步执行

 ![](https://pic.imgdb.cn/item/64f6d3c0661c6c8e549f8ca5.png)
@ -204,14 +175,11 @@ ip = 10.8.11.xx

 然后在命令行：

-<div class="termy">

-```console
+```shell
 $ youqu manage.py remote
 ```

-</div>
-
 这样运行是从配置文件去读取相关配置。

 如果你不想通过配置文件，你仍然通过命令行参数进行传参，
@ -237,37 +205,28 @@ $ youqu manage.py remote

 在命令行这样运行：

-<div class="termy">

-```console
+```shell
 $ youqu manage.py remote -a apps/autotest_deepin_music -c uos@10.8.13.x3/uos@10.8.13.x4 -k "xxx" -t "xxx"
 ```

-</div>
-
 所有用例执行完之后会在 `report` 目录下回收各个测试机执行的测试报告。

 注意：如果远程机器没有搭建自动化测试环境，记得加上参数 `-e` ：

-<div class="termy">

-```console
+```shell
 $ youqu manage.py remote -a ... -e
 ```

-</div>
-
 执行前确保远程机器已经开启了 ssh 服务，否则会提示无法连接，如果没有开启，请手动开启：

-<div class="termy">

-```console
+```shell
 $ sudo systemctl restart ssh
 $ sudo systemctl enable ssh
 ```

-</div>
-
 配置文件其他相关配置项详细说明，请查看配置文件中的注释内容。

 #### 3.2. 远程多机器分布式异步负载均衡执行
@ -282,33 +241,9 @@ $ sudo systemctl enable ssh

 使用方法和前面一样，只是需要增加一个参数 `--parallel`：

-<div class="termy">

-```console
+```shell
 $ youqu manage.py remote -a ... --parallel no
 ```

-</div>

-## 贡献者
-
-[贡献文档](https://github.com/linuxdeepin/youqu/blob/master/CONTRIBUTING.md) 
-
--8<-- "docs/contributors.html"
-
-
-## 开源许可证
-
-有趣 在 [GPL-2.0-only](https://github.com/linuxdeepin/youqu/blob/master/LICENSE) 下发布。
-
------------
-
-[__Github Star History__]()
-
-[![Stargazers over time](https://starchart.cc/linuxdeepin/youqu.svg)](https://starchart.cc/linuxdeepin/youqu)
-
-
-
-[__Gitee Info__]()
-
-[![deepin-community/youqu](https://gitee.com/deepin-community/youqu/widgets/widget_card.svg?colors=4183c4,ffffff,ffffff,e3e9ed,666666,9b9b9b)](https://gitee.com/deepin-community/youqu)
--- a/docs/框架设计/AT基础框架设计方案.md
+++ b/docs/框架设计/AT基础框架设计方案.md
@ -1,10 +1,8 @@
-# AT 基础框架设计方案
+---
+Author: mikigo
+---

-```shell
-# ====================================
-# Author  : mikigo
-# ====================================
-```
+# AT 基础框架设计方案

 ## 一、目标

@ -109,11 +107,11 @@ autotest-basic-frame  # 自动化测试基础框架

 ## 三、详细方案

-### 1、==应用库（apps）==
+### 1、应用库（apps）

 所有应用库均放置在基础框架下的 `apps` 目录下（见第二章节第3段目录结构内容）。应用库的架构设计可以参考《AT 应用库设计方案》文档。

-### 2、==核心库（src）==
+### 2、核心库（src）

 在 `src` 目录下为自动化测试的底层核心组件，通常来讲如果你需要使用到其中某一个功能模块，那么你需要显示的导入这个模块，然后才能使用该模块下的功能，如果你用到了十个功能模块，那你就需要导入十个。但是我们想让事情变得简单，一次导入，使用所有。

@ -166,7 +164,7 @@ class BaseWidget(Src):

 写 `__init__` 构造函数的原因是通过参数构造应用，并且传递 `number` 进来，可以实现多窗口的控制。

-### 3、==公共方法库（public）==
+### 3、公共方法库（public）

 公共方法库里面每个应用都是一个单独的 `py` 文件，相互之间是独立的，每个 `py` 文件里面是该应用的方法类，比如：最常用的方法类 `dde_desktop_public_widget.py`

@ -194,7 +192,7 @@ class DdeDesktopPublicWidget(_DdeDesktopPublicBaseWidget):
        pass
 ```

-==公共方法库意义==：
+公共方法库意义：

 - 公共方法库里面所封装的一些操作方法都是至少被 2 个应用都用到的，这样做可以减少整体代码量，从而减轻应用库代码的维护工作。

@ -203,7 +201,7 @@ class DdeDesktopPublicWidget(_DdeDesktopPublicBaseWidget):

 当然，如果你的应用本身是属于根本就不需要和其他应用交互的，那么你可能不会用到这里面的功能，没关系，你所有的方法都可以直接写在应用库的业务层。

-### 4、==conftest.py==
+### 4、conftest.py

 `conftest.py` 从功能上将是属于核心库（`src`）的内容，但是由于它的特殊性，即它是对应用库中的用例生效的，而且它的作用域是当前目录及以下，因此我们将它放到项目根目录。我们框架中有不少核心功能都是在这里面进行开发的，后面第四章会讲到细节。

@ -211,7 +209,7 @@ class DdeDesktopPublicWidget(_DdeDesktopPublicBaseWidget):

 根目录下的 `conftest.py` 文件只会用来写 `Hook` 函数，`apps` 目录下的 的 `conftest.py` 文件只会用来写 `fixture` 。

-### 5、==setting==
+### 5、setting

 全局配置模块，包含了以下配置文件：

--- a/docs/框架设计/AT应用库设计方案.md
+++ b/docs/框架设计/AT应用库设计方案.md
@ -1,9 +1,8 @@
+---
+Author: mikigo
+---
+
 # AT 应用库设计方案
-```shell
-# =================================================
-# Author  : mikigo
-# =================================================
-```

 ## 一、目标

@ -74,9 +73,9 @@ autotest_dde_file_manager  # 应用仓库

 - 模块划分

-    按照文件管理器的界面区域划分为：==TitleWidget 、RightViewWidget、LeftViewWidget 、PopWidget== ；
+    按照文件管理器的界面区域划分为：TitleWidget 、RightViewWidget、LeftViewWidget 、PopWidget ；

-    文管界面分为四个区域：==标题栏、右边视图区域、左边视图区域、弹窗[^1]==；
+    文管界面分为四个区域：标题栏、右边视图区域、左边视图区域、弹窗[^1]；

 	[^1]: 设置界面弹窗、保险箱弹窗、删除确认弹窗、及各种网络弹窗.

--- a/docs/框架设计/自动化测试架构设计v1.0.md
+++ b/docs/框架设计/自动化测试架构设计v1.0.md
@ -1,14 +1,9 @@
+---
+Author: mikigo
+---
+
 # 自动化测试架构设计规划

-```shell
-# ====================================
-# Author  : mikigo
-# ====================================
-```
-
-[comment]: <> (- 分类：/)
-
-[comment]: <> (- 架构师：/)
 - 目标：
 	- 应用 AT 架构工程化，参考性能自动化工程完成工程化改造。
 	- 应用间用例解耦，解除所有交叉调用的方法，各应用能跟随自身迭代周期独立维护 AT 用例。
@ -83,13 +78,13 @@
 ???+ note "现AT框架架构图"
 	![](https://pic.imgdb.cn/item/64f054c4661c6c8e54ff4948.png)

-### 2、==设计思路==
+### 2、设计思路

 框架的运行逻辑：

 通过核心层提供一个基础能力，业务层根据实际业务需求（测试用例）动态加载核心层，执行入口加载相应的用例集并控制执行，应用层根据实际测试需求，通过相应的配置项进行配置，从而触发自动化测试任务。

- ==核心层==：
+- 核心层：

 	基本保持不变，部分模块会涉及到新功能开发，核心层各功能模块保持独立性，提供通用的接口能力，供上层调用；底层核心模块包括：
 	
@ -107,7 +102,7 @@
 	- 键鼠信号模拟模块
 	- `OCR` 模块
 	
- ==业务层==：
+- 业务层：

 	以应用为维度划分，应用内包含多个测试类型，如功能测试、性能测试、漏洞扫描等，后续可以根据需要嫁接进来。其中功能测试设计思路：

@ -144,7 +139,7 @@
 		...
 		```
  
- ==globalconfig 配置模块==：
+- globalconfig 配置模块：
  
    可以根据需要进行相应配置，测试同学可以根据自己的测试计划，在 `globalconfig` 里面进行配置。
  
@ -163,7 +158,7 @@
    
    - 指定某台机器在指定镜像版本上执行用例：在 `IP` 里面配置测试机 `IP`，并在 `URL` 里面填入镜像的下载地址，框架会调用 `PXE` 进行自动装机，装机完之后自动开始执行配置的测试用例。
    
-    ==应用内局部配置==：
+    应用内局部配置：
    
    每个应用内部会有一个单独的配置模块，会包含一些本应用的测试资源的路径、执行用例的标签配置等等，如果在局部配置里面配置了用例执行标签，而外层执行器没有指定执行标签，则在执行时只会执行局部配置已配置的，若外层执行器也配置了执行标签，则会按照全局配置执行用例。
    
@ -175,11 +170,11 @@
  - 全局配置未配置，局部配置了执行的用例标签，则按照局部配置执行。
  - 全局配置了执行的用例标签，局部配置了执行的用例标签，则按照全局配置执行。
  
- ==应用层==：
+- 应用层：

 	`runner` 是测试执行的入口，它会根据配置里面的配置项，进行用例的加载和执行。它提供接口给自动化测试平台，平台上的指令实际上都是通过下发给执行器，然后由执行器来执行相应的测试。

- ==自动化测试平台==
+- 自动化测试平台

 	是一个前端系统，可以进行测试机管理、自动安装镜像、自动安装指定应用版本、进行测试用例范围选择、用例触发执行控制、结果展示输出等。

@ -241,7 +236,7 @@ class DdeDesktopPublicWidget:
 	| :----: | :------: | :------: | :------: |
 	|  001   |   `L1`   |  `core`  |  `xxx`  |

-	==标签支持扩展；==
+	标签支持扩展；

 3.2、在每个应用目录下新建 `csv` 文件，用于保存用例标签，第一列为用例的 ID，从第二列开始及之后的列，每一列都是一个用例标签；后续需要新增用例标签，可以直接在 `csv` 文件里面添加对应的列即可；

@ -268,7 +263,7 @@ class DdeDesktopPublicWidget:
 4.1、标签化管理的驱动执行逻辑功能实现

 - 开发根据用例标签文件里面的用例标签执行对应用例的功能，能支持多个标签的逻辑组合，执行入口能随意通过用例标签指定要执行的用例。
- ==用例标签的驱动方式必须能支持标签的扩展，未来随着业务的变化可能需要增加各种各样的标签。==
+- 用例标签的驱动方式必须能支持标签的扩展，未来随着业务的变化可能需要增加各种各样的标签。

 4.2、不同测试类型的用例执行