一种事件对象发送方法与装置与流程

本申请涉及计算机技术领域，尤其涉及一种事件对象发送方法与装置。

背景技术：

目前，在用户界面自动化测试中，有很多场景需要进行手势操作模拟测试。手势操作模拟测试的过程，主要分为两个子过程，分别为手势操作模拟子过程和测试结果获取子过程。

手势模拟操作子过程，包括：通过模拟用户对用户界面的手势操作产生相应的手势操作事件对象(一种java对象)，使得用户界面对应的应用根据该事件对象，执行该手势操作命令对应的操作。

测试结果获取子过程，包括：对应用的操作执行情况进行测试，从而得到针对所述用户界面的测试结果。这里所说的测试结果，视实际测试需求的不同，比如可以包括该用户界面上的控件是否能够正确响应该手势操作命令，等。

针对用户界面自动化测试而言，通常测试场景与真实场景越接近，得到的测试结果可信度越高。因此，如何在测试场景下，尽量还原用户对于用户界面真实的操作行为而产生事件对象并发送(发送的目标对象，一般是被测试的用户界面对应的应用)的过程，对于保证测试结果的可信度是非常重要的。然而，现有技术中，还没有提供方案，以实现尽量还原用户对于用户界面真实的操作行为产生事件对象并发送的过程。

类似地，针对应用进行的、需要依赖于产生事件对象并发送给应用的其他一些测试场景中，现有技术也没有提供方案，来实现尽量还原用户对于应用的真实操作行为产生事件对象并发送的过程。其中，这里所说的其他一些测试场景，一般是指测试目标与用户界面关联性较低的测试场景。比如，可以是通过模拟用户的手势操作，以测试应用对于指令的响应速度是否正常的测试场景，等等。

技术实现要素：

本申请实施例提供一种事件对象发送方法，用以解决在测试场景中，如何尽量还原用户对于应用的真实操作行为产生事件对象并发送的过程的问题。

本申请实施例提供一种事件对象发送装置，用以解决在测试场景中，如何尽量还原用户对于应用的真实操作行为产生事件对象并发送的过程的问题。

本申请实施例采用下述技术方案：

一种事件对象发送方法，包括：

确定手势操作类型和手势操作坐标；

判断设备是否具有向操作系统输入事件的权限；

若是，则将包含所述手势操作类型和所述手势操作坐标的事件输入操作系统，以使得操作系统根据所述手势操作类型和所述手势操作坐标生成事件对象，并发送给应用；

若否，则根据确定的所述手势操作类型和所述手势操作坐标，生成所述事件对象，并将生成的所述事件对象发送给所述应用。

一种事件对象发送装置，包括：

确定模块，用于确定手势操作类型和手势操作坐标；

判断模块，用于判断设备是否具有向操作系统输入事件的权限；

输入模块，用于在判断模块得到的判断结果为是时，将包含所述手势操作类型和所述手势操作坐标的事件输入操作系统，以使得操作系统根据所述手势操作类型和所述手势操作坐标生成事件对象，并发送给应用；

发送模块，用于在判断模块得到的判断结果为否时，根据确定的所述手势操作类型和所述手势操作坐标，生成所述事件对象，并将生成的所述事件对象发送给所述应用。

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：

在实际中，针对设备的触摸屏显示的用户界面发生的真实触摸操作，会触发设备的触摸屏驱动向操作系统输入触摸操作对应的事件，以使得操作系统根据事件生成事件对象并发送给应用。

比较本申请提供的方案和实际中的真实触发操作触发的上述流程可知，由于本方案能够在设备具备向操作系统输入事件的权限时，将包含手势操作类型和手势操作坐标的事件输入操作系统，以使得操作系统根据所述手势操作类型和所述手势操作坐标生成事件对象，并发送给应用(即基本完全模拟用户真实触摸所触发的流程)；此外，在不具备所述权限时，也可以根据确定的手势操作类型和手势操作坐标，生成所述事件对象，并将生成的所述事件对象发送给所述应用(即部分模拟用户真实触摸所触发的流程，具体而言，模拟的是该流程中的“操作系统生成事件对象并发送给应用”这个步骤)，因此，可以解决在测试场景中，如何尽量还原用户对于应用的真实操作行为产生事件对象并发送的过程的问题。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1a为本申请实施例提供的一种事件对象发送方法的实现流程示意图；

