CN109710528A - 一种测试脚本生成方法、装置、设备和介质 - Google Patents

Abstract

本申请提供了一种测试脚本生成方法，该方法包括：获取待处理事件；根据所述待处理事件的属性信息，生成针对所述待处理事件的测试脚本；存储所述测试脚本。这样，无需手动方式生成测试脚本，自动生成测试脚本，大幅提高自动化测试脚本的开发效率，降低维护成本，避免了由于脚本开发人员水平问题导致脚本执行成功率不高的情况，提高了代码的稳定性，通过存储测试脚本使得在执行相同的处理事件时，不必重新生成测试脚本，直接过去测试脚本进行测试，提高了测试效率。

Description

一种测试脚本生成方法、装置、设备和介质

技术领域

本申请涉及测试技术领域，具体而言，涉及一种测试脚本生成方法、装置、设备和介质。

背景技术

随着网络应用的日渐庞大和复杂，网络应用的测试越来越得到人们的重视，而在网络应用的测试方法中，自动化测试因为其具有比手工测试效率高、执行速度快等优点获得了测试技术人员的广泛关注。

传统的网络页面自动化测试技术，测试脚本的开发时间较长，并且一旦需求发生变更，如，测试页面或测试流程发生变化，测试脚本的后续维护工作量较大。另外，传统的页面自动化测试技术对自动化测试人员的专业能力要求较高，同时代码是测试人员手工编写，规范性不强，代码稳定性较差，使得页面自动化测试脚本的开发及维护成本较高。

发明内容

有鉴于此，本申请的目的在于提供一种测试脚本生成方法、装置、设备和介质，以解决现有技术中手动编写测试脚本效率低的问题。

第一方面，本申请实施例提供了一种测试脚本生成方法，该方法包括：

获取待处理事件；

根据所述待处理事件的属性信息，生成针对所述待处理事件的测试脚本；

存储所述测试脚本。

可选地，所述根据所述待处理事件的属性信息，生成针对所述待处理事件的测试脚本，包括：

根据所述待处理事件的属性信息，确定所述待处理事件是否包含子任务；

若确定所述待处理事件包含子任务，则根据子任务的属性信息，生成针对子任务的第一测试内容；

根据所述待处理事件中除子任务外的其它内容的属性信息，生成针对其它内容的第二测试内容；

基于所述第一测试内容和所述第二测试任务，生成所述测试脚本。

可选地，所述属性信息至少包括包括节点标识、节点类型、页面元素、操作类型、定位方式、定位参数、判断逻辑。

可选地，所述根据子任务的属性信息，生成针对子任务的第一测试内容，包括：

从测试代码数据库中，查找与所述子任务的属性信息中的版本信息一致的测试内容；

若查找到与所述自任务的属性信息中的版本信息一致的测试内容，则将查找的测试内容作为第一测试内容。

可选地，所述存储所述测试脚本，包括：

将所述测试脚本存储至测试脚本数据库。

第二方面，本申请实施例提供了一种测试脚本生成装置，该装置包括：

获取模块，用于获取待处理事件；

生成模块，用于根据所述待处理事件的属性信息，生成针对所述待处理事件的测试脚本；

存储模块，用于存储所述测试脚本。

可选地，所述生成模块具体用于：

根据所述待处理事件的属性信息，确定所述待处理事件是否包含子任务；

若确定所述待处理事件包含子任务，则根据子任务的属性信息，生成针对子任务的第一测试内容；

根据所述待处理事件中除子任务外的其它内容的属性信息，生成针对其它内容的第二测试内容；

基于所述第一测试内容和所述第二测试任务，生成所述测试脚本。

可选地，所述属性信息至少包括包括节点标识、节点类型、页面元素、操作类型、定位方式、定位参数、判断逻辑。

第三方面，本申请实施例提供了一种计算机设备，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述方法的步骤。

第四方面，本申请实施例提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器运行时执行上述方法的步骤。

本申请实施例提供的测试脚本生成方法，通过获取的待处理事件的属性信息，自动生成针对待处理事件的测试脚本，并存储测试脚本。这样，无需手动方式生成测试脚本，自动生成测试脚本，大幅提高自动化测试脚本的开发效率，降低维护成本，避免了由于脚本开发人员水平问题导致脚本执行成功率不高的情况，提高了代码的稳定性，通过存储测试脚本使得在执行相同的处理事件时，不必重新生成测试脚本，直接获取测试脚本进行测试，提高了测试效率。

为使本申请的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

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

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

图3为本申请实施例提供的一种计算机设备300的结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请实施例提供了一种测试脚本生成方法，如图1所示，应用于计算机设备中，本申请针对的是web页面设计中的测试脚本生成方法，中该方法包括：

S101，获取待处理事件；

这里，待处理事件包括但不限于主流程图，主流程图存储在主流程图数据库中，主流程图数据库存储主流程图标识和对应的主流程图包含的节点的节点信息，上述主流程图可以由至少一个子流程图的构成，可选地，主流程图中也可以不包含子流程图，可视具体情况而定；子流程图存储在子流程图库(又称组件组)，子流程图库存储有主流程图标识、子流程图标识以及子流程图包含的节点的节点信息之间的对应关系。

在具体实施中，处理事件存储在计算设备中的本地内存中，或者将处理事件存储在主流程图数据库中，获取待处理事件的方式在现有技术中已有详细的解释，此处不再进行过多说明。

S102，根据所述待处理事件的属性信息，生成针对所述待处理事件的测试脚本；

这里，待处理事件的属性信息至少包括节点标识、节点类型、所属页面、页面元素、操作类型、定位方式、定位参数、判断逻辑，如，节点标识用于标识主流程图中每个处理步骤，节点类型包括决策类型和非决策类型，所属页面为主流程图所属的页面，页面名称可以存储在元素库中；页面元素表征所属页面中需要操作的内容，元素名称也存储在元素库中；定位方式用于标识页面元素在主流程图所属页面中的位置，操作类型包括对页面元素执行的操作，包括点击、输入、单选框选择、弹出对话框选择、上传文件选择等，定位参数一般为页面元素的标识或者页面元素的名称；判断逻辑表征流程图中决策节点对应的步骤的判断条件，包括页面元素、比较值和比较条件，获取页面元素对应的值以及比较值，根据比较条件比对页面元素的值和比较值，得到比较结果。

所属页面表示页面元素所属的系统页面，该页面名称在流程图所属系统内唯一，所属页面信息可由用户自定义，新增加页面元素属于新的页面，在流程图保存时，新增加的页面元素的名称、所述页面名称、定位信息等均记录在元素库中，如果之前其他流程图已经添加过该页面，可以由用户从元素库该流程图所属系统的已有页面中选择，当用户从已有主流程图所属页面中选择时，可以从元素库中带出所有已存储的该所属页面的名称，显示在下面元素名称选择框中。

页面元素可以为元素名称，用于定义要操作的被测系统页面元素，元素名称必须在所属页面内唯一，当用户输入了所属页面后，该页面没有用户需要操作的这个元素名称，可以由用户定义一个名称，当主流程图保存时，该元素将被记录在元素库中。如果用户输入所属页面后，从元素库中自动带出了用户需要的页面元素，用户选择后，该元素的定位方式和定位参数将直接带出显示在下方。

定位方式一般通过页面元素的标识进行定位，页面元素的定义方式通常有以下几种，因为页面元素标识在整个页面唯一，所以在有页面元素标识的情况下，一般优先使用页面元素标识定位，如果没有页面元素标识，再考虑使用其他能唯一定位该页面元素的定位方式。

定位参数用于选定能唯一定位页面元素的定位方式后，定义该定位的参数值，例如如果选择通过页面元素的标识定位，在这里就定义该元素的表示值。

操作数据与操作类型对应，对于操作类型为点击的元素，无需输入操作数据；对于操作类型为输入、单选框选择、多选框选择、弹出对话框操作、上传文件等操作类型，需要在这里定义要操作的数据。可参考下表：

操作类型	操作数据
		点击	无
输入	要输入的数据内容
		单选框选择	选择项名称
多选框选择	选择项名称(可多个)
		弹出对话框操作	对弹出对话框的操作(如确认、取消)
上传文件	上传文件的路径
		...	...

以车险出单全流程图中投保单录入用户任务为例，此用户任务记录了用户从车险承保系统主页面进入投保单录入页面的步骤，包含两个子任务：投保单管理菜单任务和投保单录入子菜单任务，以投保单管理菜单任务为例进行说明，元素库增加投保单管理菜单任务如下内容：所属页面为主菜单页面，元素名称为投保单管理菜单，操作类型为点击，定位方式为LinkText，定位参数为投保单管理。

在生成的主流程图包含主流程图嵌入其中的子流程图以及常用的流程图。其中，基于BPMN标准生成的主流程图，在保存至主流程图数据库时，将以XML文件格式保存。主流程图数据库同时存储了主流程图所属的系统名称、主流程图名称、主流程图的版本号，其中，初始版本号为V1.0。

以上述车险出单主流程图为例，该主流程图内嵌了投保单信息录入、投保单信息修改、核保处理、缴费处理四个子流程图。因此，在主流程图数据库中将保存一张主流程图，以及四各内嵌子流程图的XML文件，初始五各流程图的版本号均为V1.0，如下：

所属系统名称	流程图名称	版本号	XML文件
				车险承保系统	车险出单主流程	V1.0	该流程图的xml文件
车险承保系统	投保单信息录入子流程	V1.0	该流程图的xml文件
				车险承保系统	投保单信息修改子流程	V1.0	该流程图的xml文件
车险核保系统	核保处理子流程	V1.0	该流程图的xml文件
				见费出单系统	缴费处理子流程	V1.0	该流程图的xml文件

在根据所述待处理事件的属性信息，生成针对所述待处理事件的测试脚本，包括：

根据所述待处理事件的属性信息，确定所述待处理事件是否包含子任务；

若确定所述待处理事件包含子任务，则根据子任务的属性信息，生成针对子任务的第一测试内容；

根据所述待处理事件中除子任务外的其它内容的属性信息，生成针对其它内容的第二测试内容；

基于所述第一测试内容和所述第二测试任务，生成所述测试脚本。

在所述根据子任务的属性信息，生成针对子任务的第一测试内容，包括：

从测试代码数据库中，查找与所述子任务的属性信息中的版本信息一致的测试内容；

若查找到与所述自任务的属性信息中的版本信息一致的测试内容，则将查找的测试内容作为第一测试内容。

这里，子任务的属性信息至少包括包括节点标识、节点类型、页面元素、操作类型、定位方式、定位参数、判断逻辑等，子任务对应的子流程图一般存储在子流程图库(又称组件库)中；第一测试内容和第二测试内容均为代码，对第一测试内容和第二测试内容进行拼接处理的方式在现有技术中已有详细的介绍，此处不再进行过多说明。

为便于流程图的组件化管理，在绘制测试业务流程图时，将常用的测试子流程图单独绘制作为组件，可以内嵌至组件库中调用。组件库中保存的是作为组件的子流程图与调用该子流程的其他流程图之间的调用关系，包括以下内容：

主流程图所属系统：调用子流程图的主流程图所属系统名称。

主流程图名称：主流程图名称，在所属系统中，主流程图名称唯一。

子流程图所属系统：作为组件的子流程图所属系统名称。

子流程图名称：子流程图名称，在所属系统中，子流程图名称唯一。

主流程图与子流程图的关系为多对多，一个主流程图可内嵌多个子流程图，一个子流程图也可以作为组件，内嵌至多个主流程图中使用。在绘制主流程图过程中，如果选择内嵌子流程图，该主流程图保存时，会在组件库中增加一条或多条记录，保存该主流程图与内嵌的子流程图之间的调用关系。当主流程图调用的子流程图发生变更时，保存主流程图，也会同步更新子流程图调用情况至组件库，确保组件库的调用关系是最新的。

在上述车险出单主流程图中，该主流程图内嵌了投保单信息录入、投保单信息修改、核保处理、缴费处理四张子流程图，因此，在该主流程图保存时，组件库中将新增四条记录如下：

主流程图所属系统	主流程图名称	子流程图所属系统	子流程图名称
				车险承保系统	车险出单主流程	车险承保系统	投保单信息录入子流程
车险承保系统	车险出单主流程	车险承保系统	投保单信息修改子流程
				车险承保系统	车险出单主流程	车险核保系统	核保处理子流程
车险承保系统	车险出单主流程	见费出单系统	缴费处理子流程

在具体实施中，依次获取待处理事件的属性信息中待处理事件标识，根据待处理事件标识，查询子流程图库(组件库)，判断子流程图库中是否存在与所述待处理事件对应的子任务(也就是子流程图)，若确定子流程图库中存在与所述待处理事件对应的多个子任务，则针对每个子任务，根据该子任务包括的节点信息，从测试模板库，获取与该子任务的各节点对应的测试模板，并根据各节点的属性信息以及获取到的测试模板，生成各节点对应的测试内容，对生成的各测试内容进行拼接处理，得到第一测试内容，由于待处理事件中除了子任务外，还包括其它任务，每个其它任务对应一个节点，若基于节点类型确定当前节点为非决策节点，根据该当前节点中节点对应的操作类型，从测试模板库获取与该当前节点对应的测试模板，根据当前节点的节点信息，生成第一中间测试内容；若基于节点类型确定当前节点为决策节点，则从测试模板库获取与决策节点对应的测试模板，基于决策节点的节点信息，生成决策节点对应的第二中间测试内容，对第一中间测试内容和第二中间测试内容进行拼接得到第二测试内容，将得到的各第一测试内容和第二测试内容进行拼接，得到测试脚本。

例如，主流程图中包括三个用户任务和一个决策任务和两个子流程图，在获取到主流程图后，从组件库中，查询与主流程图名称对应的子流程名称，若查询到与主流程图名称对应的两个子流程名称，则针对每个子流程图，针对该子流程包含的每个节点，若根据该节点的节点类型确定该节点为非决策节点，则从测试模板库获取与该节点的操作类型对应的测试模板，基于该节点的节点信息中的页面元素、定位方式等更新测试模板的内容，若根据该节点的节点类型确定该节点为决策节点，则从测试模板库获取与决策节点对应的测试模板，基于该节点的节点信息中页面元素、判断逻辑(如，比较值、比较条件等)等对上述测试模板的内容进行更新，对各节点的更新后的测试内容进行拼接处理，并去除拼接处理后的测试内容的开始节点和结束节点对应的内容，得到第一测试内容；

之后，对主流程中用户任务进行处理，针对每个用户任务包含的每个节点，若根据该节点的节点类型确定该节点为非决策节点，则从测试模板库获取与该节点的操作类型对应的测试模板，基于该节点的节点信息中的页面元素、定位方式等更新测试模板的内容，若根据该节点的节点类型确定该节点为决策节点，则从测试模板库获取与决策节点对应的测试模板，基于该节点的节点信息中页面元素、判断逻辑(如，比较值、比较条件等)等对上述测试模板的内容进行更新，对每个用户任务包含的各节点的更新后的测试任务生成第二测试内容，对第一测试内容和第二测试内容进行拼接处理，得到测试脚本。

在主流程图中增加决策节点，决策节点一般用于流程分支的判断，通常决策节点通过判断某个或多个页面元素的属性值，来决定后续流程的走向。决策节点的定义如下：

定义要判断的元素属性值，可以是一个或多个，定义类似用户任务，具体内容如下：

所属页面：该元素所属系统页面，用户自定义或从元素库中选择；

元素名称：该元素名称，用户自定义或从元素库中选择；

定位方式：唯一定位该页面元素的定位方式，用户自定义或从元素库中自动带出；

定位参数：指定定位方式后，输入该定位的参数值，用户自定义或从；元素库中自动带出；

获取属性：用户想要获取的该页面元素的某个属性，例如text(文本)、value(值)、displayed(是否显示)、enabled(是否可用)、selected(是否选中)等；

将上一步获取的元素属性值与一个固定值相比较，或多个获取的元素属性值之间相比较，根据结果指定判断值为True还是False。

在实际应用中，从流程图库中获取一个流程图的最新版本，然后先到组件库中查询该流程图是否有子流程图，如果有子流程图，则获取子流程图对应的测试模板，在生成子流程图对应的测试内容时，自动处理去掉测试模板中的开始代码和结束代码，根据节点信息在测试模板的相应位置进行更新，也就是说，将节点信息中的页面元素、定位方式等对应的内容写入到测试模板中，生成测试内容。接着，再生成主流程图中除子流程以外，其它流程对应的测试内容，并将刚生成的子流程图的测试内容与其它节点的测试内容组装起来，生成自动化测试脚本。

测试模板中各个节点(用户任务及决策任务)，各生成一个测试内容，具体生成测试内容过程如下：

开始节点：开始节点是整个测试流程的起始，开始节点生成的代码主要是初始化测试脚本，为后续流程做准备。

泳道：代表主流程(又称业务流程)的不同参与角色，即执行该主流程的不同用户。在生成代码时，会在泳道的第一个任务节点前，增加一个登陆操作，用泳道中设置的被测系统登录地址、用户名、密码登录，并在该泳道最后一个任务节点结束后，关浏览器退出登录状态。

用户任务：用户任务记录了测试过程中对被测系统页面元素的操作步骤，在用户任务生成脚本时，会根据用户任务中记录的操作顺序，结合各个操作在模板库中的代码生成模板，翻译成一段执行这些操作步骤的自动化测试脚本，作为一个类存放。

决策任务：决策任务(对应决策节点)与用户任务(对应非决策节点)类似，根据决策任务中的定义，结合模板库中决策任务生成模板，翻译成一段判断后续流程走向的代码，与用户任务相同，决策任务的代码页作为一个单独的类。

子流程：子流程图的生成脚本过程与主流程图生成过程类似，子流程图也有开始和结束节点，但是因子流程的脚本需要与其他节点的脚本进行拼接，所以生成内嵌子流程的脚本后，需要通过程序自动去掉开始和结束节点的代码，剩余部分的代码，将按流程连线的顺序与主流程图其他节点生成的代码串联拼接起来。

结束节点：结束节点代表一个完整测试流程的结束，在结束节点将生成代表整个流程完结的处理脚本。

流程连线：流程连线代表测试流程的走向，测试模型中各个节点被封装成一个个类，根据流程连线顺序串联起来，形成了一个完整的测试脚本。

生成测试脚本需要用到的代码模板存储在测试模板库中，测试模板库根据运行自动化测试脚本的不同浏览器(如IE、Firefox、Chrome)，及基于Selenium webdriver自动化测试框架的不同脚本语言(如Java、python、ruby、JavaScript等)，存储对应的测试模板(也就是代码模板)，用户在生成测试内容时，指定浏览器及脚本语言，即，可按照测试模板库中存储的对应代码模板，以及元素库中存储的元素定位信息，生成所需的自动化测试脚本。测试模板存储分为以下几类：

开始节点：表示整个流程的起始，根据浏览器参数，启动不同的浏览器。代码如下：

泳道：泳道的代码模板是执行被测系统登录操作的代码，其中被测系统地址、用户名、密码来自流程图中泳道的设置信息，其代码结构如下：

get url；//打开被测系统登录地址

sendKeys(findElement(usernameInputBox),username)；//输入用户名

sendKeys(findElement(passwordInputBox),password)；//输入密码

其中，usernameInputBox和passwordInputBox为用户名/密码输入框的定位信息，username、password为用户名、密码的输入值

用户任务：用户任务记录了测试过程中对被测系统页面元素的操作步骤，在将这些操作步骤翻译成代码时，根据定义不同的操作类型，以及页面元素的定位方式选择模板库中的不同代码模板，具体规则如下：

决策节点：决策节点根据页面元素的属性获取属性值，以及判断逻辑，代码模板如下；

check(findElement(Element),checkAttribute,comparison,checkValue,checkResult)；

其中，Element为要获取的页面元素定位信息；checkAttribute为要获取的属性名称，如text/value；comparison为比较条件，如>、＝、<、不等于、包含、不包含；checkValue为要比较的固定值；checkResult为比较结果，True或者False。

结束节点：结束节点为整个流程的结束，因此结束节点关闭浏览器，结束整个流程，代码如下：closeBrowser()；

S103，存储所述测试脚本。

在存储所述测试脚本中，包括：

将所述测试脚本存储至测试脚本数据库。

