CN111274147B

CN111274147B - 一种脚本自动测试方法、装置、电子设备以及可读介质

Info

Publication number: CN111274147B
Application number: CN202010070581.1A
Authority: CN
Inventors: 张素省
Original assignee: Zhuhai Necessary Industrial Technology Co ltd
Current assignee: Zhuhai Necessary Industrial Technology Co ltd
Priority date: 2020-01-21
Filing date: 2020-01-21
Publication date: 2021-04-27
Anticipated expiration: 2040-01-21
Also published as: CN111274147A

Abstract

本申请涉及一种脚本自动测试方法、装置、电子设备以及计算机可读介质，本申请通过获取至少两个应用端中的多个待测脚本和用于表示位于不同所述应用端中的所述待测脚本之间的运行逻辑和所述应用端中待测脚本的运行逻辑的运行逻辑信息；根据所述运行逻辑信息对多个所述待测脚本进行测试，达到自动根据运行逻辑信息对多个待测脚本进行测试的目的，减轻脚本检测人员工作负担的同时，还提高了脚本检测的效率。

Description

一种脚本自动测试方法、装置、电子设备以及可读介质

技术领域

本申请涉及脚本测试技术领域，尤其涉及一种脚本自动测试方法、装置、电子设备以及计算机可读介质。

背景技术

随着互联网时代的发展，人们采购物资的方式也随之发生变化，由于电子商城中的商品具备价格公开、品种数量多以及商品介绍齐全等优点，大到建筑耗材，小到生活用品，人们更多倾向于在电子商城上购物，为了满足人们日益增长的购物需求，电商平台也不断完善增加各种功能。

目前，购物平台系统涉及客户端和商家端，商家端中的接单流程脚本依赖于客户端中下单流程脚本输出的结果，测试人员需要先对客户端中的下单流程脚本进行测试，若测试脚本运行无误，再将下单流程脚本输出结果输入到商家端的接单流程脚本中，以对商家端中的接单流程脚本进行测试，所以针对系统进行回归测试，都主要依靠测试人员手动测试脚本，操作繁琐，效率低下。

发明内容

为了解决上述技术问题或者至少部分地解决上述技术问题，本申请提供了一种脚本自动测试方法、装置、电子设备以及计算机可读介质。

第一方面，本申请提供了一种脚本自动测试方法，所述方法包括：

获取至少两个应用端中的多个待测脚本和用于表示位于不同所述应用端中的所述待测脚本之间的运行逻辑和所述应用端中待测脚本的运行逻辑的运行逻辑信息；

根据所述运行逻辑信息对多个所述待测脚本进行测试。

可选地，根据所述运行逻辑信息对多个所述待测脚本进行测试的步骤，包括：

若运行逻辑中任意相邻的两个所述待测脚本对应的应用端不同，将上一级待测脚本输出的中间测试结果存储至交互文件中，根据所述运行逻辑信息将上一级待测脚本输出的中间测试结果作为下一级待测脚本的输入，对所述下一级待测脚本进行测试。

可选地，根据所述运行逻辑信息将上一级待测脚本输出的中间测试结果作为下一级待测脚本的输入的步骤，包括：

若所述下一级待测脚本仅依赖一个测试结果，则将所述测试结果确定为中间测试结果；

将所述中间测试结果作为所述下一级待测脚本的输入，对所述下一级待测脚本进行测试。

若所述下一级待测脚本依赖至少两个测试结果，判断从所述交互文件中是否获得到所述下一级待测脚本依赖至少两个测试结果，且每个所述测试结果均为测试成功；

若从所述交互文件中获得到所述下一级待测脚本依赖至少两个测试结果，且每个所述测试结果均为测试成功，则根据至少两个所述测试结果确定所述中间测试结果；

将所述中间测试结果作为所述下一级待测脚本的输入，对所述待测脚本进行测试。

