终端控件测试方法及装置与流程

本发明涉及到计算机技术领域，特别涉及到终端控件测试方法及装置。

背景技术：

随着互联网高速发展，智能手机操作系统主要为Android和iOS，为了保证终端发布时的数据，需要提前对终端进行测试，然而，跨平台(Android系统平台和iOS系统平台)应用测试在技术和人力上均面临较大的压力，特别是Android系统的碎片化加大了各公司测试团队对终端测试的难度。目前，可以采取人工实现的回归测试来实现终端的测试过程，然而，现有的终端测试方式无法实现全自动化的遍历，来识别出终端的控件对控件进行测试，导致终端测试方式智能化程度低。

技术实现要素：

本发明实施例提供一种终端控件测试方法及装置，旨在解决现有的终端测试方式无法实现全自动化的遍历，来识别出终端的控件对控件进行测试，导致终端测试方式智能化程度低的问题。

为实现上述目的，本发明实施例提出一种终端控件测试方法，包括：

遍历预先建立的控件交互界面图表数据模型的节点和边得到所有可点击控件作为待测试控件；

获取当前上下文状态，并基于所述上下文状态确定测试页面的返回路径；

根据所述返回路径返回测试页面，并在所述测试页面对所述待测试控件进行测试。

为了实现上述目的，本发明实施例还进一步提出一种终端控件测试装置，包括：

遍历模块，用于遍历预先建立的控件交互界面图表数据模型的节点和边 得到所有可点击控件作为待测试控件；

获取模块，用于获取当前上下文状态；

确定模块，用于基于所述上下文状态确定测试页面的返回路径；

返回模块，用于根据所述返回路径返回测试页面；

测试模块，用于在所述测试页面对所述待测试控件进行测试。

本发明基于提前建立的图表数据模型的节点和边的遍历得到待测试页面，获取上下文状态确定测试页面的返回路径，完成对终端的测试操作，实现自动化全路径遍历。实现全自动化的遍历来识别出终端的控件对控件进行测试，提高了终端测试的智能化程度。

附图说明

图1为本发明实施例终端控件测试装置所涉及的硬件架构示意图；

图2为本发明终端控件测试方法的第一实施例的流程示意图；

图3为本发明遍历预先建立的控件交互界面图表数据模型的节点和边得到所有可点击控件作为待测试控件一实施例的流程示意图；

图4为本发明基于所述上下文状态确定测试页面的返回路径一实施例的流程示意图；

图5为本发明根据所述返回路径返回测试页面，并在所述测试页面对所述待测试控件进行测试一实施例的流程示意图；

图6为本发明终端控件测试方法的第二实施例的流程示意图；

图7为本发明终端控件测试装置的第一实施例的功能模块示意图；

图8为图7中遍历模块一实施例的细化功能模块示意图；

图9为图7中确定模块一实施例的细化功能模块示意图；

图10为图9中判断单元一实施例的细化功能模块示意图；

图11为图7中测试模块一实施例的细化功能模块示意图；

图12为本发明终端控件测试装置的第二实施例的功能模块示意图。

本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

本发明实施例的主要解决方案是：遍历预先建立的控件交互界面图表数据模型的节点和边得到所有可点击控件作为待测试控件；获取当前上下文状态，并基于所述上下文状态确定测试页面的返回路径；根据所述返回路径返回测试页面，并在所述测试页面对所述待测试控件进行测试。基于提前建立的图表数据模型的节点和边的遍历得到待测试页面，获取上下文状态确定测试页面的返回路径，完成对终端的测试操作，实现自动化全路径遍历。有效避免现有的终端测试方式无法实现全自动化的遍历，来识别出终端的控件对控件进行测试，导致终端测试方式智能化程度低问题。实现全自动化的遍历来识别出终端的控件对控件进行测试，提高了终端测试的智能化程度。

由于现有的终端测试方式无法实现全自动化的遍历，来识别出终端的控件对控件进行测试，导致终端测试方式智能化程度低问题。

本发明实施例架构一终端控件测试装置，该终端控件测试装置基于提前建立的图表数据模型的节点和边的遍历得到待测试页面，获取上下文状态确定测试页面的返回路径，完成对终端的测试操作，实现自动化全路径遍历。有效避免现有的终端测试方式无法实现全自动化的遍历，来识别出终端的控件对控件进行测试，导致终端测试方式智能化程度低问题。实现全自动化的遍历来识别出终端的控件对控件进行测试，提高了终端测试的智能化程度。

