CN111782508A - 自动测试方法、装置、电子设备和存储介质 - Google Patents

Abstract

本公开关于自动测试方法、装置、电子设备和存储介质，所述方法包括：响应于所接收的测试执行指令，执行目标测试用例，其中，目标测试用例用于对目标场景下实现的目标功能进行测试；在监测到目标测试用例发生报错事件的情况下，获取报错事件的报错场景信息；若报错场景信息对应中间场景，则重新开始执行目标测试用例，其中，中间场景是目标测试用例的测试路径上除目标场景之外的测试场景。

Description

自动测试方法、装置、电子设备和存储介质

技术领域

本公开涉及软件测试领域，尤其涉及自动测试方法、装置、电子设备和存储介质。

背景技术

为了发现程序软件运行过程中因延时或产品策略等原因可能导致的功能错误，需要在软件开发阶段使用测试用例对程序软件的目标功能进行测试。在测试过程中，若发生报错事件则表示该目标功能对应的场景中存在功能错误。在相关技术中，在发生报错事件后重试测试用例直至测试用例正常结束或到达测试次数上限。

但是，程序软件中待测试的目标功能对应的目标场景通常需要经过多个中间场景才能够到达，即目标功能的测试路径上通常包含中间场景和目标场景。在这种情况下，往往只有目标场景中存在的功能错误才是真正需要解决的关键错误，而中间场景发生的非关键错误则无需特殊处理。因此，在测试过程中发生报错事件后直接重试测试用例，不仅整体上降低了对目标功能的测试效率，而且可能因重试通过而导致对目标场景中存在的关键错误的漏检。

发明内容

本公开提供了一种自动测试方法、装置、电子设备和存储介质，以至少解决相关技术中的技术问题。本公开的技术方案如下：

根据本公开实施例的第一方面，提出一种自动测试方法，包括：

响应于所接收的测试执行指令，执行目标测试用例，其中，所述目标测试用例用于对目标场景下实现的目标功能进行测试；

在监测到所述目标测试用例发生报错事件的情况下，获取所述报错事件的报错场景信息；

若所述报错场景信息对应中间场景，则重新开始执行所述目标测试用例，其中，所述中间场景是所述目标测试用例的测试路径上除所述目标场景之外的测试场景。

可选的，所述获取所述报错事件的报错场景信息，包括：

确定基于所述报错事件生成的函数调用堆栈信息；

在所述函数调用堆栈信息中查询所述报错事件对应的报错函数名；

根据所述报错函数名确定所述报错事件的报错场景信息。

可选的，所述报错场景信息包括场景类型，所述根据所述报错函数确定所述报错事件的报错场景信息，包括：

按照对应于所述目标测试用例的第一映射关系，确定所述报错函数名所归属函数类的报错类名，所述第一映射关系包括函数名和函数类的类名之间的对应关系；

按照对应于所述目标测试用例的第二映射关系查询匹配于所述报错类名的场景类型，所述第二映射关系包括函数类的类名与场景类型之间的对应关系，或者，

按照对应于所述目标测试用例的第三映射关系查询匹配于所述报错函数名和所述报错类名的场景类型，所述第三映射关系包括函数名、函数类的类名与场景类型之间的对应关系；其中，所述场景类型包括所述中间场景和所述目标场景。

可选的，还包括：

确定与所述目标场景对应的测试路径，创建所述目标场景与所述中间场景之间的目标映射关系；

根据所述目标映射关系以及所述目标场景和所述中间场景分别对应的测试函数，构建所述目标测试用例。

可选的，所述目标映射关系中包括第一映射关系，还包括第二映射关系和第三映射关系两者至少之一；其中，

所述第一映射关系，根据所述目标测试用例中的测试函数的函数名和所述测试函数所归属函数类的类名之间的对应关系创建得到；

所述第二映射关系，根据所述目标测试用例中的测试函数所归属函数类的类名和所述测试函数所对应测试场景的场景类型之间的对应关系创建得到；

所述第三映射关系，根据所述目标测试用例中的测试函数的函数名、所述测试参数所归属函数类的类名和所述测试函数所对应测试场景的场景类型三者之间的对应关系创建得到。

可选的，还包括：

若所述报错场景信息对应所述目标场景，则结束所述目标测试用例的执行过程。

根据本公开实施例的第二方面，提出一种自动测试装置，包括：

用例执行模块，被配置为响应于所接收的测试执行指令，执行目标测试用例，其中，所述目标测试用例用于对目标场景下实现的目标功能进行测试；

报错获取模块，被配置为在监测到所述目标测试用例发生报错事件的情况下，获取所述报错事件的报错场景信息；

重新测试模块，被配置为若所述报错场景信息对应中间场景，则重新开始执行所述目标测试用例，其中，所述中间场景是所述目标测试用例的测试路径上除所述目标场景之外的测试场景。

可选的，所述报错获取模块还被配置为：

确定基于所述报错事件生成的函数调用堆栈信息；

在所述函数调用堆栈信息中查询所述报错事件对应的报错函数名；

根据所述报错函数名确定所述报错事件的报错场景信息。

可选的，所述报错场景信息包括场景类型，所述报错获取模块还被配置为：

按照对应于所述目标测试用例的第一映射关系，确定所述报错函数名所归属函数类的报错类名，所述第一映射关系包括函数名和函数类的类名之间的对应关系；

按照对应于所述目标测试用例的第二映射关系查询匹配于所述报错类名的场景类型，所述第二映射关系包括函数类的类名与场景类型之间的对应关系，或者，

按照对应于所述目标测试用例的第三映射关系查询匹配于所述报错函数名和所述报错类名的场景类型，所述第三映射关系包括函数名、函数类的类名与场景类型之间的对应关系；其中，所述场景类型包括所述中间场景和所述目标场景。

可选的，还包括：

路径确定模块，被配置为确定与所述目标场景对应的测试路径，创建所述目标场景与所述中间场景之间的目标映射关系；

用例构建模块，被配置为根据所述目标映射关系以及所述目标场景和所述中间场景分别对应的测试函数，构建所述目标测试用例。

可选的，所述目标映射关系中包括第一映射关系，还包括第二映射关系和第三映射关系两者至少之一；其中，

所述第一映射关系，根据所述目标测试用例中的测试函数的函数名和所述测试函数所归属函数类的类名之间的对应关系创建得到；