图1b为本申请实施例列举的一个具体实例中获取到的控件的位置布局的示意图；

图2为本申请实施例提供的一种事件对象发送装置的结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

以下结合附图，详细说明本申请各实施例提供的技术方案。

实施例1

为了解决在用户界面测试中，如何尽量还原用户对于应用的真实操作行为产生事件对象并发送的过程的问题，本申请实施例1提供一种事件对象发送方法。

需要说明的是，本申请实施例1提供的方法至少适用于云操作系统(yunoperationsystem，yunos)，也适用于yunos兼容的其他系统。当然，将本申请实施例提供的方法应用于非yunos以及非yunos兼容的其他系统的情况，也落在本申请所请求保护的范围之内。

为使得读者清楚理解本方法中产生事件对象的过程与用户对于用户界面真实的操作行为而产生事件对象的过程的异同，以下先对用户对于用户界面真实的操作行为而产生事件对象的过程进行简单介绍：

在实际中，当用户针对设备的触摸屏显示的用户界面进行真实触摸操作时，触摸屏会检测该真实触摸操作所作用的位置点的坐标，进而触摸屏驱动会利用根据真实触摸操作所确定出的手势操作类型的信息，以及检测到的坐标，向操作系统输入包含手势操作类型的信息和检测到的坐标的事件，以使得操作系统后续能够根据事件中的信息(手势操作类型的信息和检测到的坐标)生成事件对象，并发送给用户界面对应的应用。

基于上述说明，以下以本申请实施例提供的方法的执行主体为自动化测试框架为例，对本申请实施例提供的方法进行详细介绍。可以理解，所述执行主体为自动化测试框架，仅是一种示例性说明，并非是对本申请实施例提供的方法的执行主体、使用范围和使用场景等进行限制。

具体地，本申请实施例提供的事件对象发送方法的实现流程如图1a所示，主要包括如下步骤：

步骤11，自动化测试框架确定手势操作类型和手势操作坐标。

上述自动化测试框架，是一种自动化测试工具。它可以用于对待测用户界面进行手势操作模拟测试，模拟用户对待测用户界面的手势操作，并将模拟上述手势操作产生的效果与测试之前的预期效果进行对比，获知设备性能或某一款应用性能是否可以达到预期水平，进而可以对设备或某一款待测应用进行改进，以达到更好性能。

当本申请实施例提供的该事件对象发送方法具体应用于用户界面测试时，所述设备，可以为显示所述待测用户界面的设备，而所述应用，则可以为所述待测用户界面对应的应用。

为便于描述，下文以本申请实施例提供的事件对象发送方法在用户界面测试中的应用为例，对该方法进行介绍。可以理解，该方法在用户界面测试中的应用，仅是一种示例性说明，并非是对本申请实施例提供的方法的使用范围和使用场景等进行限制。

在用户界面测试场景中，在进行手势操作模拟测试之前，测试人员可以将上述自动化测试框架安装在用于显示待测用户界面的设备中。

其中，上述待测用户界面可以包括下述界面中的至少一种：

多款应用所在的显示界面；某应用的操作界面。

那么，对待测用户界面进行手势操作模拟测试，可以是对多款应用所在的显示界面(如桌面)进行手势操作模拟测试，也可以是对某应用的操作界面进行手势操作模拟测试。其中，针对某应用的操作界面进行手势操作模拟测试，包括针对某应用的操作界面中的控件和/或非控件进行手势操作模拟测试。

所述手势操作类型，为针对待测用户界面的手势操作的类型。其中，手势操作类型，可以包括但不限于对待测用户界面进行的点击、拖拽、缩放等动作类型。手势操作类型，可以分为基本手势操作类型和复杂手势操作类型。基本手势操作类型包括单指操作类型和两指操作类型。单指操作类型，可以但不限于单击、双击、拖动等动作类型；两指操作类型，可以但不限于两指缩小、两指放大等动作类型。复杂手势操作类型比如包括多指操作类型。多指操作类型可以但不限于多指捏合、放大等动作类型。

