CN115640236A - 一种脚本质量的检测方法及计算设备 - Google Patents

Abstract

本申请实施例提供一种脚本质量的检测方法及计算设备，涉及计算机技术领域，可以准确的检测测试脚本的质量，后续可以将高质量的测试脚本用于测试，得到可信的测试结果。检测测试脚本的脚本内容，得到测试脚本的静态得分。运行测试脚本，获取运行测试脚本得到的报错信息。基于报错信息中包括的报错类型和运行测试脚本失败的次数，确定测试脚本的运行得分。综合静态得分和运行得分，评估测试脚本的质量。

Description

一种脚本质量的检测方法及计算设备

技术领域

本申请涉及计算机技术领域，尤其涉及一种脚本质量的检测方法及计算设备。

背景技术

通常情况下，在新开发的系统（本文中统称为被测试系统）上线前，都会通过大量的测试来对被测试系统测试从而发现问题，然后及时补救。如此，可以减少被测试系统上线后的问题，确保被测试系统的性能。

很显然，采用测试脚本对被测试系统测试，则测试脚本的质量将决定测试结果的好坏。测试脚本的质量高，则可以准确的发现被测试系统中的问题。测试脚本的质量低，则可能不能真正发现被测试系统中的问题。

然而，发明人在实施本申请实施例的过程中发现，现有技术中尚缺少可以准确检测测试脚本质量的方案，导致使用测试脚本测试得到的测试结果的可信度不高，无法准确的发现被测试系统中的问题。

发明内容

有鉴于此，本申请提供了一种脚本质量的检测方法及计算设备，可以准确的检测测试脚本的质量，后续可以将高质量的测试脚本用于测试，得到可信的测试结果。

第一方面，本申请实施例提供一种脚本质量的检测方法，包括：检测测试脚本的脚本内容，得到测试脚本的静态得分。运行测试脚本，获取运行测试脚本得到的报错信息。基于报错信息中包括的报错类型和运行测试脚本失败的次数，确定测试脚本的运行得分。综合静态得分和运行得分，评估测试脚本的质量。

综上所述，采用本申请实施例，可以从静态和运行态两个维度来评估测试脚本的质量，得到测试脚本的质量得分。如此，可以得到测试脚本更准确的质量评估结果，据此后续则可以准确筛选出质量高的测试脚本用于对被测试系统测试。从而提高测试结果的准确性。

在第一方面的一种可能的设计方式中，检测测试脚本的脚本内容，包括以下一项或多项：

检测测试脚本中用于初始化环境的字段中是否有内容。如果用于初始化环境的字段中没有内容，则表明测试脚本中没有初始化环境，其质量是较差的。

以及，检测测试脚本中用于指示测试步骤的字段中是否有内容。如果用于指示测试步骤的字段中没有内容，则表明测试脚本中没有操作步骤，其质量是较差的。

以及，在测试脚本中包括修改第一数据的语句的情况下，检测在所述测试脚本中修改第一数据的语句之后，是否包括恢复第一数据的语句。如果测试脚本中有修改第一数据的语句之后，没有恢复第一数据的语句，则表明会破坏被测试操作系统中的数据，影响后续其他测试脚本的执行，其质量是较差的。

以及，在测试脚本中包括插入第二数据的语句的情况下，检测在测试脚本中插入第二数据的语句之前，是否包括删除第二数据的语句。如果测试脚本中插入第二数据的语句之前，没有删除第二数据的语句，则表明可能会出现重复数据，导致测试脚本无法成功执行，其质量是较差的。

以及，在测试脚本中包括插入第二数据的语句的情况下，检测插入第二数据的语句中是否包括字段名。如果插入数据的语句中不包括字段名，则表明插入的具体字段不明确，在插入第二数据时可能会出错，测试脚本的质量较差。

以及，检测测试脚本中常量的数量、与常量和变量的数量之和的比值是否超过第一阈值。如果测试脚本中常量的占比较高，则会影响修改测试脚本的效率，测试脚本的质量较差。

在第一方面的一种可能的设计方式中，检测测试脚本的脚本内容，包括以下一项或多项：

检测测试脚本中是否包括相对路径，相对路径中包括预设字符。如果测试脚本中的路径不是相对路径，则会影响修改测试脚本的效率，测试脚本的质量较差。

以及，在测试脚本中操作步骤的数量超过第二阈值的情况下，检测测试脚本中是否包括已封装的操作步骤。如果测试脚本中的操作步骤较多，但是都没有封装，则表明测试脚本的编写没有考虑到操作步骤复用的问题，其质量较差。

以及，检测测试脚本中的环境地址中是否包括变量。如果测试脚本中的环境地址不包括变量，则会影响修改测试脚本的效率，测试脚本的质量较差。

在第一方面的一种可能的设计方式中，检测测试脚本的脚本内容，包括以下一项或多项：

检测测试脚本中是否包括注释文本。如果测试脚本中没有注释，则表明其阅读难度较高，质量较差。

以及，检测测试脚本中是否包括用于指示操作步骤的分组的字段。如果测试脚本中没有用于指示操作步骤的分组的字段，则表明测试脚本的逻辑不好，其质量较差。

以及，在测试脚本中包括用于指示密码的第一字段的情况下，检测测试脚本中第一字段的字段值（即密码）的长度是否超过预设长度。如果密码的长度没有超过预设长度，则表明密码是明文，容易造成密码泄露，其质量较差。

在第一方面的一种可能的设计方式中，检测测试脚本的脚本内容，包括以下一项或多项：

检测测试脚本中是否包括延时语句。如果测试脚本中包括延时语句，则可能因为延时影响测试脚本的执行效率，其质量较差。

以及，检测测试脚本中是否包括断言检测。如果测试脚本中不包括断言检测，则无法检测被测试系统返回的结果，其质量较差。

以及，在测试脚本中包括断言检测的情况下，检测断言检测中是否包括对预期输出的检测，预期输出包括执行测试脚本中的操作步骤后的正确结果。如果测试脚本中包括断言检测，但却未检测是否为预期输出，则无法检测被测试系统是否可以返回正确的结果，其质量较差。

在第一方面的一种可能的设计方式中，在检测测试脚本中是否包括延时语句之后，还包括：若测试脚本中包括延时语句，检测延时语句中的延时时长是否超过预设延时时长。也就是说，如果测试脚本中都延时语句，但是通常只有在延时时长较长时，才会影响测试脚本的执行效率，该情况下，测试脚本的质量较差。

在第一方面的一种可能的设计方式中，基于报错信息中包括的报错类型和运行测试脚本失败的次数，确定测试脚本的运行得分，包括：报错信息中包括的错误类型中预设报错类型越多，运行得分越低，报错信息中包括的错误类型中预设报错类型越少，运行得分越高。其中，预设报错类型为测试脚本的脚本质量导致的报错类型。以及，运行测试脚本失败的次数越少，运行得分越低，运行测试脚本失败的次数越多，运行得分越高。

在第一方面的一种可能的设计方式中，预设报错类型包括预置脚本报错，在基于报错信息中包括的报错类型和运行测试脚本失败的次数，确定测试脚本的运行得分之前，还包括：在报错信息中定位用于指示预置条件的第一关键字，报错信息中属于第一关键字的报错信息为预置条件的报错信息。如此，则可以定位出报错信息中预置条件的报错信息所在的位置。然后，检测报错信息中预置条件的报错信息中是否有报错内容，如有ERROR关键字，则有报错内容。若是，报错信息包括的报错类型中存在预置脚本报错，若否，报错信息包括的报错类型中不存在预置脚本报错。

如果报错信息中包括预置脚本报错，表明测试脚本中预置条件的部分有问题，即测试脚本的质量较差。

在第一方面的一种可能的设计方式中，预设报错类型包括后处理报错，在基于报错信息中包括的报错类型和运行测试脚本失败的次数，确定测试脚本的运行得分之前，还包括：在报错信息中定位用于指示后处理的第二关键字，报错信息中属于第二关键字的报错信息为后处理的报错信息。如此，则可以定位出报错信息中后处理的报错信息所在的位置。然后，检测报错信息中后处理的报错信息中是否有报错内容，若是，报错信息包括的报错类型中存在后处理报错，若否，报错信息包括的报错类型中不存在后处理报错。

如果报错信息中包括后处理报错，表明测试脚本中后处理的部分有问题，即测试脚本的质量较差。

在第一方面的一种可能的设计方式中，预设报错类型包括：空指针报错、请求类型不存在报错、变量找不到报错以及URL不存在报错中的一种或多种。这些报错类型都是由于测试脚本的质量有问题而导致的，因此可用于检测测试脚本运行态的质量。

在第一方面的一种可能的设计方式中，在评估测试脚本的质量之后，还包括：若测试脚本的质量高于预设质量标准，将测试脚本送入自动化测试平台，用于测试被测试系统。如此，可以将综合质量较高的测试脚本，最终用于测试被测试脚本。从而可以得到可靠的测试结果。

第二方面，本申请实施例提供一种计算设备，包括存储器和处理器，存储器和处理器耦合；其中，存储器中存储有计算机程序代码，计算机程序代码包括计算机指令，当计算机指令被处理器执行时，使得计算设备执行上述第一方面及其任一种可能的设计方式中的方法。

第三方面，本申请实施例提供一种计算机可读存储介质，包括计算机指令，当计算机指令在计算设备上运行时，使得计算设备执行上述第一方面及其任一种可能的设计方式中的方法。