所述第二映射关系，根据所述目标测试用例中的测试函数所归属函数类的类名和所述测试函数所对应测试场景的场景类型之间的对应关系创建得到；

所述第三映射关系，根据所述目标测试用例中的测试函数的函数名、所述测试参数所归属函数类的类名和所述测试函数所对应测试场景的场景类型三者之间的对应关系创建得到。

可选的，还包括：

测试结束模块，被配置为若所述报错场景信息对应所述目标场景，则结束所述目标测试用例的执行过程。

根据本公开实施例的第三方面，提出一种电子设备，包括：

处理器；

用于存储所述处理器可执行指令的存储器；

其中，所述处理器被配置为执行所述指令，以实现如上述任一实施例所述的自动测试方法。

根据本公开实施例的第四方面，提出一种存储介质，当所述存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行上述任一实施例所述的自动测试方法。

本公开的实施例提供的技术方案至少带来以下有益效果：

根据本公开的实施例，将测试路径上的场景预先划分为中间场景和目标场景后分别预定义函数类并利用对应的测试函数构建测试用例，并在报错事件发生后从报错场景信息中提取用于表征报错事件对应的场景类型，因此能够在检测到该场景类型为目标场景的情况下，直接终止针对目标功能的测试。实际上，因为对目标功能进行测试的目的就是发现目标场景中的关键错误，所以在目标场景中已经发生关键错误的情况下进行重试是无意义的。因此，本公开的上述方案在检测出目标场景中发生的关键错误后直接终止测试，不再进行后续无意义的重试，不仅在一定程度上提高了针对目标功能的整体测试效率；而且从根本上避免了因重试通过而导致的对目标场景中关键错误的漏检。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理，并不构成对本公开的不当限定。

图1是交互界面对应的中间场景和目标场景示意图；

图2是根据本公开的实施例示出的一种自动测试方法流程图；

图3是根据本公开的实施例示出的另一种自动测试方法流程图；

图4是根据本公开的实施例示出的一种中间场景对应的函数类继承关系示意图；

图5是根据本公开的实施例示出的一种目标场景对应的函数类继承关系示意图；

图6是根据本公开的实施例示出的一种测试过程对应的函数类与函数调用示意图；

图7是根据本公开的实施例示出的一种自动测试装置框图；

图8是根据本公开的实施例示出的一种电子设备的结构图。

具体实施方式

为了使本领域普通人员更好地理解本公开的技术方案，下面将结合附图，对本公开实施例中的技术方案进行清楚、完整地描述。

需要说明的是，本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本公开的实施例能够以除了在这里图示或描述的那些以外的顺序实施。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。

为了发现程序软件运行过程中因延时或产品策略等原因可能导致的功能错误，需要在软件开发阶段使用测试用例对程序软件的目标功能进行测试。在测试过程中，若发生报错事件则表示该目标功能对应的场景中存在功能错误。在相关技术中，在发生报错事件后则重试测试用例直至测试用例正常结束或到达测试次数上限。

但是，程序软件中待测试的目标功能对应的目标场景通常需要经过多个中间场景才能够到达，即目标功能的测试路径上通常包含中间场景和目标场景。以图1所示的交互界面为例进行说明。如图1所示，目标软件中待测试的目标功能对应的目标功能区域位于目标界面中，从目标软件的启动界面到达目标界面需要经过一跳转界面。此时，启动界面和跳转界面分别对应中间场景1和中间场景2，目标界面对应目标场景，即目标功能的测试路径包括中间场景1、中间场景2和目标场景。在使用测试用例对目标功能进行测试时，若启动界面和跳转界面发生功能错误，则这类错误对于目标功能的实现影响不大——称其为非关键错误；而只有在目标界面中发生的错误才是对目标功能具有实质性影响的错误——称其为关键错误。

对目标功能进行测试的目的即为发现上述关键错误，因此在测试过程中发生报错事件后，若报错事件对应的是目标界面中的关键错误，实际上测试的目标已经达到。此时若再对测试用例进行重试，不仅增大了测试工作量而导致针对目标功能的整体测试效率降低；而且在关键错误是概率性错误的情况下可能重试通过，并最终导致关键错误未被有效捕捉而发生漏检，从而失去对目标功能进行测试的意义。

为解决相关技术中发生报错事件后直接进行重试存在的上述技术问题，本公开提出一种自动测试方法，该方法应用于软件测试设备。图2是根据本公开的实施例示出的一种自动测试方法流程图，如图2所示，该测试过程可以包括：

步骤202，响应于所接收的测试执行指令，执行目标测试用例，其中，所述目标测试用例用于对目标场景下实现的目标功能进行测试。

首先需要说明的是，本公开方案所涉及的场景，可以包括单独的UI(UserInterface，用户界面)界面，也可以包括UI界面及与其相关的非可视化步骤，甚至可以为不存在显示界面的后台处理步骤对应的非可视化场景，本公开对此并不进行限制。

在测试过程中，可以针对同一程序软件的多个目标场景同时进行多项测试，其中对于同一目标场景可以同时采用多个测试用例对多个目标功能进行多项测试，在本公开涉及到的测试中，仅关注采用一测试用例对任一程序软件的任一目标场景进行测试的过程。上述测试用例是利用归属于继承预设的函数类的函数子类的测试函数构建的，上述预设的函数类包括对应于中间场景的中间函数类和对应于目标场景的目标函数类；上述函数子类包括继承中间函数类的中间函数子类和继承目标函数类的目标函数子类；上述测试函数包括归属于中间函数子类的中间测试函数和归属于目标函数子类的目标测试函数。其中，上述中间测试函数类、目标测试函数类、中间测试函数以及目标测试函数的个数均可以为一个或多个。使用上述中间测试函数和目标测试函数构建的测试用例可以是仅针对某一目标场景所实现的某一目标功能构建的针对性测试用例，也可以是利用上述函数构建的并不针对特定目标场景或特定目标功能的通用测试用例，本公开对于测试用例所使用函数和函数类的个数、以及测试用例的适用性并不进行限制。

为描述简洁，下文解释性语句中将利用一个测试用例针对针对某一目标场景所实现的某一目标功能进行测试的过程简称为“测试过程”，特此说明。显然，在使用多个测试用例对目标场景实现的目标功能进行测试的过程中，每一测试用例的运行过程即为该测试用例对应的测试过程。