其中，本实施例终端控件测试装置可以承载于PC端，也可以承载于手机、平板电脑等电子终端。该终端控件测试装置所涉及的硬件架构可以如图1所示。

图1示出了本发明实施例终端控件测试装置所涉及的硬件架构。如图1所示，所述终端控件测试装置所涉及的硬件包括：处理器301，例如CPU，网络接口304，用户接口303，存储器305，通信总线302。其中，通信总线302用于实现该信息推送平台中各组成部件之间的连接通信。用户接口303可以包括显示屏(Display)、键盘(Keyboard)、鼠标等组件，用于接收用户输入的信息， 并将接收的信息发送至处理器305进行处理。显示屏可以为LCD显示屏、LED显示屏，也可以为触摸屏，用于显示终端控件测试装置需要显示的数据，例如显示图表数据模型、终端控件测试等操作界面。可选用户接口303还可以包括标准的有线接口、无线接口。网络接口304可选的可以包括标准的有线接口、无线接口(如Wi-Fi接口)。存储器305可以是高速RAM存储器，也可以是非易失性存储器(non-volatile memory)，例如磁盘存储器。存储器305可选的还可以是独立于前述处理器301的存储装置。如图1所示，作为一种计算机存储介质的存储器305中可以包括操作系统、网络通信模块、用户接口模块以及终端控件测试程序。

在图1所示的终端控件测试装置所涉及的硬件中，网络接口304主要用于连接应用平台，与应用平台进行数据通信；用户接口303主要用于连接客户端，与客户端进行数据通信，接收客户端输入的信息和指令；而处理器301可以用于调用存储器305中存储的终端控件测试程序，并执行以下操作：

遍历预先建立的控件交互界面图表数据模型的节点和边得到所有可点击控件作为待测试控件；

获取当前上下文状态，基于所述上下文状态确定测试页面的返回路径；

根据所述返回路径返回测试页面，在所述测试页面对所述待测试控件进行测试。

进一步地，在一个实施例中，处理器301调用存储器305中存储的终端控件测试程序可以执行以下操作：

遍历预先建立的控件交互界面图表数据模型的节点和边得到所有可点击控件；

对所有可点击控件进行过滤，过滤掉重复位置和可调焦属性为是的控件得到过滤后的控件作为待测试控件。

进一步地，在一个实施例中，处理器301调用存储器305中存储的终端控件测试程序可以执行以下操作：

在接收到控件点击操作后，通过上下文状态判断点击操作是否跳转至其他应用；

若是，则判断是否跳转至其他交互界面；

若是，则通过页面标记语言和页面源码判断是否跳转到同一交互界面的 其他布局中；

基于上述各个跳转过程确定测试页面的返回路径。

进一步地，在一个实施例中，处理器301调用存储器305中存储的终端控件测试程序可以执行以下操作：

获取上下文状态对应数据包的包名，并通过自我封装的调试接口比对所述包名与预设包名；

若不同，则通过进程命令终止掉该应用；

若相同，则判断跳转至其他应用。

进一步地，在一个实施例中，处理器301调用存储器305中存储的终端控件测试程序可以执行以下操作：

根据所述返回路径返回测试页面；

根据反序列所述控件交互界面图表数据模型的边的数据确定当前待测试的控件；

在所述测试页面对所述当前待测试的控件进行测试。

进一步地，在一个实施例中，处理器301调用存储器305中存储的终端控件测试程序可以执行以下操作：

在完成待测试控件的测试后，获取测试结果；

根据所述测试结果生成测试报告。

本实施例根据上述方案，基于提前建立的图表数据模型的节点和边的遍历得到待测试页面，获取上下文状态确定测试页面的返回路径，完成对终端的测试操作，实现自动化全路径遍历。有效避免现有的终端测试方式无法实现全自动化的遍历，来识别出终端的控件对控件进行测试，导致终端测试方式智能化程度低问题。实现全自动化的遍历来识别出终端的控件对控件进行测试，提高了终端测试的智能化程度。

基于上述硬件架构，提出本发明终端控件测试方法实施例。

如图2所示，提出本发明一种终端控件测试方法的第一实施例，所述终端控件测试方法包括：

步骤S10，遍历预先建立的控件交互界面图表数据模型的节点和边得到所有可点击控件作为待测试控件；

