测试方法、装置及设备

技术领域

本公开实施例涉及自动化测试技术领域，尤其涉及一种测试方法、装置及设备。

背景技术

在自动化测试领域中，测试系统可以调用测试用例对计算机软件进行测试，以保证计算机软件的功能正常。例如，在应用程序发布之前，需要对应用程序的安装、启动、运行过程等进行全面测试。

现有技术中，为了保证测试的覆盖率，可以通过回放事件序列的方式对计算机软件中的一些不容易被测试到的功能进行测试。其中，该事件序列中可以包括顺序执行的多个事件，不同事件可以是针对不同或相同的界面执行的，这里的事件用于指示对计算机软件界面可进行的操作。例如，如果事件序列包括：E1->E2->E3->E4，那么回放事件序列的过程可以为先后执行四个事件E1、E2、E3、E4。

然而，上述测试过程存在测试成功率较低的问题。

发明内容

本公开实施例提供一种测试方法、装置及设备，可以提高测试成功率。

第一方面，本公开实施例提供一种测试方法，所述方法包括：

在对目标软件执行第一事件序列的过程中，若所述第一事件序列中的目标事件执行失败，则确定所述目标事件对应的目标界面信息，所述第一事件序列中包括的事件用于触发所述目标软件进行界面跳转，以测试所述界面跳转是否异常；

获取所述目标界面信息对应的目标界面中可执行的突发处理事件，所述突发处理事件用于消除所述目标界面中导致所述目标事件执行失败的异常显示对象；

在所述目标界面中执行所述突发处理事件之后，从所述目标事件开始继续执行所述第一事件序列。

第二方面，本公开实施例提供一种测试装置，所述装置包括：

界面信息确定模块，用于在对目标软件执行第一事件序列的过程中，若所述第一事件序列中的目标事件执行失败，则确定所述目标事件对应的目标界面信息，所述第一事件序列中包括的事件用于触发所述目标软件进行界面跳转，以测试所述界面跳转是否异常；

突发处理事件获取模块，用于获取所述目标界面信息对应的目标界面中可执行的突发处理事件，所述突发处理事件用于消除所述目标界面中导致所述目标事件执行失败的异常显示对象；

继续测试模块，用于在所述目标界面中执行所述突发处理事件之后，从所述目标事件开始继续执行所述第一事件序列。

第三方面，本公开实施例提供一种电子设备，包括：至少一个处理器和存储器；

所述存储器存储计算机执行指令；

所述至少一个处理器执行所述存储器存储的计算机执行指令，使得所述电子设备实现如第一方面所述的方法。

第四方面，本公开实施例提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机执行指令，当处理器执行所述计算机执行指令时，使计算设备实现如第一方面所述的方法。

第五方面，本公开实施例提供一种计算机程序，所述计算机程序用于实现如第一方面所述的方法。

本公开实施例提供了一种测试方法、装置及设备，该方法包括：在对目标软件执行第一事件序列的过程中，若第一事件序列中的目标事件执行失败，则确定目标事件对应的目标界面信息，第一事件序列中包括的事件用于触发目标软件进行界面跳转，以测试界面跳转是否异常；获取目标界面信息对应的目标界面中可执行的突发处理事件，突发处理事件用于消除目标界面中导致目标事件执行失败的异常显示对象；在目标界面中执行突发处理事件之后，从目标事件开始继续执行第一事件序列。本公开实施例可以在执行第一事件序列中的一个目标事件失败时，可以通过突发处理事件消除异常显示对象，从而可以继续执行第一事件序列，有助于提高第一事件序列的执行成功率，进而提高测试成功率。

附图说明

为了更清楚地说明本公开实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1是本公开实施例提供的一种测试场景示意图；

图2是本公开实施例提供的一种测试方法的步骤流程图；

图3是本公开实施例提供的一种基于第一事件序列进行测试的界面跳转示意图；

图4是本公开实施例提供的一种界面布局示意图；

图5是本公开实施例提供的对图4所示的界面执行事件的失败原因示意图；

图6是本公开实施例提供的一种事件序列中的事件执行顺序示意图；

图7是本公开实施例提供的两个事件序列合并前的一种示意图；

图8是本公开实施例提供的两个事件序列合并之后的事件序列示意图；

图9和图10是本公开实施例提供的第一事件序列和第二事件序列之间的两种执行顺序示意图；

图11是本公开实施例提供的一种测试装置的结构框图；

图12是本公开实施例提供的一种电子设备的结构框图。

具体实施方式

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