步骤204，在监测到所述目标测试用例发生报错事件的情况下，获取所述报错事件的报错场景信息。

在任一测试过程中，某测试函数发现程序软件的功能错误后，可以触发报错事件。本公开对于可触发报错事件的错误类型、错误特征等相关参数并不进行限制，这类参数可由测试人员预先设置，例如，上述错误可以为软件测试过程中的Error类错误，也可以为Warning类错误。

通常，在任一测试过程中发生报错事件后，会立即停止测试用例的当前测试过程，并产生相应的报错场景信息。在一实施例中，可以在测试结束后，读取报错事件对应的报错场景信息。此时，可以在针对目标场景的多个测试过程全部结束后统一读取上述报错场景信息，以避免对进行中的测试过程产生影响，同时在目标场景的多个测试过程均发生错误的情况下，便于对多个错误进行统一分析以整体解决功能错误。

在另一实施例中，也可以通过测试监听器获取报错场景信息：在测试过程中通过测试监听器监听测试，若测试监听器监听到报错事件，则通过测试监听器获取报错事件对应的报错场景信息。实际上，上述测试监听器实现的是对测试过程的实时监听，在同时使用多个测试用例对目标场景进行测试的情况下，不必等待全部测试用例停止后即可及时获知该报错事件的发生并获取相应的报错场景信息，从而对报错事件对应的错误进行及时有效的处理，一定程度上提升了针对目标功能的测试效率。

一般地，软件开发系统的自动测试框架会提供测试监听器，以便于捕捉测试过程中的报错事件以及相应的报错场景信息。例如，若测试在安卓Android测试框架下进行，此时可以通过Android测试框架提供的org.junit.runner.notification.RunListener监听器，利用testRunFinish方法获取报错事件对应的报错场景信息。以测试框架提供的原生监听器作为测试监听器，能够保证测试过程中监听器对程序软件及测试用例的兼容性。

在一实施例中，上述报错场景信息可以为函数调用堆栈信息，此时，可以先确定基于报错事件生成的函数调用堆栈信息，然后在函数调用堆栈信息中查询报错事件对应的报错函数名，并根据报错函数名确定报错事件的报错场景信息。因为函数调用堆栈信息中不仅包含触发报错事件的报错函数，而且包含该函数之前的函数调用记录，因此在报错事件对应的函数调用堆栈信息中查询发生报错的测试函数，有助于准确确定出触发报错事件的测试函数的函数名及其对应的函数调用记录，从而便于更加准确的分析报错情况。

进一步的，上述报错场景信息可以包括场景类型，例如中间场景或目标场景；在确定出报错函数名的情况下，可以通过预先建立的映射关系确定上述报错场景信息。例如，可以先按照对应于目标测试用例的第一映射关系，确定报错函数名所归属函数类的报错类名，其中，该第一映射关系包括函数名和函数类的类名之间的对应关系。然后，作为一示例性实施例，可以按照对应于目标测试用例的第二映射关系查询匹配于报错类名的场景类型，其中，该第二映射关系包括函数类的类名与场景类型之间的对应关系。此时，直接根据报错函数所归属函数类的类名确定其对应的场景类型，所使用的第二映射关系仅包含简单的函数类名和场景类型，因此第二映射关系的建立较为简便，降低了建立映射关系的工作量；而且由于只需要从报错场景信息中提取触发报错事件的测试函数所归属函数类的类名，并使用相应的类名查询对应的场景类型，信息提取及类型查询的信息量较少，从而一定程度上加快了信息提取及类型查询的速度。

或者，作为另一示例性实施例，也可以按照对应于目标测试用例的第三映射关系查询匹配于报错函数名和报错类名的场景类型，第三映射关系包括函数名、函数类的类名与场景类型之间的对应关系；其中，场景类型包括中间场景和目标场景。此时，使用不仅包含函数类和函场景类型，还包括函数名的第三映射关系查询相应的场景类型，能够避免测试用例中同名测试函数可能导致的查询结果错误，而且能够在确定出场景类型后准确定位功能错误对应的错误位置，从而不仅提高了场景类型查询的准确度，也在一定程度上保证了对程序功能错误的排查及处理效率。

在一实施例中，可以通过下述方式预先构建目标测试用例：确定与目标场景对应的测试路径，并创建目标场景与中间场景之间的目标映射关系；然后根据该目标映射关系以及目标场景和中间场景分别对应的测试函数，构建目标测试用例。其中，上述测试路径包括中间场景和目标场景，目标测试用例的具体构建过程可以参见相关技术中公开的内容，此处不再赘述。通过预先创建的目标映射关系构建针对目标场景所实现目标功能的目标测试用例，保证了所构建目标测试用例的中测试函数、测试函数所归属函数类和场景类型三者之间的对应关系，进而在发生报错事件的情况下，能够基于预先建立的目标映射关系准确无误的判定报错的测试函数对应的场景类型，保证了准确高效的处理报错事件。

进一步的，上述目标映射关系中可以包括第一映射关系，还可以包括第二映射关系和第三映射关系两者至少之一；其中，第一映射关系，根据目标测试用例中的测试函数的函数名和测试函数所归属函数类的类名之间的对应关系创建得到；第二映射关系，根据目标测试用例中的测试函数所归属函数类的类名和测试函数所对应测试场景的场景类型之间的对应关系创建得到；第三映射关系，根据目标测试用例中的测试函数的函数名、测试参数所归属函数类的类名和测试函数所对应测试场景的场景类型三者之间的对应关系创建得到。可以理解的是，上述三种映射关系可以是相互独立的，例如，三者分别对应三份映射关系表；三者之间也可以是相互关联的，例如第三映射关系可以包含第一映射关系，即二者对应同一份映射关系表。

步骤206，若所述报错场景信息对应中间场景，则重新开始执行所述目标测试用例，其中，所述中间场景是所述目标测试用例的测试路径上除所述目标场景之外的测试场景。

若确定出报错场景信息对应中间场景，则说明报错事件发生在中间场景下，即被测试程序软件发生的功能错误为中间场景下的非关键错误(例如概率性错误)，因此，可以重新开始执行目标测试用例再次对目标功能进行测试，以便排除该非关键错误，避免后续针对该非关键词错误进行详细排查带来的测试效率降低。