若运行逻辑中任意相邻的两个脚本中的上一级脚本和下一级脚本，以上一级待测脚本的输出作为输入的下一级待测脚本存在至少两个；

针对每个所述下一级待测脚本，将所述上一级待测脚本输出的中间测试结果作为下一级待测脚本的输入，对所述下一级待测脚本进行测试。

可选地，还包括：

若在多个所述待测脚本中确定任一所述待测脚本运行出错，则生成运行出错的待测脚本的预警信息。

可选地，还包括：

若所述待测脚本输出的测试结果为测试失败，重新获取运行出错的所述待测脚本的上一级待测脚本输出的中间测试结果；

将所述中间测试结果作为所述待测脚本的输入，对所述待测脚本进行重新测试；

若重新测试次数超过预设阈值，则确定所述待测脚本运行出错。

或者，若所述待测脚本输出的测试结果为测试失败，将所述中间测试结果作为所述待测脚本的输入，以对所述待测脚本进行重新测试；

记录重新测试时刻；

若所述重新测试时刻与当前时刻的差值超过预设阈值，则确定所述待测脚本运行出错。

第二方面，本申请还提供了一种脚本自动测试装置，包括：

获取模块，用于获取至少两个应用端中的多个待测脚本和用于表示位于不同所述应用端中的所述待测脚本之间的运行逻辑和所述应用端中待测脚本的运行逻辑的运行逻辑信息；

测试模块，用于根据所述运行逻辑信息对多个所述待测脚本进行测试。

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

第四方面，本申请还提供了一种具有处理器可执行的非易失的程序代码的计算机可读介质，所述程序代码使所述处理器执行第一方面任一所述方法。

本申请实施例提供的上述技术方案与现有技术相比具有如下优点：本申请通过获取至少两个应用端中的多个待测脚本和用于表示位于不同所述应用端中的所述待测脚本之间的运行逻辑和所述应用端中待测脚本的运行逻辑的运行逻辑信息；根据所述运行逻辑信息对多个所述待测脚本进行测试，达到自动根据运行逻辑信息对多个待测脚本进行测试的目的，减轻脚本检测人员工作负担的同时，还提高了脚本检测的效率。

附图说明

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

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

图1为本申请实施例提供的一种脚本自动测试方法的流程图；

图2为本申请实施例提供的另一种脚本自动测试方法的流程图；

图3为本申请实施例提供的另一种脚本自动测试方法的流程图；

图4为本申请实施例提供的另一种脚本自动测试方法的流程图；

图5为本申请实施例提供的另一种脚本自动测试方法的流程图；

图6为本申请实施例提供的另一种脚本自动测试方法的流程图；

图7为本申请实施例提供的实际应用中执行脚本流程示意图；

图8为本申请实施例提供的一种脚本自动测试装置的示意图；

图9为本申请实施例提供的一种电子设备的结构图。

具体实施方式

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

目前，为了保证系统上线能够稳定运行，在系统上线之前或者迭代更新之后都会对系统中多个脚本进行测试，例如：购物平台系统涉及客户端和商家端，商家端中的接单流程脚本依赖于客户端中下单流程脚本输出的结果，测试人员需要先对客户端中的下单流程脚本进行测试，若测试脚本运行无误，再将下单流程脚本输出结果输入到商家端的接单流程脚本中，以对商家端中的接单流程脚本进行测试，所以针对系统进行回归测试，都主要依靠测试人员手动测试脚本，操作繁琐，效率低下，基于此本发明提供了一种脚本自动测试方法，如图1所示，所述方法包括：

步骤S101，获取至少两个应用端中的多个待测脚本和用于表示位于不同所述应用端中的所述待测脚本之间的运行逻辑和所述应用端中待测脚本的运行逻辑的运行逻辑信息；

在本发明实施例中，一个应用端中可以有多个待测脚本，其中，脚本是是一种纯文本保存的程序，待测脚本是指需要进行测试的程序，通常在系统或者APP上线前/版本迭代后，为了保证系统或APP稳定运行，会对其包含的脚本进行测试。