所述手势操作坐标，为针对待测用户界面的操作点的坐标。该操作点的坐标，可以是在设备屏幕所在平面中建立的屏幕坐标系中的坐标。根据该操作点的坐标，后续可以定位出手势操作的具体作用位置。

具体的，自动化测试框架可以接收针对待测用户界面的手势操作命令，并根据该手势操作命令，确定手势操作类型和手势操作坐标，作为所述用于手势操作模拟的手势操作类型和手势操作坐标。

所述手势操作命令，是一种模拟的命令，具体而言是模拟对待测用户界面执行的指定手势操作所产生的命令。该手势操作命令中，包括手势操作类型和手势操作坐标。该手势操作命令可以是测试人员编写的，具体可以是一段代码。该手势操作命令的作用在于，触发待测用户界面所在的设备对所述指定手势操作进行响应。

测试人员编写好手势操作命令后，可以利用其他设备将该手势操作命令，发送给安装在用于显示待测用户界面的设备中的自动化测试框架。自动化测试框架接收到上述手势操作命令后，可以将该手势操作命令中包含的诸如手势操作类型和手势操作坐标等信息，存储在自动化测试框架的数据库中。

上述自动化测试框架接收到的手势操作命令的编写语言可以是c语言(thecprogramminglanguage)、java语言(thejavaprogramminglanguage)或其他类型的计算机语言，这里不对此进行限定。

在实际应用中，为了使自动化测试框架可以快速地确定出手势操作坐标，可以直接将手势操作坐标编写进手势操作命令，那么这种情况下，手势操作命令包括手势操作类型和手势操作坐标。

下文将对在这种情况下如何根据手势操作命令确定手势操作类型和手势操作坐标进行介绍，此处不再赘述。

针对手势操作命令而言，本申请实施例中，可以由测试人员来编写手势操作命令，也可以通过人工录制的方法直接获取到上述手势操作命令，而不需要进行编写。其中，人工录制的方法包括：测试人员对待测用户界面进行点击或缩放等手势操作，使得待测用户界面所在的触屏设备自身产生相应的操作命令，该操作命令中包含手势操作类型和手势操作坐标；测试人员可以直接获取到上述操作命令。获取到的该操作命令便可作为手势操作命令进行保存，以便后续发送给自动化测试框架。

在实际应用中，当测试目标为“不同屏幕尺寸的触屏设备展示的待测用户界面中的某控件是否能够正确响应手势操作”时，由于受到不同触屏设备屏幕尺寸的影响，不同触屏设备所展示的该待测用户界面中的所述控件的位置坐标有所不同。这种情况下，若仍然采用手势操作命令包括手势操作类型和手势操作坐标的方式，需要针对不同屏幕尺寸的触屏设备分别编写手势操作命令，这样显然会耗费较多的人力资源。为避免耗费的人力资源过多，本申请实施例中，手势操作命令可以不包括手势操作坐标，而是包括手势操作类型和待测用户界面中的应用的特征。

其中，上述待测用户界面，可以是桌面，也可以是某应用的操作界面。当上述待测用户界面是桌面时，那么上述应用的特征，比如可以为某应用的应用名称。当上述待测用户界面是某应用的操作界面时，那么上述应用的特征，可以包括某应用的操作界面中的控件名称、控件类型等信息中的至少一种。手势操作命令中包括的上述应用的特征所对应的应用或控件，即为预期的能够对手势操作命令进行响应的应用或控件。

另外，测试人员可以直接将手势操作类型和待测用户界面中的应用的特征编写进手势操作命令。