在一实施例中，可以预设使用目标测试用例对目标功能或目标功能对应的中间场景进行测试的测试次数上限，并在每次重试之前判断当前已测试次数是否已达到上述测试次数上限，若测试次数已达到预设的测试次数上限，可以终止对目标功能的测试，以避免非概率性功能错误无限重试导致陷入死循环；若测试次数未达到上述测试次数上限，可以使用目标测试用例重新对目标功能进行测试。上述测试次数上限可以根据程序软件的性质、目标功能属性、测试时间、测试资源占用率等实际情况进行预设，本公开对此并不进行限制。

在一实施例中，可以在报错场景信息对应目标场景的情况下，直接结束目标测试用例的执行过程。检测出报错场景信息对应于目标场景，即说明上述报错事件对应的功能错误是发生在目标场景下的关键错误，此时已经实现发现目标场景中的关键错误这一检测目的，因此可以直接终止针对目标功能的测试，以节省测试时间提高测试效率。

进一步的，在报错场景信息对应目标场景的情况下，也可以展示关于报错场景信息的报错提醒信息；并在接收到针对报错场景信息的排查指令后，按照排查指令对目标场景进行相应的排查处理。其中，上述报错提醒信息可以包括上述报错场景信息中的部分或全部信息，如错误类型、错误对象ID、触发报错事件的测试函数的函数名，以及该测试函数所归属函数类的类名等，以便准确展示给测试人员。此时，在检测出报错事件对应的功能错误是位于目标场景中的关键错误的情况下展示报错提醒信息，便于测试人员查看该报错提醒信息后获知上述报错事件的发生，并针对该报错事件对应的功能错误发出排查指令，以人工排查并解决上述功能错误，从而实现了针对目标场景的关键错误的人工排查与处理。

根据本公开的实施例，在测试之前构建测试用例阶段即将测试路径上的场景划分为中间场景和目标场景，并在发生报错事件后从报错场景信息中提取用于表征报错事件对应的场景类型的报错场景信息，因此能够在检测到报错场景信息对应于中间场景的情况下，直接重新执行目标测试用例，而在在检测出目标场景中发生的关键错误后直接终止测试，不再进行后续无意义的重试。不仅提高了针对目标功能的整体测试效率，而且从根本上避免了因重试通过而导致的对目标场景中关键错误的漏检。

由图1可知，中间界面和目标界面分别对应前述方法中的中间场景和目标场景，应当理解的是，实际上中间界面的个数可以为一个或多个。下面结合图3-图6，对利用构建的测试用例对目标界面下所实现的目标功能进行测试的过程进行详细描述。参见图3所示另一种自动测试方法流程图，该方法应用于软件测试设备，该方法可以包括：

步骤302，预定义对应于不同类型界面的预设函数类、继承预设函数类的函数子类以及归属于函数子类的测试函数。

对于目标软件中待测试的目标功能，首先确定目标功能所在目标界面对应的测试路径，然后确定测试路径上的目标界面以及除目标界面以外的中间界面，并预定义对应于不同类型界面的预设函数类、继承预设函数类的函数子类以及归属于函数子类的测试函数。其中，确定上述测试路径的具体过程可以参见相关技术中公开的内容，本公开对此并不进行限制。对于目标界面所实现的目标功能，其对应的测试路径可以有多个，相应的，不同测试路径可以分别对应不同的测试用例，以尽可能全面的发现目标功能相关的功能错误。

对应于图1所示的中间界面和目标界面构成的测试路径，可以预定义中间界面对应的中间函数类和继承该中间函数类的中间函数子类，二者之间的继承关系可参见图4。如图4所示，继承中间函数类MiddleTest的中间函数子类分别为FirstUi和SecondUi；归属于中间函数子类FirstUi和SecondUi的测试函数分别为中间测试函数doNext_1()和中间测试函数doNext_2()。可以理解的是，上述中间测试函数doNext_1()和doNext_2()分别用于对启动界面和跳转界面进行测试。由图4所示的函数类和函数子类的继承关系可知，中间界面对应的全部函数子类均继承自对应于中间界面的同一个基础函数类(即中间函数类MiddleTest)，因此在报错场景信息中触发报错事件的检测函数无论归属于任一中间函数子类，都能够按照上述继承关系确定该检测函数对应的函数类为中间函数类，进而确定相应的功能成为是存在于中间界面的非关键错误，保证了错误判断的准确性。

相应的，也可以预定义目标界面对应的目标函数类和继承该目标函数类的目标函数子类，二者之间的继承关系可参见图5。如图5所示，继承目标函数类TargetTest的目标函数子类为TargetUi；归属于该目标函数子类TargetUi的测试函数为目标测试函数runTest()。可以理解的是，上述目标测试函数runTest()用于对目标界面实现的目标功能进行测试。

无论是中间界面或目标界面，界面对应的测试函数、函数子类和函数类三者之间的对应关系都应当符合测试路径上包含的中间界面和目标界面的对应关系，以保证后续界面类型识别的准确性。而且，上述各函数子类中除包含测试函数外，还可以包含接口类函数等测试相关的其他函数，不再一一赘述。

图4和图5仅是示例性的，对于上述中间函数子类和目标函数子类，其个数可以为一个或多个；类似的，归属于任一函数子类的测试函数也可以为一个或多个，上述函数类和测试函数的个数可以根据目标场景及测试路径的具体情况进行合理选择，本公开对此并不进行限制。在具体使用时，预定义的函数类的类名以及测试函数的函数名可以根据具体场景自定义设置，并非仅限于本实施例所示的上述名称。

步骤304，创建目标界面与中间界面之间的目标映射关系。

在本实施例中，目标映射关系中可以包括第一映射关系，还可以包括第二映射关系和第三映射关系两者至少之一。其中，第一映射关系，可以根据目标测试用例中的测试函数的函数名和测试函数所归属函数子类和/或函数类的类名之间的对应关系创建得到；第二映射关系，根据目标测试用例中的测试函数所归属函数子类和/或函数类的类名和测试函数所对应测试场景的场景类型之间的对应关系创建得到；第三映射关系，根据目标测试用例中的测试函数的函数名、测试参数所归属函数子类和/或函数类的类名和测试函数所对应测试场景的场景类型三者之间的对应关系创建得到。可以理解的是，上述三种映射关系可以是相互独立的，例如，三者分别对应三份映射关系表；三者之间也可以是相互关联的，例如第三映射关系可以包含第一映射关系，即二者对应同一份映射关系表。

