mikigo
parent
86487c8fea
commit
c7f13e4904
|
|
@ -1,3 +1,5 @@
|
|||
|
||||
|
||||
# YouQu
|
||||
|
||||
> YouQu, a simple and powerful autotest framework.
|
||||
|
|
@ -7,6 +9,8 @@
|
|||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
[](https://pepy.tech/project/youqu)
|
||||
[](https://pepy.tech/project/youqu)
|
||||
|
|
@ -54,7 +58,7 @@ youqu manage.py run
|
|||
|
||||
## Documentations
|
||||
|
||||
- [Documents](https://mikigo.github.io/youqu-docs/)
|
||||
- [Documents](https://linuxdeepin.github.io/deepin-autotest-framework/)
|
||||
|
||||
## Getting help
|
||||
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
|
||||
|
||||
# 有趣
|
||||
|
||||
> 有趣，是一个使用简单且功能强大的自动化测试基础框架。
|
||||
|
|
@ -7,6 +9,8 @@
|
|||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
[](https://pepy.tech/project/youqu)
|
||||
[](https://pepy.tech/project/youqu)
|
||||
|
|
@ -54,7 +58,7 @@ youqu manage.py run
|
|||
|
||||
## 文档
|
||||
|
||||
- [文档](https://mikigo.github.io/youqu-docs/)
|
||||
- [文档](https://linuxdeepin.github.io/deepin-autotest-framework/)
|
||||
|
||||
## 帮助
|
||||
|
||||
|
|
|
|||
|
|
@ -464,7 +464,10 @@ def pytest_collection_modifyitems(session):
|
|||
|
||||
if session.config.option.autostart:
|
||||
for item in session.items[::-1]:
|
||||
if letmego.read_testcase_running_status(item):
|
||||
_reruns = None
|
||||
if hasattr(session.config.option, "reruns"):
|
||||
_reruns = session.config.option.reruns
|
||||
if letmego.read_testcase_running_status(item, reruns=_reruns):
|
||||
session.items.remove(item)
|
||||
|
||||
if (suite_id or task_id) and session.items:
|
||||
|
|
@ -540,6 +543,9 @@ def pytest_collection_finish(session):
|
|||
|
||||
def pytest_runtest_setup(item):
|
||||
"""pytest_runtest_setup"""
|
||||
if hasattr(item, "execution_count"):
|
||||
letmego.conf.setting.EXECUTION_COUNT = item.execution_count
|
||||
|
||||
print() # 处理首行日志换行的问题
|
||||
current_item_count = (
|
||||
f"[{item.session.items.index(item) + 1}/{item.session.item_count}]"
|
||||
|
|
|
|||
|
|
@ -44,11 +44,11 @@
|
|||
|
||||
整体的框架设计在《自动化测试架构设计》文档里面已经有详细描述了，这里贴一下整体的架构图：
|
||||
|
||||
|
||||
|
||||
|
||||
为了突显本文的重点，抽取其中重要功能模块，如下图：
|
||||
|
||||
|
||||
|
||||
|
||||
### 3、目录结构
|
||||
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ AT 应用库改造是基于自动化测试基础框架进行用例方法和业
|
|||
|
||||
整体仍然遵循 PO 设计理念，根据业务需要，将文管业务层进行 3 层划分：
|
||||
|
||||
|
||||
|
||||
|
||||
### 2、目录结构
|
||||
|
||||
|
|
@ -85,11 +85,11 @@ class BaseWidget(Src):
|
|||
|
||||
右键菜单：暂时不考虑为单独的模块，考虑以图像识别的定位方案做成公共库。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
- 各个模块只继承基类
|
||||
|
||||
|
|
|
|||
|
|
@ -233,7 +233,7 @@ class TestMusic(BaseCase):
|
|||
|
||||
举例，`PMS` 用例：
|
||||
|
||||
|
||||
|
||||
|
||||
直接选中用例内容，复制下来，然后粘贴到自动化用例脚本中：
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
comments: true
|
||||
|
||||
|
||||
|
||||
有趣（YouQu）
|
||||
================
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
|
||||
|
||||
|
||||
# 智能化功能测试
|
||||
|
||||
|
|
@ -413,7 +413,7 @@ python3 run.py
|
|||
python3 -m serial.tools.list_ports -v
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
（2）修改串口的权限
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
|
||||
|
||||
|
||||
# 智能化性能测试
|
||||
|
||||
|
|
@ -416,7 +416,7 @@ apps
|
|||
|
||||
## 五、测试流程
|
||||
|
||||
|
||||
|
||||
|
||||
## 六、用例编写及方法参数指引
|
||||
|
||||
|
|
@ -717,7 +717,7 @@ usb_mk.drag_rel(100, 200) # 鼠标向左边移动100个像素，向下移动20
|
|||
|
||||
https://item.taobao.com/item.htm?spm=a1z09.2.0.0.41d72e8dUYx2pi&id=582653718178&_u=i25r20ia6a2e
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
@ -725,19 +725,19 @@ https://item.taobao.com/item.htm?spm=a1z09.2.0.0.41d72e8dUYx2pi&id=582653718178&
|
|||
|
||||
普通的 `USB` 线即可。
|
||||
|
||||
|
||||
|
||||
|
||||
### 3、杜邦线
|
||||
|
||||
3.1、`40P` 母对公杜邦线。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
3.2、一母二公杜邦线。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
@ -745,23 +745,23 @@ https://item.taobao.com/item.htm?spm=a1z09.2.0.0.41d72e8dUYx2pi&id=582653718178&
|
|||
|
||||
4.1、使用 `USB` 延长线连接控制端和继电器。
|
||||
|
||||
|
||||
|
||||
|
||||
4.2、在继电器常端和公共端均连接一根杜邦线。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
4.3、在主板上开机针和重启针上插上一母二公杜邦线。
|
||||
|
||||
|
||||
|
||||
|
||||
4.4、将开机针外接的一母二公杜邦线的两根公线分别接入继电器的1路继电器（如图 1左侧继电器）和原电源开关。
|
||||
|
||||
4.5、将重启针外接的一母二公杜邦线的两根公线分别接入继电器的2路继电器（如图 1 右侧继电器）和原电源开关。
|
||||
|
||||
|
||||
|
||||
|
||||
若想保留原电源开关的电源灯，可根据如上图所示，使用杜邦线连接主板上的电源灯和原电源开关
|
||||
|
||||
|
|
@ -781,7 +781,7 @@ https://item.taobao.com/item.htm?spm=a1z09.2.0.0.41d72e8dUYx2pi&id=582653718178&
|
|||
sudo docker container ls # 列出运行中的 Docker 容器
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
2）缺少 uos 容器，检查 USB 串口连接线和采集盒连接线是否正常，重启后执行
|
||||
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@
|
|||
|
||||
在元素识别的过程中，我们需要截取某个元素的小图进行识别，比如截取播放按钮：
|
||||
|
||||
|
||||
|
||||
|
||||
那么实际上，元素定位的问题就转换为，将截图的小图（play_btn）拿到整个屏幕的大图（screen）中去做匹配，如果匹配成功，返回小图在大图中的坐标（ x, y ）即可。
|
||||
|
||||
|
|
@ -146,7 +146,7 @@ def find_image(
|
|||
|
||||
气泡识别指的是，某些场景下要定位的元素是一些会消失的小弹窗，这类场景在用例执行过程中进行图像识别时就可能存在不稳定性，有可能图像识别的时候气泡已经消失了，也有可能气泡出现的时间太短了，不容易捕捉到，就像气泡一样，出现一下就消失，因此我们形象的称之为 “气泡识别”；
|
||||
|
||||
|
||||
|
||||
|
||||
【原理实现】
|
||||
|
||||
|
|
@ -154,7 +154,7 @@ def find_image(
|
|||
|
||||
在一段时间内（包含气泡从出现到消失），不停的截取这段时间内的大图，以此确保在截取的一堆图片中，肯定有至少一张图片能捕捉到气泡，最后再对这一堆图片逐个进行图像识别；
|
||||
|
||||
|
||||
|
||||
|
||||
代码示例：
|
||||
|
||||
|
|
@ -198,7 +198,7 @@ def get_during(
|
|||
|
||||
为了实现识别图像的目的，我们可以通过将图片的每个像素的RGB值，与整个屏幕中的RGB进行对比，如果小图上的RGB值与对应大图位置的RGB都相等，则匹配成功，即可返回小图在大图中的中心坐标点。
|
||||
|
||||
|
||||
|
||||
|
||||
1、读取小图和大图的RGB值
|
||||
|
||||
|
|
@ -219,23 +219,23 @@ big_data = big_pic.load()
|
|||
|
||||
（1）匹配从大图的坐标（0，0）开始匹配，匹配小图里面所有的坐标点（0，0）—（small_pic.width，small_pic.height）；
|
||||
|
||||
|
||||
|
||||
|
||||
（2）如果在大图的（0，0）对应的所有小图的RGB值不相等，则移动到下一个坐标点（1，0），同样匹配小图里面所有的坐标点（0，0）—（small_pic.width，small_pic.height）；
|
||||
|
||||
|
||||
|
||||
|
||||
（3）按照这样的规律将这一行每移动一个坐标点，都将小图所有的RGB与对应大图的值进行匹配；
|
||||
|
||||
|
||||
|
||||
|
||||
（4）如果在大图的其中一个坐标点上匹配到了小图的所有RGB值，则此时返回小图在大图中的坐标点；
|
||||
|
||||
|
||||
|
||||
|
||||
（5）如果匹配了大图所有的坐标点，都没有匹配到，则说明大图中不存在小图，匹配失败；
|
||||
|
||||
|
||||
|
||||
|
||||
【代码实现】
|
||||
|
||||
|
|
@ -294,7 +294,7 @@ class ImageRgb:
|
|||
|
||||
测试机截取当前屏幕图片以及模板图片，发送给 RPC 服务端，服务端拿到两张图片进行图像识别，最后将识别结果返回给测试机；
|
||||
|
||||
|
||||
|
||||
|
||||
要特殊说明的是： RPC 是一种协议，许多语言都是支持的，比如说服务端也可以用 C++ 来实现，客户端使用 Python 也是可以调用的。
|
||||
|
||||
|
|
@ -381,15 +381,15 @@ except OSError as exc:
|
|||
|
||||
在右键菜单呼出来之后，通过键盘的 `up`、`down` 按键，进行选择菜单选择，选中目标之后 `enter` 即可；比如：在桌面点击右键菜单之后，按 1 次 `down` ，会出现下图：
|
||||
|
||||
|
||||
|
||||
|
||||
继续再按 2 次 `down`，会出现这样：
|
||||
|
||||
|
||||
|
||||
|
||||
再按 `enter`，会出现这样：
|
||||
|
||||
|
||||
|
||||
|
||||
如此，“排序方式”的步长为 3；通过使用键盘上下键，就实现了对右键菜单的操作；
|
||||
|
||||
|
|
@ -401,7 +401,7 @@ except OSError as exc:
|
|||
|
||||
把每个菜单选项单独截图保存，图片中仅包含一个菜单选项，如下图所示：
|
||||
|
||||
|
||||
|
||||
|
||||
这样，每个菜单选项就可以通过图像识别的方式进行元素定位；
|
||||
|
||||
|
|
@ -411,7 +411,7 @@ except OSError as exc:
|
|||
|
||||
鼠标点击右键的时候，鼠标的当前坐标是可以获取到的，菜单选项的宽（ w ）一般是固定的，变化的是菜单的长度（ h ），可以通过某个选项相对于鼠标的距离在确定菜单选项的坐标，如下图所示：
|
||||
|
||||
|
||||
|
||||
|
||||
通过维护菜单选项（相对位置）相对于鼠标位置的距离，即可轻松计算出菜单选项在屏幕中的坐标。
|
||||
|
||||
|
|
@ -438,7 +438,7 @@ except OSError as exc:
|
|||
|
||||
使用 OCR 识别右键菜单虽然已经很完美了，但是在一些情况下仍然存在一点问题，就是屏幕中出现多个和菜单选项文字相同的文字时，比如下面这种情况：
|
||||
|
||||
|
||||
|
||||
|
||||
屏幕恰好出现了两个“复制”，此时要定位到菜单中的 “复制”，就需要进一步做数据处理，比如：OCR 返回 2 个“复制”的坐标，用例里面来判断用哪个，从业务上将处理起来比较麻烦，因为你得明确知道菜单在左边还是右边，然后这本身就是不确定的；
|
||||
|
||||
|
|
@ -448,13 +448,13 @@ except OSError as exc:
|
|||
|
||||
在点击右键菜单之前截一张图，点击右键菜单之后再截取一张图，两张图唯一变化的就是右键菜单，将其他相同的地方都屏蔽掉，只留下菜单界面，如此即可消除干扰，如下图所示：
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
将两种图做前后对比提取可以得到这样的图：
|
||||
|
||||
|
||||
|
||||
|
||||
你看，通过前后图片的对比，将相同的部分给消除掉，再进行 OCR 识别，这样就不会有干扰了；
|
||||
|
||||
|
|
@ -497,11 +497,11 @@ action = (
|
|||
|
||||
示意图：
|
||||
|
||||
|
||||
|
||||
|
||||
这样，我们截取了当前图片中比较有代表性的位置（一只鸟），在切换图片之后再用这张小图在当前屏幕中进行图像识别：
|
||||
|
||||
|
||||
|
||||
|
||||
我们再拿着这张小图在当前屏幕中进行图像识别，这样在当前图片中，就不能找到这只鸟了，图像识别的结果是 False，那么也就可以判断图片切换是成功的。
|
||||
|
||||
|
|
@ -523,7 +523,7 @@ def save_temporary_picture(_x: int, _y: int, width: int, height: int):
|
|||
|
||||
代码示例：
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
@ -539,13 +539,13 @@ def save_temporary_picture(_x: int, _y: int, width: int, height: int):
|
|||
|
||||
在 UI 设计图中我们是可以获取到元素按钮相对于应用边框的距离的，然后我们可以通过技术手段获取到应用界面在当前屏幕中的位置及应用窗口的大小，示意图如下：
|
||||
|
||||
|
||||
|
||||
|
||||
`（x1, y1）`为应用左上角相对于屏幕左上角（0, 0）的位置；`（x2, y2）`是按钮【播放所有】的左上角相对于应用窗口左上角`（x1, y1）`的坐标，那么实际上【播放所有】左上角相对于屏幕左上角（0, 0）的位置为：`（ x1 + x2, y1 + y2 ）`；
|
||||
|
||||
是按钮【播放所有】的大小（w2, h2），可以从 UI 设计图上获取；
|
||||
|
||||
|
||||
|
||||
|
||||
在 UI 设计稿上点击【播放所有】图标，然后移动鼠标就就可以看到上图的参考线及数据；
|
||||
|
||||
|
|
@ -645,7 +645,7 @@ def click_add_music_list_btn_in_music_by_ui(self):
|
|||
|
||||
RPC 的调用逻辑：
|
||||
|
||||
|
||||
|
||||
|
||||
这样我们只需要在服务端部署好 OCR 识别的服务，然后通过 RPC 服务将功能提供出来，框架里面只需要调用对应的 RPC 接口就行了。
|
||||
|
||||
|
|
@ -858,7 +858,7 @@ sudo systemctl status ocr.service
|
|||
|
||||
Linux 桌面应用大多是采用 Qt 编写的，在 Qt 中也是从最顶层的 `MainWindow` 开始构建应用，所以逻辑也是一样的，Qt 应用的自动化测试同样可以通过 DOM 树（属性树）进行元素定位，我们称之为**属性定位**。
|
||||
|
||||
|
||||
|
||||
|
||||
借助开源工具 `dogtail` 我们可以对元素进行获取，从而进行定位操作。`dogtail` 的项目介绍可以[猛戳这里](https://gitlab.com/dogtail/dogtail/)。
|
||||
|
||||
|
|
@ -872,7 +872,7 @@ Linux 桌面应用大多是采用 Qt 编写的，在 Qt 中也是从最顶层的
|
|||
mikigo@mikigo-PC:~$ sniff
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
**查看应用的标签**
|
||||
|
||||
|
|
@ -882,15 +882,15 @@ mikigo@mikigo-PC:~$ sniff
|
|||
|
||||
首先，为了方便查看元素控件对应的位置，建议现在上方工具栏点击 `Actions`，然后勾选 `Hightlight Items`，这样在 sniff 中鼠标选中元素标签的时候，应用中会有相应的光标锁定。
|
||||
|
||||
|
||||
|
||||
|
||||
在 sniff 里面点击进入应用的标签 tree 中后，点击相应的元素控件，在工具下方，会展示元素控件的 `Name`，这个就是标签名称。
|
||||
|
||||
|
||||
|
||||
|
||||
在 tree 中有些地方是空白的或者是 Form，是因为开发人员在添加标签的时候没有添加，或者有些父窗口不需要添加，这种在实际业务中是不影响的，我们只要保证自动化测试用例中，要用到的元素都添加了标签即可。
|
||||
|
||||
|
||||
|
||||
|
||||
#### 2.2、元素操作
|
||||
|
||||
|
|
@ -1147,7 +1147,7 @@ python3 manage.py run --ifixed yes
|
|||
| :----: | :-----------------: | :-------------------: | :----------: | :------------: |
|
||||
| 001 | ... | skip-受到某新需求影响 | fixed-已修复 | removed-已废弃 |
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
@ -1481,7 +1481,7 @@ else:
|
|||
- 加入了失败录屏，你可以在 `html` 报告中直接看录制的视频；
|
||||
- 加入了 IP 地址、系统信息、镜像版本等；
|
||||
|
||||
|
||||
|
||||
|
||||
### 3. 查看报告
|
||||
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@
|
|||
|
||||
### 1、现有架构介绍
|
||||
|
||||
|
||||
|
||||
|
||||
现有自动化测试架构整体分为三层：用例层（业务逻辑层）、中间层（元素定位和操作方法层）、核心层（底层功能库层）。
|
||||
|
||||
|
|
@ -68,7 +68,7 @@
|
|||
|
||||
### 1、架构设计
|
||||
|
||||
|
||||
|
||||
|
||||
### 2、设计思路
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue