CN114741303A - 一种测试脚本的生成方法、装置及电子设备 - Google Patents

Abstract

本申请公开了一种测试脚本的生成方法、装置及电子设备，响应于启动初始测试用例，对初始测试用例的执行过程进行监测，得到监测信息；提取监测信息中的故障因子信息；基于故障因子信息，生成第一测试用例；基于第一测试用例以及测试特征信息，生成至少一个第二测试用例；基于第一测试用例和第二测试用例，生成目标测试脚本。通过故障因子信息的分析以及测试特征，能够构建出更全面的测试用例，并生成对应的自动执行的目标测试脚本，提升了测试的准确性和效率。

Description

一种测试脚本的生成方法、装置及电子设备

技术领域

本申请涉及计算机技术领域，更具体的说是涉及一种测试脚本的生成方法、装置及电子设备。

背景技术

测试工程师在测试软件，以及验证修复测试用例中的缺陷或漏洞时，需要进行多次重复的手工测试，繁琐耗时。并且可能会遗漏掉很多与当前漏洞相关的测试用例，造成了测试质量的降低，从而降低了软件测试的准确性以及效率。

发明内容

有鉴于此，本申请提供如下技术方案：

一种测试脚本的生成方法，包括：

响应于启动初始测试用例，对所述初始测试用例的执行过程进行监测，得到监测信息；

提取所述监测信息中的故障因子信息；

基于所述故障因子信息，生成第一测试用例；

基于所述第一测试用例以及测试特征信息，生成至少一个第二测试用例；

基于所述第一测试用例和所述第二测试用例，生成目标测试脚本。

可选地，所述对所述初始测试用例的执行过程进行监测，得到监测信息，包括：

监测目标对象针对所述初始测试用例的操作信息；

记录所述初始测试用例的显示信息；

将所述操作信息和所述显示信息确定为监测信息。

可选地，所述提取所述监测信息中的故障因子信息，包括：

获取目标对象针对故障因子的操作信息；

提取与所述操作信息相匹配的监测信息，并将提取的监测信息确定为故障因子信息。

可选地，所述提取与所述操作信息相匹配的监测信息，并将提取的监测信息确定为故障因子信息，包括：

基于所述操作信息，确定故障因子的关键词信息；

基于所述关键词信息和所述操作信息，确定提取故障因子信息的目标范围；

在所述监测信息中提取与所述目标范围相匹配的故障因子信息。

可选地，所述基于所述第一测试用例以及测试特征信息，生成至少一个第二测试用例，包括：

获取与测试场景相匹配的测试特征信息；

获取与第一测试用例的故障因子信息相匹配的关联故障因子信息；

基于所述测试特征信息和所述关联故障因子信息，生成至少一个第二测试用例。

可选地，所述基于所述第一测试用例和所述第二测试用例，生成目标测试脚本，包括：

确定与第一测试用例和所述第二测试用例相匹配的自动化执行组件；

基于所述自动化执行组件对所述第一测试用例和所述第二测试用例进行录制，得到目标测试脚本。

可选地，所述方法还包括：

响应于对所述目标测试脚本进行执行，确定是否出现故障因子；

如果是对所述目标测试脚本进行优化，得到优化后的测试脚本。

一种测试脚本的生成装置，包括：

监测单元，用于响应于启动初始测试用例，对所述初始测试用例的执行过程进行监测，得到监测信息；

提取单元，用于提取所述监测信息中的故障因子信息；

第一生成单元，用于基于所述故障因子信息，生成第一测试用例；

第二生成单元，用于基于所述第一测试用例以及测试特征信息，生成至少一个第二测试用例；

第三生成单元，用于基于所述第一测试用例和所述第二测试用例，生成目标测试脚本。

可选地，所述监测单元包括：

第一监测子单元，用于监测目标对象针对所述初始测试用例的操作信息；

记录子单元，用于记录所述初始测试用例的显示信息；

第一确定子单元，用于将所述操作信息和所述显示信息确定为监测信息。

可选地，所述提取单元包括：

第一获取子单元，用于获取目标对象针对故障因子的操作信息；

提取子单元，用于提取与所述操作信息相匹配的监测信息，并将提取的监测信息确定为故障因子信息。

可选地，所述提取子单元具体用于：

基于所述操作信息，确定故障因子的关键词信息；

基于所述关键词信息和所述操作信息，确定提取故障因子信息的目标范围；

在所述监测信息中提取与所述目标范围相匹配的故障因子信息。

可选地，所述第二生成单元包括：

第二获取子单元，用于获取与测试场景相匹配的测试特征信息；

第三获取子单元，用于获取与第一测试用例的故障因子信息相匹配的关联故障因子信息；

第一生成子单元，用于基于所述测试特征信息和所述关联故障因子信息，生成至少一个第二测试用例。

可选地，所述第三生成单元包括：

第二确定子单元，用于确定与所述第一测试用例和所述第二测试用例相匹配的自动化执行组件；

录制子单元，用于基于所述自动化执行组件对所述第一测试用例和所述第二测试用例进行录制，得到目标测试脚本。

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

优化单元，用于响应于对所述目标测试脚本进行执行，确定是否出现故障因子；

如果是对所述目标测试脚本进行优化，得到优化后的测试脚本。

一种可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时，实现如上述中任一项所述的测试脚本的生成方法。

一种电子设备，包括：

存储器，用于存储程序；

处理器，用于调用并执行所述存储器中的所述程序，通过执行所述程序实现上述中任一项所述的测试脚本的生成方法。

经由上述的技术方案可知，本申请公开了一种测试脚本的生成方法、装置及电子设备，响应于启动初始测试用例，对初始测试用例的执行过程进行监测，得到监测信息；提取监测信息中的故障因子信息；基于故障因子信息，生成第一测试用例；基于第一测试用例以及测试特征信息，生成至少一个第二测试用例；基于第一测试用例和第二测试用例，生成目标测试脚本。通过故障因子信息的分析以及测试特征，能够构建出更全面的测试用例，并生成对应的自动执行的目标测试脚本，提升了测试的准确性和效率。

附图说明

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

图1为本申请实施例提供的一种测试脚本的生成方法的流程示意图；

图2为本申请实施例提供的一种基于故障因子生成RPA脚本的方法的流程示意图；

图3为本申请实施例提供的一种生成第二测试用例方法的流程示意图；

图4为本申请实施例提供的一种测试测试场景的示意图；

图5为本申请实施例提供的一种测试脚本的生成装置的结构示意图。

具体实施方式

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

在本申请实施例中提供了一种测试脚本的生成方法，该方法主要应用于对系统或者软件的测试应用场景中，可以通过测试端执行相应的测试脚本来实现对系统或者软件的测试，本申请通过对初始测试用例的测试过程的自动分析和测试特征的分析，能够自动生成测试脚本并执行，提升了测试用例的全面性，从而提升了测试的准确性和效率。

参见图1，为本申请实施例提供的一种测试脚本的生成方法的流程示意图，该方法可以包括以下步骤：

S101、响应于启动初始测试用例，对初始测试用例执行过程进行监测，得到监测信息。

初始测试用例是根据测试需求分析阶段得到的测试需求信息，生成的测试用例。测试需求阶段是指在系统上线前或者软件开发前，依据项目需求信息，提取出的测试需求，为测试用例的设计提供需求。测试用例(Test Case)是指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。其内容包括测试目标、测试环境、输入数据、测试步骤、预期结果等，以便于核实是否满足某个特定软件的需求。

初始测试用例就是测试端根据测试需求最初编写的测试用例，在本申请实施例中，对初始测试用例的执行过程进行监测，得到监测信息。该监测主要是指在初始测试用例执行过程中，监测对应的测试人员的操作信息以及当前测试显示显示等。在一种实施方式中，所述对初始测试用例的执行过程进行监测，得到监测信息，包括：监测目标对象对初始测试用例的操作信息；记录初始测试用例的显示信息；将该操作信息和显示信息确定为监测信息。目标对象可以是执行当前初始测试用例的测试终端，或者该测试终端的操作者如测试人员。可以是对目标对象的所有操作信息进行监测，也可以是对目标对象满足特定操作条件的操作信息进行监测，如对出现故障信息的记录操作进行监测。初始测试用例的显示信息包括初始测试用例在执行过程中的全部或满足特定条件的部分显示信息，如对测试用例的执行结果对应的显示信息进行记录，或者对出现报错信息时对应的显示界面进行记录。

S102、提取所述监测信息中的故障因子信息。

故障因子信息中可以包括至少一个故障因子，每一故障因子可以表征在当前的测试场景中出现的一种故障，例如，故障因子信息包括第一故障因子和第二故障因子，其中，第一故障因子和第二故障因子可以代表不同测试条件下的故障因子。也可以包括第二故障因子是第一故障因子的关联故障因子，例如，第一故障因子是在针对随机数测试时产生的故障因子，对应的，第二故障因子可以是针对特定数据测试时产生的故障因子。

在本申请实施例中确定故障因子信息时可以是在测试结果没有达到预期效果时，在监测信息中提取的故障因子。例如，针对某一测试条件的偏差结果较大，可以在与该测试条件对应的监测信息范围内提取故障因子信息。另一种实施方式还可以是根据测试端的操作信息来确定故障因子信息。对应的，所述提取监测信息中的故障因子信息，包括：获取目标对象针对故障因子的操作信息；提取与操作信息相匹配的监测信息，并将提取的监测信息确定为故障因子信息。其中，目标对象可以是执行测试的测试操作人员，其对故障因子的操作信息包括对故障因子的标注、描述信息。然后自动截取该部分的监测信息作为故障因子信息。例如，故障因子是初始测试用例中的一些未被发现的缺陷或漏洞问题，也可以被称为bug。可以通过监测测试人员的操作，来确定当前初始测试用例中是否出现bug，如果出现了bug，可以自动截取引发bug的操作流程确定为故障因子信息。

S103、基于故障因子信息，生成第一测试用例。

可以通过截取的包括故障因子信息的监测信息，来生成对应的第一测试用例，使得第一测试用例是针对故障因子信息完善的测试用例，便于后续的测试。

S104、基于第一测试用例以及测试特征信息，生成至少一个第二测试用例。

其中，第二测试用例可以有一个或者多个，其主要是根据第一测试用例以及测试特征信息生成的，第一测试用例中包括了针对故障因子信息的描述特征，测试特征信息主要是通过测试需求文档获得，对测试需求文档进行语义理解，可以生成更多的测试用例，即第二测试用例。例如，测试特征信息包括“输入数字0-99”的测试用例，第二测试用例可以包括生成“非数字”的测试用例，生成“-1”的测试用例，生成“100”的测试用例等。另外，第第一测试用例中包括了故障因子信息，可以基于该故障因子信息在生成第二测试用例时重点关注产生该故障因子的测试用例的生成，例如，故障因子产生于在周末日期的测试过程中，而第二测试用例可以包括生成针对法定节假日的测试用例。

S105、基于第一测试用例和第二测试用例，生成目标测试脚本。

测试脚本可以是用于进行测试的纯文本保存的程序，在本申请实施例中的目标测试脚本是可以用于自动执行的测试脚本，即对第一测试用例和第二测试用例进行组合得到的测试脚本，其中，在组合该过程中还设置了自动化执行组件来实现该目标测试脚本的自动化执行。具体的，该目标测试脚本可以是RPA(Robotic process automation，机器人流程自动化)脚本，该RPA脚本是以软件机器人以及人工智能为基础的自动化执行测试过程的测试脚本。

本申请实施例公开了一种测试脚本的生成方法，响应于启动初始测试用例，对初始测试用例的执行过程进行监测，得到监测信息；提取监测信息中的故障因子信息；基于故障因子信息，生成第一测试用例；基于第一测试用例以及测试特征信息，生成至少一个第二测试用例；基于第一测试用例和第二测试用例，生成目标测试脚本。通过故障因子信息的分析以及测试特征，能够构建出更全面的测试用例，并生成对应的自动执行的目标测试脚本，提升了测试的准确性和效率。

以软件测试场景为例，在软件测试过程中通常包括需求分析阶段、测试用例设计阶段、测试框架设计阶段、测试脚本编写阶段，以及测试脚本执行阶段。其中，需求分析阶段是进行测试项目需求的解读；测试用例设计阶段是根据测试需求，设计测试用例；测试框架设计阶段主要是编写自动化测试框架；测试脚本编写阶段是根据测试用例，编写测试脚本；测试脚本执行阶段是根据测试脚本进行实际的测试执行。

在本申请实施例中在需求分析阶段，测试人员根据测试项目确定测试特征信息，然后测试用例设计阶段和测试框架设计阶段生成初始测试用例，通过测试人员对该初始测试用例进行执行，并监测执行过程中测试人员的操作，以确定是否出现故障因子(其中，软件测试中通常被称为bug)，若出现获取测试人员的对该bug的描述信息，从而在监测信息中提取出故障因子信息。

在一种可能的实现方式中，提取与操作信息相匹配的监测信息，并将提取的监测信息确定为故障因子信息，包括：基于操作信息，确定故障因子的关键词信息；基于关键词信息和操作信息，确定提取故障一致信息的目标范围，在监测信息中提取与目标范围相匹配的故障因子信息。

其中，基于测试人员针对故障因子的操作信息可以获取测试人员的记录操作，从而获取与该记录操作相匹配的故障因子的描述信息。然后提取该故障因子的描述信息中的关键词，并对关键词信息进行分析，结合测试人员的记录操作确定出操作起点和结束点，然后将此范围作为提取故障因子信息的目标范围，从而提取出故障因子信息。进一步可以基于提取的针对故障一致信息的操作记录生成第一测试用例，具体的可以是生成RPA脚本。

举例说明，以故障因子为软件测试中的bug，第一测试用例为RPA脚本为例对该过程进行说明，参见图2，为本申请实施例提供的一种基于故障因子生成RPA脚本的方法的流程示意图，该方法可以包括以下步骤：

S201、响应于启动监测模式，监测针对目标对象的所有操作，得到监测信息。

其中，监测模式是通过监测软件的执行来实现的，启动监测模式可以包括测试人员打开监测软件。目标对象为测试人员，操作记录信息包括测试人员打开的软件信息、点击、输入等操作的信息，以及屏幕截图等信息。

S202、当检测到目标对象启动bug系统，并提交bug信息后，确定当前测试用例出现bug。

其中，bug系统是针对bug进行记录的系统，bug信息可以是bug的描述信息，如包括该bug的产生时间、预估产生条件以及影响信息等。

S203、在bug信息中获取bug描述信息进行关键词分析，并集合记录得到的监测信息识别出操作起点和结束点。

S204、获取与操作起点和结束点对应的操作记录生成RPA脚本。

在该实施方式中，可以实现在测试用例执行过程中自动截取引发故障因子的操作流程，从而根据该操作流程自动生成对应的脚本信息，便于bug的复现，提升了测试脚本生成的效率以及测试准确性。

在本申请实施例中通过对故障因子信息的分析生成第一测试用例后，还可以基于第一测试用例以及测试特征信息，生成至少一个第二测试用例，以便能够构建出更多、更完善的测试用例。在一种实施方式中，该过程可以包括：获取与测试场景相匹配的测试特征信息；获取与第一测试用例的故障因子信息相匹配的关联故障因子信息；基于测试特征信息和关联故障因子信息，生成至少一个第二测试用例。

关联的故障因子信息可以是基于已出现的故障因子信息来预估的其他故障因子，这样在衍生得到测试用例的时候可以针对这些故障因子进行测试，也可以在编写测试用例时重点关注这些故障因子，从而使得编写的测试用例可以有效避免这些故障因子的影响。

仍以故障因子为软件测试中的bug为例，对本申请实施例中的构建更多测试用例的实施方式进行说明，参见图3，为本申请实施例提供的一种生成第二测试用例方法的流程示意图，该过程可以包括以下步骤：

S301、对包括bug描述信息和测试用例文档进行分析，获得bug对应的测试用例。

S302、在测试用例中提取到对应的测试需求文档。

S303、对测试需求文档进行语义分析，生成更多的测试用例，即为第二测试用例。

例如，需求文档中包括“输入数字0-99”，则生成输入“非数字”的测试用例，生成输入“-1”的测试用例，以及生成输入“100”的测试用例。

在该实施方式中，通过bug描述和操作流程，能够分析并构造更全面的测试用例，保证了测试过程中更全面的测试和保证了测试质量。

在本申请实施例的一种实施方式中，生成的目标测试脚本是可以自动执行的测试脚本，如RPA脚本。对应的，所述基于第一测试用例和第二测试用例，生成目标测试脚本，包括：

确定与第一测试用例和第二测试用例相匹配的自动化执行组件；

基于自动化执行组件对第一测试用例和第二测试用例进行录制，得到目标测试脚本。

其中，自动化执行组件来自RPA(Robotic process automation，机器人流程自动化)组件库，该RPA组件库为预先创建的用于存储能够执行多种动作的组件的数据库，使得该数据库中每一组件可以执行对应的操作动作，如单击动作、双击动作、截屏动作等。从该RPA组件库中筛选出与第一测试用例和第二测试用例中的关键词对应的动作的自动化执行组件，然后基于选定的自动化执行组件对应的动作的顺序依次录制动作信息，生成对应的目标测试脚本，可以通过RPA制动执行更全面的测试用例。

在本申请实施例的一种实施方式中，该方法还包括：

响应于目标测试脚本进行执行，确定是否出现故障因子；

如果是，对所述目标测试脚本进行优化，得到优化后的测试脚本。

可以对生成的目标测试脚本进行验证，以确定其中是否还存在故障因子，如软件测试中的bug，如果出现，可以通过开发人员对该bug进行修复，得到更加完善的测试脚本。

参见图4，为本申请实施例提供的一种测试场景的示意图，在该测试场景中包括测试端和开发端，该测试场景主要是针对软件测试场景，其中故障信息为软件测试中的bug，测试脚本为RPA脚本。

在测试端的执行流程主要包括：

S410、监测测试端操作信息；

S411、确定是否出现bug，如果是，执行S412；

S412、自动截取引发bug的操作流程；

S413、基于引发bug的操作流程，生成RPA脚本；

S414、根据测试用例和需求文档生成更多、更完善的测试操作的RPA脚本。

开发端的执行流程主要包括：

S420、通过RPA对RPA及脚本进行执行复现bug；

S421、修改bug；

S422、使用RPA验证bug；

S423、用RPA验证更完善的测试用例；

S424、确定是否出现bug，如果是，继续执行S420，直至测试完成。

在本申请实施例中可以监测测试端的操作，当出现bug后，截取引发bug的操作流程，生成RPA脚本，然后，通过对bug描述和操作流程的逆袭，构建出更多、更完善的测试用例，开发端可以通过RPA复现bug，而且开发端提交修复后的脚本就，可以通过RPA可以自动执行更全面的测试用例，进一步验证程序。通过RPA避免了毫无价值的重复手工操作。通过bug描述，和操作流程，利用人工智能，构建更全面的测试用例，并用RPA自动执行，保证更全面的测试，保证测试质量。

在本申请的另一实施例中还提供了一种测试脚本的生成装置，参见图5，该装置可以包括：

监测单元501，用于响应于启动初始测试用例，对所述初始测试用例的执行过程进行监测，得到监测信息；

提取单元502，用于提取所述监测信息中的故障因子信息；

第一生成单元503，用于基于所述故障因子信息，生成第一测试用例；

第二生成单元504，用于基于所述第一测试用例以及测试特征信息，生成至少一个第二测试用例；

第三生成单元505，用于基于所述第一测试用例和所述第二测试用例，生成目标测试脚本。

本申请实施例公开了一种测试脚本的生成装置，监测单元响应于启动初始测试用例，对初始测试用例的执行过程进行监测，得到监测信息；提取单元提取监测信息中的故障因子信息；第一生成单元基于故障因子信息，生成第一测试用例；第二生成单元基于第一测试用例以及测试特征信息，生成至少一个第二测试用例；第三生成单元基于第一测试用例和第二测试用例，生成目标测试脚本。通过故障因子信息的分析以及测试特征，能够构建出更全面的测试用例，并生成对应的自动执行的目标测试脚本，提升了测试的准确性和效率。

可选地，所述监测单元包括：

第一监测子单元，用于监测目标对象针对所述初始测试用例的操作信息；

记录子单元，用于记录所述初始测试用例的显示信息；

第一确定子单元，用于将所述操作信息和所述显示信息确定为监测信息。

可选地，所述提取单元包括：

第一获取子单元，用于获取目标对象针对故障因子的操作信息；

提取子单元，用于提取与所述操作信息相匹配的监测信息，并将提取的监测信息确定为故障因子信息。

可选地，所述提取子单元具体用于：

基于所述操作信息，确定故障因子的关键词信息；

基于所述关键词信息和所述操作信息，确定提取故障因子信息的目标范围；

在所述监测信息中提取与所述目标范围相匹配的故障因子信息。

可选地，所述第二生成单元包括：

第二获取子单元，用于获取与测试场景相匹配的测试特征信息；

第三获取子单元，用于获取与第一测试用例的故障因子信息相匹配的关联故障因子信息；

第一生成子单元，用于基于所述测试特征信息和所述关联故障因子信息，生成至少一个第二测试用例。

可选地，所述第三生成单元包括：

第二确定子单元，用于确定与所述第一测试用例和所述第二测试用例相匹配的自动化执行组件；

录制子单元，用于基于所述自动化执行组件对所述第一测试用例和所述第二测试用例进行录制，得到目标测试脚本。

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

优化单元，用于响应于对所述目标测试脚本进行执行，确定是否出现故障因子；

如果是对所述目标测试脚本进行优化，得到优化后的测试脚本。

需要说明的是，本实施例中各个单元以及子单元的具体实现可以参考前文中的相应内容，此处不再详述。

在本申请的另一实施例中，还提供了一种可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时，实现如上任一项所述的测试脚本的生成方法的各个步骤。

在本申请的另一实施例中，还提供了一种电子设备，所述电子设备可以包括：

存储器，用于存储应用程序和所述应用程序运行所产生的数据；

处理器，用于执行所述应用程序，以实现如上述中任一项所述的测试脚本的生成方法。

需要说明的是，本实施例中处理器的具体实现可以参考前文中的相应内容，此处不再详述。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (10)

1.一种测试脚本的生成方法，包括：

响应于启动初始测试用例，对所述初始测试用例的执行过程进行监测，得到监测信息；

提取所述监测信息中的故障因子信息；

基于所述故障因子信息，生成第一测试用例；

基于所述第一测试用例以及测试特征信息，生成至少一个第二测试用例；

基于所述第一测试用例和所述第二测试用例，生成目标测试脚本。

2.根据权利要求1所述的方法，所述对所述初始测试用例的执行过程进行监测，得到监测信息，包括：

监测目标对象针对所述初始测试用例的操作信息；

记录所述初始测试用例的显示信息；

将所述操作信息和所述显示信息确定为监测信息。

3.根据权利要求2所述的方法，所述提取所述监测信息中的故障因子信息，包括：

获取目标对象针对故障因子的操作信息；

提取与所述操作信息相匹配的监测信息，并将提取的监测信息确定为故障因子信息。

4.根据权利要求3所述的方法，所述提取与所述操作信息相匹配的监测信息，并将提取的监测信息确定为故障因子信息，包括：

基于所述操作信息，确定故障因子的关键词信息；

基于所述关键词信息和所述操作信息，确定提取故障因子信息的目标范围；

在所述监测信息中提取与所述目标范围相匹配的故障因子信息。

5.根据权利要求1所述的方法，所述基于所述第一测试用例以及测试特征信息，生成至少一个第二测试用例，包括：

获取与测试场景相匹配的测试特征信息；

获取与第一测试用例的故障因子信息相匹配的关联故障因子信息；

基于所述测试特征信息和所述关联故障因子信息，生成至少一个第二测试用例。

6.根据权利要求1所述的方法，所述基于所述第一测试用例和所述第二测试用例，生成目标测试脚本，包括：

确定与所述第一测试用例和所述第二测试用例相匹配的自动化执行组件；

基于所述自动化执行组件对所述第一测试用例和所述第二测试用例进行录制，得到目标测试脚本。

7.根据权利要求1所述的方法，所述方法还包括：

响应于对所述目标测试脚本进行执行，确定是否出现故障因子；

如果是，对所述目标测试脚本进行优化，得到优化后的测试脚本。

8.一种测试脚本的生成装置，包括：

监测单元，用于响应于启动初始测试用例，对所述初始测试用例的执行过程进行监测，得到监测信息；

提取单元，用于提取所述监测信息中的故障因子信息；

第一生成单元，用于基于所述故障因子信息，生成第一测试用例；

第二生成单元，用于基于所述第一测试用例以及测试特征信息，生成至少一个第二测试用例；

第三生成单元，用于基于所述第一测试用例和所述第二测试用例，生成目标测试脚本。

9.一种可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时，实现如权利要求1-7中任一项所述的测试脚本的生成方法。

10.一种电子设备，包括：

存储器，用于存储程序；

处理器，用于调用并执行所述存储器中的所述程序，通过执行所述程序实现如权利要求1-7中任一项所述的测试脚本的生成方法。

Images