第四方面，本申请实施例提供一种芯片系统，芯片系统应用于包括处理器和存储器的计算设备，芯片系统包括一个或多个接口电路和一个或多个处理器，接口电路和处理器通过线路互联，接口电路用于从计算设备的存储器接收信号，并向处理器发送信号，信号包括存储器中存储的计算机指令，当处理器执行计算机指令时，使得计算设备执行上述第一方面及其任一种可能的设计方式中的方法。

第五方面，本申请提供一种计算机程序产品，当所述计算机程序产品在计算机上运行时，使得所述计算机执行如第一方面及其任一种可能的设计方式所述的方法。

可以理解地，上述提供的第二方面所述的计算设备，第三方面所述的计算机存储介质，第四方面所述的芯片系统，第五方面所述的计算机程序产品所能达到的有益效果，可参考第一方面及其任一种可能的设计方式中的有益效果，此处不再赘述。

附图说明

图1为本申请实施例提供的一种脚本质量的检测方法的流程简图；

图2为本申请实施例提供的一种计算设备的硬件结构图；

图3为本申请实施例提供的一种检测独立性的示意图；

图4为本申请实施例提供的一种检测重用性的示意图；

图5为本申请实施例提供的一种检测可读性的示意图；

图6为本申请实施例提供的一种检测健壮性的示意图；

图7为本申请实施例提供的一种检测预设报错类型的示意图；

图8为本申请实施例提供的一种测试脚本的处理流程的示意图；

图9为本申请实施例提供的一种系统结构图；

图10为本申请实施例提供的一种芯片系统的组成结构图。

具体实施方式

下面结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。其中，在本申请实施例的描述中，以下实施例中所使用的术语只是为了描述特定实施例的目的，而并非旨在作为对本申请的限制。如在本申请的说明书和所附权利要求书中所使用的那样，单数表达形式“一种”、“所述”、“上述”、“该”和“这一”旨在也包括例如“一个或多个”这种表达形式，除非其上下文中明确地有相反指示。还应当理解，在本申请以下各实施例中，“至少一个”、“一个或多个”是指一个或两个以上（包含两个）。术语“和/或”，用于描述关联对象的关联关系，表示可以存在三种关系；例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B的情况，其中A、B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。

在本说明书中描述的参考“一个实施例”或“一些实施例”等意味着在本申请的一个或多个实施例中包括结合该实施例描述的特定特征、结构或特点。由此，在本说明书中的不同之处出现的语句“在一个实施例中”、“在一些实施例中”、“在其他一些实施例中”、“在另外一些实施例中”等不是必然都参考相同的实施例，而是意味着“一个或多个但不是所有的实施例”，除非是以其他方式另外特别强调。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。术语“连接”包括直接连接和间接连接，除非另外说明。“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。

在本申请实施例中，“示例性地”或者“例如”等词用于表示作例子、例证或说明。本申请实施例中被描述为“示例性地”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性地”或者“例如”等词旨在以具体方式呈现相关概念。

在说明本申请方案之前，需要先对本申请方案涉及的相关术语做简单说明。

1、测试脚本。

测试脚本是为了对被测试系统的功能进行自动化测试而编写的脚本。

2、测试用例。

测试用例(test case)是为实施测试而向被测试系统提供的预置条件、测试输入、操作步骤（action word，AW）以及预期结果的特定组合。

A．预置条件。

测试用例在执行前需要满足一些前提条件，这些前提条件就是预置条件。通常情况下，预置条件分为两种情况：(1)环境条件。例如：测试word打开文件的功能，预置条件则包括提前准备被打开的文件。(2)测试用例的先后顺序条件。被测试系统的功能可能比较复杂，如果每个测试用例都是从头开始则会导致测试用例写起来非常复杂。那么，可以通过在预置条件中设定测试用例的先后运行顺序，从而使得在后的测试用例只需接着在先的测试用例执行相应的操作即可。

B．测试输入。

测试用例执行过程中可能需要外部数据的支持，这些外部数据即为测试输入。例如，测试输入可以是用户手动输入的数据或者数据库中存储的数据等。在测试用例中写明测试输入，如写明数据的存储路径，以便于测试过程中获取。

C．操作步骤。

测试过程中对被测试系统执行的操作即为操作步骤。例如，对仓储系统执行入库1件商品的操作，则入库1件商品的操作即为操作步骤。

D．预期输出。

在对被测试系统执行测试步骤后，希望被测试系统可以得到的结果即为预期输出。也就是说，预期输出可以检验被测试系统是否可以正常实现操作步骤对应的功能。如果被测试系统实际返回的结果与预期输出相同，则表示被测试系统可以正常实现操作步骤对应的功能。如果被测试系统实际返回的结果与预期输出不相同，则表示被测试系统不可以正常实现操作步骤对应的功能。

示例性的，在仓储系统的库存为4件商品的情况下，对仓储系统执行入库1件商品的操作步骤，则预期输出是库存为5件商品。若仓储系统实际输出的库存为5件商品，则表明仓储系统可以正常实现入库的功能。若仓储系统实际输出的库存为4件商品，则表明仓储系统不能正常实现入库的功能。

应理解，测试脚本的编写需要对应相应的测试用例。例如，测试用例中包括预置条件（如环境条件），则测试脚本中需要包括设置该预置条件的语句。又如，测试用例中包括预期输出，则测试脚本中需要包括检测被测试系统的实际输出是否为预期输出的语句，即断言检测。

在被测试系统上线前，如物流系统、购物系统、仓储系统等系统上线前，通常需要采用测试脚本对被测试系统测试从而发现问题，然后及时补救。以仓储系统为例，则需要采用测试脚本测试仓储系统是否可以在各种入库、出库的操作下，准确的更新库存量。从而可以发现仓储系统是否可以实现正常的功能。即，发现仓储系统是否存在问题。

与此同时，测试脚本的质量高低，往往直接决定了测试结果的准确与否。然而，常规技术中并未给出一种可以准确的检测测试脚本质量的方案，导致使用测试脚本测试得到的测试结果的可信度不高，无法准确的发现被测试系统中的问题。

基于此，本申请实施例提供了一种脚本质量的检测方法，可以应用于需要对被测试系统的功能进行测试的场景中，在测试前，检测测试脚本的质量，并将质量较高的测试脚本用于系统测试，得到准确的测试结果。

参见图1，可以在基于测试用例编写得到测试脚本后，检测测试脚本的内容，得到测试脚本的静态得分（如图1中101所示静态检测过程）。并且，将测试脚本提交入库并批量执行（如图1中102所示批量执行过程），检测测试脚本的运行结果，得到测试脚本的运行得分（如图1中103所示运行检测过程）。最后，可以从静态和运行态两个维度来评估测试脚本的质量，得到测试脚本的质量得分（如图1中104所示综合评估过程）。如此，可以得到测试脚本更准确的质量评估结果，据此后续则可以准确筛选出质量高的测试脚本用于对被测试系统测试，从而提高测试结果的准确性。

本申请实施例还提供了一种计算设备，该计算设备可用于执行上述脚本质量的检测方法。示例性的，上述计算设备可以是云端、服务器、手机、平板电脑等具有较强的运算能力的设备。其中，服务器可以是一台服务器，或者可以是一个服务器集群，也可以是多个服务器集群，或者可以包括一类或多类服务器。

示例性的，参见图2，以计算设备是服务器为例，计算设备200可以包括：处理器210和内部存储器220。

处理器210可以包括一个或多个处理单元，例如：处理器210可以包括应用处理器（application processor，AP），调制解调处理器，图形处理器（graphics processingunit，GPU），图像信号处理器（image signal processor，ISP），控制器，存储器，视频编解码器，数字信号处理器（digital signal processor，DSP），基带处理器，和/或神经网络处理器（neural-network processing unit，NPU）等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。

内部存储器220可以用于存储计算机可执行程序代码，可执行程序代码包括指令。处理器210通过运行存储在内部存储器220的指令，从而执行服务器的各种功能以及数据处理。例如，处理器210可以通过执行存储在内部存储器220中的指令，完成脚本质量检测的操作。

内部存储器220可以包括存储程序区和存储数据区。其中，存储程序区可存储操作系统，至少一个功能所需的应用程序（比如声音播放功能，图像播放功能等）等。存储数据区可存储服务器使用过程中所创建的数据（比如对脚本的质量检测的得分）等。此外，内部存储器220可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件，闪存器件，通用闪存存储器（universal flash storage，UFS）等。

本申请实施例提供的脚本质量的检测方法，可以在具有上述硬件结构的计算设备（如服务器）200中实现。

下文将以计算设备是服务器为例来说明本申请方案。

本申请实施例中，服务器一方面可以检测测试脚本的内容，另一方面还可以检测测试脚本的运行结果。下面将分别说明上述两方面的具体实现。

第一方面，检测测试脚本的内容，即静态检测。

在一些实施例中，在静态检测的过程中，服务器可以检测测试脚本的独立性。针对任一测试脚本，其独立性是指该测试脚本与其它测试脚本之间的依赖程度。该测试脚本与其它测试脚本之间的依赖性越强，则表明该测试脚本受其它测试脚本的干扰越大和/或该测试脚本对其它测试脚本的干扰越大，该测试脚本的独立性越弱；反之，该测试脚本与其它测试脚本之间的依赖性越弱，则表明该测试脚本受其它测试脚本的干扰越小和/或该测试脚本对其它测试脚本的干扰越小，该测试脚本的独立性越强。

参见图3，在一种具体的实现方式中，独立性检测包括检测测试脚本中是否有环境条件（如图3中S301所示）。

测试用例的预置条件中包括环境条件。测试脚本基于测试用例编写，则测试脚本中自然包括设置该环境条件的语句。也就是说，测试脚本中应该包括环境条件。

基于此，服务器可以检测测试脚本中用于预置环境条件的字段中是否有内容。若用于预置环境条件的字段中有内容，则确定测试脚本中有环境条件；若用于预置环境条件的字段中没有内容，则确定测试脚本中没有环境条件。其中，用于预置环境条件的字段可以为Setup字段或者BeforeMethod字段。

若测试脚本中有环境条件，则表明该测试脚本是一个完整的脚本，采用该测试脚本，可以首先设置得到所需的初始化环境，而无需依赖于其它测试脚本，独立性较强。反之，若测试脚本中没有环境条件，则表明该测试脚本不是一个完整的脚本，采用该测试脚本无法首先设置得到所需的初始化环境，而可能需要依赖于其它测试脚本设置的环境，独立性较弱。

继续参见图3，在一种具体的实现方式中，独立性检测包括检测测试脚本中是否有至少一个操作步骤（如图3中S302所示）。

测试用例中包括对被测试系统执行的操作步骤。测试脚本基于测试用例编写，则测试脚本中自然包括操作步骤。例如，测试用例中包括入库1件商品的操作步骤，则测试脚本中包括入库1件商品的语句。

基于此，服务器可以检测测试脚本中用于指示操作步骤的字段中是否有内容。若用于指示操作步骤的字段中有内容，则确定测试脚本中有至少一个操作步骤；若用于指示操作步骤的字段中没有内容，则确定测试脚本中没有操作步骤。其中，用于指示操作步骤的字段中可以为TestStep字段。

若测试脚本中有至少一个操作步骤，则表明该测试脚本是一个完整的脚本，采用该测试脚本可以对被测试系统执行至少一个操作步骤，从而测试被测试系统的某种功能是否正常，独立性较强。反之，若测试脚本中没有操作步骤，则表明该测试脚本不是一个完整的脚本，采用该测试脚本无法对被测试系统执行操作步骤，独立性较弱。

继续参见图3，在一种具体的实现方式中，独立性检测包括检测测试脚本中在修改（即update）数据后，是否有恢复数据的语句（如图3中S303所示）。为了便于说明，可以将该修改和恢复的数据记为第一数据。

仍以被测试系统是仓储系统为例，仓储系统默认的入库模式为异步入库，如每隔24小时更新一次库存、而不是实时更新。而在测试过程中，为了可以及时得到库存的更新结果，则需要将入库模式修改为同步入库。即，执行入库操作后可立即更新库存。若在修改入库模式后，没有恢复成默认的入库模式，则会造成仓储系统的数据遭到破坏。反之，若在修改入库模式后，又恢复成默认的入库模式，则仓储系统的数据依然会保持原样。

基于此，服务器可以在检测到测试脚本中修改数据的语句后，进一步检测修改数据的语句后是否有恢复数据的语句。在一种具体的实现方式中，服务器可以检测修改数据的语句后用于指示后处理的字段（如teardown字段）中是否有恢复数据的语句。若后处理的字段中有恢复数据的语句，则确定有恢复数据的语句；若后处理的字段中包括恢复数据的语句，则确定没有恢复数据的语句。在测试脚本中，后处理是指操作步骤结束后的语句，用于在执行操作步骤后完成数据恢复、执行结果检测（如断言检测）等处理。

进一步的，有些测试脚本中可能包括多处修改数据的语句，相应的，测试脚本中则应该有多处恢复数据的语句。因此，服务器还需要检测测试脚本中修改数据的语句的数量和恢复数据的语句的数量是否相同。若两者相同，才能确定有恢复数据的语句；若两者不相同，则确定没有恢复数据的语句。

若测试脚本中修改数据的语句后，进一步有恢复数据的语句，则表明该测试脚本未对被测试系统造成破坏，不会干扰其它测试脚本的执行，独立性较强。反之，若测试脚本中修改数据的语句后，没有恢复数据的语句，则表明该测试脚本会对被测试系统造成破坏，可能会干扰其它测试脚本的执行，独立性较弱。

继续参见图3，在一种具体的实现方式中，独立性检测包括检测测试脚本中在插入（即insert）数据前，是否有删除数据的语句（如图3中S304所示）。为了便于说明，可以将该插入和删除的数据记为第二数据。

在测试过程中，若出现相同的两份数据，则会导致测试无法正常进行。例如，数据库中包括两张相同的表1，那么就可能在调用表1时出现混乱，导致测试无法正常运行。因此，测试脚本中在插入数据的语句前，需要进一步包括删除数据的语句。例如，在插入表1前，需要删除掉已经存在的表1。这样，可以保证不会出现相同的两份数据。那么，测试脚本无论是在已经有历史数据的环境中，还是在没有历史数据的环境中都可以成功运行。

基于此，服务器在检测到测试脚本中插入数据的语句后，可以进一步检测插入数据的语句前是否有删除该插入的数据的语句。示例性的，服务器在检测到insert语句后，可以在insert语句之前查找delete语句。若查找到delete语句、且delete语句中指定的删除对象与insert语句中指定的插入对象相同，则确定测试脚本中在插入数据前，有删除数据的语句。若未查找到delete语句，或者查找到delete语句、但delete语句中指定的删除对象与insert语句中指定的插入对象不同，则确定测试脚本中在插入数据前，没有删除数据的语句。

若测试脚本中在插入数据前，有删除数据的语句，则表明该测试脚本在已经有历史数据的环境中或者在没有历史数据的环境中都可以运行，不会因为数据重复而导致无法正常运行，独立性较强。反之，若测试脚本中在插入数据前，没有删除数据的语句，则表明若在已经有历史数据的环境中运行该测试脚本，则极有可能因插入数据造成数据重复，从而进一步导致运行失败，独立性较弱。

继续参见图3，在一种具体的实现方式中，独立性检测包括检测测试脚本中插入（即insert）数据的语句中，是否带有字段名（如图3中S305所示）。

应理解，在自动化测试的场景中，插入通常是指插入表格。在插入语句中，通常会携带表名，以指定需要插入的表格。在一些场景中，被测试系统中的表格是可能发生更新的。针对这种场景，若仅在插入数据的语句中携带表名，而不指定表中的具体字段，则可能导致指示的插入对象不明确，从而影响测试。

示例性的，在t1时刻，被测试系统中表格1仅有商品名称和价格两个字段及其对应的字段值，若插入数据的语句写成下述格式：insert “表格1”（商品名称，价格） values（值1，值3），则可以将表格1中商品名称字段的值对应值1，以及价格字段的值对应值2。t2时刻，表格1中新增了库存字段及其字段值，若插入数据的语句还是写成下述格式：insert “表格1”（商品名称，价格） values（值1，值2），则依然可以将表格1中商品名称字段的值对应值1，以及价格字段的值对应值2。

然而，若插入数据的语句写成下述格式：insert “表格1” values（值1，值2），则在t2时刻后，则不清楚插入的值1和值2分别是商品名称、价格以及库存共三个字段中哪个字段的字段值。

因此，插入数据的语句中不仅需要携带表明，还需要携带字段名。这样，无论表格是否更新，如增加字段或者删减字段，都可以明确插入对象。那么，测试脚本无论在表格未更新的场景下运行，还是在表格已更新的场景下运行，都可以明确需要插入的内容。

基于此，服务器在检测到测试脚本中包括插入数据的语句后，可以进一步检测插入数据的语句中是否携带有字段名。若插入数据的语句中携带有字段名，则表明该测试脚本无论在表格未更新的场景下运行，还是在表格已更新的场景下运行，都可以明确插入对象，而不依赖于表格是否已被其它测试脚本更改，独立性较强。反之，若插入数据的语句中未携带字段名，则表明该测试脚本可能仅在表格未发生更新的场景下，才能明确插入对象，独立性较弱。

继续参见图3，在一种具体的实现方式中，独立性检测包括检测测试脚本中，常量的占比是否低于第一阈值（如图3中S306所示）。

通常情况下，一旦某个常量发生变化，则需要对所有测试脚本中出现的该常量进行修改，使所有测试脚本中该常量都更新为最新值。例如，常量“111111”更新为“222222”，则需要将所有测试脚本中出现的“111111”替换为“222222”，该修改过程耗时耗力，而且容易出错。为了避免这种问题，在测试脚本中，通常可以变量来代替常量，仅需通过改变变量的赋值即可实现对测试脚本中多次出现的该变量的更新。也就是说，常量越多，则更新越繁琐；常量越少，则修改越简单。

基于此，服务器可以检测测试脚本中常量的占比是否低于第一阈值。常量的占比是指常量的数量与常量和变量的数量之和的比值。若常量的占比低于第一阈值，如5%，则表明测试脚本中仅将少量的参数以常量的形式表示，修改较为简单，独立性较强。若常量的占比高于或等于第一阈值，则表明测试脚本中较多的参数都以常量的形式表示，修改较为繁琐，独立性较弱。

前述分别以各种独立性的检测项，说明了检测测试脚本的独立性的具体实现。实际实施时，可以采用上述一种或多种独立性的检测项来检测测试脚本的独立性。若采用多种独立性的检测项来检测测试脚本的独立性，服务器可以按照一定的顺序串行检测，或者也可以并行检测。例如，服务器可以按照图3中S301-S306的顺序串行执行，也可以并行执行S301-S306。本申请实施例对此不作具体限定。

在服务器中，可以预先为各个独立性的检测项分配相应的分值，然后服务器可以基于各个独立性的检测项的检测结果及其分值，来得到测试脚本的独立性得分。示例性的，共有图3所示的6个独立性的检测项，则可以为每个独立性的检测项分配20分，在每一个独立性的检测项检测得到表示独立性强的结果后，则将独立性得分加20。例如，图3中S301-S305的检测结果都是“是”，而S306的检测结果为“否”，则独立性得分为20*5=100分。

进一步的，为了提高计算得到的独立性得分的合理性，在为各个独立性的检测项分配相应的分值时，可以基于各个独立性的检测项的重要程度来分配分值。例如，图3所示S301-S304的重要程度较高，而S305-S306的重要程度较低，则可以为S301-S304对应的四个独立性的检测项分别分配20分，而为S305-S306对应的两个独立性的检测项分别分配10分。

在另一些实施例中，在静态检测的过程中，服务器可以检测测试脚本的重用性。针对任一测试脚本，其重用性是指该测试脚本的适配能力。该测试脚本适配于各种执行机和/或该测试脚本中的操作步骤适配于各个测试脚本的能力越强，其重用性越强。反之，该测试脚本适配于各种执行机和/或该测试脚本中的操作步骤适配于各个测试脚本的能力越弱，其重用性越弱。

参见图4，在一种具体的实现方式中，重用性检测包括检测测试脚本中的路径是否使用相对路径（如图4中S401所示）。

测试脚本从编写完成到最后进入自动化工厂用于对被测试系统测试的过程中，需要在不同的执行机中执行。例如，在编写完成后，首先需要在本地机器上执行。在进入自动化工厂后，需要在自动化测试平台中执行。与此同时，在测试脚本中，可能存在涉及路径的语句，例如，从指定路径中获取文件并上传的语句。实际中，不同执行机中用于执行测试脚本的路径不同，相应的，存储测试过程中需要使用的文件的路径也存在差异。那么，若采用绝对路径，则当在不同执行机中运行同一测试脚本时，需要将语句中的路径修改为当前执行机中对应的绝对路径。

示例性的，测试脚本中存在从指定路径下获取表格1的语句。在本地机器中，表格1存储在C：\Users\test下。在自动化测试平台中，表格1存储在D：\Document\test。那么，若采用绝对路径的方式，则在本地机器中执行该测试脚本之前，需要将测试脚本中的指定路径修改为“C：\Users\test”。在自动化平台中执行该测试脚本之前，需要将测试脚本中的指定路径修改为“D：\Document \test”。

进一步的，若同一测试脚本中存在多个指定路径，或者大量测试脚本中都存在指定路径，则会极大的增加修改绝对路径的工作量。因此，在编写测试脚本时，可以将测试脚本中涉及的路径以相对路径的形式表示。例如，前述示例中的 “C：\Users\test”和“D：\Document \test”都可以表示为“…\test”。当前在本地机器中执行测试脚本时，相对路径“…\test”的具体含义为本地机器中用于执行测试脚本的路径（即C：\Users）下的test文件。当前在自动化测试平台中执行测试脚本时，相对路径“…\test”的具体含义为自动化测试平台中用于执行测试脚本的路径（即D：\Document）下的test文件中。这样，在不同的执行机中执行测试脚本，即使不同执行机中存储相同文件的路径不同，也无需修改路径。从而使测试脚本可以灵活适用于各种执行机。

基于此，服务器可以检测测试脚本中用于指示路径的字段，如“path”字段的字段值是否为相对路径。示例性的，服务器可以检测用于指示路径的字段的字段值中是否包括第一预设字符，如“…”、“***”、“&&&”等字符。若用于指示路径的字段的字段值中包括第一预设字符，则确定测试脚本中的路径是相对路径。若用于指示路径的字段的字段值中不包括第一预设字符，则确定测试脚本中的路径不是相对路径。

若测试脚本中的路径是相对路径，则表明测试脚本在各种执行机中执行时，无需修改测试脚本中的路径，其都可以准确的指向相应的路径，从而可以灵活适配于各种执行机，重用性较强。若测试脚本中的路径不是相对路径，则表明测试脚本在各种执行机中执行时，需要相应的修改测试脚本中的路径，其才能准确的指向相应的路径，无法灵活适配于各种执行机，重用性较弱。

继续参见图4，在一种具体的实现方式中，重用性检测包括在测试脚本中操作步骤的数量超过第二阈值的情况下，检测测试脚本中是否包括已封装的操作步骤（如图4中S402所示）。

用于测试一个被测试系统的多个测试脚本中，可能有大量重复的操作步骤。

仍以被测试系统是仓储系统为例，用于测试该仓储系统的多个测试脚本中，可能都包括发货、签收以及扫描的操作步骤。因此，为了便于多个测试脚本中复用这些重复的操作步骤，可以将这些重复的操作步骤进行封装。后续，当有其它测试脚本需要使用这些重复的操作步骤时，仅需调用封装好的操作步骤即可。这样，可以在多个测试脚本中灵活复用相同的操作步骤，无需在多个测试脚本中，重复编写相同的操作步骤。

基于此，在测试脚本中操作步骤的数量超过第二阈值的情况下，如第二阈值为5、8、10等数量，服务器可以检测该测试脚本中是否包装已封装的操作步骤。若测试脚本中包装已封装的操作步骤，表明测试脚本的编写已经考虑到了复用操作步骤的问题，封装好的操作步骤可以复用到各个测试脚本中，重用性较强。若测试脚本中不包装已封装的操作步骤，表明测试脚本的编写极有可能未考虑到复用操作步骤的问题，只能通过重复编写相同的操作步骤来实现同样的功能，重用性较弱。

以第二阈值是5为例，若测试脚本中包括的操作步骤有8个，超过5个，但是却没有一个个操作步骤是已经封装好的。也就是说，8个操作步骤全是重新编写的，没有1个是复用的，则极有可能在编写测试脚本时，未考虑到复用操作步骤的问题。

继续参见图4，在一种具体的实现方式中，重用性检测包括检测测试脚本中的环境地址是否为可配置的（如图4中S403所示）。

各个操作步骤具有对应的执行环境。并且不同的操作步骤，其执行环境可能不同。相应的，在测试用例中会为各个操作步骤添加环境地址（如http-url），以指示执行操作步骤的环境。相应的，测试脚本中也会有各个操作步骤的环境地址。

示例性的，操作步骤1的http-url为url1，url1指向集成测试环境，即表示操作步骤1在集成测试环境中执行。以及， 操作步骤2的http-url为url2，url1指向验收测试环境，即表示操作步骤2在验收测试环境中执行。

与此同时，测试脚本从编写完成到最后进入自动化工厂用于对被测试系统测试的过程中，同一操作步骤的执行环境也可能需要发生变化。也就是说，各个操作步骤的环境地址可能发生变化。为了可以获得相应的执行环境，则需要修改各个操作步骤的环境地址。

然而，一一修改各个操作步骤的环境地址显然是耗时耗力的，并且有可能遗漏修改。因此，在为各个操作步骤添加环境地址时，可以环境变量的形式表示。那么，当操作步骤的执行环境发生改变后，仅需重新配置环境变量的值即可。

示例性的，测试脚本中包括如下表1所示的5个操作步骤及其对应的环境变量。

表1

上表1表示，操作步骤1和操作步骤2的执行环境为url11指向的环境，操作步骤3、操作步骤4以及操作步骤5的执行环境为url21指向的环境。在表1的基础上，若操作步骤3、操作步骤4以及操作步骤5的执行环境发生了改变，则可以仅更新环境变量URL2的取值即可。例如，由url21指向的环境变化为url22指向的环境，则可以更新得到如下表2所示的5个操作步骤及其对应的环境变量。

表2

也就是说，采用环境变量的形式，则无论各个操作步骤的执行环境如何变化，操作步骤1和操作步骤2的环境地址都可以写成URL1，操作步骤3、操作步骤4以及操作步骤5的环境地址都可以写成URL2。而无需随着执行环境的变化随之修改。从而可以使各个操作步骤的环境地址适用于各个执行环境。

基于此，服务器可以检测测试脚本中各个操作步骤的环境地址是否为可配置的，即检测环境地址是否以环境变量的形式表示。示例性的，服务器可以从测试脚本中查找用于指示环境地址的字段（如http-url字段），并检测用于指示环境地址的字段的字段值是否包括环境变量。例如，在用于指示环境地址的字段的字段值中查找测试脚本中定义的变量。若查找到，则确定包括环境变量。从而可确定环境地址是可配置的。若未查找到，则确定不包括环境变量。从而可确定环境地址不是可配置的。

若确定环境地址是可配置的，则表示环境地址可以适配于各种执行环境，重用性较强。若确定环境地址不是可配置的，则表示环境地址无法灵活适配于各种执行环境，重用性较弱。

前述分别以各种重用性的检测项，说明了检测测试脚本的重用性的具体实现。实际实施时，可以采用上述一种或多种重用性的检测项来检测测试脚本的重用性。若采用多种重用性的检测项来检测测试脚本的重用性，服务器可以按照一定的顺序串行检测，或者也可以并行检测。例如，服务器可以按照图4中S401-S403的顺序串行执行，也可以并行执行S401-S403。本申请实施例对此不作具体限定。