在本实施例中，预先采用Graph(图表数据模型)来模拟Activity(交互界面)间的链接，并动态绘制Activity Graph(交互界面图表数据模型)，将应用的每个Activity抽象为Graph的node(节点)，每个Activity之间的跳转关联抽象为edge(边)。在成功建立Activity Graph后，侦测是否需要对终端控件进行测试。所述终端控件进行测试的触发方式可以为多种，例如，1)通过物理按键触发；2)在测试设备与待测试终端连接时触发；3)通过测试设备或者待测试设备上的虚拟按键触发。以上所列举出的终端控件进行测试的触发方式仅仅为示例性的，本领域技术人员利用本发明的技术思想，根据其具体需求所提出的其它终端控件进行测试的触发方式均在本发明的保护区间内，在此不进行一一穷举。

在终端控件进行测试被触发后，遍历预先建立的控件交互界面Graph的节点和边得到所有可点击控件作为待测试控件。在本实施例中，为了保证全自动遍历终端，提供一种Appium(一种跨平台的测试开源框架)来支持本发明实施例，iOS平台使用UIAutomation(自动化测试)引擎，Android平台4.0以下使用selendroid(原生应用的UI自动化测试框架)引擎，4.0以上使用UIAutomation引擎。

本发明实施例的遍历逻辑为：遍历所有用户界面，甚至所有可点击控件。框架的数据结构建立在Graph上，将应用的每个Activity抽象为Graph的node节点，每个Activity之间的跳转关联抽象为edge边，并且实现定义Graph为方向矢量图，之所以这么做主要是为了实现导航而为之，通过Graph的edge遍历实现Activity的遍历，自增长模式的Graph在遍历每个clickable(可点击区域)时会形成相应的node和edge，新的node和edge会完成递归，并统一由Graph管理。在终端测试之前，提前定义好应用中的Activity.layout(交互界面布局)，clickables其实就是通过标准W3C协议获得的终端可点击控件，之所以说通过标准W3C协议主要是因为用到了webdriver(网页驱动)，它支持xpath XML(路径语言)，获取到当前页面所有可点击控件。

优选地，为了提高终端测试的速度，提升终端测试的体验。参考图3，所述遍历预先建立的控件交互界面图表数据模型的节点和边得到所有可点击控件作为待测试控件的过程可以包括：

步骤S11，遍历预先建立的控件交互界面图表数据模型的节点和边得到所 有可点击控件；

步骤S12，对所有可点击控件进行过滤，过滤掉重复位置和可调焦属性为是的控件得到过滤后的控件作为待测试控件。

在本实施例中，为了提高性能，对clickables进行一次过滤，去除了重复位置和focusable(可调焦)属性值为ture的控件。遍历的“引擎”实现模拟用户点击，通过上面的clickables点击进入不同的页面(Activity和layout)或者仅仅是改变了当前的page-source(页面源码)。

本实施例中通过Graph数据建模，图表数据模型形成的关系图可以作为结果的dom(标准对象模型)比对，并且在获取到Activity关系图基础上，可以实现全路径遍历，不单单的使用单一路径导航到目标Activity，在对目标Activity的导航路径选择上采取全路径覆盖。

步骤S20，获取当前上下文状态，并基于所述上下文状态确定测试页面的返回路径；

在遍历获取到所有课点击控件作为待测试控件之后，或者对遍历得到的可点击控件进行过滤得到过滤后的可点击控件作为待测试控件后，获取上下文状态，并基于所述上下文状态确定测试页面的返回路径。

具体的，参考图4，所述基于所述上下文状态确定测试页面的返回路径的过程可以包括：

步骤S21，在接收到控件点击操作后，通过上下文状态判断点击操作是否跳转至其他应用；

步骤S22，若是，则判断是否跳转至其他交互界面；

步骤S23，若是，则通过页面标记语言和页面源码判断是否跳转到同一交互界面的其他布局中；

步骤S24，基于上述各个跳转过程确定测试页面的返回路径。

在本实施例中，上下文管理：遍历算法中的上下文判断情况多变，采用反射、自省手段获取当前上下文状态，以此为基础决定下一步操作，目的是能够最终返回被测layout布局。

具体的，所述通过上下文状态判断点击操作是否跳转至其他应用的步骤包括：获取上下文状态对应数据包的包名，并通过自我封装的调试接口比对所述包名与预设包名；若不同，则通过进程命令终止掉该应用；若相同，则 判断跳转至其他应用。

首先判断点击是否跳转到其他应用，通过自我封装的调试接口(在Android系统中，所述调试接口为adb接口，也还可以是iOS调试接口或Windows Phone 7系统的调试接口等)，实现当前package(包)包名比对，如果不同，通过进程命令终止掉该应用；之后判断是否跳转至其他activity，如果有新的activity被发现，则记录在Graph中；之后通过页面标记语言(所述页面标记语言可以是xml，页面xml为用xml写成的页面)布局和page-source判断是否跳转至同一activity的其他layout中，基于上述各个跳转过程确定测试页面的返回路径。