需要说明的是，在实际中，当用户针对设备的触摸屏显示的用户界面进行真实触摸操作时，触摸屏会检测该真实触摸操作所作用的位置点的坐标，进而触摸屏驱动会利用根据真实触摸操作所确定出的手势操作类型的信息，以及检测到的坐标，向操作系统的输入子系统写入包含手势操作类型的信息以及检测到的坐标的事件。可见，实际场景中，写入事件，会用到“真实触摸操作所作用的位置点的坐标”。因此，本申请实施例的测试场景中，为了使得应用于用户界面测试的手势操作模拟方法，能够尽可能地模拟用户针对用户界面进行的真实触摸操作所触发的流程，本申请实施例中，可以根据手势操作命令，确定用于生成事件的坐标，也即确定模拟用户真实触摸操作所作用的位置点的坐标。

下文将对在手势操作命令中包括“手势操作类型和待测用户界面中的应用的特征”的情况下如何确定手势操作坐标进行介绍，此处不再赘述。

特别的，针对某应用的操作界面中的非控件区域进行手势操作模拟测试，编写的手势操作命令中可以包括手势操作坐标而不包括应用的特征。这是因为相较于应用的特征而言，非控件区域的特征(比如非控件区域的名称、类型等信息)比较难获取到。因此，针对这种情况编写的手势操作命令包括手势操作类型和手势操作坐标。

本申请实施例中，视手势操作命令中包含的信息的不同，根据手势操作命令，确定手势操作类型和手势操作坐标可以有以下几种实现方式：

方式1：当手势操作命令中包括手势操作类型和手势操作坐标时，自动化测试框架通过对手势操作命令进行解析，获取手势操作命令中包含的手势操作类型和手势操作坐标。

方式2：当手势操作命令中包括手势操作类型和待测用户界面中的应用的特征时，自动化测试框架通过对手势操作命令进行解析，获取手势操作命令中包含的手势操作类型和待测用户界面中的应用的特征；根据所述特征，确定出手势操作坐标。

其中，自动化测试框架获取到待测用户界面中的应用的特征后，可以通过上述待测用户界面中的应用的特征，获知手势操作所要作用的应用是哪些应用，或手势操作所要作用的某应用的操作界面中的控件是哪些控件。

本申请实施例中，在获取到待测用户界面中的应用的特征后，还可以根据所述特征确定出手势操作坐标，这样做的目的是为了使得自动化测试框架在执行后续步骤时，能够根据包含手势操作类型和手势操作坐标的事件生成事件对象，进而将该事件对象发送给待测用户界面对应的应用。

以下，对手势操作命令中不包含手势操作坐标时，自动化测试框架是如何确定手势操作坐标，进行详细介绍：

子步骤1，自动化测试框架利用自身具有的可以检测设备硬件信息的功能模块，对设备硬件进行检测，从而获取到待测应用所在触屏设备的硬件信息，比如设备屏幕分辨率的信息，或者设备屏幕分辨率的信息以及屏幕显示方式(横屏或竖屏)的信息。

子步骤2，自动化测试框架根据手势操作命令中包括的待测用户界面中的应用的特征，确定与该特征对应的某应用(或某控件)的位置布局。

比如，所述功能模块可以从应用的保存有用户界面布局配置信息的文件夹(或数据库)中，获取到所述位置布局。需要说明的是，所述文件夹(或数据库)中建立有应用的特征与位置布局的映射关系，从而根据手势操作命令中包括的待测用户界面中的应用的特征，可以从所述文件夹(或数据库)中查询到与应用的特征对应的某应用(或某控件)的位置布局。

其中，上述位置布局，可以是应用(或控件)在屏幕中的相对位置信息。该相对位置信息比如包括应用(或控件)相对于屏幕边缘的位置的信息。

子步骤3，自动化测试框架根据通过执行子步骤1和子步骤2分别获取到的信息，确定出手势操作坐标。

针对子步骤3的实现方式举例如下：

若假设：预期对手势操作命令进行响应的是某控件，该控件以正方形的形式在待测界面中显示；获取到的触屏设备的硬件信息，为设备的屏幕分辨率(100×100)的信息以及屏幕显示方式的信息；根据获取到的设备屏幕分辨率信息，确定设备屏幕分辨率为“100×100”；根据屏幕分辨率信息以及屏幕显示方式的信息查询到的所述位置布局如图1b所示。其中，图中由x坐标轴和y坐标轴构成的是屏幕坐标系；最下方的数字“0.1”，表示该控件的下边缘相距屏幕下边缘的距离与屏幕高度的比例。其他数字的含义以此类推，不再赘述。

