1. 每次运行前需要在img目录下新建input、output、output_tree目录(内容为空)
2. img目录下已有output_click目录,若无则需新建该目录,并在该目录下新建click.txt
3. 开始运行前必须把treegraph.py中parse_json函数中的项目路径修改为本地对应的绝对路径
4. 运行时前端图片每次必须清空数据
5. 运行结束后必须删除要求1中新建目录内的所有内容
1. 运行main,弹出前端页面
2. 运行main2
3. 点击上传图片,图片解析后弹出识别过程图,关闭过程图,图片节点自动添加到树图
4. 输入图片节点id,显示组件框图
5. 根据screen提示点击坐标click(x,y)确定组件,先清空GUI预览数据,再上传点击组件后的图片
6. 若点击组件后上传图片不变,根据提示点击下一个组件;若点击组件后上传图片改变,则进入下一个节点继续执行步骤4,或在合并组件后回到原节点;若点击组件后返回上一级节点,则根据提示点击回到原节点并选择下一组件。
7. 某一节点(即图片)组件全部遍历后,根据提示回到上一级节点,继续执行步骤4。
1.树图
以主屏幕界面图片为根节点,点击后新生成页面图片为子节点生成树图,用边连接,边持有两端节点属性。图中节点为图片,节点数字为id,边上显示属性为点击父节点图片能到达子节点的组件坐标。
- json
图像识别后返回该图片识别出的所有组件列表及组件属性,其中组件属性按顺序分别为:组件id、组件属性、组件最小列、组件最小行、组件最大列、组件最大行(这四项即为组件占据坐标)、组件宽度、组件高度。
3.jpg
图像识别后生成标注所有组件的框图
使用openCV+numpy库
i 屏幕识别
- 原图:
- 识别过程:
原图-高斯模糊-转灰度图-中值滤波-canny边缘检测-自适应阈值处理(使轮廓闭合)-提取轮廓
- 自适应阈值处理后的结果:
- 检测后的结果:
- 存在的问题:识别后的屏幕图片无法进行UI元素的识别,因此UI元素识别的图片为屏幕截图。
ii. UI元素识别
目前的目标识别主要使用了UIED库(GitHub - MulongXie/UIED: An accurate GUI element detection approach based on old-fashioned CV algorithms [Upgraded on 5/July/2021])。
UIED库的处理流程是:
1. 原图转灰度图再转二值图
2. 检测闭合轮廓,选择其中为矩形的
3. 结果处理,合并其中较小的矩形
4. 获得所有识别出元素的坐标,写入json文件,并在图中画出。
iii. 相似页面检测
流程:关键点检测-关键点匹配(使用汉明距离)-knn筛选匹配点。再由关键点计算相似度(0=<similarity<=1),将相似度>0.5的视为相似。
安装机械臂后,使用YamboomRobot与机械臂完成连接并进行初始化校准工作。
正常进行动作组执行后,机械臂舵机发生故障无法正常运转,扭矩处于关闭状态。在尝试远程连接打开总线舵机扭矩、按K1K2调整急停状态、重新设置舵机ID、烧录镜像等方式后仍无法运行,咨询客服认为涉及到底层单片机功能需要寄回检测调试。
于是我们仅了解了机械臂操作相关的API,并给出操作的处理思路。
控制6个总线舵机对对应的api为Arm_serial_servo_write6(S1, S2, S3, S4, S5, S6, time)。我们使用JupyterLab与机械臂进行远程连接,定义对应的move函数进行操作。在拍摄第一张图片后,机械臂首先进行识别定位,记忆屏幕左上角为原点位置(init_x, init_y),记忆屏幕长度height和宽度width。之后定义move(x, y),x和y为treegraph分析过程中产生的下一个点击位置相对于原点的长宽百分比,根据此百分比计算出机械臂在屏幕上的目标定位,映射到机械臂的六自由度控制,完成机械臂移动。
为了利用机械臂模拟真正用户对app的使用,我们未集成已有的侵入式GUI界面探索策略,而是将测试过程建模成一个个状态,利用机械臂对每个组件进行遍历操作,将页面跳转关系最终建模成树图,完成未知路径的探索,并支持已知路径的引导。
软件测试过程建模成4类对象:组件Compo、状态State、操作Action和树图TreeGraph,其中State、Action分别对应TreeGraph的Node和Edge。
1. Compo(x, y, height, width, is_used)
a. x, y, height, width:相对左上角原点(0, 0)的相对坐标和高宽,范围在(0, 1)之间,百分比保留三位小数。
b. is_used:bool值,默认False,记录该组件是否被机械臂操作。每个组件只能被操作一次。
2. State(screen_id, screenshot_path, compo_list)
a. screen_id:屏幕id,唯一标识屏幕,如10。
b. screenshot_path:屏幕的截图路径,保存在img/input路径下,如img/input/test10.jpg。
c. compo_list:屏幕所有可操作组件组成的列表。
3. Action(action_type, compo)
a. action_type:理论上是与机械臂操作类型一一对应的操作列表,如[click, input, roll, swipe....]。因本项目规模与时间有限,仅针对“点击”操作进行测试,故该字段定义为“click”字符串。
b. compo:存储本次操作的组件。
4. TreeGraph(graph)
a. graph=nx.MultiDiGraph(sub_graph=True):利用networkx库建立可以存储多边的有向图。
b. graph.add_node(new_state, id=new_state.screen_id):graph的结点类型为State,属性为'id'。
c. graph.add_edge(curr_state, new_state, action=curr_action):graph的边属性'action'类型为Action,连接两个State。
探索策略的基本思路是机械臂不断拍摄当前GUI界面的图片,通过目标识别算法识别所有可操作组件(存储为State的compo_list),机械臂通过DFS算法遍历操作组件,记录操作后的跳转界面,上传,如此往复获得该软件的状态转移图graph。具体流程见1.2运行步骤和项目视频,下面重点介绍DFS算法中的4种情况:
1. 点击compo后跳转的页面在树中
a. 界面没有变化等于curr_state:本项目树图不保存自循环,继续遍历curr_state组件。(对应dfs_wrapper的case1)
b. 界面有变化:
i. 是curr_state的子state:说明之前已有其他compo跳转到该界面,并且该界面探索已结束。故利用State.upt_compo_list方法合并组件,如将“朋”“友”“圈”合并为“朋友圈”大组件,并更新树图边的action属性,然后继续遍历curr_state组件。(对应dfs_wrapper的case2)
ii. 不是子state:说明形成环,并且该界面探索已结束。故只需要添加有向边,然后继续遍历curr_state组件。(对应dfs_wrapper的case3)
2. 点击compo后跳转的页面不在树中
a. 添加点和有向边,然后进入new_state遍历组件。(对应dfs_wrapper的case4)
最终我们可以得到1.3中的探索成果,注意经过软件特性和实验观察边都是双向的,所以绘制graph时uv之间的边其实均为v->u的action类型,但存储的edges中因为有向性不会被覆盖,u->v和v->u均有。
1. 坐标转换
为了实现机械臂所处的实际坐标与GUI应用所处的虚拟坐标转换,我们以百分比的形式解析并存储各组件坐标,过程如下:
1. 在探索前测量测试手机的实际宽高。
2. 利用parse_json(json_path)函数解析每个compo的相对坐标和宽高
3. 通过curr_action_info(curr_state, curr_action)函数获得当前compo的中心坐标百分比,可换算成实际坐标供机械臂点击。
2. 关键操作引导
虽然算法以未知路径探索为主体,但在case2、case3和compo_list全部遍历完毕时,我们需要利用已知路径信息引导机械臂到指定页面:
1. case3进入的界面探索已结束,需要返回curr_state。
2. case2进入的子界面探索已结束,需要返回curr_state。
3. 当curr_staate的compo_list全部遍历完毕时,需要返回父节点。
实现已知路径引导的函数为find_path(source_node, target_node),它利用nx.all_pairs_shortest_path(graph)库函数获得任意两点间的最短路径path[source_node][target_node],并利用image_recognition.is_similar函数跟踪用户上传的图片是否符合引导预期,若偏离则报错。
交互界面使用python的TKinter库进行实现。
分为左中右三个部分。
-
第一部分:GUI预览与图片上传。测试者可以点击上传图片,上传对应的屏幕GUI,点击清空数据将当前预览图片清空,但由于图片已进行上传,清空数据不影响后续树图执行,仅对当前GUI预览产生影响。(若使用机械臂进行操作,则同样使用定时捕捉图片信息更新的情况来获得机械臂拍摄的图片)
-
第二部分:实时操作指令与树图展示。实时捕捉click.txt信息的变更和树图的更新情况并进行展示。clicktxt中的信息指示了应当进行操作的屏幕和屏幕内点击位置。坐标(x,y)中的x代表相对于屏幕宽度的百分比(以屏幕左侧为起点),y代表相对于屏幕高度的百分比(以屏幕顶部为起点)。
-
第三部分:组件框图查询。该部分主要用于让测试者可以随时查询已经生成的识别后组件框图,用于方便定位或分析。在上方输入框内输入序号即可得到对应的组件框图(若未查找到对应图片则无显示)
交互界面形成后的展示效果如下。相关代码主要位于tkinterGUI.py中,使用main.py启动。
- treegraph中调用img_rec is_similar
img_rec()与is_similar()均为图像识别类image_recognition.py中的函数,其作用分别为图像识别与判断两图片是否相同,treegraph类通过from image_recognition import img_rec, is_similar调用函数,执行相关操作。
- treegraph中的get_newest_img_path,get_upload
前端上传图片后,图片会通过tkinterGUI中的方法存入img目录下的input目录中,treegraph中的get_newest_img_path()函数可通过时间戳判断目录下最新添加的文件,并返回该最新文件,get_upload()调用该函数并赋值返回,即获取到前端上传的最新截图。
- tkinterGUI中的交互
由于TKinter运行时使用mainloop陷入主循环,无法调用其他函数,因此使用了Tk类提供的after方法,在每个规定时间间隔后执行update函数。识别clicktxt和output_tree中的更新内容并显示到GUI界面。
由于时间、规模和能力限制,本项目存在以下不足:
-
未使用机械臂进行操作:因为机械臂损坏的问题,我们用人为操作代替,加入了“显示组件框图”作为辅助。但目前的建模(如坐标以百分比表示)是完全可以支持机械臂自主探索的。
-
目标识别在识别屏幕后无法进行UI元素的识别:暂时使用屏幕截图代替。
-
操作类型只有click,未定义组件类型:项目初期我们计划使用机器学习算法识别组件类型,如[button, input],但因算法效果不佳停滞。操作本来计划参考RoScript设置[click, swipt, input]多种类型,并与组件类型对应,但因开销较大(仅有click就需要处理上千张输入图片),技术难度大(input用机械臂较难)停滞。
-
在进行已有树图的引导时未处理偏移:目前find_path函数跟踪到用户偏离后,未重新规划路线,而是直接报错。这与探索阶段树图构建不完整、算法复杂度增大均有关联。
这些不足是项目未来的发展方向,我们期望用更丰富的知识储备进行优化。