步骤306，基于测试函数和目标映射关系构建针对目标功能的目标测试用例。

在预定义上述函数类、函数子类及测试函数后，可以基于上述测试函数构建针对目标功能的目标测试用例。在一实施例中，可以按照测试路径上的中间界面和目标界面的第一时序关系，以及界面内各待触发元素在测试路径上对应的第二时序关系有序调用相应的测试函数，因此，针对目标功能构建的上述目标测试用例就是目标功能对应的测试函数的有序集合。

可以使用预定义的上述全部测试函数构建针对目标功能的目标测试用例，也可以使用上述全部测试函数中的部分测试函数构建针对目标功能的目标测试用例，即本公开对于构建目标测试用例的测试函数个数并不进行限制，但应保证用于构建针对目标功能的目标测试用例的测试函数及其所归属函数子类和函数类的对应关系满足上述中间界面和目标界面的对应关系，以保证测试用例进行软件测试的有效性及识别界面对应的场景类型的准确性。在一实施例中，可以针对目标功能的不同测试路径分别构建至少一个目标测试用例。

步骤308，使用测试用例对目标功能进行测试。

因为针对目标功能创建的目标测试用例就是目标功能对应的测试函数的有序集合，所以运行上述目标测试用例对目标功能进行测试的过程，即为有序调用目标测试用例所包含的测试函数触发测试路径上中间界面和目标界面所包含元素以实现被触发元素所对应目标功能的过程。

在针对目标功能的目标测试用例执行过程中，目标测试函数的调用时序以及测试函数与函数子类的对应关系可参见图6。如图6所示，在测试函数开始运行后，首先调用并执行对应于启动界面的中间测试函数doNext_1()，该函数执行完后显示界面由启动界面转入跳转界面；然后调用并执行对应于跳转界面的中间测试函数doNext_2()，该函数执行完后显示界面由跳转界面转入目标界面；最后调用并执行对应于目标界面的目标测试函数runTest()，以实现对目标界面中目标功能区域所实现目标功能的测试。当最终被调用的测试函数结束运行后，整个测试用例即运行结束。

步骤310，判断是否发生报错事件。

可以理解的是，图6所示的目标测试用例表示的是测试过程未发生报错事件的情况下的测试过程。实际上，上述中间测试函数doNext_1()、中间测试函数doNext_2()和目标测试函数runTest()执行过程中均有可能发现相应界面中存在的功能错误并触发报错事件。通常情况下，在测试过程中发生报错事件后，会立即停止当前测试过程，并产生相应的错误堆栈信息。

在一实施例中，若针对目标功能同时执行多个目标测试用例，则为了避免对处于测试过程中的目标测试用例产生影响，并在多个测试过程发生错误的情况下对多个错误进行统一分析，可以在测试结束后统一读取报错事件对应的错误堆栈信息。此时，若因发生报错事件导致测试停止，则可以获取到相应的错误堆栈信息；反之，若测试过程中未发生报错事件，即测试过程正常停止，则此时不存在错误堆栈信息。因此，在测试结束后判定是否存在保存信息即可获知测试过程中是否发生报错事件。

在一实施例中，为及时获知报错事件的发生并进行相应处理，可以通过测试监听器获取错误堆栈信息。以针对目标功能的测试在Android测试框架下进行为例，可以采用Android测试框架提供的org.junit.runner.notification.RunListener监听器作为测试监听器，对上述测试过程进行实时监听。对于其他测试框架下的软件软件测试也可以采用相应测试框架提供的其他原生监听器作为测试监听器，以保证测试过程中监听器对程序软件及目标测试用例的兼容性，提高测试效率。当然，也可以不采用测试框架提供的原生监听器，而采用第三方监听器或自定义监听器对上述检测过程中可能发生的报错事件进行监听，以更好的满足测试人员的测试习惯或针对目标功能的个性化需求。

若测试过程中发生报错事件，则转入步骤3121；否则，若测试过程中未发生报错事件，则转入步骤316。

步骤312，获取报错事件对应的错误堆栈信息。

对应于判定是否发生报错事件的不同方式，若在测试结束后统一读取报错事件对应的错误堆栈信息，则可以直接获取错误堆栈信息。若通过监听器对上述检测过程中可能发生的报错事件进行实时监听，则可以在监听到报错事件后立即获取报错事件对应的错误堆栈信息，例如，仍以针对目标界面的该测试在Android测试框架下进行为例，在监听到报错事件后，可以将利用testRunFinish方法获取报错事件对应的错误堆栈信息。

在一实施例中，上述错误堆栈信息中可以包含多种信息、例如，可以包含功能错误类型、功能错误位置、错误对象ID、触发报错事件的测试函数的函数名，以及该测试函数所归属函数类的类名等信息。

步骤314，基于错误堆栈信息中的报错函数名确定报错事件对应的场景类型。

在获取到错误堆栈信息后，可以先从错误堆栈信息中提取报错函数对应的报错函数名，然后确定该函数名对应的场景类型。

在一实施例中，可以先按照步骤306中预先建立的对应于目标测试用例的第一映射关系，确定报错函数名所归属函数类和/或函数子类的报错类名。作为一示例性实施例，报错场景信息可以仅包括触发报错事件的测试函数所归属函数类的类名，此时，可以按照预设的类名与场景类型的第一映射关系，查询匹配于触发报错事件的测试函数所归属函数类的类名的场景类型。上述第一映射关系是根据测试用例所使用的测试函数所归属的函数类以及函数类的场景类型之间的对应关系预先建立的。此时，直接根据报错函数所归属函数类的类名确定其对应的场景类型，所使用的第二映射关系仅包含简单的函数类和/或函数子类的报错类名和场景类型，因此第二映射关系的建立较为简便，降低了建立映射关系的工作量；而且由于只需要从报错场景信息中提取触发报错事件的报错类名，并使用相应的报错类名查询对应的场景类型，信息提取及类型查询的信息量较少，便于提高信息提取及类型查询的速度。