根据设备屏幕分辨率“100×100”，以及如图1b所示的位置布局的信息，可以计算出该控件的中心点坐标(100×0.85，100×0.85)＝(85，85)。

执行完步骤11后，自动化测试框架会通过执行下述步骤12——判断待测应用所在触屏设备的类型，进而根据不同的判断结果进行不同的后续操作。这里所说的触屏设备的类型，是以设备是否具有向操作系统的输入子系统输入事件的权限(如root权限)作为分类依据的。

本申请实施例中，可以在自动化测试框架中，预先保存不同触屏设备的硬件信息与用户界面中控件的位置布局的映射关系，从而使得自动化测试框架可以兼容不同屏幕分辨率的设备，实现跨设备芯片平台的兼容性。

步骤12，自动化测试框架判断设备是否具有向操作系统输入事件的权限。

若是，则执行步骤13；若否，则执行步骤15。

一般地，自动化测试框架判断设备是否具有向操作系统输入事件的权限，即判断设备是否具有向操作系统的输入子系统输入事件的权限，具体的，判断方法比如可以如下：

自动化测试框架通过获取设备硬件信息，判断设备是否具有root权限；

若设备具有root权限，则判定设备具有向操作系统的输入子系统输入事件的权限；

若设备不具有root权限，则判定设备不具有向操作系统的输入子系统输入事件的权限。

其中，这里所说的子系统，是linux系统提供的input子系统。按键、触摸屏、键盘、鼠标等输入，都可以利用input子系统接口函数来实现设备驱动。

在linux内核中，使用input子系统实现输入设备驱动的时候，设备驱动的核心工作是向input子系统报告按键、触摸屏、键盘、鼠标等输入事件(event，通过input_event结构体描述)。

步骤13，自动化测试框架将包含所述手势操作类型和所述手势操作坐标的事件输入操作系统，以使得操作系统根据所述手势操作类型和所述手势操作坐标生成事件对象，并发送给应用。

所述事件对象，为包含所述手势操作类型和所述手势操作坐标的动作事件(motionevent)对象。

具体的，自动化测试框架判断是否支持所述操作系统所支持的硬件指令编写协议。若判断出支持所述操作系统所支持的硬件指令编写协议，则将符合所述硬件指令编写协议且包含所述手势操作类型和所述手势操作坐标的事件，输入所述操作系统；若判断出不支持所述操作系统所支持的硬件指令编写协议，则执行步骤15。

其中，所述硬件指令编写协议，是编写硬件指令所遵循的逻辑。若设备的cpu型号不同，那么硬件指令编写协议可能不同，最终便可能会导致硬件指令不同。比如，若某手机和某平板电脑分别支持不同的硬件指令编写协议，则可能会出现这样的情况：该手机的硬件指令“001”代表点击动作，该平板电脑的硬件指令“001”代表拖拽动作。

自动化测试框架可以将与自动化测试框架支持相同的硬件指令编写协议的cpu型号储存在自动化测试框架的数据库中，若自动化测试框架在对待测用户界面所在的触屏设备的硬件信息进行检测后，检测到上述设备cpu型号与上述数据库中存储的某一cpu型号相同，则认为自动化测试框架支持所述操作系统所支持的硬件指令编写协议；否则，则认为自动化测试框架不支持所述操作系统所支持的硬件指令编写协议。

在判断出自动化测试框架支持所述操作系统所支持的硬件指令编写协议后，自动化测试框架将符合所述硬件指令编写协议且包含所述手势操作类型和所述手势操作坐标的事件，输入所述操作系统，即输入操作系统的输入子系统。这里所说的输入子系统，具体而言是触摸屏对应的输入子系统，即touchscreeninput子系统，用于记录用户触摸屏幕时，用户的手势操作类型和手势操作坐标。该子系统对应的目录为：/dev/input/event1。自动化测试框架将符合所述硬件指令编写协议且包含所述手势操作类型和所述手势操作坐标的事件，输入所述操作系统的输入子系统，即，将所述事件输入/dev/input/event1。