如背景技术所述，现有技术存在测试成功率较低的问题。为了解决上述技术问题，发明人对现有技术进行分析之后发现，存在上述技术问题的原因之一在于，在执行事件序列的过程中，会逐个执行每个事件，但是事件是在界面上进行的，界面上可能会出现一些影响事件执行的异常显示对象，从而导致事件执行失败，进而导致测试失败。

为了解决上述技术问题，本公开实施例考虑可以在消除上述目标界面的异常显示对象之后，继续执行第一事件序列，以使基于第一事件序列对目标软件的测试成功。

但是，如何消除上述目标界面的异常显示对象是解决问题的关键。考虑到异常显示对象是在目标界面突发性显示的信息，从而，该异常显示对象是对应有突发处理事件的，本公开实施例考虑通过执行突发处理事件来消除该异常显示对象。例如，异常显示对象可以是显示在目标界面上的弹窗时，突发处理事件可以是关闭该弹窗的事件。

下面以具体地实施例对本公开实施例的技术方案以及本公开的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本公开实施例进行描述。

图1是本公开实施例提供的一种测试场景示意图。参照图1所示，本公开实施例的测试场景涉及测试客户端101、测试服务端102、伴侣客户端103和事件库104。

其中，测试客户端101用于向用户提供测试界面，用户可以通过测试界面发起测试指令，测试客户端可以将测试指令转换为测试请求，以发送给测试服务端，测试请求中通常可以携带事件标识。例如，用户可以在测试客户端上选取需要执行的事件序列，以使测试客户端发起测试请求，该测试请求中包括该事件序列，事件序列中包括若干事件的事件标识。

测试服务端102在接收到该测试请求之后，可以根据事件标识从事件库中获取对应的事件信息，以基于事件信息执行事件，实现对目标软件的测试，并将测试结果反馈给测试客户端。其中，原子事件的事件信息可以包括但不限于：事件所在的界面、事件的执行信息。事件的执行信息包括但不限于：事件针对的控件、针对该控件的操作方式等。组合事件的事件信息可以包括但不限于：组合事件中包括的原子事件的事件标识以及执行顺序等。

事件库104用于存储事件，在实际应用中，事件库104可以分为原子事件库和组合事件库。其中，原子事件库用于存储不可分割的最小可执行的原子事件，组合事件库用于存储多个原子事件组合得到的组合事件。从而，当测试服务端102需要获取原子事件的事件信息时，可以将原子事件的事件标识发送给原子事件库。当测试服务端102需要获取组合事件的事件信息时，可以将组合事件的事件标识发送给组合事件库。

伴侣客户端103用于向用户提供事件配置界面，以使用户对事件进行配置。伴侣客户端在接收到用户配置的事件信息时，生成携带该事件信息的配置请求，发送给事件库104中。当用户配置的事件为原子事件时，伴侣客户端将原子事件的事件信息发送给原子事件库，以使原子事件库将原子事件的事件信息进行存储。当用户配置的事件为组合事件时，伴侣客户端将组合事件的事件信息发送给组合事件库，以使组合事件库将组合事件的事件信息进行存储。

上述原子事件的事件信息还可以包括原子事件的一些其余信息：原子事件所对应的应用程序、应用程序的版本信息、原子事件的名称、原子事件的配置内容、原子事件的创建时间、原子事件的创建者、原子事件的执行成功率等。其中，原子事件的执行成功率在初始时设置为0，并随着测试过程中原子事件的执行成功与否而更新。

上述组合事件的事件信息还可以包括：组合事件的名称、组合事件所对应的应用程序、组合事件的配置内容等。

当然，上述用户还可以在事件配置界面中删除原子事件库中的原子事件和/或组合事件库中的组合事件。

此外，伴侣客户端103还用于向用户提供事件序列配置界面，以使用户对事件序列进行配置。伴侣客户端在接收到用户配置的事件序列时，可以将该事件序列存储到事件序列库中，并在测试时调用该事件序列进行测试。例如，用户可以通过测试客户端101访问事件序列库，以获取到所有的事件序列，并从中选取需要执行的事件序列。测试客户端101可以根据选取的事件序列生成测试请求，以使测试服务端102执行该测试请求中指定的事件序列。

用户在配置上述事件序列时还可以指定事件序列的其余信息，包括但不限于：执行条件、执行次数、事件序列中相邻两个事件之间的执行时间间隔和执行概率。

其中，执行次数用于指示在每次根据该事件序列测试目标软件时，该事件序列的执行次数，例如，3次。

执行条件用于指示开始执行该事件序列的条件，例如，事件序列的执行条件可以为该事件序列的第一个事件所针对的界面信息，从而在当前界面的界面信息与该界面信息匹配时，开始执行该事件序列。