或者，作为另一示例性实施例，报错场景信息可以同时包括触发报错事件的测试函数的函数名，以及测试函数所归属函数类的类名，此时，可以按照预设的函数名、类名与场景类型的第二映射关系，查询同时匹配于触发所述报错事件的测试函数的函数名和所述测试函数所归属函数类的类名的场景类型。上述第二映射关系是根据测试用例所使用的测试函数、测试函数所归属的函数类，以及函数类的场景类型之间的对应关系预先建立的。此时，使用不仅包含函数类和/或函数子类和函场景类型，还包括函数名的第三映射关系查询相应的场景类型，能够避免测试用例中同名测试函数可能导致的查询结果错误，而且能够在确定出场景类型后准确定位功能错误对应的错误位置，从而不仅提高了场景类型查询的准确度，也在一定程度上保证了对程序功能错误的排查及处理效率。

仍以针对目标功能的测试在Android测试框架下进行为例，相应的错误堆栈信息为报错事件对应的错误堆栈信息。相应的错误堆栈信息具体如下：

androidx.test.uiautomator.UiObjectNotFoundException:UiSelector[CLASS＝android.widg et.ImageView,RESOURCE_ID＝com.smile.gifmaker:id/action_bar_share_profile]

at androidx.test.uiautomator.UiObject.click(UiObject.java:416)

at cc.AAA.testkuai.SecondUi$doNext_2$1.invoke(ShareProfileTest.kt:254)

at cc.AAA.testkuai.FirstUi$doNext_1$1.invoke(ShareProfileTest.kt:26)

at cc.AAA.testkuai.tool.ShareKt.shareImByFriends(Share.kt:80)

at cc.AAA.testkuai.ShareProfileTest.shareByImTest(ShareProfileTest.kt:110)

at java.lang.reflect.Method.invoke(Native Method)

对于上述错误堆栈信息，作为一示例性实施例，可以从中提取触发报错事件的测试函数所归属函数子类的全部子类名SecondUi和FirstUi。此时可以在第一映射关系对应的第一映射关系表中查询SecondUi和FirstUi的类型(此时，第一映射关系表中应当保存有各个子类名及其对应的类型：中间函数子类或目标函数子类)；也可以在第一映射关系表中查询SecondUi和FirstUi对应的函数类的类型(此时，第一映射关系表中应当保存有各个子类名及其所继承函数类的类型：中间函数类或目标函数类)。由预设的函数类继承关系(即前述约定：中间场景的测试代码放在函数子类SecondUi和函数子类FirstUi中，并且在函数doNext_2和doNext_1里实现)可知，函数子类SecondUi和函数子类FirstUi均继承中间函数类MiddleTest，因此通过上述查询结果可以判定程序软件中存在的功能错误是位于中间界面中的非关键错误。

当然，由上述错误堆栈信息可知：归属于中间函数子类FirstUi的测试函数doNext_1和归属于中间函数子类SecondUi的测试函数doNext_2之间是调用和被调用的关系。因此也可以仅从上述错误堆栈信息中提取触发报错事件的测试函数所归属函数子类的最低子类名SecondUi，然后再使用上述检测方法在第一映射关系表中查询函数子类SecondUi的类型或其所继承的函数类的类型。最终，可以通过上述查询结果可以判定程序软件中存在的功能错误是位于中间界面中的非关键错误。

作为另一示例性实施例，可以从错误信息中提取触发报错事件的测试函数的全部函数名doNext_2和doNext_1，以及上述函数名所归属函数子类的全部子类名SecondUi和FirstUi。同样的，此时通过上述查询结果可以判定程序软件中存在的功能错误是位于中间界面中的非关键错误。类似的，也可以仅从上述错误堆栈信息中提取触发报错事件的测试函数的最低函数名doNext_2，以及上述最低函数名所归属函数子类的最低子类名SecondUi，然后再使用上述检测方法查询对应于检测函数doNext_2和函数子类SecondUi的函数子类的类型或其所继承的函数类的类型，最终通过上述查询结果可以判定程序软件中存在的功能错误是位于中间界面中的非关键错误。

在另一实施例中，错误堆栈信息具体如下：

androidx.test.uiautomator.UiObjectNotFoundException:UiSelector[CLASS＝android.widg et.ImageView,RESOURCE_ID＝com.smile.gifmaker:id/action_bar_share_profile]

at androidx.test.uiautomator.UiObject.click(UiObject.java:416)

at cc.BBB.testkuai.TargetUi$runTest$1.invoke(ShareProfileTest.kt:350)

at cc.BBB.testkuai.tool.ShareKt.shareImByFriends(Share.kt:80)

at cc.BBB.testkuai.ShareProfileTest.shareByImTest(ShareProfileTest.kt:110)

at java.lang.reflect.Method.invoke(Native Method)

对于上述错误堆栈信息，可以从中提取触发报错事件的测试函数所归属函数子类的子类名TargetUi。此时可以在第二映射关系对应的第二映射关系表中查询TargetUi的类型(此时第二映射关系表中应当保存有各个子类名及其对应的类型：中间函数子类或目标函数子类)；也可以在第二映射关系表中查询函数子类TargetUi对应的函数类的类型(此时第二映射关系表中应当保存有各个函数子类的子类名所继承函数类的类型：中间函数类或目标函数类)。由预设的函数类继承关系可知，函数子类TargetUi继承自目标函数类TargetTest，因此通过上述查询结果可以判定程序软件中存在的功能错误是位于目标界面中的关键错误。

作为另一示例性实施例，可以从中提取触发报错事件的测试函数的函数名runTest，以及上述函数名所归属函数子类的子类名TargetUi。同样的，此时通过上述查询结果可以判定程序软件中存在的功能错误是位于目标界面中的关键错误。

若提取的报错场景信息对应于中间界面，说明报错事件对应的功能错误发生在中间界面中，此时转入步骤308，采用当前测试用例重新进行测试。在重试之前可以判断测试用例的当前已经执行次数(即为当前已测试次数)是否已达到预设的测试次数上限，若已达到则可以终止使用该测试用例对目标功能的测试；若未达到预设的测试次数上限，可以使用该测试用例对目标功能重新进行测试。例如，可以预设对用于用户交互的目标功能的测试次数上限为6次，对后台执行的目标功能的测试次数上限为3次；也可以预设若当前软件测试设备的CPU占用率超出50％，针对目标功能的测试次数上限为8次，若当前软件测试设备的CPU占用率超出80％，针对目标功能的测试次数上限为4次等，不再赘述。另外，上述测试次数上限还可以根据测试效果进行调整，例如，可以初始化设置测试次数上限为5次，若在一轮测试全部完成后，超过一半的测试试用例不超出3次即测试通过，则后续测试可以将测试次数上限调整为3次；若在一轮测试全部完成后，超过80％的测试用例完成5次测试后均未通过，则后续测试可以将测试次数上限调整为8次，不再赘述。