步骤S30，根据所述返回路径返回测试页面，并在所述测试页面对所述待测试控件进行测试。

在本实施例中，页面导航：通过Graph图的深度或广度遍历获取返回路径后，需要导航到该被测页面的算法。

具体的，参考图5，所述根据所述返回路径返回测试页面，并在所述测试页面对所述待测试控件进行测试的过程包括：

步骤S31，根据所述返回路径返回测试页面；

步骤S32，根据反序列所述控件交互界面图表数据模型的边的数据确定当前待测试的控件；

步骤S33，在所述测试页面对所述当前待测试的控件进行测试。

在实现导航到该被测页面的算法时，其中的难点为如何导航到多个layout和待滑动页面的某个元素，导航用到的点击控件事先通过序列化存入Graph的edge中，待需要对此对象点击操作时，反序列该edge的数据，获取到该控件。

在本发明其他实施例中，为了提供更好更直观的测试数据，参考图6，在步骤S30之后，还可以包括：

步骤S40，在完成待测试控件的测试后，获取测试结果；

步骤S50，根据所述测试结果生成测试报告。

在完成待测试控件的测试后，获取测试结果，在对终端的待测试控件均测试完毕后，获取该终端所有控件的测试结果，根据所述所有的测试结果生成测试报告，在测试装置本地保存，或者发送至第三方终端，所述第三方终 端为与所述测试装置通信连接的终端，例如，手机、pad、笔记本电脑等，或者在测试装置上显示所述测试报告及测试结果，以供测试装置端用户直观的了解测试结果。所述测试结果可以以柱状图或者曲线图等形式体现。

本实施例基于提前建立的图表数据模型的节点和边的遍历得到待测试页面，获取上下文状态确定测试页面的返回路径，完成对终端的测试操作，实现自动化全路径遍历。实现全自动化的遍历来识别出终端的控件对控件进行测试，提高了终端测试的智能化程度。

对应地，提出本发明终端控件测试装置的第一实施例。参考图7，所述终端控件测试装置包括遍历模块10、获取模块20、确定模块30、返回模块40及测试模块50。

所述遍历模块10，用于遍历预先建立的控件交互界面图表数据模型的节点和边得到所有可点击控件作为待测试控件；

在本实施例中，预先采用Graph来模拟Activity间的链接，并动态绘制Activity Graph，将应用的每个Activity抽象为Graph的node，每个Activity之间的跳转关联抽象为edge。在成功建立Activity Graph后，侦测是否需要对终端控件进行测试。所述终端控件进行测试的触发方式可以为多种，例如，1)通过物理按键触发；2)在测试设备与待测试终端连接时触发；3)通过测试设备或者待测试设备上的虚拟按键触发。以上所列举出的终端控件进行测试的触发方式仅仅为示例性的，本领域技术人员利用本发明的技术思想，根据其具体需求所提出的其它终端控件进行测试的触发方式均在本发明的保护区间内，在此不进行一一穷举。

在终端控件进行测试被触发后，遍历预先建立的控件交互界面Graph的节点和边得到所有可点击控件作为待测试控件。在本实施例中，为了保证全自动遍历终端，提供一种Appium开源框架来支持本发明实施例，iOS平台使用UIAutomation引擎，Android平台4.0以下使用selendroid引擎，4.0以上使用UIAutomation引擎。

本发明实施例的遍历逻辑为：遍历所有用户界面，甚至所有可点击控件。框架的数据结构建立在Graph上，将应用的每个Activity抽象为Graph的node，每个Activity之间的跳转关联抽象为edge，并且实现定义Graph为方向矢量 图，之所以这么做主要是为了实现导航而为之，通过Graph的edge遍历实现Activity的遍历，自增长模式的Graph在遍历每个clickable时会形成相应的node和edge，新的node和edge会完成递归，并统一由Graph管理。在终端测试之前，提前定义好应用中的Activity.layout，clickables其实就是通过标准W3C协议获得终端可点击控件，之所以说通过标准W3C协议主要是因为用到了webdriver网页驱动，它支持xpath XML路径语言，获取到当前页面所有可点击控件。

优选地，为了提高终端测试的速度，提升终端测试的体验。参考图8，所述遍历模块10包括：遍历单元11及过滤单元12，

所述遍历单元11，用于遍历预先建立的控件交互界面图表数据模型的节点和边得到所有可点击控件；