除上述执行条件外，还可以通过上述事件序列的执行概率进一步确定是否开始执行该事件序列。例如，当当前界面的界面信息与N个事件序列的执行条件匹配时，那么可以按照N个事件序列的执行概率进一步选取要执行的事件序列，要执行的事件序列可以是N个事件序列中执行概率最大的一个或多个事件序列。

当然，上述测试客户端101和上述伴侣客户端103还可以调用测试服务端的接口，以访问事件序列库中的事件序列。

图2是本公开实施例提供的一种测试方法的步骤流程图。图2所示的方法可以应用在前述测试服务端102中，也就是说本公开实施例中的步骤均由测试服务端102执行。参照图2所示，该测试方法包括：

S201：在对目标软件执行第一事件序列的过程中，若第一事件序列中的目标事件执行失败，则确定目标事件对应的目标界面信息，第一事件序列中包括的事件用于触发目标软件进行界面跳转，以测试界面跳转是否异常。

本公开实施例提及的目标软件可以是需要测试的任一计算机软件，例如，应用程序、网页等。本公开实施例对目标软件的具体形式不加以限制。

其中，第一事件序列是用于对目标软件进行测试的任意事件序列，其中包括多个按照顺序排列的事件，从而基于第一事件序列的测试过程就是按照顺序执行各个事件的过程。第一事件序列中的事件可以是前述原子事件。

需要说明的是，事件是针对界面执行的，执行事件之后，界面会发生跳转，以跳转到另一个界面。图3是本公开实施例提供的一种基于第一事件序列进行测试的界面跳转示意图。参照图3所示，第一事件序列包括以下4个事件：E1、E2、E3和E4。其中，E1是针对界面S1执行的，在执行E1之后从界面E1跳转到E2。E2是针对界面S2执行的，在执行E2之后从界面E2跳转到E3。E3是针对S3执行的，在执行S3之后从界面S3跳转到S4。E4是针对S4执行的，在执行完S4之后从界面S4跳转到其余界面。

理想情况下，上述第一事件序列可以顺利执行结束，在执行结束之后代表通过该第一事件序列对目标软件的测试过程结束。

但是，由于偶然性显示的异常显示对象的出现，可能会导致第一事件序列中的某一个事件执行失败，将该执行失败的事件可以称为目标事件。图4是本公开实施例提供的一种界面布局示意图，参照图4所示，界面S1中有4个控件BTN1至BTN4，事件是针对界面S1中的BTN2进行的。图5是本公开实施例提供的对图4所示的界面执行事件的失败原因示意图，参照图5所示，界面S1中的部分区域被弹窗W1覆盖，被覆盖的区域中的BTN2也被覆盖，从而导致对BTN2进行操作的事件也无法执行，从而导致该事件执行失败。

上述执行失败的事件可以是第一事件序列中的任一事件，当然，第一事件序列中的至少一个事件执行失败均会导致基于第一事件序列的测试失败。

在实际应用中，可以通过弹窗提示用户一些异常信息，从而异常显示对象可以包括：弹窗。

上述异常显示对象通常不是始终在目标界面上显示的，而是随机显示的。这个随机可以是与目标界面的运行场景相关联。例如，如果目标软件是商品售卖软件，那么当未登录的用户打开目标软件时，可以在显示目标软件的目标界面时，在该目标界面上显示弹窗，以提示用户登录。

S202：获取目标界面信息对应的目标界面中可执行的突发处理事件，突发处理事件用于消除目标界面中导致目标事件执行失败的异常显示对象。

在执行第一事件序列的过程中，如果一个事件执行失败，那么可以将该目标事件作为目标事件，将该事件的界面信息作为目标界面信息。

其中，任一事件的界面信息可以包括以下至少一种：该事件所对应的界面标识、该界面标识对应的界面所归属的应用程序、该应用程序的版本信息。

其中，界面标识是一个界面的唯一标识，不同界面的界面标识不同，从而目标界面信息对应的目标界面也就是目标事件所在的界面，也就是说，在目标界面上执行目标事件失败时，在该目标界面上执行突发处理事件，以消除导致目标事件失败的异常显示对象。界面标识可以根据界面布局生成，从而不同布局的界面得到的界面标识不同。具体地，可以通过swifthand算法进行抽象，以确定界面的界面标识。

基于上述界面信息可以从事件库中获取到突发处理事件，事件库用于存储大量的事件以及相关信息，该相关信息可以包括但不限于：该事件的事件类型、该事件的上述界面信息。从而，可以从事件库中获取事件类型为目标类型，且界面信息与目标界面信息匹配的事件，作为在目标界面中可执行的突发处理事件，目标类型用于指示事件为突发处理事件。