否则，若提取的报错场景信息对应于目标界面，说明报错事件对应的功能错误发生在目标界面中，此时转入步骤316。

步骤316，结束对目标功能的测试过程。

在上述测试用例的测试过程中并未发生报错事件的情况下，实际上当前检测过程已经正常结束。在报错事件对应的功能错误是发生在目标界面中的关键错误的情况下，实际上此时当前检测过程也已经因为报错事件的发生而被强制结束，而且此时软件测试的目的已经实现，因此无需对测试用例进行重试。

可见，在检测出报错时间对应的功能错误是发生在目标界面中的关键错误的情况下，直接结束对测试过程而不对测试用例进行重试，不仅提高了软件测试的效率，而且也避免了因重试通过而导致的对目标场景中关键错误的漏检。

与前述自动测试方法的实施例相对应地，本公开还提出了自动测试装置的实施例。

图7是根据本公开的实施例示出的一种自动测试装置的示意框图。本实施例所示的自动测试装置可以适用于软件测试设备。如图7所示，所述自动测试装置可以包括：

用例执行模块701，被配置为响应于所接收的测试执行指令，执行目标测试用例，其中，所述目标测试用例用于对目标场景下实现的目标功能进行测试；

报错获取模块702，被配置为在监测到所述目标测试用例发生报错事件的情况下，获取所述报错事件的报错场景信息；

重新测试模块703，被配置为若所述报错场景信息对应中间场景，则重新开始执行所述目标测试用例，其中，所述中间场景是所述目标测试用例的测试路径上除所述目标场景之外的测试场景。

可选的，所述报错获取模块还被配置为：

确定基于所述报错事件生成的函数调用堆栈信息；

在所述函数调用堆栈信息中查询所述报错事件对应的报错函数名；

根据所述报错函数名确定所述报错事件的报错场景信息。

可选的，所述报错场景信息包括场景类型，所述报错获取模块还被配置为：

按照对应于所述目标测试用例的第一映射关系，确定所述报错函数名所归属函数类的报错类名，所述第一映射关系包括函数名和函数类的类名之间的对应关系；

按照对应于所述目标测试用例的第二映射关系查询匹配于所述报错类名的场景类型，所述第二映射关系包括函数类的类名与场景类型之间的对应关系，或者，

按照对应于所述目标测试用例的第三映射关系查询匹配于所述报错函数名和所述报错类名的场景类型，所述第三映射关系包括函数名、函数类的类名与场景类型之间的对应关系；其中，所述场景类型包括所述中间场景和所述目标场景。

可选的，还包括：

路径确定模块704，被配置为确定与所述目标场景对应的测试路径，创建所述目标场景与所述中间场景之间的目标映射关系；

用例构建模块705，被配置为根据所述目标映射关系以及所述目标场景和所述中间场景分别对应的测试函数，构建所述目标测试用例。

可选的，所述目标映射关系中包括第一映射关系，还包括第二映射关系和第三映射关系两者至少之一；其中，

所述第一映射关系，根据所述目标测试用例中的测试函数的函数名和所述测试函数所归属函数类的类名之间的对应关系创建得到；

所述第二映射关系，根据所述目标测试用例中的测试函数所归属函数类的类名和所述测试函数所对应测试场景的场景类型之间的对应关系创建得到；

所述第三映射关系，根据所述目标测试用例中的测试函数的函数名、所述测试参数所归属函数类的类名和所述测试函数所对应测试场景的场景类型三者之间的对应关系创建得到。

可选的，还包括：

测试结束模块706，被配置为若所述报错场景信息对应所述目标场景，则结束所述目标测试用例的执行过程。

本公开的实施例还提出一种电子设备，包括：

处理器；

用于存储所述处理器可执行指令的存储器；

其中，所述处理器被配置为执行所述指令，以实现如上述任一实施例所述的自动测试方法。

本公开的实施例还提出一种存储介质，当所述存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行上述任一实施例所述的自动测试方法。

本公开的实施例还提出一种计算机程序产品，所述计算机程序产品被配置为执行上述任一实施例所述的自动测试方法。

图8是根据本公开的实施例示出的一种电子设备的示意框图。例如，电子设备800可以是移动电话，计算机，数字广播终端，消息收发设备，游戏控制台，平板设备，医疗设备，健身设备，个人数字助理等。

参照图8，电子设备800可以包括以下一个或多个组件：处理组件802，存储器804，电源组件806，多媒体组件808，音频组件810，输入/输出(I/O)的接口812，传感器组件814，以及通信组件818。

处理组件802通常控制电子设备800的整体操作，诸如与显示，电话呼叫，数据通信，相机操作和记录操作相关联的操作。处理组件802可以包括一个或多个处理器820来执行指令，以完成上述自动测试方法的全部或部分步骤。此外，处理组件802可以包括一个或多个模块，便于处理组件802和其他组件之间的交互。例如，处理组件802可以包括多媒体模块，以方便多媒体组件808和处理组件802之间的交互。

存储器804被配置为存储各种类型的数据以支持在电子设备800的操作。这些数据的示例包括用于在电子设备800上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。存储器804可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

电源组件806为电子设备800的各种组件提供电力。电源组件806可以包括电源管理系统，一个或多个电源，及其他与为电子设备800生成、管理和分配电力相关联的组件。

多媒体组件808包括在电子设备800和用户之间的提供一个输出接口的屏幕。在一些实施例中，屏幕可以包括液晶显示器(LCD)和触摸面板(TP)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。所述触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与所述触摸或滑动操作相关的持续时间和压力。在一些实施例中，多媒体组件808包括一个前置摄像头和/或后置摄像头。当电子设备800处于操作模式，如拍摄模式或视频模式时，前置摄像头和/或后置摄像头可以接收外部的多媒体数据。每个前置摄像头和后置摄像头可以是一个固定的光学透镜系统或具有焦距和光学变焦能力。

音频组件810被配置为输出和/或输入音频信号。例如，音频组件810包括一个麦克风(MIC)，当电子设备800处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器804或经由通信组件818发送。在一些实施例中，音频组件810还包括一个扬声器，用于输出音频信号。