所述过滤单元12，用于对所有可点击控件进行过滤，过滤掉重复位置和可调焦属性为是的控件得到过滤后的控件作为待测试控件。

在本实施例中，为了提高性能，对clickables进行一次过滤，去除了重复位置和focusable为ture的控件。遍历的“引擎”实现模拟用户点击，通过上面的clickables点击进入不同的页面(Activity和layout)或者仅仅是改变了当前的page-source。

本实施例中通过Graph数据建模，图表数据模型形成的关系图可以作为结果的dom比对，并且在获取到Activity关系图基础上，可以实现全路径遍历，不单单的使用单一路径导航到目标Activity，在对目标Activity的导航路径选择上采取全路径覆盖。

所述获取模块20，用于获取当前上下文状态；

所述确定模块30，用于基于所述上下文状态确定测试页面的返回路径；

在遍历获取到所有课点击控件作为待测试控件之后，或者对遍历得到的可点击控件进行过滤得到过滤后的可点击控件作为待测试控件后，获取上下文状态，并基于所述上下文状态确定测试页面的返回路径。

具体的，参考图9，所述确定模块30包括：判断单元31及确定单元32，

所述判断单元31，用于在接收到控件点击操作后，通过上下文状态判断点击操作是否跳转至其他应用；还用于若跳转至其他应用，则判断是否跳转至其他交互界面；还用于若跳转至其他交互界面，则通过页面标记语言和页 面源码判断是否跳转到同一交互界面的其他布局中；

所述确定单元32，用于基于上述各个跳转过程确定测试页面的返回路径。

在本实施例中，上下文管理：遍历算法中的上下文判断情况多变，采用反射、自省手段获取当前上下文状态，以此为基础决定下一步操作，目的是能够最终返回被测layout。

具体的，参考图10，所述判断单元31包括：获取子单元311，用于获取上下文状态对应数据包的包名，并通过自我封装的调试接口比对所述包名与预设包名；处理子单元312，用于若所述包名与预设包名不同，则通过进程命令终止掉该应用；判断子单元313，用于若所述包名与预设包名相同，则判断跳转至其他应用。

首先判断点击是否跳转到其他应用，通过自我封装的调试接口(在Android系统中，所述调试接口为adb接口，也还可以是iOS调试接口或Windows Phone 7系统的调试接口等)，实现当前package包包名比对，如果不同，通过进程命令终止掉该应用；之后判断是否跳转至其他activity，如果有新的activity被发现，则记录在Graph中；之后通过页面标记语言布局和page-source判断是否跳转至同一activity的其他layout中，基于上述各个跳转过程确定测试页面的返回路径。

所述返回模块40，用于根据所述返回路径返回测试页面；

所述测试模块50，用于在所述测试页面对所述待测试控件进行测试。

在本实施例中，页面导航：通过图表数据模型图的深度或广度遍历获取返回路径后，需要导航到该被测页面的算法。

具体的，参考图11所述测试模块50包括：返回单元51和测试单元52，

所述返回单元51，用于根据所述返回路径返回测试页面；还用于根据反序列所述控件交互界面图表数据模型的边的数据返回当前待测试的控件；

所述测试单元52，用于在所述测试页面对所述当前待测试的控件进行测试。

在实现导航到该被测页面的算法时，其中的难点为如何导航到多个layout和待滑动页面的某个元素，导航用到的点击控件事先通过序列化存入Graph的edge中，待需要对此对象点击操作时，反序列该edge的数据，获取到该控件。

在本发明终端控件测试装置的第二实施例中，参考图12，所述终端控件测试装置还包括生成模块60，

所述获取模块20，还用于在完成待测试控件的测试后，获取测试结果；

所述生成模块60，用于根据所述测试结果生成测试报告。

在完成待测试控件的测试后，获取测试结果，在对终端的待测试控件均测试完毕后，获取该终端所有控件的测试结果，根据所述所有的测试结果生成测试报告，在测试装置本地保存，或者发送至第三方终端，所述第三方终端为与所述测试装置通信连接的终端，例如，手机、pad、笔记本电脑等，或者在测试装置上显示所述测试报告及测试结果，以供测试装置端用户直观的了解测试结果。所述测试结果可以以柱状图或者曲线图等形式体现。

本实施例基于提前建立的图表数据模型的节点和边的遍历得到待测试页面，获取上下文状态确定测试页面的返回路径，完成对终端的测试操作，实现自动化全路径遍历。实现全自动化的遍历来识别出终端的控件对控件进行测试，提高了终端测试的智能化程度。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。