当上述事件类型为目标类型时，表示事件为突发处理事件。当事件类型不为目标类型时，表示事件不为突发处理事件。例如，目标类型可以用1表示，从而事件类型为1时，事件为突发处理事件；事件类型为0时，事件不为突发处理事件。上述事件类型可以在配置原子事件时由用户指定，本公开实施例中将不会影响测试的服务端需要兼容的事件设置为突发处理事件。

在从事件库中选取可执行的突发处理事件时，不仅需要确定事件库中的事件的事件类型是否为目标类型，还需要将上述目标界面信息与事件库中的每个事件的上述界面信息进行匹配。当事件库中的一个事件的事件类型为目标类型，且该事件的界面信息与目标事件信息匹配时，那么可以确定该事件为突发处理事件，并从事件库中获取该突发处理事件的操作信息，以根据该操作信息在目标界面上执行该突发处理事件。

其中，操作信息用于指示如何执行该突发处理事件，可以包括但不限于：操作对象、操作类型等。例如，操作对象可以是目标界面中的控件，操作类型可以为点击该控件。

需要说明的是，当界面信息中包括上述界面标识、应用程序和版本信息时，对于事件库中的一个事件，只有当该事件对应的界面标识与目标界面信息中的界面标识匹配，且该事件对应的应用程序与目标界面中的应用程序匹配，且该事件对应的版本信息与目标界面信息中的版本信息匹配，则确定该事件的界面信息与目标界面信息匹配。否则，如果该事件对应的界面标识与目标界面信息中的界面标识不匹配，和/或，该事件对应的应用程序与目标界面中的应用程序不匹配，和/或，该事件对应的版本信息与目标界面信息中的版本信息不匹配，那么确定该事件的界面信息与目标界面信息不匹配。

可以看出，本公开实施例在获取突发处理事件时，考虑了以下多个方面。

第一方面，考虑了事件所在的界面，这样可以保证对突发处理事件的执行是在对的界面上，从而可以有助于提高突发处理事件的执行成功率。

第二方面，还考虑了事件所在的界面所归属的应用程序，也就是说，目标软件需要和该应用程序一致，从而可以保证在对目标软件的目标界面执行失败时，执行该目标软件上的突发处理事件，保证了突发处理事件和软件之间的一致性，有助于提高突发处理事件的执行成功率。

第三方面，本公开实施例还考虑了软件的版本信息，也就是说，目标软件的版本信息需要与事件库中的应用程序的版本信息一致，从而可以避免由于版本信息不一致而导致的突发事件处理失败，有助于提高突发处理事件的执行成功率。

S203：在目标界面中执行突发处理事件之后，从目标事件开始继续执行第一事件序列。

可以理解的是，在执行目标事件失败时，先在目标界面中执行突发处理事件，以消除异常显示对象，再继续执行目标事件以及之后的事件。图6是本公开实施例提供的一种事件序列中的事件执行顺序示意图。参照图6所示，第一事件序列包括以下事件：E1至E4，在按照E1至E2的顺序执行到目标事件E2失败时，可以先执行突发处理事件E5，再执行目标事件E2、以及E2之后的事件E3、E4。这样，相当于执行的第一事件序列包括以下事件：E1、E5、E2、E3、E4。

可选地，上述第一事件序列可以是对多个事件序列合并得到的序列。具体地，可以先获取至少两个事件序列；然后，确定这至少两个事件序列是否包括至少一个相同事件和至少一个不同事件，当至少两个事件序列中包括至少一个相同事件和至少一个不同事件时，根据相同事件将至少两个事件序列合并为上述第一事件序列，上述第一事件序列中包括上述相同事件和上述不同事件，不同事件将上述第一事件序列拆分为至少两条执行路径。

图7是本公开实施例提供的两个事件序列合并前的一种示意图，图8是本公开实施例提供的两个事件序列合并之后的事件序列示意图。

参照图7所示，事件序列SQ1包括以下事件：E1、E2、E3、E5和E7，事件序列SQ2包括以下事件：E1、E2、E4、E6和E7。可以看出，SQ1和SQ2包括两个相同事件E1、E2和E7，不同事件E3、E4、E5和E6。从而，可以看出上述相同事件和不同事件，将SQ1和SQ2合并，得到图8所示的事件序列。