在本发明实施例中，应用端可以是应用系统，在实际应用中，一个系统中一般存在至少两个应用端，且各应用端之间存在交互关系，例如：在一个系统中，A应用端与B应用端之间存在交互关系，具体的，A应用端中的a脚本的输出的结果需要调度给B应用端中的b脚本使用，以使b脚本可以运行。

在该步骤中，运行逻辑信息可以是检测人员预先配置的，该运行逻辑信息可以包括待测脚本之间的执行先后关系或者待测脚本的执行优先级等等能够反映脚本之间执行逻辑的信息。

步骤S102，根据所述运行逻辑信息对多个所述待测脚本进行测试。

在本发明实施例中，运行逻辑信息中包含各个待测脚本之间的逻辑运行关系，例如有脚本a和脚本b以及脚本c，运行逻辑信息可以包括：脚本a的输出的结果用作脚本b的输入，脚本b输出的结果用作脚本c的输入。

本发明实施例通过获取检测的运行逻辑信息，以达到确定位于不同所述应用端中多个待测脚本之间的运行逻辑的目的，代替传统人工逐一测试脚本的方式，减轻脚本检测人员工作负担，并且还提高了脚本检测的效率。

在本发明提供的又一实施例中，还提供了一种基于运行逻辑信息测试待测脚本的具体实施方式，步骤S102，根据所述运行逻辑信息对多个所述待测脚本进行测试的步骤，包括：

在本发明实施例中，当运行逻辑中任意相邻两个待测脚本分别属于不同的应用终端，则通过将运行逻辑上相邻的两个待测脚本中执行优先级高的上一级待测脚本输出的中间测试结果存储至交互文件中，以用于数据调度，即当下一级待测脚本进行测试时，从交互文件中获取中间测试结果，以进行脚本的测试，其中交互文件的格式可以根据实际情况而定，例如：本地文件或者数据库文件等等，另外，数据调度可以通过Jenkins服务器调度，或者其他能过实现数据调度过程的服务器，本发明对此不作具体限定。

本发明实施例通过设置交互文件建立不同应用端的脚本之间的逻辑联系，并且通过将运行逻辑上相邻的上一级待测脚本的输出作为下一级待测脚本的输入的方式，实现自动化测试，不仅减少检测人员的工作量，还可以提高脚本测试的效率。

另外，在实际应用中，应用端中一般有多个脚本，所以根据所述运行逻辑信息对多个所述待测脚本进行测试的步骤，还可以包括：

若运行逻辑中任意相邻的两个所述待测脚本位于同一个所述应用端中，根据所述运行逻辑信息将上一级待测脚本输出的中间测试结果作为下一级待测脚本的输入，对所述下一级待测脚本进行测试。

在该步骤中，同一个应用终端中的脚本输出的结果可以不用加载至交互文件中，直接根据运行逻辑将中间测试结果作为下一级待测脚本的输入。本发明实施例通过将运行逻辑上相邻的上一级待测脚本的输出作为下一级待测脚本的输入的方式，实现了自动化测试，减少检测人员的工作量的同时，还提高脚本测试的效率。

在本发明提供的又一实施例中，由于实际应用中，各个应用端中的待测脚本之间的运行逻辑可能存在一对多的对应关系（脚本a与脚本b需要用脚本c输出的中间测试结果驱动），或者一对一的对应关系（脚本a需要用脚本b输出的中间测试结果驱动），基于此，针对多个待测脚本中任意运行逻辑相邻的两个待测脚本之间存在一对一的对应关系的情况，如图2所示，根据所述运行逻辑信息将上一级待测脚本输出的中间测试结果作为下一级待测脚本的输入的步骤，包括：

步骤S201，若所述下一级待测脚本仅依赖一个测试结果，则将所述测试结果确定为中间测试结果；