在得到测试脚本后，比对当前测试脚本对应的处理事件标识是否大于测试脚本库中的处理事件标识，若当前测试脚本对应的处理事件标识与测试脚本库中的处理事件标识一致，则不存储当前测试脚本，若当前测试脚本对应的处理事件标识与测试脚本库中的处理事件标识不一致，在测试脚本库中存储当前测试脚本与对应的处理事件标识(主流程图标识)，这样，当从主流程库获取的处理事件标识未发生变化时，可以直接从测试脚本数据库中获取当前处理事件标识对应的测试脚本，并执行得到的测试脚本。

在存储测试脚本时，将测试脚本进行压缩后存在测试脚本库中，测试脚本库存储主流程所属的系统名称、主流程图名称、主流程图版本号以及存储路径之间的对应关系。其中，存储路径是根据系统/主流程图名称拼音首字母自动生成的，由于主流程图名称在所属系统中唯一，所以自动生成的脚本存放路径也唯一，测试脚本名称为主流程图名称首字母和版本号连接进行标记。当同一张主流程图的新版本生成测试脚本时，将在测试脚本库中新增一条记录，测试脚本名称中的版本号增加预设值，与该主流程图之前版本的测试脚本存放在一个目录下。

以上述车险出单主流程图为例，该主流程图内嵌了投保单信息录入、投保单信息修改、核保处理、缴费处理四张子流程图。在首次生成测试脚本时，测试脚本库将新增五条记录，其中前四条记录为内嵌子流程测试脚本，第五条记录为全流程测试脚本：

若投保单信息录入子流程发生变更，该主流程图新版本生成脚本时，将在测试脚本库中新增如下一条记录：

在对处理事件进行测试处理时，从流程图库中获取该系统所有流程图的最新版本号，与测试脚本库中存储的测试脚本版本号比对。如果测试脚本库中不存在该流程图的测试脚本，或测试脚本版本号与该流程图最新版本号不一致，则按照最新的流程图生成测试脚本，存储在测试脚本库中。若一致，则根据测试脚本执行测试，并向用户反馈测试结果，测试结果以HTML格式进行展示。

本申请实施例提供的测试脚本生成方法，通过获取的待处理事件的属性信息，自动生成针对待处理事件的测试脚本，并存储测试脚本。这样，无需手动方式生成测试脚本，自动生成测试脚本，大幅提高自动化测试脚本的开发效率，降低维护成本，避免了由于脚本开发人员水平问题导致脚本执行成功率不高的情况，提高了代码的稳定性，通过存储测试脚本使得在执行相同的处理事件时，不必重新生成测试脚本，直接过去测试脚本进行测试，提高了测试效率。

本申请实施例提供了一种测试脚本生成装置，如图2所示，该装置包括：

获取模块21，用于获取待处理事件；

生成模块22，用于根据所述待处理事件的属性信息，生成针对所述待处理事件的测试脚本；

存储模块23，用于存储所述测试脚本。

可选地，所述生成模块22具体用于：

根据所述待处理事件的属性信息，确定所述待处理事件是否包含子任务；

若确定所述待处理事件包含子任务，则根据子任务的属性信息，生成针对子任务的第一测试内容；

根据所述待处理事件中除子任务外的其它内容的属性信息，生成针对其它内容的第二测试内容；

基于所述第一测试内容和所述第二测试任务，生成所述测试脚本。

可选地，所述属性信息至少包括节点标识、节点类型、页面元素、操作类型、定位方式、定位参数、判断逻辑。

可选地，所述生成模块22用于：

从测试代码数据库中，查找与所述子任务的属性信息中的版本信息一致的测试内容；

若查找到与所述自任务的属性信息中的版本信息一致的测试内容，则将查找的测试内容作为第一测试内容。

可选地，所述存储模块23用于：

将所述测试脚本存储至测试脚本数据库。

对应于图1中的测试脚本生成方法，本申请实施例还提供了一种计算机设备300，如图3所示，该设备包括存储器301、处理器302及存储在该存储器301上并可在该处理器302上运行的计算机程序，其中，上述处理器302执行上述计算机程序时实现上述测试脚本生成方法。