参照图8所示，事件序列包括两条执行路径，这两条执行路径是合并前的SQ1和SQ2。从图8中可以看出，E1、E2和E7是两条执行路径共享的相同事件，E3、E5、E4和E6将目标图8所示的第一事件序列拆分为两条执行路径。

本公开实施例的上述过程可以通过将事件序列合并，使合并后的事件序列包括两个执行路径，从而在实际测试过程中，如果测试场景导致一条执行路径无法执行时，还可以执行另一条执行路径。这样，可以进一步提高第一事件序列的执行成功率，进而提高测试成功率。例如，上述SQ1和SQ2可以是两种登录方式的事件序列，SQ1是密码登录，SQ2是验证码登录，这样，在其中一种登录失败时，还可以通过另一种方式登录。

可以理解的是，在实际应用中，当存在多个事件序列时，不同事件序列的执行顺序也会影响事件序列的执行成功率，进而影响测试成功率。例如，如果一个事件序列SQ1依赖于SQ3，此时，如果先执行SQ3再执行SQ1，那么可能会导致SQ1执行失败。所以，本公开实施例考虑先确定事件序列之间的依赖关系，然后优先执行被依赖的至少一个事件序列LSQ1，再执行依赖事件序列LSQ1的事件序列LSQ2。如此，可以避免LSQ2依赖的数据未生成而导致的LSQ2执行失败，从而可以提高测试成功率。从而，上述事件序列之间的依赖关系如何确定是提高测试成功率的关键。

可选地，上述依赖关系可以通过界面之间的关系确定。具体地，在对目标软件执行第一事件序列之前，先获取待执行的第一事件序列和第二事件序列；然后，判断第一事件序列中的第一事件执行后跳转到的第一界面与第二事件序列中的第二事件对应的第二界面之间的关系，如果第一事件序列中的第一事件执行后跳转到的第一界面是第二事件序列中的第二事件对应的第二界面，则确定第一事件序列的执行顺序在第二事件序列之前。

图9是本公开实施例提供的第一事件序列和第二事件序列之间的一种执行顺序示意图。参照图9所示，第一事件序列可以包括以下事件：E1、E2、E3和E4，其针对的界面分别是S1、S2、S3和S4，执行E1后从S1跳转到S2，执行E2之后从S2跳转到S3，执行E3后从S3跳转到S4。第二事件序列可以包括以下事件：E5、E6、E7和E8，其针对的界面分别为：S2、S5、S6和S7。

可以看出，第二事件序列中的事件E5针对的界面S2是第一事件序列中的事件E2执行后跳转到的界面S2，从而，第二事件序列依赖于第一事件序列，第一事件序列在第二事件序列之前执行。

本公开实施例可以按照上述界面之间的关系确定第一事件序列和第二事件序列之间的执行顺序，避免执行第二事件序列时，由于第二事件序列中的第二事件针对的第二界面还未生成，而导致第二事件执行失败以及第二事件序列执行失败，有助于提高测试成功率。

当然，在确定上述执行顺序之后，可以按照上述执行顺序执行上述两个事件序列。具体地，先执行第一事件序列，并在执行第一事件序列的过程中每跳转到一个界面时，记录界面的界面信息。在执行第一事件序列到达目标时间时，根据第一界面的界面信息执行第二事件序列，目标时间包括以下至少一种：执行完第一事件序列的第一时间、到达第一界面的第二时间、比第二时间早预设时长的时间。

其中，根据第一界面的界面信息执行第二事件序列可以为，根据第一界面的界面信息执行第二事件序列中的第二事件。也就是说，在执行第二事件时需要从第一事件的界面信息中确定第二事件针对的控件的位置，并对该控件进行第二事件对应的操作。

在本公开实施例中，当第一事件序列在第二事件序列之前执行时，第二事件序列的启动可以有多种策略。

在第一种策略中，可以在第一事件序列执行完之后开始执行第二事件序列的第一个事件。如图9所示，在执行第一事件序列中的最后一个事件E4完之后，开始执行第二事件序列中的第一个事件E5。可以理解的是，在执行到E4时，记录的界面信息中已经包括S2的界面信息，从而可以根据记录的S2的界面信息执行E5，从而保证E5的正常执行。

可以看出，上述第一种策略不需要关注第二事件序列中依赖于第一事件序列的事件在第二事件序列中的位置，从而其适用于所有第一事件序列在第二事件序列之前的场景。

在第二种策略中，可以在第一事件序列执行到达第一界面时，开始执行第二事件序列的第一个事件。如图9所示，在执行第一事件序列中的E2之后，到达界面S2，此时，已经记录了S2的界面信息，从而可以根据S2的界面信息开始执行第二事件序列的第一个事件E5，从而保证E5的正常执行。