与独立性的检测类似的：在服务器中，可以预先为各个重用性的检测项分配相应的分值，然后服务器可以基于各个重用性的检测项的检测结果及其分值，来得到测试脚本的重用性得分。进一步的，为了提高计算得到的重用性得分的合理性，在为各个重用性的检测项分配相应的分值时，可以基于各个重用性的检测项的重要程度来分配分值。

在另一些实施例中，在静态检测的过程中，服务器可以检测测试脚本的可读性。针对任一测试脚本，其可读性是指该测试脚本在逻辑层次以及隐私安全等表达层面上的水平。该测试脚本的逻辑层次越清晰、隐私安全越高，其可读性越强；反之，该测试脚本的逻辑层次越乱、隐私安全越低，其可读性越弱。

参见图5，在一种具体的实现方式中，可读性检测包括检测测试脚本中是否有注释文本（如图5中S501所示）。

通常情况下，测试脚本中的注释文本可以指示语句的含义，提示测试脚本的功能，以及提示下一个需要运行的测试用例等。简言之，注释文本可以极大提升测试脚本的可读性。

基于此，服务器可以检测测试脚本中是否包括注释文本。示例性的，服务器可以检测测试脚本中是否包括用于指示注释文本的第二预设字符，例如，常见的第二预设字符为“\\”。若检测到测试脚本中包括第二预设字符，则可以确定测试脚本中包括注释文本，该测试脚本的可读性较强。若检测到测试脚本中不包括第二预设字符，则可以确定测试脚本中不包括注释文本，该测试脚本的可读性较弱。

继续参见图5，在一种具体的实现方式中，可读性检测包括检测测试脚本中的操作步骤是否有分组（如图5中S502所示）。

测试脚本中包括多个操作步骤，若多个操作步骤仅仅是顺序排布，则用户（如测试人员）可能难以发现多个操作步骤之间的逻辑关系。因此，为了提升测试脚本的表达逻辑，可以将多个操作步骤按照功能分组。例如，测试脚本中包括5个操作步骤，其中操作步骤1和操作步骤2用于门店检测，操作步骤3、操作步骤4以及操作步骤5用于入库，则在测试脚本中，操作步骤可以写成如下格式：

Group（“门店检测”）{ 操作步骤1、操作步骤2}；

Group（“入库”）{ 操作步骤3、操作步骤4、操作步骤5}。

即，操作步骤1和操作步骤2都属于门店检测组，操作步骤3、操作步骤4以及操作步骤5都属于入库组。这样，可以明确多个操作步骤之间的关联。

基于此，服务器可以检测测试脚本中的操作步骤是否有分组。示例性的，服务器可以检测测试脚本中是否存在用于指示分组的字段，如Group字段、Packet字段。若检测到存在用于指示分组的字段，则确定测试脚本中的操作步骤有分组。若检测到不存在用于指示分组的字段，则确定测试脚本中的操作步骤没有分组。

若测试脚本中的操作步骤有分组，则表明测试脚本的表达很有逻辑，可读性较强。若测试脚本中的操作步骤没有分组，则表明测试脚本的表达缺乏逻辑，可读性较弱。

继续参见图5，在一种具体的实现方式中，可读性检测包括检测测试脚本中的密码是否加密（如图5中S503所示）。

若测试脚本中的密码为明文，则很有可能导致密码泄露。因此，即使是出现在测试脚本中的密码，也可以通过对其加密，从而提高密码的安全性。

基于此，服务器可以检测测试脚本中的密码是否加密。在一种具体的实现方式中，服务器可以先检测测试脚本中是否包括用于指示密码的字段（也可以称为第一字段），如检测“password”、“passwd”、“pwd”等字段。若检测到包括用于指示密码的字段，服务器可以进一步获取用于指示密码的字段的字段值（即密码），判断密码的长度是否超过预设长度。若检测到密码的长度超过预设长度，则可以确定密码为密文。从而确定测试脚本中的密码已加密。若检测到密码的长度未超过预设长度，则可以确定密码为明文。从而确定测试脚本中的密码未加密。

示例性的，明文密码的常见长度小于或等于12个字符，则可以设置预设长度为12个字符。若测试脚本中的密码为“12345678”，其长度为8个字符，未超过12个字符，则可以确定测试脚本中的密码未加密。若测试脚本中的密码为“m6k2wd1w4ck4ykb7j322w6n5i3n5r3y9t4m8n8x9z4”，其长度为42个字符，超过12个字符，则可以确定测试脚本中的密码已加密。

若检测到测试脚本中的密码已加密，则确定测试脚本的隐私安全较高，可读性越强。若检测到测试脚本中的密码未加密，则确定测试脚本的隐私安全较低，可读性越弱。

前述分别以各种可读性的检测项，说明了检测测试脚本的可读性的具体实现。实际实施时，可以采用上述一种或多种可读性的检测项来检测测试脚本的可读性。若采用多种可读性的检测项来检测测试脚本的可读性，服务器可以按照一定的顺序串行检测，或者也可以并行检测。例如，服务器可以按照图5中S501-S503的顺序串行执行，也可以并行执行S501-S503。本申请实施例对此不作具体限定。

与独立性的检测类似的：在服务器中，可以预先为各个可读性的检测项分配相应的分值，然后服务器可以基于各个可读性的检测项的检测结果及其分值，来得到测试脚本的可读性得分。进一步的，为了提高计算得到的可读性得分的合理性，在为各个可读性的检测项分配相应的分值时，可以基于各个可读性的检测项的重要程度来分配分值。

在另一些实施例中，在静态检测的过程中，服务器可以检测测试脚本的健壮性。针对任一测试脚本，其健壮性是指该测试脚本是否可以快速且有效的测试被测试系统的能力。该测试脚本可以快速且有效的测试被测试系统，则其健壮性较强。反之，该测试脚本不能快速且有效的测试被测试系统的能力，则其健壮性较弱。

参见图6，在一种具体的实现方式中，健壮性检测包括检测测试脚本中是否包括延时语句（如图6中S601所示）。

在被测试系统中，有些任务可能会定时执行。仍以被测试系统是仓储系统为例，随时随地都可能有大量的用户在进行入库、出库等操作，若实时更新库存，则可能造成数据更新压力大。因此，可以设定每5分钟更新一次库存。

与此同时，由于任务需要定时执行，那么在执行测试脚本中某个操作步骤后，可能需要等待一定时长后才能获取到对被测试系统执行该操作步骤后，被测试系统实际返回的结果。该实际返回的结果可用于检测被测试系统是否可以返回预期输出。示例性的，仓储系统每5分钟更新一次库存，若操作步骤为入库1件商品的操作，那么在执行该操作步骤后，可能无法及时获取到最新的库存结果。例如，30秒前刚刚更新过一次库存，则可能需要等待4分30秒才能获取到下一次更新库存后的结果，那么可以在测试脚本中设置延时5分钟后获取一次执行结果。从而保证在下一次更新库存后一定可以获取到最新的库存，即实际返回的结果。

上述通过设置延时来获取执行结果的方式，可以保证获取到执行结果。但是，随着测试脚本的数量增多，则需要大量的延时，这样会影响测试脚本的执行效率。例如，每个测试脚本需要延时5分钟，则100个测试脚本需要延时500分钟，那么所有的测试脚本串行执行一遍，延时就需要耗费500分钟。

为了解决延时的方式带来的执行效率低的问题，可以在测试脚本中设置每隔第一预设时长（如5秒、10秒、30秒等）查询一次，直至查询到更新的结果则退出查询。

示例性的，仓储系统中当前记录的库存为4件商品，在执行完测试脚本中入库1件商品的操作步骤后，可以每隔10秒钟查询一次。那么，在仓储系统的库存更新功能正常的情况下，若上一次更新库存为3分钟前，则在循环查询（5-3）*60/10=12次后可以查询到更新后的库存，即库存为5件商品，而无需等待5分钟。同理，若上一次更新库存为4分钟30秒前，则在循环查询（5-4.5）*60/10=3次后可以查询到更新后的库存，即库存为5件商品，也无需等待5分钟。

由此可见，通过循环查询的方式，而非延时的方式，可以提高测试脚本的执行效率。

基于此，服务器可以检测测试脚本中是否包括延时语句。示例性的，服务器可以检测测试脚本中是否包括用于指示延时的字段，如delay字段。若测试脚本中包括用于指示延时的字段，则确定测试脚本中包括延时语句。若测试脚本中不包括用于指示延时的字段，则确定测试脚本中不包括延时语句。

若测试脚本中包括延时语句，则表明延时语句可能会影响执行效率，不能快速对被测试系统进行测试，健壮性较弱。若测试脚本中不包括延时语句，则表明不会因为延时语句影响测试效率，可以快速对被测试系统测试，健壮性较强。

在一些场景中，虽然用到了延时语句，但是延时语句中的延时时长较短，例如延时时长为5秒、10秒等，对执行效率的影响不大。

进一步的，服务器在检测到测试脚本中包括延时语句后，可以继续检测延时时长是否超过第二预设时长，例如，10秒、30秒等。若延时时长超过第二预设时长，则表明过长的延时时长会影响测试效率，健壮性较弱。若延时时长未超过第二预设时长，则表明较短的延时时长并不会影响测试效率，健壮性较强。