由于所述设备的操作系统会不断地查询输入操作系统对应所述目录中的事件是否有更新，若所述目录中的事件有所更新，那么操作系统会根据更新的事件生成事件对象，并将该事件对象发送给应用。就操作系统将事件对象发送给所述应用的具体实现方式而言，操作系统一般会调用注入输入事件(injectinputevent)这一注入事件对象的方法，将生成的motionevent对象发送给所述应用。

需要特别说明的是，因为一般操作系统的内核部分都是由c语言编写的，所以，自动化测试框架可以根据确定出的手势操作类型和手势操作坐标，以及自动化测试框架中包含的事件生成逻辑，生成由c语言编写的、符合所述硬件指令编写协议、且包含通过执行步骤11确定出的手势操作类型和手势操作坐标的事件文件。其中，上述手势操作类型可以包括基本手势操作类型或复杂手势操作类型中的至少一种。

步骤14，待测用户界面对应的应用接收事件对象，并执行与该事件对象相对应的操作。

比如，若待测用户界面是某应用的操作界面，那么上述某应用(下文称待测应用)接收到步骤14发送的事件对象后，根据手势操作坐标，确定待测应用的操作界面中位于所述手势操作坐标的界面元素——比如假设确定出的该界面元素为某控件。进一步地，待测应用根据保存的、该控件所能实现的不同功能与手势操作类型的映射关系，确定接收到的手势操作类型所映射的功能。最后，待测应用调用该控件实现确定出的功能。该功能比如是在展示待测应用的操作界面中显示电子卡片，等。

步骤15，自动化测试框架根据确定的所述手势操作类型和所述手势操作坐标，生成所述事件对象，并将生成的所述事件对象发送给所述应用。

在自动化测试框架不具备向操作系统输入事件的权限时，自动化测试框架，可以直接根据确定的所述手势操作类型和所述手势操作坐标，调用操作系统的生成motionevent对象的方法，生成包含所述手势操作类型和所述手势操作坐标的motionevent对象。其中，生成的motionevent对象，在本申请实施例的测试场景中，被视为用户触摸设备的触摸屏产生的事件对象。

本申请实施例中，自动化测试框架可以调用操作系统的用于生成motionevent对象的方法，实现根据确定出的手势操作类型和手势操作坐标，模拟操作系统生成包含手势操作类型和手势操作坐标的motionevent对象。

另外，自动化测试框架，可以调用操作系统的injectinputevent这一注入方法，将生成的motionevent对象发送给应用。由于当用户真实触摸设备的触摸屏，从而触发操作系统生成motionevent对象后，操作系统一般也会调用injectinputevent这一注入方法，将生成的motionevent对象发送给应用。因此，本申请实施例中，自动化测试也通过调用该方法，来实现模拟操作系统发送motionevent对象给应用，从而可以比较真实地模拟用户真实触摸触摸屏而触发的流程。

在执行完毕步骤15后，执行步骤14。

在实际中，针对设备的触摸屏显示的用户界面发生的真实触摸操作，会触发设备的触摸屏驱动向输入子系统输入触摸操作对应的事件，以使得操作系统根据事件生成事件对象并发送给应用。

比较本申请提供的方案和实际中的真实触发操作触发的上述流程可知，由于本方案能够在设备具备向操作系统输入事件的权限时，将包含手势操作类型和手势操作坐标的事件输入操作系统，以使得操作系统根据所述手势操作类型和所述手势操作坐标生成事件对象，并发送给应用(即基本完全模拟用户真实触摸所触发的流程)；此外，在不具备所述权限时，也可以根据确定的手势操作类型和手势操作坐标，生成所述事件对象，并将生成的所述事件对象发送给所述应用(即部分模拟用户真实触摸所触发的流程，具体而言，模拟的是该流程中的“操作系统生成事件对象并发送给应用”这个步骤)，因此，可以解决在测试场景中，如何尽量还原用户对于应用的真实操作行为产生事件对象并发送的过程的问题。