步骤S202，将所述中间测试结果作为所述下一级待测脚本的输入，对所述下一级待测脚本进行测试。

在本发明实施例中，在多个待测脚本中任意两个运行逻辑相邻的上一级待测脚本和下一级待测脚本中，若下一级待测脚本仅需要上一级待测脚本输出的测试结果就可以运行该脚本，则将所述测试结果确定为中间测试结果，并将所述中间测试结果作为所述下一级待测脚本的输入，以对下一级待测脚本进行测试。

本发明实施例在下一级待测脚本仅依赖一个测试结果时，可以直接将上一级待测脚本输出测试结果确定为中间测试结果，并将所述中间测试结果作为所述下一级待测脚本的输入，对下一级待测脚本进行测试，以实现自动化测试流程。

在本发明实施例中，针对于各个应用端中的待测脚本之间的运行逻辑可能存在一对多的对应关系（脚本a与脚本b需要用脚本c输出的中间测试结果驱动），如图3所示，根据所述运行逻辑信息将上一级待测脚本输出的中间测试结果作为下一级待测脚本的输入的步骤，包括：

步骤S301，若所述下一级待测脚本依赖至少两个测试结果，判断从所述交互文件中是否获得到所述下一级待测脚本依赖至少两个测试结果，且每个所述测试结果均为测试成功；

在本发明实施例中，在多个待测脚本中任意两个运行逻辑相邻的上一级待测脚本和下一级待测脚本中，下一级待测脚本不仅依赖于上一级待测脚本输出的测试结果，还依赖于其他应用端中的待测脚本输出的测试结果时，可以从交互文件中获取下一级待测脚本依赖的待测脚本输出的测试结果，其中，只有当测试结果为测试成功时，输出的测试结果才可以驱动下一级待测脚本。

步骤S302，若从所述交互文件中获得到所述下一级待测脚本依赖至少两个测试结果，且每个所述测试结果均为测试成功，则根据至少两个所述测试结果确定所述中间测试结果；

在本发明实施例中，若从所述交互文件中获得到所述下一级待测脚本依赖至少两个测试结果，且每个所述测试结果均为测试成功，则对下一级待测脚本依赖的至少两个测试结果进行集合，得到中间测试结果。

步骤S303，将所述中间测试结果作为所述下一级待测脚本的输入，对所述待测脚本进行测试。

在本发明实施例中，当下一级待测脚本需要两个或两个以上测试结果驱动时，将包含两个或两个以上测试结果的中间测试结果作为所述下一级待测脚本的输入，以对该待测脚本进行测试。本发明实施例通过从交互文件中获取待测脚本依赖的测试结果，实现跨应用端调度数据的过程，达到根据运行逻辑检测不同应用端之间存在交互关系的脚本的目的。

在实际应用中，在电商平台系统中，执行客户端中下单流程脚本之后，输出“订单号码”给订单流程脚本，但是订单流程脚本的执行还需要商家端中的订单生产完成脚本输出的“已生产”驱动客户端执行脚本确认订单生产中状态，确认之后商家端继续根据订单号进行发货商家脚本输出“已发货”结果驱动客户端脚本继续执行剩余脚本。

在本发明提供的又一实施例中，还提供了一种运行逻辑中任意相邻的两个脚本中的上一级脚本和下一级脚本，以上一级待测脚本的输出作为输入的下一级待测脚本存在至少两个的情况下的具体实施方式，如图4所示，根据所述运行逻辑信息将上一级待测脚本输出的中间测试结果作为下一级待测脚本的输入的步骤，包括：

步骤S401，若运行逻辑中任意相邻的两个脚本中的上一级脚本和下一级脚本，以上一级待测脚本的输出作为输入的下一级待测脚本存在至少两个；

步骤S402，针对每个所述下一级待测脚本，将所述上一级待测脚本输出的中间测试结果作为下一级待测脚本的输入，对所述下一级待测脚本进行测试。