继续参见图6，在一种具体的实现方式中，健壮性检测包括检测测试脚本中是否有断言检测（如图6中S602所示）。

测试脚本中不仅需要包括操作步骤，用于操作被测试系统，还需要包括断言检测，用于检测对被测试系统执行操作步骤后是否可以获得预期输出。也就是说，测试脚本中没有断言检测，则无法检测被测试系统的功能正常与否。

仍以被测试系统是仓储系统为例，仓储系统中当前记录的库存为4件商品，在执行完测试脚本中入库1件商品的操作步骤后，若没有断言检测来校验库存是否更新为5件商品，则无法确定仓储系统的入库功能是否正常。

基于此，服务器可以检测测试脚本中是否包括断言检测。示例性的，服务器可以检测测试脚本中是否存在用于指示断言检测的字段，如assertTrue字段。若测试脚本中存在用于指示断言检测的字段，则可以确定测试脚本中包括断言检测。若测试脚本中不存在用于指示断言检测的字段，则可以确定测试脚本中不包括断言检测。

若测试脚本中包括断言检测，则测试脚本可以在对被测试系统执行相应的操作步骤后检测是否可以获得预期输出，从而有效检测被测试系统的功能正常与否，健壮性较强。若测试脚本中不包括断言检测，则测试脚本无法在对被测试系统执行相应的操作步骤后检测是否可以获得预期输出，无法有效检测被测试系统的功能正常与否，健壮性较弱。

继续参见图6，在一种具体的实现方式中，健壮性检测包括检测测试脚本中是否只检查返回码（如resultcode），而未检查实际返回的结果是否正确（如图6中S603所示）。

其中，返回码也可以称为http状态码或者协议状态码。返回码是客户端向服务端发送请求的时候，描述返回的请求结果的参数。示例性的，常见的返回码包括但不限于：200，表示服务端成功返回网页；404，表示请求的网页不存在；503，表示服务不可用。

在测试脚本的断言检测中，可以检测返回码，从而确定被测试系统是否可以正常响应。然而，即使通过检测返回码，确定被测试系统可以正常响应，并不代表被测试系统可以得到正确的结果，例如更新得到正确的库存。

基于此，服务器可以检测测试脚本中是否仅检查返回码。例如，仅检查resultcode是否为200。若仅检查返回码，则表明并不能准确的检测被测试系统是否得到了正确的结果，健壮性较弱。若不仅检查了返回码，还检查了被测试系统是否得到了正确的结果，例如检查了库存是否更新为5，健壮性较强。

继续参见图6，在一种具体的实现方式中，健壮性检测包括检测测试脚本中是否只检查数据存在与否，而未检查实际返回的结果是否正确（如图6中S604所示）。

在基于测试脚本中的操作步骤对被测试系统执行操作步骤后，被测试系统中的数据则可能发生变化，例如，在执行入库操作后，则库存会发生更新。为了检测被测试系统在被执行操作步骤后实际返回的结果是否正确，通常需要从被测试系统中查询最新的数据，并判断查询到的实际返回的结果是否为预期结果。从而实现检测被测试系统是否可以得到正确的结果。

若在测试脚本中，仅检查查询到的结果中数据存在与否，如检查查询到的数据是否大于0，则很显然无法准确检测被测试系统是否可以得到正确的结果。

基于此，服务器可以检测测试脚本中是否仅检查数据存在与否。例如，仅检查查询到的库存是否大于0。若仅检查数据存在与否，则表明并不能准确的检测被测试系统得到了正确的结果，健壮性较弱。若不仅检查了数据存在与否，还检查了被测试系统是否得到了正确的结果，例如检查了库存是否更新为5，健壮性较强。

至此，需要说明的是，在实际实施，可以将前述S603和S604结合为一个步骤，即：检测测试脚本是否包括检查实际返回的结果是否正确（即是否为预期输出）的语句。若包括检查实际返回的结果是否正确的语句，则表明测试脚本的健壮性较强。若不包括检查实际返回的结果是否正确的语句，则表明测试脚本的健壮性较弱。

前述分别以各种健壮性的检测项，说明了检测测试脚本的健壮性的具体实现。实际实施时，可以采用上述一种或多种健壮性的检测项来检测测试脚本的健壮性。若采用多种健壮性的检测项来检测测试脚本的健壮性，服务器可以按照一定的顺序串行检测，或者也可以并行检测。例如，服务器可以按照图6中S601-S604的顺序串行执行，也可以并行执行S601-S604。本申请实施例对此不作具体限定。

与独立性的检测类似的：在服务器中，可以预先为各个健壮性的检测项分配相应的分值，然后服务器可以基于各个健壮性的检测项的检测结果及其分值，来得到测试脚本的健壮性得分。进一步的，为了提高计算得到的健壮性得分的合理性，在为各个健壮性的检测项分配相应的分值时，可以基于各个健壮性的检测项的重要程度来分配分值。

经过前述第一方面中各个实施例，可以完成对测试脚本的静态检测。

第二方面，检测测试脚本的运行结果，即运行检测。

本申请实施例中，服务器在完成上述静态检测之后，还可以进一步基于测试脚本的运行结果来完成对测试脚本的运行检测。通常情况下，当在本地完成测试脚本的编写与调测之后，会将大量测试脚本入库，如存入代码库GitLab中。此后，会多次批量执行测试脚本。应理解，批量执行测试脚本，可以过滤出一些执行失败的测试脚本，后续则可以依据测试脚本执行成功与否的结果筛选出送入自动化工厂的测试脚本，并真正用于对被测试系统进行测试。

示例性的，共有1000个测试脚本用于测试仓储系统的入库功能，则在将该1000个测试脚本入库后，可以每天批量执行一次该1000个测试脚本。每一次批量执行后，可以得到1000个测试脚本的运行结果，如1000个测试脚本中有70个测试脚本执行失败。在多次批量执行后，发现有30个测试脚本多次执行失败，则可以将除该30个测试脚本之外的测试脚本送入自动化工厂中，用于测试仓储系统的入库功能。

本申请实施例中，检测测试脚本的运行结果，即：对进入自动化工厂前的多次批量执行的结果进行检测评估。

在一些实施例中，在运行检测的过程中，针对任一测试脚本，服务器可以分析该测试脚本的运行日志（也可以称为自动化框架日志）中报错API的返回消息，并基于分析结果确定测试脚本的运行得分。

示例性的，报错API的返回消息中可以包括：测试脚本的整体报错信息以及测试脚本中对应测试用例的各个组成部分的具体报错信息。

其中，整体报错信息可以反映出运行测试脚本后是否可以得到预期输出。例如，运行测试脚本并未得到预期输出，则测试脚本的整体报错信息中可能有如下关键字“expect（A） but found （B）”，表示预期输出为A，但是实际得到的结果为B。

以及，测试用例的主要构成包括预置条件（Setup）、操作步骤（AW）以及后处理（TearDown）。与之对应的，具体报错信息包括对应预置条件的报错信息，对应操作步骤的报错信息以及对应后处理的报错信息。其中，预置脚本的报错信息包括测试脚本中预置条件的语句不规范导致的各种报错；操作步骤的报错信息包括测试脚本中操作步骤的语句不规范导致的各种报错；以及，后处理的报错信息包括测试脚本中后处理的语句不规范导致的各种报错。

测试脚本运行失败的原因有多种，一部分是由于测试脚本的质量不好导致的，另一部分是由于其他原因，如执行机有问题或者被测试系统有问题导致的。基于此，在本实施例，服务器可以从报错API的返回消息中检测预设报错类型。预设报错类型是指由测试脚本的质量原因导致的报错。从而确定测试脚本的运行得分。

参见图7，通过分析报错API的返回消息，服务器可以检测是否有预置脚本报错（如图7中S701所示）。即，预设报错类型包括预置脚本报错。

其中，若测试脚本中操作步骤之前的语句不规范，则可能导致出现预置脚本报错。即，预置脚本报错是脚本质量有问题导致的。示例性的，测试脚本中BeforeMethod字段（即对应测试用例的预置条件部分）存在语句不规范，则可能导致出现预置脚本报错。例如，BeforeMethod字段中插入表格前没有删除已有的表格，则可能导致出现预置脚本报错。

基于此，服务器可以检测报错API的返回消息中是否有预置条件报错。具体的，服务器可以在报错API的返回消息中定位预置条件的报错信息。示例性的，服务器可以在报错API的返回消息中，定位用于指示预置条件的报错信息的关键字（也可以称为第一关键字），那么，隶属于该关键字的报错信息则可以确认为预置条件的报错信息。从而实现定位预置条件的报错信息。其中，用于指示预置条件的报错信息的关键字可以是Setup或者BeforeMethod。在定位出预置条件的报错信息后，服务器可以查找预置条件的报错信息中是否有报错内容。示例性的，若预置条件的报错信息中有报错关键字（如ERROR），则表明预置条件的报错信息中有报错内容；反之，若预置条件的报错信息中没有报错关键字（如ERROR），则表明预置条件的报错信息中没有报错内容。若预置条件的报错信息中有报错内容，则表明有预置脚本报错。若预置条件的报错信息中没有报错内容，则表明没有预置脚本报错。

若检测出有预置脚本报错，则表明测试脚本运行态下的质量较差。若检测出没有预置脚本报错，则表明测试脚本运行态下的质量较好。