并且，由于本申请实施例所述的自动化测试框架，既可以对具备向操作系统输入事件的权限的设备进行用户界面的测试，也可以对不具备该权限的设备进行用户界面的测试，因此，具备跨设备平台的兼容性。

需要说明的是，现有技术中采用的一些用户界面测试方案，可以预先设置一些事件对象，在测试目标为用户界面中的控件是否能正确响应用户的触摸操作时，可以将预先设置好的事件对象发送给应用，以触发应用的所述控件执行与事件对象对应的操作。比如，由android提供的uiautomator或instrumentation，都是这样的实现原理。

上述现有技术存在的缺陷在于：1、采用uiautomator和instrumentation时，所述预先设置的事件对象，目前仅包含由一些基本的手势操作(比如单指点击、单指滑动或单指拖动等)所触发的事件对象，因此，采用这样的方案，无法模拟生成用户对于触摸屏的特殊的手势操作(比如多指捏合或多指缩放等)所触发的事件对象；2、并没有模拟出根据用户触摸操作的操作点的坐标生成事件对象，而是直接调用预先设置的事件对象发送给应用，从而与由用户真实碰触触摸屏触发生成事件对象并发送给应用的过程差别较大。

而本申请实施例所采用的上述方案中，针对向操作系统输入事件的方式而言，考虑到采用该方式对输入的事件包含的手势操作类型和手势操作坐标并不会进行限定，因此在执行步骤11时，可以根据需要，将诸如多指捏合或多指缩放等特殊的手势操作的类型，确定为用于手势操作模拟的手势操作类型，并将特殊的手势操作对应的手势操作坐标，确定为用于手势操作模拟的手势操作坐标——比如，可以将特殊的手势操作的类型和特殊的手势操作对应的手势操作坐标，编译到所述手势操作命令中——从而，可以使得写入的事件包含特殊的手势操作的类型和特殊的手势操作对应的手势操作坐标，也就使得生成的事件对象包含特殊的手势操作的类型和特殊的手势操作对应的手势操作坐标，避免了上述第1个缺陷。此外，就设备不具备向操作系统输入事件的情况而言，在该情况下，由于自动化测试框架可以直接根据手势操作类型和手势操作坐标来生成事件对象，而并不是调用预先设置好的事件对象，因此也不会受限于预先设置的事件对象而不能模拟产生特殊的手势操作对应的对象。具体而言，在该情况下，当手势操作类型和手势操作坐标，分别为特殊的手势操作的类型和特殊的手势操作对应的手势操作坐标时，也可以保证生成的事件对象包含特殊的手势操作的类型和特殊的手势操作对应的手势操作坐标，从而避免了上述第1个缺陷。

由于本申请实施例提供的测试框架，可以用于对用户界面进行多指操作的模拟测试，因此，可以用于对支持多指操作的设备(如平板电脑以及包含触摸屏的车载系统)的用户界面测试。

针对上述第2个缺陷而言，由于在本申请实施例中，自动化测试框架可以通过接收手势操作命令的方式，获取到手势操作坐标，以便后续根据手势操作坐标来生成事件对象，因此，相对于现有技术，本方案中生成事件对象的流程，与由用户真实碰触触摸屏触发生成事件对象的过程更为接近，从而避免了上述第2个缺陷。

本申请实施例中，为了使所述自动化测试框架能够实施本申请实施例提供的上述方法，一般地，可以测试人员在自动化测试框架中编译用于实现该方法的代码。

还需要说明的是，采用现有技术中的uiautomator或instrumentation进行用户界面测试时，因为这两种方法，均不具备“重试机制”，因此，在设备处理资源(如cpu资源和内存资源)被其他应用程序占用而使用率较高的情况下，很可能会发生测试失败且无法自动重试的问题(即出现“点击无效”的情况)。而本申请实施例中，可以为自动化测试框架设置“重试机制”。该重试机制，可以由向所述自动化测试框架发送前文所述的手势操作命令的一方，与自动化测试框架配合实现。具体地，发送该手势操作命令的一方(如设备a)，可以与运行有所述自动化测试框架的一方(如设备b)之间，采用基于socket通信机制进行通信。设备a可以向设备b中的自动化测试框架，发送用于询问自动化测试框架是否完成前文所述的某步骤的查询请求；自动化测试框架在接收到该查询请求后，判断该步骤是否成功完成，若是，则返回成功执行的应答消息，若否，则自动化测试框架可以返回执行失败的应答消息，并重新执行该步骤。对于设备a而言，若接收到步骤成功完成的消息，则询问该步骤的下一步骤是否成功完成；而若接收到执行失败的应答消息，则从接收到执行失败的应答消息后开始计时，计时时长到达预定的时长阈值后，重新发送所述查询请求。

