From e39a614dd555e0eca9c4e72f04f2a759d23c46d7 Mon Sep 17 00:00:00 2001 From: mikigo Date: Thu, 31 Aug 2023 17:11:25 +0800 Subject: [PATCH] Deployed c7f13e4 with MkDocs version: 1.5.2 --- .../index.html" | 4 +- .../index.html" | 8 +-- .../index.html" | 2 +- index.html | 2 +- sitemap.xml.gz | Bin 127 -> 127 bytes .../index.html" | 4 +- .../index.html" | 22 +++--- .../index.html" | 64 +++++++++--------- .../index.html" | 4 +- 9 files changed, 55 insertions(+), 55 deletions(-) diff --git "a/AT\345\237\272\347\241\200\346\241\206\346\236\266\350\256\276\350\256\241\346\226\271\346\241\210/index.html" "b/AT\345\237\272\347\241\200\346\241\206\346\236\266\350\256\276\350\256\241\346\226\271\346\241\210/index.html" index 6c13fa0f..bf38e341 100644 --- "a/AT\345\237\272\347\241\200\346\241\206\346\236\266\350\256\276\350\256\241\346\226\271\346\241\210/index.html" +++ "b/AT\345\237\272\347\241\200\346\241\206\346\236\266\350\256\276\350\256\241\346\226\271\346\241\210/index.html" @@ -950,9 +950,9 @@

1、统一概念2、架构图

整体的框架设计在《自动化测试架构设计》文档里面已经有详细描述了，这里贴一下整体的架构图：

-

+

为了突显本文的重点，抽取其中重要功能模块，如下图：

-

+

3、目录结构

autotest-basic-frame  # 自动化测试基础框架
 ├── apps  # 应用库
diff --git "a/AT\345\272\224\347\224\250\345\272\223\350\256\276\350\256\241\346\226\271\346\241\210/index.html" "b/AT\345\272\224\347\224\250\345\272\223\350\256\276\350\256\241\346\226\271\346\241\210/index.html"
index 15812070..d56fec19 100644
--- "a/AT\345\272\224\347\224\250\345\272\223\350\256\276\350\256\241\346\226\271\346\241\210/index.html"
+++ "b/AT\345\272\224\347\224\250\345\272\223\350\256\276\350\256\241\346\226\271\346\241\210/index.html"
@@ -857,7 +857,7 @@ 
二、方案设计1、分层设计图

 
整体仍然遵循 PO 设计理念，根据业务需要，将文管业务层进行 3 层划分：

-

+

 
2、目录结构

 
autotest-dde-file-manager  # 应用仓库
 ├── case  # 用例
@@ -911,9 +911,9 @@ 
2、操作层

-

-

+

+

+

 
    
 
  • 各个模块只继承基类
    • 
 

diff --git "a/AT\345\274\200\345\217\221\350\247\204\350\214\203/index.html" "b/AT\345\274\200\345\217\221\350\247\204\350\214\203/index.html"
index c7b337f7..3cd64cd4 100644
--- "a/AT\345\274\200\345\217\221\350\247\204\350\214\203/index.html"
+++ "b/AT\345\274\200\345\217\221\350\247\204\350\214\203/index.html"
@@ -759,7 +759,7 @@ 
2. 用例函数规范

+

 
直接选中用例内容，复制下来，然后粘贴到自动化用例脚本中：

 
class TestMusic(BaseCase):
     """音乐用例"""
diff --git a/index.html b/index.html
index f1848e68..0892048b 100644
--- a/index.html
+++ b/index.html
@@ -866,7 +866,7 @@
   
 
 
-

+

 
有趣（YouQu）

 
# =============================================
 # Attribution : Chengdu Test Department