继续参见图7，通过分析报错API的返回消息，服务器可以检测是否有后处理报错（如图7中S702所示）。即，预设报错类型包括后处理报错。

其中，若测试脚本中操作步骤之后的语句不规范，则可能导致出现后处理报错。即，后处理报错是脚本质量有问题导致的。示例性的，测试脚本中BeforeMethod字段中有修改数据的语句，但是在teardown字段中没有恢复数据的语句，则可能导致出现后处理报错。

基于此，服务器可以检测报错API的返回消息中是否有后处理报错。具体的，服务器可以在报错API的返回消息中定位后处理的报错信息。示例性的，服务器可以在报错API的返回消息中，定位用于指示后处理的报错信息的关键字（也可以称为第二关键字），那么，隶属于该关键字的报错信息则可以确认为后处理的报错信息。从而实现定位后处理的报错信息。其中，用于指示后处理的报错信息的关键字可以是TearDown或者AfterMethod。在定位出后处理的报错信息后，服务器可以查找后处理的报错信息中是否有报错内容。示例性的，若后处理的报错信息中有报错关键字（如ERROR），则表明后处理的报错信息中有报错内容；反之，若后处理的报错信息中没有报错关键字（如ERROR），则表明后处理的报错信息中没有报错内容。若后处理的报错信息中有报错内容，则表明有后处理报错。若后处理的报错信息中没有报错内容，则表明没有后处理报错。

若检测出有后处理报错，则表明测试脚本运行态下的质量较差。若检测出没有后处理报错，则表明测试脚本运行态下的质量较好。

继续参见图7，通过分析报错API的返回消息，服务器可以检测是否有空指针报错（如图7中S703所示）。即，预设报错类型包括空指针报错（Null Point Exception，NPE）。

其中，NPE通常是由于在一个类的对象指针创建之后，没有为其分配空间，而在调用该对象指针时，直接调用这个对象的方法或者数据而导致的报错。

基于此，服务器可以检测报错API的返回消息中是否有NPE。示例性的，服务器可以检测报错API的返回消息中是否有指示NPE的关键字，如Null Point Exception或者NPE。若检测到有指示NPE的关键字，则表明有NPE；若检测到没有指示NPE的关键字，则表明没有NPE。

若检测出有NPE，则表明测试脚本运行态下的质量较差。若检测出没有NPE，则表明测试脚本运行态下的质量较好。

继续参见图7，通过分析报错API的返回消息，服务器可以检测是否有请求类型不存在报错（如图7中S704所示）。即，预设报错类型包括请求类型不存在报错。

通常情况下，在RESTful架构中，请求类型（requestType）包括GET、HEAD、PUT以及POST共四类。若在测试脚本中，请求类型是上述四种类型之外的类型，则会出现请求类型不存在报错。例如，requestType为GET1，而不是上述四种请求类型中的任一种。即，请求类型不存在是脚本质量有问题导致的。

基于此，服务器可以检测报错API的返回消息中是否有请求类型不存在报错。示例性的，服务器可以检测报错API的返回消息中是否有指示请求类型不存在的关键字，如Request type is not existed。若检测到有指示请求类型不存在的关键字，则表明有请求类型不存在报错；若检测到没有指示请求类型不存在的关键字，则表明没有请求类型不存在报错。

若检测出有请求类型不存在报错，则表明测试脚本运行态下的质量较差。若检测出没有请求类型不存在报错，则表明测试脚本运行态下的质量较好。

继续参见图7，通过分析报错API的返回消息，服务器可以检测是否有变量找不到报错（如图7中S705所示）。即，预设报错类型包括变量找不到报错。

其中，若测试脚本中出现了变量，但是并未定义该变量，则可能导致出现变量找不到报错。即，变量找不到是脚本质量有问题导致的。

基于此，服务器可以检测报错API的返回消息中是否有变量找不到报错。示例性的，服务器可以检测报错API的返回消息中是否有指示变量找不到的关键字，如“找不到符号”。若检测到有指示变量找不到的关键字，则表明有变量找不到报错；若检测到没有指示变量找不到的关键字，则表明没有变量找不到报错。

若检测出有变量找不到报错，则表明测试脚本运行态下的质量较差。若检测出没有变量找不到报错，则表明测试脚本运行态下的质量较好。

继续参见图7，通过分析报错API的返回消息，服务器可以检测是否有URL不存在报错（如图7中S706所示）。即，预设报错类型包括URL不存在报错。

其中，若测试脚本中环境地址下的URL有误，则可能导致出现URL不存在报错。即，URL不存在是脚本质量有问题导致的。

基于此，服务器可以检测报错API的返回消息中是否有URL不存在报错。示例性的，服务器可以检测报错API的返回消息中是否有指示URL不存在的关键字，如“No messageavailable”，“pateh”:“URL”。若检测到有指示URL不存在的关键字，则表明有URL不存在报错；若检测到没有指示URL不存在的关键字，则表明没有URL不存在报错。

若检测出有URL不存在报错，则表明测试脚本运行态下的质量较差。若检测出没有URL不存在报错，则表明测试脚本运行态下的质量较好。

前述分别以各种运行态的检测项，说明了检测测试脚本运行态的质量的具体实现。实际实施时，可以采用上述一种或多种运行态的检测项来检测测试脚本运行态的质量。若采用多种运行态的检测项来检测测试脚本运行态的质量，服务器可以按照一定的顺序串行检测，或者也可以并行检测。例如，服务器可以按照图7中S701-S706的顺序串行执行，也可以并行执行S701-S706。本申请实施例对此不作具体限定。

在服务器中，可以预先为各个运行态的检测项分配相应的分值，然后服务器可以基于各个运行态的检测项的检测结果及其分值，来得到测试脚本的独立性得分。示例性的，共有图7所示的6个运行态的检测项，则可以为每个运行态的检测项分配20分，在每一个运行态的检测项检测得到表示运行态的质量好的结果后，则将运行得分加20。例如，图7中S701-S706的检测结果都是“是”，而S706的检测结果为“否”，则独立性得分为20*5=100分。

进一步的，为了提高计算得到的运行得分的合理性，在为各个运行态的检测项分配相应的分值时，可以基于各个运行态的检测项的重要程度来分配分值。例如，图7所示S701-S702的重要程度较高，而S703-S706的重要程度较低，则可以为S701-S702对应的两个运行态的检测项分别分配30分，而为S703-S706对应的四个运行态的检测项分别分配10分。

另外，实际中，每个测试脚本在入库后，通常都会被执行多次。在一种具体的实现方式中，针对单次的执行日志，可以采用前述图7所示的过程得到单次运行的运行得分，然后将多次运行的运行得分进行统计分析，例如，求平均值、求和或者求中位数等，得到最终的运行得分。在另一种具体的实现方式中，服务器也可以针对多次执行对应的多个执行日志整体采用图7所示的过程得到运行得分。例如，若多个执行日志中没有预置脚本报错，则运行得分加30分，若多个执行日志中没有URL不存在报错，则运行得分加10分。

在另一些实施例中，在运行检测的过程中，针对任一测试脚本，服务器可以统计多次批量执行过程中，该测试脚本运行失败的次数。通常情况下，同一测试脚本运行失败的次数越多，则其质量有问题的可能性越大。

基于此，针对任一测试脚本，服务器可以检测多次批量执行的运行结果中，测试脚本运行失败的次数，并基于运行失败的次数来确定运行得分。其中，随着运行失败的次数增加，则运行得分会随之减少。

前述分别说明了基于预设报错类型和运行失败的次数来确定运行得分的具体实现，实际实施时，两种方式也可以结合。示例性的，可以在基于预设报错类型得到的运行得分与基于运行失败的次数得到的运行得分加权求和，得到最终的运行得分。

在得到静态得分和运行得分后，服务器可以综合静态得分和运行得分综合评估测试脚本的质量。示例性的，服务器可以将独立性、重用性、可读性和健壮性分别的得分与运行分加权求和，得到测试脚本的综合质量分。最终，服务器基于综合质量分修改测试脚本。或者，服务器基于综合质量分对测试脚本进行筛选，将综合质量分满足条件（如大于预设分数）的测试脚本放入自动化工厂，真正用于测试被测试系统。

为了便于对本申请方案的理解，下面以图8所示的完整示例来说明本申请方案的流程。

S801、编写测试脚本。

示例性的，可以采用接口自动化编写的方式来编写测试脚本。

S802、判断是否通过本地调测。若是，则执行S803；若否，则执行S801。

示例性的，通过本地调测，可以检测测试脚本中的逻辑正确与否。例如，在库存为4的基础上，入库1件商品，本地调测可以检测测试脚本中断言检测中的预期结果是否为5。若是5，则调测通过；若不是5，则调测失败。

进一步的，若本地调测通过，则可以执行S803及其后续步骤，检测测试脚本的质量。若本地调测不通过，则需要重复执行S801，重新编写测试脚本。

S803、静态检测，得到静态得分。

可参见前文中第一方面关于静态检测的具体实现的相关说明，此处不再赘述。

S804、提交入库。

示例性的，将大量测试脚本提交至代码库GitLab中。

S805、批量执行。

示例性的，每天批量执行一次代码库中的测试脚本。

S806、运行检测，得到运行得分。

可参见前文中第二方面关于运行检测的具体实现的相关说明，此处不再赘述。

S807、基于静态得分和动态得分提交入厂。