实施例2

出于与实施例1相同的发明构思，本申请实施例2提供一种事件对象发送装置，该装置的具体结构示意图如图2所示，包括下述模块：

确定模块21，用于确定手势操作类型和手势操作坐标。

判断模块22，用于判断设备是否具有向操作系统输入事件的权限。

输入模块23，用于在判断模块得到的判断结果为是时，将包含所述手势操作类型和所述手势操作坐标的事件输入操作系统，以使得操作系统根据所述手势操作类型和所述手势操作坐标生成事件对象，并发送给应用。

发送模块24，用于在判断模块得到的判断结果为否时，根据确定的所述手势操作类型和所述手势操作坐标，生成所述事件对象，并将生成的所述事件对象发送给所述应用。

在一种实施方式中，所述手势操作类型和手势操作坐标，为针对待测用户界面的手势操作的类型和操作点的坐标。

所述设备，为显示所述待测用户界面的设备。

所述应用，为所述待测用户界面对应的应用。

在一种实施方式中，确定模块21，具体用于：

接收手势操作命令；

根据手势操作命令，确定手势操作类型和手势操作坐标。

在一种实施方式中，确定模块21，具体用于：

通过对手势操作命令进行解析，获取手势操作命令中包含的手势操作类型和手势操作坐标；或，

通过对手势操作命令进行解析，获取手势操作命令中包含的手势操作类型和所述应用的特征；根据所述特征，确定手势操作坐标。

在一种实施方式中，输入模块23，具体用于：

模拟所述设备的触摸屏驱动，将包含所述手势操作类型和所述手势操作坐标的事件输入所述操作系统。

在一种实施方式中，输入模块23，具体用于：

判断是否支持所述操作系统所支持的硬件指令编写协议；

若判断出支持所述操作系统所支持的硬件指令编写协议，则将符合所述硬件指令编写协议且包含所述手势操作类型和所述手势操作坐标的事件，输入所述操作系统。

在一种实施方式中，发送模块24，具体用于：

根据确定的所述手势操作类型和所述手势操作坐标，调用操作系统的用于生成motionevent对象的方法，生成包含所述手势操作类型和所述手势操作坐标的motionevent对象。

在一种实施方中，发送模块24，具体用于：调用操作系统的injectinputevent，将生成的motionevent对象发送给应用。

在一种实施方式中，输入模块23，具体用于：向操作系统的输入子系统输入事件。

在实际中，针对设备的触摸屏显示的用户界面发生的真实触摸操作，会触发设备的触摸屏驱动向操作系统，输入触摸操作对应的事件，以使得操作系统根据事件生成事件对象并发送给应用。

比较本申请提供的方案和实际中的真实触发操作触发的上述流程可知，由于本方案能够在设备具备向操作系统输入事件的权限时，将包含手势操作类型和手势操作坐标的事件输入操作系统，以使得操作系统根据所述手势操作类型和所述手势操作坐标生成事件对象，并发送给应用(即基本完全模拟用户真实触摸所触发的流程)；此外，在不具备所述权限时，也可以根据确定的手势操作类型和手势操作坐标，生成所述事件对象，并将生成的所述事件对象发送给所述应用(即部分模拟用户真实触摸所触发的流程，具体而言，模拟的是该流程中的“操作系统生成事件对象并发送给应用”这个步骤)，因此，可以解决在测试场景中，如何尽量还原用户对于应用的真实操作行为产生事件对象并发送的过程的问题。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flashram)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitorymedia)，如调制的数据信号和载波。

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

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。