可以看出，当第二事件为第二事件序列中的第一个事件时，上述第二种策略可以尽可能的提前执行第二事件序列，实现第一事件序列中的事件E3、E4，与第二事件序列中的各事件的并行执行，节约了事件序列的总执行时长，提高了测试效率。

在第三种策略中，可以在第一事件序列还未执行到第一界面时，开始执行第二事件序列的第一个事件。这里的未执行到第一界面的时间，可以为比第二时间早预设时长的时间。当依赖第一界面的第二事件不是第二事件序列中的第一个事件时，可以按照上述第三种策略执行第二事件序列。

图10是本公开实施例提供的第一事件序列和第二事件序列的另一种执行顺序示意图。如图10所示，第一事件序列包括以下事件：E1、E2、E3和E4，其针对的界面分别是S1、S2、S3和S4，执行E1后从S1跳转到S2，执行E2之后从S2跳转到S3，执行E3后从S3跳转到S4。第二事件序列可以包括以下事件：E5、E6、E7和E8，其针对的界面分别为：S5、S2、S6和S7。第二事件序列的第二事件E6依赖于第一事件序列的第一事件E2。假设执行到达第一界面的第一时间为t1，预设时长为t，那么可以在t2＝t1-t时，开始执行第二事件序列中的第一个事件E5。如此，可以保证准备执行第二事件序列中的第一事件E6的时间接近于执行第一事件序列到达S2的时间接近t1。如此，实现了并行执行第一事件之前的若干事件和第二事件之前的若干事件，节约了事件序列的总执行时长，提高了测试效率。

可以看出，上述三种策略均是针对第二事件序列依赖于第一事件序列的情况进行的。与上述第二事件序列依赖于第一事件序列的原理相同，第一事件序列也可以依赖于第二事件序列，从而两者的执行顺序可以为先执行第二事件序列再执行第一事件序列。

具体地，在对目标软件执行第一事件序列之前，先获取待执行的第一事件序列和第二事件序列；然后，判断第二事件序列中的第三事件执行后跳转到的第三界面与第一事件序列中的第四事件对应的第四界面之间的关系，如果第二事件序列中的第三事件执行后跳转到的第三界面是第一事件序列中的第四事件对应的第四界面，则确定第二事件序列的执行顺序在第一事件序列之前。

对应地，在执行第二事件序列的过程中每跳转到一个界面时，记录界面的界面信息。并在执行第二事件序列到达第一目标时间时，根据第三事件的界面信息执行第一事件序列，该第一目标时间包括以下至少一种：执行完第二事件序列的第三时间、到达第三界面的第四时间、比第四时间早预设时长的时间。

可以理解的是，当第一事件序列依赖于第二事件序列时，第一事件序列的开始执行时间，与前述当第二事件序列依赖于第一事件序列时，第二事件序列的开始执行时间原理相同，本公开实施例在此不再赘述。

对应于上文实施例的测试方法，图11是本公开实施例提供的一种测试装置的结构框图。为了便于说明，仅示出了与本公开实施例相关的部分。参照图11，上述测试装置300包括：界面信息确定模块301、突发处理事件获取模块302和继续测试模块303。

其中，界面信息确定模块301，用于在对目标软件执行第一事件序列的过程中，若所述第一事件序列中的目标事件执行失败，则确定所述目标事件对应的目标界面信息，所述第一事件序列中包括的事件用于触发所述目标软件进行界面跳转，以测试所述界面跳转是否异常。

突发处理事件获取模块302，用于获取所述目标界面信息对应的目标界面中可执行的突发处理事件，所述突发处理事件用于消除所述目标界面中导致所述目标事件执行失败的异常显示对象。

继续测试模块303，用于在所述目标界面中执行所述突发处理事件之后，从所述目标事件开始继续执行所述第一事件序列。

可选地，所述突发处理事件获取模块302还用于：

从事件库中获取事件类型为目标类型，且界面信息与所述目标界面信息匹配的事件，作为在所述目标界面中可执行的突发处理事件，所述目标类型用于指示所述事件为所述突发处理事件。

可选地，所述界面信息包括以下至少一种：所述事件所对应的界面标识、所述界面标识对应的界面所归属的应用程序、所述应用程序的版本信息。

可选地，所述异常显示对象是随机显示在所述目标界面中的显示对象。

可选地，所述异常显示对象包括：弹窗。

可选地，所述装置还包括：

事件序列获取模块，用于获取至少两个事件序列；