示例性的，可以将综合质量分超过预设分数的测试脚本提交到自动化工厂中，用于对被测试系统进行测试。

本申请实施例还提供了一种检测测试脚本质量的系统，参见图9，该系统包括服务器901、显示设备902和代码仓库903。

服务器901包括检测进程和数据库。检测进程用于执行前述方法实施例中服务器执行的功能，实现对测试脚本的质量检测。数据库用于存储检测配置和检测得分。检测配置可以包括独立性、重用性、可读性、健壮性检测涉及的检测项，以及包括预设报错类型等。检测得分包括静态得分和运行得分，静态得分进一步可细分为独立性、重用性、可读性、健壮性的得分。显示设备902可以是手机、平板、个人计算机等具有显示功能的设备，其用于显示服务器得到的检测得分。代码仓库（如GitLab）903用于存储检测对象，如测试脚本。

示例性的，服务器运行检测进程，可以从代码仓库中获取测试脚本以及从数据库中获取检测配置，在完成检测后将检测得分存储到数据库，并且还可以将检测得分发送给显示设备，以供显示设备将检测得分展示给用户，如测试人员。

本申请实施例还提供了一种服务器，该服务器可以包括：存储器和一个或多个处理器。存储器和处理器耦合。该存储器用于存储计算机程序代码，该计算机程序代码包括计算机指令。当处理器执行计算机指令时，电子设备可执行上述方法实施例中服务器执行的各个功能或者步骤，实现测试脚本的质量检测。

本申请实施例还提供一种芯片系统，如图10所示，该芯片系统1000包括至少一个处理器1001和至少一个接口电路1002。处理器1001和接口电路1002可通过线路互联。例如，接口电路1002可用于从其它装置（例如电子设备的存储器）接收信号。又例如，接口电路1002可用于向其它装置（例如处理器1001）发送信号。示例性的，接口电路1002可读取存储器中存储的指令，并将该指令发送给处理器1001。当所述指令被处理器1001执行时，可使得服务器执行上述实施例中的各个步骤。当然，该芯片系统还可以包含其他分立器件，本申请实施例对此不作具体限定。

本实施例还提供一种计算机可读存储介质，该计算机可读存储介质中存储有计算机指令，当该计算机指令在电子设备上运行时，使得电子设备执行上述方法实施例中服务器执行的各个功能或者步骤，实现测试脚本的质量检测。

本实施例还提供了一种计算机程序产品，当该计算机程序产品在计算机上运行时，使得计算机执行上述方法实施例中服务器执行的各个功能或者步骤，实现测试脚本的质量检测。

另外，本申请的实施例还提供一种装置，这个装置具体可以是芯片，组件或模块，该装置可包括相连的处理器和存储器；其中，存储器用于存储计算机执行指令，当装置运行时，处理器可执行存储器存储的计算机执行指令，以使芯片执行上述方法实施例中服务器执行的各个功能或者步骤，实现测试脚本的质量检测。

其中，本实施例提供的电子设备、通信系统、计算机可读存储介质、计算机程序产品或芯片均用于执行上文所提供的对应的方法，因此，其所能达到的有益效果可参考上文所提供的对应的方法中的有益效果，此处不再赘述。

通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。

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

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

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

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

最后应说明的是，以上实施例仅用以说明本申请的技术方案而非限制，尽管参照较佳实施例对本申请进行了详细说明，本领域的普通技术人员应当理解，可以对本申请的技术方案进行修改或等同替换，而不脱离本申请技术方案的精神和范围。

Claims (14)

1.一种脚本质量的检测方法，其特征在于，包括：

检测测试脚本的脚本内容，得到所述测试脚本的静态得分；

运行所述测试脚本，获取运行所述测试脚本得到的报错信息；

基于所述报错信息中包括的报错类型和运行所述测试脚本失败的次数，确定所述测试脚本的运行得分；

综合所述静态得分和所述运行得分，评估所述测试脚本的质量。

2.根据权利要求1所述的方法，其特征在于，所述检测所述测试脚本的脚本内容，包括以下一项或多项：

检测所述测试脚本中用于初始化环境的字段中是否有内容；以及，

检测所述测试脚本中用于指示测试步骤的字段中是否有内容；以及，

在所述测试脚本中包括修改第一数据的语句的情况下，检测在所述测试脚本中修改所述第一数据的语句之后，是否包括恢复所述第一数据的语句；以及，

在所述测试脚本中包括插入第二数据的语句的情况下，检测在所述测试脚本中插入第二数据的语句之前，是否包括删除所述第二数据的语句；以及，

在所述测试脚本中包括插入第二数据的语句的情况下，检测所述插入所述第二数据的语句中是否包括字段名；以及，

检测所述测试脚本中常量的数量、与常量和变量的数量之和的比值是否超过第一阈值。

3.根据权利要求1所述的方法，其特征在于，所述检测所述测试脚本的脚本内容，包括以下一项或多项：

检测所述测试脚本中是否包括相对路径，所述相对路径中包括预设字符；以及，

在所述测试脚本中操作步骤的数量超过第二阈值的情况下，检测所述测试脚本中是否包括已封装的操作步骤；以及，

检测所述测试脚本中的环境地址中是否包括变量。

4.根据权利要求1所述的方法，其特征在于，所述检测所述测试脚本的脚本内容，包括以下一项或多项：

检测所述测试脚本中是否包括注释文本；以及，

检测所述测试脚本中是否包括用于指示操作步骤的分组的字段；以及，

在所述测试脚本中包括用于指示密码的第一字段的情况下，检测所述测试脚本中所述第一字段的字段值的长度是否超过预设长度。

5.根据权利要求1所述的方法，其特征在于，所述检测所述测试脚本的脚本内容，包括以下一项或多项：

检测所述测试脚本中是否包括延时语句；以及，

检测所述测试脚本中是否包括断言检测；以及，

在所述测试脚本中包括所述断言检测的情况下，检测所述断言检测中是否包括对预期输出的检测，所述预期输出包括执行所述测试脚本中的操作步骤后的正确结果。

6.根据权利要求5所述的方法，其特征在于，在所述检测所述测试脚本中是否包括延时语句之后，所述方法还包括：

若所述测试脚本中包括所述延时语句，检测所述延时语句中的延时时长是否超过预设延时时长。

7.根据权利要求1-6中任一项所述的方法，其特征在于，所述基于所述报错信息中包括的报错类型和运行所述测试脚本失败的次数，确定所述测试脚本的运行得分，包括：

所述报错信息中包括的错误类型中预设报错类型越多，所述运行得分越低，所述报错信息中包括的错误类型中预设报错类型越少，所述运行得分越高；以及，

运行所述测试脚本失败的次数越少，所述运行得分越低，运行所述测试脚本失败的次数越多，所述运行得分越高；

其中，所述预设报错类型为所述测试脚本的脚本质量导致的报错类型。

8.根据权利要求7所述的方法，其特征在于，所述预设报错类型包括预置脚本报错，在所述基于所述报错信息中包括的报错类型和运行所述测试脚本失败的次数，确定所述测试脚本的运行得分之前，所述方法还包括：

在所述报错信息中定位用于指示预置条件的第一关键字，所述报错信息中属于所述第一关键字的报错信息为所述预置条件的报错信息；

检测所述报错信息中预置条件的报错信息中是否有报错内容，若是，则确定所述报错信息包括的报错类型中存在预置脚本报错；若否，则确定所述报错信息包括的报错类型中不存在预置脚本报错。

9.根据权利要求7所述的方法，其特征在于，所述预设报错类型包括后处理报错，在所述基于所述报错信息中包括的报错类型和运行所述测试脚本失败的次数，确定所述测试脚本的运行得分之前，所述方法还包括：

在所述报错信息中定位用于指示后处理的第二关键字，所述报错信息中属于所述第二关键字的报错信息为所述后处理的报错信息；

检测所述报错信息中后处理的报错信息中是否有报错内容，若是，则确定所述报错信息包括的报错类型中存在后处理报错；若否，则确定所述报错信息包括的报错类型中不存在后处理报错。

10.根据权利要求7所述的方法，其特征在于，所述预设报错类型包括：空指针报错、请求类型不存在报错、变量找不到报错以及URL不存在报错中的一种或多种。

11.根据权利要求1所述的方法，其特征在于，在所述评估所述测试脚本的质量之后，所述方法还包括：

若所述测试脚本的所述质量高于预设质量标准，将所述测试脚本送入自动化测试平台，用于测试被测试系统。

12.一种计算设备，其特征在于，所述计算设备包括存储器和处理器，所述存储器和所述处理器耦合；其中，所述存储器中存储有计算机程序代码，所述计算机程序代码包括计算机指令，当所述计算机指令被所述处理器执行时，使得所述计算设备执行如权利要求1-11中任一项所述的方法。

13.一种计算机可读存储介质，其特征在于，包括计算机指令，当所述计算机指令在计算设备上运行时，使得所述计算设备执行如权利要求1-11中任一项所述的方法。

14.一种芯片系统，其特征在于，所述芯片系统应用于包括处理器和存储器的计算设备，所述芯片系统包括一个或多个接口电路和一个或多个处理器，所述接口电路和所述处理器通过线路互联，所述接口电路用于从所述计算设备的存储器接收信号，并向所述处理器发送所述信号，所述信号包括所述存储器中存储的计算机指令，当所述处理器执行所述计算机指令时，使得所述计算设备执行如权利要求1-11中任一项所述的方法。

Images