具体地，上述存储器301和处理器302能够为通用的存储器和处理器，这里不做具体限定，当处理器302运行存储器301存储的计算机程序时，能够执行上述测试脚本生成方法，解决了现有技术中手动编写测试脚本效率低的问题的问题，本申请通过获取的待处理事件的属性信息，自动生成针对待处理事件的测试脚本，并存储测试脚本。这样，无需手动方式生成测试脚本，自动生成测试脚本，大幅提高自动化测试脚本的开发效率，降低维护成本，避免了由于脚本开发人员水平问题导致脚本执行成功率不高的情况，提高了代码的稳定性，通过存储测试脚本使得在执行相同的处理事件时，不必重新生成测试脚本，直接过去测试脚本进行测试，提高了测试效率。

对应于图1中的测试脚本生成方法，本申请实施例还提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述测试脚本生成方法的步骤。

具体地，该存储介质能够为通用的存储介质，如移动磁盘、硬盘等，该存储介质上的计算机程序被运行时，能够执行上述测试脚本生成方法，解决了现有技术中手动编写测试脚本效率低的问题的问题，本申请通过获取的待处理事件的属性信息，自动生成针对待处理事件的测试脚本，并存储测试脚本。这样，无需手动方式生成测试脚本，自动生成测试脚本，大幅提高自动化测试脚本的开发效率，降低维护成本，避免了由于脚本开发人员水平问题导致脚本执行成功率不高的情况，提高了代码的稳定性，通过存储测试脚本使得在执行相同的处理事件时，不必重新生成测试脚本，直接过去测试脚本进行测试，提高了测试效率。

在本申请所提供的实施例中，应该理解到，所揭露系统和方法，可以通过其它的方式实现。以上所描述的系统实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，系统或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请提供的实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释，此外，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

最后应说明的是：以上所述实施例，仅为本申请的具体实施方式，用以说明本申请的技术方案，而非对其限制，本申请的保护范围并不局限于此，尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本申请实施例技术方案的精神和范围。都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应所述以权利要求的保护范围为准。

Claims (10)

1.一种测试脚本生成方法，其特征在于，该方法包括：

获取待处理事件；

根据所述待处理事件的属性信息，生成针对所述待处理事件的测试脚本；

存储所述测试脚本。

2.如权利要求1所述的方法，其特征在于，所述根据所述待处理事件的属性信息，生成针对所述待处理事件的测试脚本，包括：

根据所述待处理事件的属性信息，确定所述待处理事件是否包含子任务；

若确定所述待处理事件包含子任务，则根据子任务的属性信息，生成针对子任务的第一测试内容；

根据所述待处理事件中除子任务外的其它内容的属性信息，生成针对其它内容的第二测试内容；

基于所述第一测试内容和所述第二测试任务，生成所述测试脚本。

3.如权利要求1或2中所述的方法，其特征在于，所述属性信息至少包括节点标识、节点类型、页面元素、操作类型、定位方式、定位参数、判断逻辑。

4.如权利要求2所述的方法，其特征在于，所述根据子任务的属性信息，生成针对子任务的第一测试内容，包括：

从测试代码数据库中，查找与所述子任务的属性信息中的版本信息一致的测试内容；

若查找到与所述自任务的属性信息中的版本信息一致的测试内容，则将查找的测试内容作为第一测试内容。

5.如权利要求1所述的方法，其特征在于，所述存储所述测试脚本，包括：

将所述测试脚本存储至测试脚本数据库。

6.一种测试脚本生成装置，其特征在于，该装置包括：

获取模块，用于获取待处理事件；

生成模块，用于根据所述待处理事件的属性信息，生成针对所述待处理事件的测试脚本；

存储模块，用于存储所述测试脚本。

7.如权利要求6所述的装置，其特征在于，所述生成模块具体用于：

根据所述待处理事件的属性信息，确定所述待处理事件是否包含子任务；

若确定所述待处理事件包含子任务，则根据子任务的属性信息，生成针对子任务的第一测试内容；

根据所述待处理事件中除子任务外的其它内容的属性信息，生成针对其它内容的第二测试内容；

基于所述第一测试内容和所述第二测试任务，生成所述测试脚本。

8.如权利要求6或7中所述的装置，其特征在于，所述属性信息至少包括包括节点标识、节点类型、页面元素、操作类型、定位方式、定位参数、判断逻辑。

9.一种计算机设备，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现上述权利要求1-5中任一项所述的方法的步骤。

10.一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，其特征在于，所述计算机程序被处理器运行时执行上述权利要求1-5中任一项所述的方法的步骤。