I/O接口812为处理组件802和外围接口模块之间提供接口，上述外围接口模块可以是键盘，点击轮，按钮等。这些按钮可包括但不限于：主页按钮、音量按钮、启动按钮和锁定按钮。

传感器组件814包括一个或多个传感器，用于为电子设备800提供各个方面的状态评估。例如，传感器组件814可以检测到电子设备800的打开/关闭状态，组件的相对定位，例如所述组件为电子设备800的显示器和小键盘，传感器组件814还可以检测电子设备800或电子设备800一个组件的位置改变，用户与电子设备800接触的存在或不存在，电子设备800方位或加速/减速和电子设备800的温度变化。传感器组件814可以包括接近传感器，被配置用来在没有任何的物理接触时检测附近物体的存在。传感器组件814还可以包括光传感器，如CMOS或CCD图像传感器，用于在成像应用中使用。在一些实施例中，该传感器组件814还可以包括加速度传感器，陀螺仪传感器，磁传感器，压力传感器或温度传感器。

通信组件818被配置为便于电子设备800和其他设备之间有线或无线方式的通信。电子设备800可以接入基于通信标准的无线网络，如WiFi，运营商网络(如2G、3G、4G或5G)，或它们的组合。在一个示例性实施例中，通信组件818经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，所述通信组件818还包括近场通信(NFC)模块，以促进短程通信。例如，在NFC模块可基于射频识别(RFID)技术，红外数据协会(IrDA)技术，超宽带(UWB)技术，蓝牙(BT)技术和其他技术来实现。

在本公开一实施例中，电子设备800可以被一个或多个应用专用集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理设备(DSPD)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)、控制器、微控制器、微处理器或其他电子元件实现，用于执行上述自动测试方法。

在本公开一实施例中，还提供了一种包括指令的非临时性计算机可读存储介质，例如包括指令的存储器804，上述指令可由电子设备800的处理器820执行以完成上述自动测试方法。例如，所述非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

本领域技术人员在考虑说明书及实践这里公开的公开后，将容易想到本公开的其它实施方案。本公开旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求指出。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上对本公开实施例所提供的方法和装置进行了详细介绍，本文中应用了具体个例对本公开的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本公开的方法及其核心思想；同时，对于本领域的一般技术人员，依据本公开的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本公开的限制。

Claims (10)

1.一种自动测试方法，其特征在于，包括：

响应于所接收的测试执行指令，执行目标测试用例，其中，所述目标测试用例用于对目标场景下实现的目标功能进行测试；

在监测到所述目标测试用例发生报错事件的情况下，获取所述报错事件的报错场景信息；

若所述报错场景信息对应中间场景，则重新开始执行所述目标测试用例，其中，所述中间场景是所述目标测试用例的测试路径上除所述目标场景之外的测试场景。

2.根据权利要求1所述的方法，其特征在于，所述获取所述报错事件的报错场景信息，包括：

确定基于所述报错事件生成的函数调用堆栈信息；

在所述函数调用堆栈信息中查询所述报错事件对应的报错函数名；

根据所述报错函数名确定所述报错事件的报错场景信息。

3.根据权利要求2所述的方法，其特征在于，所述报错场景信息包括场景类型，所述根据所述报错函数确定所述报错事件的报错场景信息，包括：

按照对应于所述目标测试用例的第一映射关系，确定所述报错函数名所归属函数类的报错类名，所述第一映射关系包括函数名和函数类的类名之间的对应关系；

按照对应于所述目标测试用例的第二映射关系查询匹配于所述报错类名的场景类型，所述第二映射关系包括函数类的类名与场景类型之间的对应关系，或者，

按照对应于所述目标测试用例的第三映射关系查询匹配于所述报错函数名和所述报错类名的场景类型，所述第三映射关系包括函数名、函数类的类名与场景类型之间的对应关系；其中，所述场景类型包括所述中间场景和所述目标场景。

4.根据权利要求1所述的方法，其特征在于，还包括：

确定与所述目标场景对应的测试路径，创建所述目标场景与所述中间场景之间的目标映射关系；

根据所述目标映射关系以及所述目标场景和所述中间场景分别对应的测试函数，构建所述目标测试用例。

5.根据权利要求4所述的方法，其特征在于，所述目标映射关系中包括第一映射关系，还包括第二映射关系和第三映射关系两者至少之一；其中，

所述第一映射关系，根据所述目标测试用例中的测试函数的函数名和所述测试函数所归属函数类的类名之间的对应关系创建得到；

所述第二映射关系，根据所述目标测试用例中的测试函数所归属函数类的类名和所述测试函数所对应测试场景的场景类型之间的对应关系创建得到；

所述第三映射关系，根据所述目标测试用例中的测试函数的函数名、所述测试参数所归属函数类的类名和所述测试函数所对应测试场景的场景类型三者之间的对应关系创建得到。

6.根据权利要求1所述的方法，其特征在于，还包括：

若所述报错场景信息对应所述目标场景，则结束所述目标测试用例的执行过程。

7.一种自动测试装置，其特征在于，包括：

用例执行模块，被配置为响应于所接收的测试执行指令，执行目标测试用例，其中，所述目标测试用例用于对目标场景下实现的目标功能进行测试；

报错获取模块，被配置为在监测到所述目标测试用例发生报错事件的情况下，获取所述报错事件的报错场景信息；

重新测试模块，被配置为若所述报错场景信息对应中间场景，则重新开始执行所述目标测试用例，其中，所述中间场景是所述目标测试用例的测试路径上除所述目标场景之外的测试场景。

8.根据权利要求7所述的装置，其特征在于，所述报错获取模块还被配置为：

确定基于所述报错事件生成的函数调用堆栈信息；

在所述函数调用堆栈信息中查询所述报错事件对应的报错函数名；

根据所述报错函数名确定所述报错事件的报错场景信息。

9.一种电子设备，其特征在于，包括：

处理器；

用于存储所述处理器可执行指令的存储器；

其中，所述处理器被配置为执行所述指令，以实现如权利要求1至6中任一项所述的自动测试方法。

10.一种计算机可读存储介质，其特征在于，当所述存储介质中的指令由电子设备的处理器执行时，使得所述电子设备能够执行如权利要求1至6中任一项所述的自动测试方法。

Images