一种测试脚本生成方法及相关装置与流程

1.本技术涉及计算机技术领域，尤其涉及一种测试脚本生成方法、装置、电子设备、计算机可读存储介质以及计算机程序产品。


背景技术：

2.软件开发是指开发人员根据用户要求建造出软件的过程。为了提升开发效率，开发人员会将待开发软件划分为多个模块，并分别对多个模块进行开发。其中，模块之间通过接口进行交互。为了保证软件的正常运行，开发人员需要利用自动化测试工具执行测试脚本，以对软件进行接口测试。
3.通常情况下，开发人员采用录制的方式生成测试脚本。其中，录制的方式是指自动化测试工具的客户端录制开发人员调用待测接口的操作，利用代理服务器，将录制的操作以采样器的形式保存至指定的线程组中，开发人员可以选择需要的采样器，从而生成对应的测试脚本。
4.然而，上述生成测试脚本的方式适用场景有限，且需要开发人员在多个采样器中选择所需的采样器，耗费大量的时间。


技术实现要素：

5.本技术提供了一种测试脚本生成方法，该方法能够自动生成测试脚本，适用性强，同时，能够提高测试效率。本技术还提供了上述方法对应的装置、电子设备、计算机可读存储介质以及计算机程序产品。
6.第一方面，本技术提供了一种测试脚本生成方法。所述方法包括：
7.从原始文件中，获取目标格式的接口文本，所述原始文件为包括接口信息的多种格式的文件；
8.基于所述接口文本，提取至少一个接口的接口参数；
9.根据所述至少一个接口的接口参数，生成对应的测试脚本。
10.在一些可能的实现方式中，所述根据所述至少一个接口的接口参数，生成对应的测试脚本，包括：
11.基于类树形存储结构，生成所述至少一个接口的接口参数对应的测试要素模型；
12.根据所述至少一个接口的接口参数对应的测试要素模型，生成对应的测试脚本。
13.在一些可能的实现方式中，所述基于类树形存储结构，生成所述至少一个接口的接口参数对应的测试要素模型，包括：
14.当所述接口的协议类型为传输控制协议tcp时，所述类树形存储结构的结点依次存储所述接口的协议类型、请求参数内容和响应断言，以生成对应的测试要素模型；
15.当所述接口的协议类型为超文本传输协议http时，所述类树形存储结构的结点依次存储所述接口的协议类型、请求参数形式、请求参数内容和响应断言，以生成对应的测试要素模型。
16.在一些可能的实现方式中，所述基于所述接口文本，提取至少一个接口的接口参数，包括：
17.对所述接口文本进行段落切割，获得所述至少一个接口的信息文本；
18.从所述至少一个接口的信息文本中，提取所述至少一个接口的接口参数。
19.在一些可能的实现方式中，所述对所述接口文本进行段落切割，获得所述至少一个接口的信息文本，包括：
20.根据所述接口文本和预设的接口标识，确定所述接口文本的接口数量；
21.基于预设的分隔符对所述接口文本进行段落切割，获得至少一个段落文本和所述接口文本的段落数量；
22.若所述段落数量与所述接口数量相同，根据所述至少一个段落文本，获得所述至少一个接口的信息文本；
23.若所述段落数量与所述接口数量不相同，基于所述预设的接口标识对所述接口文本进行段落切割，获得所述至少一个接口的信息文本。
24.在一些可能的实现方式中，所述目标格式为纯文本格式，所述原始文件包括：接口文档、程序日志、开发人员的交付邮件中的一种或多种。
25.第二方面，本技术提供了一种测试脚本生成装置。所述装置包括：
26.获取模块，用于从原始文件中，获取目标格式的接口文本，所述原始文件为包括接口信息的多种格式的文件；
27.提取模块，用于基于所述接口文本，提取至少一个接口的接口参数；
28.生成模块，用于根据所述至少一个接口的接口参数，生成对应的测试脚本。
29.在一些可能的实现方式中，所述生成模块具体用于：
30.基于类树形存储结构，生成所述至少一个接口的接口参数对应的测试要素模型；
31.根据所述至少一个接口的接口参数对应的测试要素模型，生成对应的测试脚本。
32.在一些可能的实现方式中，所述生成模块具体用于：
33.当所述接口的协议类型为传输控制协议tcp时，所述类树形存储结构的结点依次存储所述接口的协议类型、请求参数内容和响应断言，以生成对应的测试要素模型；
34.当所述接口的协议类型为超文本传输协议http时，所述类树形存储结构的结点依次存储所述接口的协议类型、请求参数形式、请求参数内容和响应断言，以生成对应的测试要素模型。
35.在一些可能的实现方式中，所述提取模块具体用于：
36.对所述接口文本进行段落切割，获得所述至少一个接口的信息文本；
37.从所述至少一个接口的信息文本中，提取所述至少一个接口的接口参数。
38.在一些可能的实现方式中，所述提取模块具体用于：
39.根据所述接口文本和预设的接口标识，确定所述接口文本的接口数量；
40.基于预设的分隔符对所述接口文本进行段落切割，获得至少一个段落文本和所述接口文本的段落数量；
41.若所述段落数量与所述接口数量相同，根据所述至少一个段落文本，获得所述至少一个接口的信息文本；
42.若所述段落数量与所述接口数量不相同，基于所述预设的接口标识对所述接口文
本进行段落切割，获得所述至少一个接口的信息文本。
43.在一些可能的实现方式中，所述目标格式为纯文本格式，所述原始文件包括：接口文档、程序日志、开发人员的交付邮件中的一种或多种。
44.第三方面，本技术提供了一种电子设备。所述电子设备包括处理器和存储器，所述存储器中存储有指令，所述处理器执行所述指令，使得所述电子设备平台执行如本技术第一方面或第一方面的任一种实现方式所述的方法。
45.第四方面，本技术提供了一种计算机可读存储介质。所述计算机可读存储介质中存储有指令，当其在电子设备上运行时，使得所述电子设备执行上述第一方面或第一方面的任一种实现方式所述的方法。
46.第五方面，本技术提供了一种计算机程序产品。所述计算机程序产品包括计算机可读指令，当其在电子设备上运行时，使得所述电子设备执行上述第一方面或第一方面的任一种实现方式所述的方法。
47.本技术在上述各方面提供的实现方式的基础上，还可以进行进一步组合以提供更多实现方式。
48.基于上述内容描述，可知本技术的技术方案具有如下有益效果：
49.具体地，该方法首先从原始文件中，获取目标格式的接口文本。其中，原始文件为包括接口信息的多种格式的文件。接着基于接口文本，提取至少一个接口的接口参数，然后根据至少一个接口的接口参数，生成对应的测试脚本。该方法通过从原始文件中获取目标格式的接口文本，并提取接口参数，能够实现从不规范的接口文件中提取接口参数，适用性强。同时，无需更改程序代码，自动生成测试脚本，能够提升测试效率。
附图说明
50.结合附图并参考以下具体实施方式，本技术各实施例的上述和其他特征、优点及方面将变得更加明显。贯穿附图中，相同或相似的附图标记表示相同或相似的元素。应当理解附图是示意性的，原件和元素不一定按照比例绘制。
51.图1为本技术实施例提供的一种测试脚本生成方法的流程示意图；
52.图2为本技术实施例提供的一种段落切割的流程示意图；
53.图3为本技术实施例提供的一种测试要素模型的结构示意图；
54.图4为本技术实施例提供的另一种测试要素模型的结构示意图；
55.图5为本技术实施例提供的一种测试脚本生成装置的结构示意图；
56.图6为本技术实施例提供的一种实现测试脚本生成的电子设备的结构示意图。
具体实施方式
57.下面将参照附图更详细地描述本技术的实施例。虽然附图中显示了本技术的某些实施例，然而应当理解的是，本技术可以通过各种形式来实现，而且不应该被解释为限于这里阐述的实施例，相反提供这些实施例是为了更加透彻和完整地理解本技术。应当理解的是，本技术的附图及实施例仅用于示例性作用，并非用于限制本技术的保护范围。
58.本文使用的术语“包括”及其变形是开放性包括，即“包括但不限于”。术语“基于”是“至少部分地基于”。术语“一个实施例”表示“至少一个实施例”；术语“另一实施例”表示“至少一个另外的实施例”；术语“一些实施例”表示“至少一些实施例”。其他术语的相关定义将在下文描述中给出。
59.需要注意，本技术中提及的“第一”、“第二”等概念仅用于对不同的装置、模块或单元进行区分，并非用于限定这些装置、模块或单元所执行的功能的顺序或者相互依存关系。
60.需要注意，本技术中提及的“一个”、“多个”的修饰是示意性而非限制性的，本领域技术人员应当理解，除非在上下文另有明确指出，否则应该理解为“一个或多个”。
61.为了便于理解本技术的技术方案，下面对本技术中具体的应用场景进行说明。
62.软件开发是指开发人员根据用户要求编写、建造出软件的过程，包括需求捕捉、需求分析、设计、实现和测试等多个步骤。在软件开发的过程中，为了提升开发效率，开发人员会根据用户需求，将待开发软件划分为多个模块，并分别对多个模块进行开发。其中，模块与模块之间通过接口进行连接与交互。
63.为了保证软件的正常运行，在软件开发的过程中，开发人员会进行接口测试。目前，开发人员可以利用自动化测试工具执行测试脚本，从而实现软件的接口测试。其中，接口测试可以包括接口参数传递测试、接口功能测试、接口输出结果测试。
64.在进行接口测试时，开发人员可以利用多种方式生成测试脚本。例如，开发人员可以通过手工编写的方式，在自动化测试工具的用户界面添加所需的配置元件、线程组、采样器等，并填写各配置元件参数，从而生成测试脚本。再例如，开发人员可以采用录制的方式，通过配置http代理服务器，在本地建立代理服务，而后在自动化测试工具的客户端录制开发人员调用待测接口的操作，代理服务器拦截并解析数据包，将录制的操作以采样器的形式保存在线程组中，开发人员可以选择需要的采样器，从而生成测试脚本。又例如，开发人员可以通过文本编辑的方式，按照自动化测试工具的代码规范，在文本文件中建立配置元件，从而生成测试脚本。
65.然而，手工编写的方法需要开发人员手动添加配置元件、修改参数，操作繁琐复杂，且容易出错。录制的方式适用场景有限，且开发人员从多个采样器中挑选所需的采样器，需要耗费时间与精力。文本编辑的方式需要开发人员掌握自动化测试工具的代码规范，且编写的文本冗长，极易出错。
66.基于此，本技术实施例提供了一种测试脚本生成方法。具体地，该方法首先从原始文件中，获取目标格式的接口文本。其中，原始文件为包括接口信息的多种格式的文件。接着基于接口文本，提取至少一个接口的接口参数，然后根据至少一个接口的接口参数，生成对应的测试脚本。该方法通过从原始文件中获取目标格式的接口文本，并提取接口参数，能够实现从不规范的接口文件中提取接口参数，适用性强。同时，无需更改程序代码，自动生成测试脚本，能够提升测试效率。
67.接下来，结合附图对本技术实施例提供的测试脚本生成方法进行详细说明。
68.参见图1所示的一种测试脚本生成方法的流程示意图，该方法可以由电子设备执行，具体包括如下步骤：
69.s101：电子设备从原始文件中，获取目标格式的接口文本。
70.其中，原始文件可以为包括接口信息的多种格式的文件。在一些可能的实现方式中，原始文件可以包括接口文档、程序日志、开发人员的交付邮件中的一种或多种，目标格式可以为纯文本格式。
locator，url)，可以通过正则表达式(http[s]？)://([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}):([0-9]{2,5})((/[^\n\s？] ) )”或其子语句提取协议类型、ip、端口、路径等内容。
[0082]
对于请求方法，可以通过在参数字典中存储请求方法进行提取。例如，可以在参数字典中存储get、post、put等请求方法。当接口的url或其子元素附近出现参数字典中的请求方法时，可以认为是该接口的请求方法。
[0083]
对于请求参数或报文，可以通过正则表达式“([\d\w] (:|＝)[\d\w] [\n,]？) ”或“{.*}”进行提取。
[0084]
对于信息头，可以在参数字典中存储信息头参数，再通过正则表达式“([\d\w] (:|＝)[\d\w] [\n,]？) ”进行提取。例如，可以在参数字典中存储content-type、cookies。通过正则表达式提取出参数名与参数值，并检索参数字典，从而验证提取出的参数名是否存在于参数字典中，如存在，则可以认为提取出的参数名与参数值为信息头信息。
[0085]
对于响应断言，可以在参数字典中存储返回标志字段，当信息文本中出现返回标志字段时，可以认为是该接口的响应断言。
[0086]
s103：电子设备根据至少一个接口的接口参数，生成对应的测试脚本。
[0087]
由于提取的接口参数为无序的键值对，为了提高生成测试脚本的效率，根据接口参数层层递进的构成特征，可以对接口参数进行存储。
[0088]
在一些可能的实现方式中，电子设备可以基于类树形存储结构，生成至少一个接口的接口参数对应的测试要素模型，根据至少一个接口的接口参数对应的测试要素模型，生成对应的测试脚本。
[0089]
下面，结合图3和图4所示的测试要素模型的结构示意图进行介绍。
[0090]
在本技术实施例中，如图3所示，当接口的协议类型为传输控制协议tcp时，类树形存储结构的结点可以依次存储接口的协议类型、请求参数内容和响应断言，以生成对应的测试要素模型。其中，请求参数内容可以包括ip、端口和报文。
[0091]
进一步地，如图4所示，当接口的协议类型为超文本传输协议http时，类树形存储结构的结点可以依次存储所述接口的协议类型、请求参数形式、请求参数内容和响应断言，以生成对应的测试要素模型。其中，请求参数形式可以包括键值对、报文、无参数，请求参数内容可以包括请求方式、ip、端口和路径。
[0092]
进一步地，若在接口参数提取过程中，未提取到某一结点的数据，则可以将该结点存储为默认值或空值。
[0093]
在生成测试要素模型后，电子设备可以根据测试要素模型，生成对应的测试脚本。
[0094]
具体地，电子设备可以使用jmeter自动化测试工具进行接口测试。其中，jmeter是由apache组织开发的基于java的开源性能测试工具，可模拟用户对服务器、网络或对象发起大量请求，以测试它们的强度和分析性能。jmeter支持http、tcp等多种接口协议，是接口测试及接口性能测试的常用工具。jmeter测试脚本是jmeter的发起测试的配置载体，存储着测试计划、各类配置元件、线程组、采样器等元件，以.jmx为文件后缀，本质上是xml格式的文本文件，jmeter发起的接口测试是完全依照脚本指定的方式对测试对象进行测试。
[0095]
电子设备可以按照如下过程生成jmeter测试脚本。首先，生成基础测试元件。其中，基础测试元件可以包括测试计划、线程组，测试计划在jmeter测试脚本中的名称为“testplan”，线程组在jmeter测试脚本中的名称为“threadgroup”。
[0096]
接着，根据测试要素模型，生成接口相关测试元件。根据测试要素模型中的协议类型，确定生成的采样器种类。当协议类型为tcp时，创建tcp采样器“tcpsampler”，并根据测试要素模型中的请求参数内容，填充tcp采样器的参数值，例如，电子设备可以将ip填充至“tcpsampler.server”，端口填充至“tcpsampler.port”，报文填充至“tcpsampler.request”，若存在响应断言，则生成“responseassertion”，并将响应断言填充至“asserion.test_strings”。当协议类型为http时，生成http请求元件“httpsamplerproxy”，并判断请求参数形式，如果请求参数形式为键值对，则生成“httpargument”，将参数名填充至“argument.name”，将参数值填充至“argument.value”；如果请求参数形式为报文格式，则将参数值填充至“argument.value”；如果无参数，则不生成“httpargument”。请求参数形式相关元件生成完成后，将协议类型填充至“httpsampler.protocol”，ip填充至“httpsampler.domain”，端口填充至“httpsampler.port”，路径填充至“httpsampler.path”，如果存在响应断言，则生成“responseassertion”，并将响应断言填充至“asserion.test_strings”，如果存在信息头，则生成“headermanager.headers”，并将参数名填充至“header.name”，参数值填充至“header.value”，从而生成测试脚本。
[0097]
该方法首先从原始文件中，获取目标格式的接口文本。其中，原始文件为包括接口信息的多种格式的文件。接着基于接口文本，提取至少一个接口的接口参数，然后根据至少一个接口的接口参数，生成对应的测试脚本。该方法通过从原始文件中获取目标格式的接口文本，并提取接口参数，能够实现从不规范的接口文件中提取接口参数，适用性强。同时，无需更改程序代码，自动生成测试脚本，能够提升测试效率。
[0098]
基于本技术实施例提供的上述方法，本技术实施例还提供了与上述方法对应的测试脚本生成装置。描述于本技术实施例中所涉及到的单元/模块可以通过软件的方式实现，也可以通过硬件的方式来实现。其中，单元/模块的名称在某种情况下并不构成对该单元/模块本身的限定。
[0099]
参见图5所示的测试脚本生成装置的结构示意图，该装置500包括：
[0100]
获取模块501，用于从原始文件中，获取目标格式的接口文本，其中，原始文件为包括接口信息的多种格式的文件；
[0101]
提取模块502，用于基于接口文本，提取至少一个接口的接口参数；
[0102]
生成模块503，用于根据至少一个接口的接口参数，生成对应的测试脚本。
[0103]
在一些可能的实现方式中，生成模块503具体用于：
[0104]
基于类树形存储结构，生成至少一个接口的接口参数对应的测试要素模型；
[0105]
根据至少一个接口的接口参数对应的测试要素模型，生成对应的测试脚本。
[0106]
在一些可能的实现方式中，生成模块503具体用于：
[0107]
当接口的协议类型为传输控制协议tcp时，类树形存储结构的结点依次存储接口的协议类型、请求参数内容和响应断言，以生成对应的测试要素模型；
[0108]
当接口的协议类型为超文本传输协议http时，类树形存储结构的结点依次存储接口的协议类型、请求参数形式、请求参数内容和响应断言，以生成对应的测试要素模型。
[0109]
在一些可能的实现方式中，提取模块502具体用于：
[0110]
对接口文本进行段落切割，获得至少一个接口的信息文本；
[0111]
从至少一个接口的信息文本中，提取至少一个接口的接口参数。
[0112]
在一些可能的实现方式中，提取模块502具体用于：
[0113]
根据接口文本和预设的接口标识，确定接口文本的接口数量；
[0114]
基于预设的分隔符对接口文本进行段落切割，获得至少一个段落文本和接口文本的段落数量；
[0115]
若段落数量与接口数量相同，根据至少一个段落文本，获得至少一个接口的信息文本；
[0116]
若段落数量与接口数量不相同，基于预设的接口标识对接口文本进行段落切割，获得至少一个接口的信息文本。
[0117]
在一些可能的实现方式中，目标格式为纯文本格式，原始文件包括：接口文档、程序日志、开发人员的交付邮件中的一种或多种。
[0118]
根据本技术实施例的测试脚本生成装置500可对应于执行本技术实施例中描述的方法，并且测试脚本生成装置500的各个模块/单元的上述和其它操作和/或功能分别为了实现图1所示实施例中的各个方法的相应流程，为了简洁，在此不再赘述。
[0119]
本文中以上描述的功能可以至少部分地由一个或多个硬件逻辑部件来执行。参见图6所示的实现测试脚本生成的电子设备600的结构示意图，需要说明的是，图6所示的电子设备仅仅是一个示例，不应对本技术实施例的功能和使用范围带来任何限制。
[0120]
如图6所示，电子设备600可以包括处理装置(例如中央处理器、图形处理器等)601，其可以根据存储在只读存储器(rom)602中的程序或者从存储装置608加载到随机访问存储器(ram)603中的程序而执行各种适当的动作和处理。在ram603中，还存储有电子设备600操作所需的各种程序和数据。处理装置601、rom 602以及ram 603通过总线604彼此相连。输入/输出(i/o)接口605也连接至总线604。
[0121]
通常，以下装置可以连接至i/o接口605：包括例如触摸屏、触摸板、键盘、鼠标、摄像头、麦克风、加速度计、陀螺仪等的输入装置606；包括例如液晶显示器(lcd)、扬声器、振动器等的输出装置607；包括例如磁带、硬盘等的存储装置608；以及通信装置609。通信装置609可以允许电子设备600与其他设备进行无线或有线通信以交换数据。虽然图6示出了具有各种装置的电子设备600，但是应理解的是，并不要求实施或具备所有示出的装置。可以替代地实施或具备更多或更少的装置。
[0122]
本技术还提供一种计算机可读存储介质，也称作机器可读介质。在本技术的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦除可编程只读存储器(eprom或快闪存储器)、光纤、便捷式紧凑盘只读存储器(cd-rom)、光学储存设备、磁储存设备、或上述内容的任何合适组合。
[0123]
需要说明的是，本技术上述的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不
限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑磁盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本技术中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本技术中，计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读信号介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：电线、光缆、rf(射频)等等，或者上述的任意合适的组合。
[0124]
上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被该电子设备执行时，使得电子设备：从原始文件中，获取目标格式的接口文本，其中，原始文件为包括接口信息的多种格式的文件；基于接口文本，提取至少一个接口的接口参数；根据至少一个接口的接口参数，生成对应的测试脚本。
[0125]
特别地，根据本技术的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本技术的实施例包括一种计算机程序产品，其包括承载在非暂态计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信装置从网络上被下载和安装，或者从存储装置被安装。在该计算机程序被处理装置执行时，执行本技术实施例的方法中限定的上述功能。
[0126]
尽管已经采用特定于结构特征和/或方法逻辑动作的语言描述了本主题，但是应当理解所附权利要求书中所限定的主题未必局限于上面描述的特定特征或动作。相反，上面所描述的特定特征和动作仅仅是实现权利要求书的示例形式。
[0127]
虽然在上面论述中包含了若干具体实现细节，但是这些不应当被解释为对本技术的范围的限制。在单独的实施例的上下文中描述的某些特征还可以组合地实现在单个实施例中。相反地，在单个实施例的上下文中描述的各种特征也可以单独地或以任何合适的子组合的方式实现在多个实施例中。
[0128]
以上描述仅为本技术的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解，本技术中所涉及的公开范围，并不限于上述技术特征的特定组合而成的技术方案，同时也应涵盖在不脱离上述公开构思的情况下，由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本技术中公开的(但不限于)具有类似功能的技术特征进行互相替换而形成的技术方案。