事件序列合并模块，用于当所述至少两个事件序列中包括至少一个相同事件和至少一个不同事件时，根据所述相同事件将所述至少两个事件序列合并为所述第一事件序列，所述第一事件序列中包括所述相同事件和所述不同事件，所述不同事件将所述第一事件序列拆分为至少两条执行路径。

可选地，所述装置还包括：

待执行序列获取模块，用于在对目标软件执行第一事件序列之前，获取待执行的所述第一事件序列和第二事件序列。

执行顺序确定模块，用于若所述第一事件序列中的第一事件执行后跳转到的第一界面是所述第二事件序列中的第二事件对应的第二界面，则确定所述第一事件序列的执行顺序在所述第二事件序列之前。

可选地，所述装置还包括：

界面信息记录模块，用于在执行所述第一事件序列的过程中每跳转到一个界面时，记录所述界面的界面信息。

第二事件序列执行模块，用于在执行所述第一事件序列到达目标时间时，根据所述第一界面的界面信息执行所述第二事件序列，所述目标时间包括以下至少一种：执行完所述第一事件序列的第一时间、到达所述第一界面的第二时间、比所述第二时间早预设时长的时间。

本实施例提供的测试装置，可用于执行上述图2所示的方法实施例的技术方案，其实现原理和技术效果类似，本实施例此处不再赘述。

图12是本公开实施例提供的一种电子设备600的结构框图。该电子设备600包括存储器602和至少一个处理器601。

其中，存储器602存储计算机执行指令。

至少一个处理器601执行存储器602存储的计算机执行指令，使得电子设备601实现前述图2中的方法。

此外，该电子设备还可以包括接收器603和发送器604，接收器603用于接收从其余装置或设备的信息，并转发给处理器601，发送器604用于将信息发送到其余装置或设备。

在第一方面的第一种示例中，本公开实施例提供了一种测试方法，所述方法包括：

在对目标软件执行第一事件序列的过程中，若所述第一事件序列中的目标事件执行失败，则确定所述目标事件对应的目标界面信息，所述第一事件序列中包括的事件用于触发所述目标软件进行界面跳转，以测试所述界面跳转是否异常。

获取所述目标界面信息对应的目标界面中可执行的突发处理事件，所述突发处理事件用于消除所述目标界面中导致所述目标事件执行失败的异常显示对象。

在所述目标界面中执行所述突发处理事件之后，从所述目标事件开始继续执行所述第一事件序列。

基于第一方面的第一种示例，在第一方面的第二种示例中，所述获取所述目标界面信息对应的目标界面中可执行的突发处理事件，包括：

从事件库中获取事件类型为目标类型，且界面信息与所述目标界面信息匹配的事件，作为在所述目标界面中可执行的突发处理事件，所述目标类型用于指示所述事件为所述突发处理事件。

基于第一方面的第二种示例，在第一方面的第三种示例中，所述界面信息包括以下至少一种：所述事件所对应的界面标识、所述界面标识对应的界面所归属的应用程序、所述应用程序的版本信息。

基于第一方面的第一至第三任一种示例，在第一方面的第四种示例中，所述异常显示对象是随机显示在所述目标界面中的显示对象。

基于第一方面的第四种示例，在第一方面的第五种示例中，所述异常显示对象包括：弹窗。

基于第一方面的第一至第三任一种示例，在第一方面的第六种示例中，所述方法还包括：

获取至少两个事件序列。

当所述至少两个事件序列中包括至少一个相同事件和至少一个不同事件时，根据所述相同事件将所述至少两个事件序列合并为所述第一事件序列，所述第一事件序列中包括所述相同事件和所述不同事件，所述不同事件将所述第一事件序列拆分为至少两条执行路径。

基于第一方面的第一至第三任一种示例，在第一方面的第七种示例中，在对目标软件执行第一事件序列之前，所述方法还包括：

获取待执行的所述第一事件序列和第二事件序列。

若所述第一事件序列中的第一事件执行后跳转到的第一界面是所述第二事件序列中的第二事件对应的第二界面，则确定所述第一事件序列的执行顺序在所述第二事件序列之前。

基于第一方面的第七种示例，在第一方面的第八种示例中，所述方法还包括：

在执行所述第一事件序列的过程中每跳转到一个界面时，记录所述界面的界面信息。

在执行所述第一事件序列到达目标时间时，根据所述第一界面的界面信息执行所述第二事件序列，所述目标时间包括以下至少一种：执行完所述第一事件序列的第一时间、到达所述第一界面的第二时间、比所述第二时间早预设时长的时间。

在第二方面的第一种示例中，提供了一种测试装置，所述装置包括：