在本发明实施例中，当运行逻辑中任意相邻的两个脚本中的上一级脚本和下一级脚本，以上一级待测脚本的输出作为输入的下一级待测脚本存在至少两个时，则需要将上一级待测脚本输出的中间测试结果分别作为每个下一级待测脚本的输入，以对每个下一级待测脚本进行测试。

本发明实施例首先通过运行逻辑判断逻辑相邻的两个待测脚本中，下一级待测脚本是否依赖于多个上一级待测脚本输出的测试结果，若否，则可以直接将测试结果确定为中间测试结果，此时，中间测试结果中只包含一个上一级待测脚本的测试结果，最后将中间测试结果作为下一级待测脚本的输入，以自动运行下一级待测脚本，实现根据各脚本之间的运行逻辑，自动测试脚本的目的。

在本发明提供的又一实施例中，还提供一种校验实施例，包括：

在本发明实施例中，确定待测脚本运行出错的方法可以依据实际情况而定，本发明实施例通过能够测试脚本运行是否出错的方法确定运行出错的脚本，以生成与运行出错的脚本对应的预警信息，达到提示相关检测人员的目的，保证待测产品在上线前或者版本迭代后的稳定运行，减少产品上线后的运行错误。

进一步地，在本发明实施例中提供了两种用于确定脚本运行错误的具体实施方式，首先如图5所示，包括：

步骤S501，若所述待测脚本输出的测试结果为测试失败，重新获取运行出错的所述待测脚本的上一级待测脚本输出的中间测试结果；

在本发明实施例中，若测试当前级脚本输出的测试结果为测试失败，则重新获取当前级脚本的上一级待测脚本输出的测试结果，以用于重新对当前级脚本进行测试，避免因为小概率的测试异常而将脚本确定为运行错误脚本。

步骤S502，将所述中间测试结果作为所述待测脚本的输入，对所述待测脚本进行重新测试；

在本发明实施例中，当前级正在测试的脚本输出的测试结果为测试失败时，可以将中间测试结果作为所述运行出错的待测脚本的输入，以对待测脚本进行重新测试。

步骤S503，若重新测试次数超过预设阈值，则确定所述待测脚本运行出错；

在本发明实施例中，可以预先设置一个重试次数的阈值，例如：重试3次，重试5次等等，具体设置的重试次数可以根据经验值而定，本发明实施例对此不作具体限定。本发明实施例通过调取待测脚本依赖的中间测试结果，实现重新对当前级脚本进行测试，避免因为小概率的测试异常而将脚本确定为运行错误脚本。

另外，本发明实施例还提供了一种用于确定脚本运行错误的具体实施方式，如图6所示，所述方法包括：

步骤S601，若所述待测脚本输出的测试结果为测试失败，将所述中间测试结果作为所述待测脚本的输入，以对所述待测脚本进行重新测试；

在本发明实施例中，当前级待测脚本输出测试结果为测试失败，则重新获取当前级脚本的上一级待测脚本输出的测试结果，以用于重新对当前级脚本进行测试，避免因为小概率的测试异常而将脚本确定为运行错误脚本。

步骤S602，记录重新测试时刻；

步骤S603，若所述重新测试时刻与当前时刻的差值超过预设阈值，则确定所述待测脚本运行出错。

在本发明实施例中，重新测试时刻可以是“x年x月x日x时x分x秒，”当前时刻可以是测试系统中的实际时间，通过将重新测试时刻与当前时刻作差，可以确定该脚本的运行时长，在实际运行中，当脚本出现死循环时，即重新测试时刻与当前时刻的差值超过预设阈值，则可以确定待测脚本运行出错，本发明实施例通过计算重试时长的方式，可以确定因死循环或者程序出错造成脚本无法输出测试结果的情况，进而确定待测脚本运行出错。