diff --git a/sitemap.xml.gz b/sitemap.xml.gz
index 44adf4a155abf8ed791f98e796f8b091eb3fec47..8ffaebc15a65973fb20bad12fae1cda842f2b2db 100644
GIT binary patch
delta 12
Tcmb=gXOr*d;INIH$W{pe7F7df

delta 12
Tcmb=gXOr*d;8>+Mk*yK{7s>;t

diff --git "a/\346\231\272\350\203\275\345\214\226\345\212\237\350\203\275\346\265\213\350\257\225/index.html" "b/\346\231\272\350\203\275\345\214\226\345\212\237\350\203\275\346\265\213\350\257\225/index.html"
index 7bd5ca98..25f669d5 100644
--- "a/\346\231\272\350\203\275\345\214\226\345\212\237\350\203\275\346\265\213\350\257\225/index.html"
+++ "b/\346\231\272\350\203\275\345\214\226\345\212\237\350\203\275\346\265\213\350\257\225/index.html"
@@ -1210,7 +1210,7 @@
   
 
 
-

+

 
智能化功能测试

 
# Attribution ：chengdu Test Team
 # Date        ：2021/08/20
@@ -1469,7 +1469,7 @@ 
六、USB_MK串口驱动方法
python3 -m serial.tools.list_ports -v
 

-

+

 
（2）修改串口的权限

 
sudo chmod 777 /dev/ttyACM0
 

diff --git "a/\346\231\272\350\203\275\345\214\226\346\200\247\350\203\275\346\265\213\350\257\225/index.html" "b/\346\231\272\350\203\275\345\214\226\346\200\247\350\203\275\346\265\213\350\257\225/index.html"
index b4371780..cdf9ccde 100644
--- "a/\346\231\272\350\203\275\345\214\226\346\200\247\350\203\275\346\265\213\350\257\225/index.html"
+++ "b/\346\231\272\350\203\275\345\214\226\346\200\247\350\203\275\346\265\213\350\257\225/index.html"
@@ -1140,7 +1140,7 @@
   
 
 
-

+

 
智能化性能测试

 
# =============================================
 # Attribution : Application Test Department III
@@ -1516,7 +1516,7 @@ 
3、场景个性化配置}
 

 
五、测试流程

-

+

 
六、用例编写及方法参数指引

 
1、用例实例说明

 
# 标准库导入
@@ -1730,25 +1730,25 @@ 
十、继电器控制主机开机/重启1、继电器设备

 
LCUS-2 型 双路 USB 智能串口控制继电器。

 
https://item.taobao.com/item.htm?spm=a1z09.2.0.0.41d72e8dUYx2pi&id=582653718178&_u=i25r20ia6a2e

-

+

 
2、USB 延长线

 
普通的 USB 线即可。

-

+

 
3、杜邦线

 
3.1、40P 母对公杜邦线。

-

+

 
3.2、一母二公杜邦线。

-

+

 
4、安装图文教程

 
4.1、使用 USB 延长线连接控制端和继电器。

-

+

 
4.2、在继电器常端和公共端均连接一根杜邦线。

-

+

 
4.3、在主板上开机针和重启针上插上一母二公杜邦线。

-

+

 
4.4、将开机针外接的一母二公杜邦线的两根公线分别接入继电器的1路继电器（如图 1左侧继电器）和原电源开关。

 
4.5、将重启针外接的一母二公杜邦线的两根公线分别接入继电器的2路继电器（如图 1 右侧继电器）和原电源开关。

-

+

 
若想保留原电源开关的电源灯，可根据如上图所示，使用杜邦线连接主板上的电源灯和原电源开关

 
十一、常见问题说明

 
1、ERROR: for uos  Cannot restart container 2301b1a1395d7959ee6523d61b61c87084649af530786cdb8fb5b3ecbcbd1068: linux runtime spec devices: error gathering device information while adding custom device "/dev/ttyACM0": no such file or directory

@@ -1758,7 +1758,7 @@ 
十一、常见问题说明1）检查哪一个容器未启动

 
sudo docker container ls # 列出运行中的 Docker 容器
 

-

+

 
2）缺少 uos 容器，检查 USB 串口连接线和采集盒连接线是否正常，重启后执行 

 
bash install/setup.up # 重新完整部署环境
 

diff --git "a/\346\241\206\346\236\266\345\212\237\350\203\275\344\273\213\347\273\215/index.html" "b/\346\241\206\346\236\266\345\212\237\350\203\275\344\273\213\347\273\215/index.html"
index 63b20a41..121b4507 100644
--- "a/\346\241\206\346\236\266\345\212\237\350\203\275\344\273\213\347\273\215/index.html"
+++ "b/\346\241\206\346\236\266\345\212\237\350\203\275\344\273\213\347\273\215/index.html"
@@ -1910,7 +1910,7 @@ 
1、常规识别

+

 
那么实际上，元素定位的问题就转换为，将截图的小图（play_btn）拿到整个屏幕的大图（screen）中去做匹配，如果匹配成功，返回小图在大图中的坐标（ x,  y ）即可。

 
为了方便描述，以下我将整个屏幕的截图称为：大图，某个元素图片的截图称为：小图。

 
基于 OpenCV 的模板匹配 cv.matchTemplate() 功能，我们实现了图像定位的功能，框架提供了一个图像识别的底层接口（一般不对上层提供调用）：

@@ -1999,11 +1999,11 @@ 
1、常规识别2、气泡识别

 
【背景】

 
气泡识别指的是，某些场景下要定位的元素是一些会消失的小弹窗，这类场景在用例执行过程中进行图像识别时就可能存在不稳定性，有可能图像识别的时候气泡已经消失了，也有可能气泡出现的时间太短了，不容易捕捉到，就像气泡一样，出现一下就消失，因此我们形象的称之为 “气泡识别”；

-

+

 
【原理实现】

 
为了能稳定的识别气泡类场景，我们采用的方案是：

 
在一段时间内（包含气泡从出现到消失），不停的截取这段时间内的大图，以此确保在截取的一堆图片中，肯定有至少一张图片能捕捉到气泡，最后再对这一堆图片逐个进行图像识别；

-

+

 
代码示例：

 
def get_during(
         cls,
@@ -2032,7 +2032,7 @@ 
3、不依赖 OpenCV 的图像识别方案3.1、自研图像识别技术

 
【原理】

 
为了实现识别图像的目的，我们可以通过将图片的每个像素的RGB值，与整个屏幕中的RGB进行对比，如果小图上的RGB值与对应大图位置的RGB都相等，则匹配成功，即可返回小图在大图中的中心坐标点。

-

+

 
1、读取小图和大图的RGB值

 
（1）小图的RGB值

 
small_data = small_pic.load() 
@@ -2043,15 +2043,15 @@ 
3.1、自研图像识别技术

 
2、将小图与大图的RGB值进行匹配

 
（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）如果匹配了大图所有的坐标点，都没有匹配到，则说明大图中不存在小图，匹配失败；

-

+

 
【代码实现】

 
class ImageRgb:
 
@@ -2098,7 +2098,7 @@ 
3.2、基于 RPC 服务实现图像识别在远程服务器上部署 OpenCV 的环境，并将其部署为 RPC 服务，测试机上不用安装 OpenCV 依赖，而是通过请求 RPC 服务的方式进行图像识别；

 
【原理】

 
测试机截取当前屏幕图片以及模板图片，发送给 RPC 服务端，服务端拿到两张图片进行图像识别，最后将识别结果返回给测试机；

-

+

 
要特殊说明的是： RPC 是一种协议，许多语言都是支持的，比如说服务端也可以用 C++ 来实现，客户端使用 Python 也是可以调用的。

 
【代码实现】

 
服务端代码示意（Service）：

@@ -2167,22 +2167,22 @@ 
4.1、右键菜单定位的方案及问题右键菜单的元素定位是一个难点，过去我们调研和使用过的元素定位操作方法有 4 种：

 
第一种：步长操作法

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

-

+

 
继续再按 2 次 down，会出现这样：

-

+

 
再按 enter，会出现这样：

-

+

 
如此，“排序方式”的步长为 3；通过使用键盘上下键，就实现了对右键菜单的操作；

 
但是，这种方式有个很烦人的问题，就是右键菜单的选项位置不可能一直不变，在需求迭代的过程中，菜单选项的变化是很大的，甚至有些应用支持自定义菜单，比如文管右键菜单可以自定义；

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

 
第二种：常规图像识别法

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

-

+

 
这样，每个菜单选项就可以通过图像识别的方式进行元素定位；

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

 
第三种：相对位移法

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

-

+

 
通过维护菜单选项（相对位置）相对于鼠标位置的距离，即可轻松计算出菜单选项在屏幕中的坐标。

 
从理论上此方案是可行的，但是这里仍然存在两个严重的问题：