界面信息确定模块，用于在对目标软件执行第一事件序列的过程中，若所述第一事件序列中的目标事件执行失败，则确定所述目标事件对应的目标界面信息，所述第一事件序列中包括的事件用于触发所述目标软件进行界面跳转，以测试所述界面跳转是否异常。

突发处理事件获取模块，用于获取所述目标界面信息对应的目标界面中可执行的突发处理事件，所述突发处理事件用于消除所述目标界面中导致所述目标事件执行失败的异常显示对象。

继续测试模块，用于在所述目标界面中执行所述突发处理事件之后，从所述目标事件开始继续执行所述第一事件序列。

基于第二方面的第一种示例，在第二方面的第二种示例中，所述突发处理事件获取模块还用于：

从事件库中获取事件类型为目标类型，且界面信息与所述目标界面信息匹配的事件，作为在所述目标界面中可执行的突发处理事件，所述目标类型用于指示所述事件为所述突发处理事件。

基于第二方面的第二种示例，在第二方面的第三种示例中，所述界面信息包括以下至少一种：所述事件所对应的界面标识、所述界面标识对应的界面所归属的应用程序、所述应用程序的版本信息。

基于第二方面的第一至第三任一种示例，在第二方面的第四种示例中，所述异常显示对象是随机显示在所述目标界面中的显示对象。

基于第二方面的第四种示例，在第二方面的第五种示例中，所述异常显示对象包括：弹窗。

基于第二方面的第一至三任一种示例，在第二方面的第五种示例中，所述装置还包括：

事件序列获取模块，用于获取至少两个事件序列。

事件序列合并模块，用于当所述至少两个事件序列中包括至少一个相同事件和至少一个不同事件时，根据所述相同事件将所述至少两个事件序列合并为所述第一事件序列，所述第一事件序列中包括所述相同事件和所述不同事件，所述不同事件将所述第一事件序列拆分为至少两条执行路径。

基于第二方面的第一至三任一种示例，在第二方面的第七种示例中，所述装置还包括：

待执行序列获取模块，用于在对目标软件执行第一事件序列之前，获取待执行的所述第一事件序列和第二事件序列。

执行顺序确定模块，用于若所述第一事件序列中的第一事件执行后跳转到的第一界面是所述第二事件序列中的第二事件对应的第二界面，则确定所述第一事件序列的执行顺序在所述第二事件序列之前。

基于第二方面的第七种示例，在第二方面的第八种示例中，所述装置还包括：

界面信息记录模块，用于在执行所述第一事件序列的过程中每跳转到一个界面时，记录所述界面的界面信息。

第二事件序列执行模块，用于在执行所述第一事件序列到达目标时间时，根据所述第一界面的界面信息执行所述第二事件序列，所述目标时间包括以下至少一种：执行完所述第一事件序列的第一时间、到达所述第一界面的第二时间、比所述第二时间早预设时长的时间。

第三方面，根据本公开的一个或多个实施例，提供了一种电子设备，包括：至少一个处理器和存储器。

所述存储器存储计算机执行指令。

所述至少一个处理器执行所述存储器存储的计算机执行指令，使得所述电子设备实现第一方面任一项所述的方法。

第四方面，根据本公开的一个或多个实施例，提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机执行指令，当处理器执行所述计算机执行指令时，使计算设备实现第一方面任一项所述的方法。

第五方面，根据本公开的一个或多个实施例，提供了一种计算机程序，所述计算机程序用于实现第一方面任一项所述的方法。

以上描述仅为本公开的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解，本公开中所涉及的公开范围，并不限于上述技术特征的特定组合而成的技术方案，同时也应涵盖在不脱离上述公开构思的情况下，由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本公开中公开的(但不限于)具有类似功能的技术特征进行互相替换而形成的技术方案。

此外，虽然采用特定次序描绘了各操作，但是这不应当理解为要求这些操作以所示出的特定次序或以顺序次序执行来执行。在一定环境下，多任务和并行处理可能是有利的。同样地，虽然在上面论述中包含了若干具体实现细节，但是这些不应当被解释为对本公开的范围的限制。在单独的实施例的上下文中描述的某些特征还可以组合地实现在单个实施例中。相反地，在单个实施例的上下文中描述的各种特征也可以单独地或以任何合适的子组合的方式实现在多个实施例中。

尽管已经采用特定于结构特征和/或方法逻辑动作的语言描述了本主题，但是应当理解所附权利要求书中所限定的主题未必局限于上面描述的特定特征或动作。相反，上面所描述的特定特征和动作仅仅是实现权利要求书的示例形式。