在本发明提供的又一实施例中，所述脚本自动测试方法可应用于C2M(Customer-To-Manufactory,用户直连工厂)柔性生产模式的电商平台，其通过C2M模式省去经销商、代理商等中间环节，有利于提高商品的性价比；该电商平台可以直接对接制造商，同时可支持用户根据自身需求定制商品；用户先在电商平台下单后，制造商再开始生产，不同的商品生产周期不同。

C2M模式的电商平台虽然建立了用户与商家直接沟通/下单的渠道，但对于拥有多个应用端的C2M模式的电商平台的系统，在系统维护、更新版本或者上线之前都需要人工启动不同应用端的流程脚本，以完成对系统整体流程的运行测试，例如：C2M模式的电商平台的系统涉及客户端和商家端，商家端中的接单流程脚本依赖于客户端中下单流程脚本输出的结果，测试人员需要先对客户端中的下单流程脚本进行测试，若测试脚本运行无误，再将下单流程脚本输出结果输入到商家端的接单流程脚本中，以对商家端中的接单流程脚本进行测试，依靠测试人员手动测试脚本，不仅操作繁琐，且效率低下。

基于此，本发明实施例将脚本自动测试方法对C2M模式的电商平台中的流程脚本进行自动化测试，以解决现有技术必须人工测试不同应用端中的流程脚本，效率低下的问题，具体地，如图7所示，电商平台系统中包含客户端和商家端，客户端和商家端中各自有多个待测脚本，且不同应用端中的待测脚本存在交互关系，具体实施方式：

首先获取到客户端和商家端中的多个待测脚本以及配置文件，配置文件中可以包括运行逻辑文件，运行逻辑文件可以是检测人员预先录入的各个待测脚本之间的运行逻辑，本发明实施例通过配置客户端的待测脚本和商家端的待测脚本的运行逻辑，实现自动化对于系统中各个流程脚本进行测试的目的，提高测试效率。

然后当客户支付订单以后，生成订单号等一系列的订单相关信息，上述信息都可以存放至交互文件中，以便用户可以随时查看订单相关信息或者订单状态；

之后同时执行客户端中的执行脚本和商家端中的执行脚本，客户端的执行脚本用于判断订单是否已生产中，而“订单是否已生产”是商家端执行脚本输出的结果，当商家端的执行脚本运行后，将“订单已生产”或者“订单未生产”的测试结果发送给客户端App，其中，不同应用端之间用于交互的信息都可以存放至交互文件中，以便对不同执行脚本的依赖数据进行调取，且可以达到用户可视化的目的，用户通过查阅交互文件即可确定订单流程的进度；

同理，当商家端执行脚本输出“订单已发货”，将“订单已发货”的测试结果作为中间测试结果输入到交互文件中，当客户端执行用户需要调度作为输入的数据时，即可从交互文件中查找该执行用户依赖的驱动数据，若读取到“订单已发货”的测试结果，则可以继续执行客户端的执行脚本；

最后测试结束，可以生成检测报告，以发给相关检测人员，该系统功能流程完成测试的信息等等。

在本发明的又一实施例中，还提供了一种脚本自动测试装置，其如图8所示，包括：

获取模块01，用于获取至少两个应用端中的多个待测脚本和用于表示位于不同所述应用端中的所述待测脚本之间的运行逻辑和所述应用端中待测脚本的运行逻辑的运行逻辑信息；

测试模块02，用于根据所述运行逻辑信息对多个所述待测脚本进行测试。

在本发明的又一实施例中，还提供一种电子设备，包括：处理器、通信接口、存储器和通信总线，其中，处理器，通信接口，存储器通过通信总线完成相互间的通信；

存储器，用于存放计算机程序；

处理器，用于执行存储器上所存放的程序时，实现方法实施例所述的脚本自动测试方法。

本发明实施例提供的电子设备，处理器通过执行存储器上所存放的程序实现了获取至少两个应用端中的多个待测脚本和用于表示位于不同所述应用端中的所述待测脚本之间的运行逻辑和所述应用端中待测脚本的运行逻辑的运行逻辑信息；根据所述运行逻辑信息对多个所述待测脚本进行测试，达到自动根据运行逻辑信息对多个待测脚本进行测试的目的，减轻脚本检测人员工作负担的同时，还提高了脚本检测的效率。

上述电子设备提到的通信总线1140可以是外设部件互连标准(PeripheralComponentInterconnect，简称PCI)总线或扩展工业标准结构(ExtendedIndustryStandardArchitecture，简称EISA)总线等。该通信总线1140可以分为地址总线、数据总线、控制总线等。为便于表示，图9中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

通信接口1120用于上述电子设备与其他设备之间的通信。

存储器1130可以包括随机存取存储器(RandomAccessMemory，简称RAM)，也可以包括非易失性存储器(non-volatilememory)，例如至少一个磁盘存储器。可选的，存储器还可以是至少一个位于远离前述处理器的存储装置。

上述的处理器1110可以是通用处理器，包括中央处理器(CentralProcessingUnit，简称CPU)、网络处理器(NetworkProcessor，简称NP)等；还可以是数字信号处理器(DigitalSignalProcessing，简称DSP)、专用集成电路(ApplicationSpecificIntegratedCircuit，简称ASIC)、现场可编程门阵列(Field-ProgrammableGateArray，简称FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

在本发明的又一实施例中，还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有脚本自动测试方法的程序，所述脚本自动测试方法的程序被处理器执行时实现方法实施例所述的脚本自动测试方法的步骤。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行计算机程序指令时，全部或部分地产生按照本发明实施例的流程或功能。计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘SolidStateDisk(SSD))等。

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

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

Claims

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

根据所述运行逻辑信息对多个所述待测脚本进行测试，包括：

若运行逻辑中任意相邻的两个所述待测脚本对应的应用端不同，将上一级待测脚本输出的中间测试结果存储至交互文件中，根据所述运行逻辑信息将上一级待测脚本输出的中间测试结果作为下一级待测脚本的输入，对所述下一级待测脚本进行测试；

根据所述运行逻辑信息将上一级待测脚本输出的中间测试结果作为下一级待测脚本的输入的步骤，包括：若所述下一级待测脚本依赖至少两个测试结果，判断从所述交互文件中是否获得到所述下一级待测脚本依赖至少两个测试结果，且每个所述测试结果均为测试成功；若从所述交互文件中获得到所述下一级待测脚本依赖至少两个测试结果，且每个所述测试结果均为测试成功，则根据至少两个所述测试结果确定所述中间测试结果；将所述中间测试结果作为所述下一级待测脚本的输入，对所述待测脚本进行测试；

根据所述运行逻辑信息将上一级待测脚本输出的中间测试结果作为下一级待测脚本的输入的步骤，还包括：若运行逻辑中任意相邻的两个脚本中的上一级脚本和下一级脚本，以上一级待测脚本的输出作为输入的下一级待测脚本存在至少两个；针对每个所述下一级待测脚本，将所述上一级待测脚本输出的中间测试结果作为下一级待测脚本的输入，对所述下一级待测脚本进行测试。

2.根据权利要求1所述的脚本自动测试方法，其特征在于，根据所述运行逻辑信息将上一级待测脚本输出的中间测试结果作为下一级待测脚本的输入的步骤，包括：

3.根据权利要求1所述的脚本自动测试方法，其特征在于，还包括：

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

若重新测试次数超过预设阈值，则确定所述待测脚本运行出错；

记录重新测试时刻；

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

测试模块，用于根据所述运行逻辑信息对多个所述待测脚本进行测试，包括：

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

7.一种具有处理器可执行的非易失的程序代码的计算机可读介质，其特征在于，所述程序代码使所述处理器执行所述权利要求1至4任一所述方法。