一种接口测试脚本的生成方法及其相关设备与流程

[0001]
本申请涉及计算机技术领域，尤其涉及一种接口测试脚本的生成方法、生成装置、计算机设备和计算机可读存储介质。


背景技术：

[0002]
接口是指外部系统与系统之间或者内部各子系统之间的交互点，可以分为外部接口和内部接口。目前常见的web接口包括http协议的接口和web service接口。
[0003]
在项目开发后的测试中，重要的一项就是针对各个接口的测试，接口测试主要用于检测外部系统与所测系统之间交互点或者所测系统内部各子系统之间交互点的数据交互、传递、控制管理过程以及交互点双方的相互依赖关系等。
[0004]
在进行项目的接口测试时，测试人员可以通过jmeter、postman等测试工具或是自己另外构建框架去实现接口测试用例。但如果待测项目存在的接口较多或者待测项目的一些接口包含的字段较多时，创建接口测试用例时，把接口的入参输入到jmeter中或是postman中，并且输入字段的参数，这些过程就会耗费测试人员大量的时间成本，导致接口测试效率难以提高。


技术实现要素：

[0005]
本申请实施例的目的在于提出一种接口测试脚本的生成方法、生成装置、计算机设备和计算机可读存储介质，用于解决现有的在进行接口测试时，由于需要人工设置接口入参，导致耗费测试人员大量时间成本，接口测试效率难以提高的技术问题。
[0006]
为了解决上述技术问题，本申请实施例提供一种一种接口测试脚本的生成方法，采用了如下所述的技术方案：
[0007]
获取从前端调用后端的所有请求中满足预设过滤规则的数据包；
[0008]
对该数据包进行解析操作，确定接口信息；
[0009]
根据该接口信息和预先设置的接口测试脚本模板，生成接口测试脚本。
[0010]
为了解决上述技术问题，本申请实施例还提供一种接口测试脚本的生成装置，采用了如下所述的技术方案，该生成装置包括：
[0011]
获取单元，用于获取从前端调用后端的所有请求中满足预设过滤规则的数据包；
[0012]
第一解析单元，用于对该数据包进行解析操作，确定接口信息；
[0013]
生成单元，用于根据该接口信息和预先设置的接口测试脚本模板，生成接口测试脚本。
[0014]
为了解决上述技术问题，本申请实施例还提供一种计算机设备，包括存储器和处理器，该存储器中存储有计算机可读指令，该处理器执行该计算机可读指令时采用了如下该的技术方案：
[0015]
获取从前端调用后端的所有请求中满足预设过滤规则的数据包；
[0016]
对该数据包进行解析操作，确定接口信息；
[0017]
根据该接口信息和预先设置的接口测试脚本模板，生成接口测试脚本。
[0018]
为了解决上述技术问题，本申请实施例还提供一种计算机可读存储介质，其特征在于，该计算机可读存储介质上存储有计算机可读指令，该计算机可读指令被处理器执行时实现采用了如下该的技术方案：
[0019]
获取从前端调用后端的所有请求中满足预设过滤规则的数据包；
[0020]
对该数据包进行解析操作，确定接口信息；
[0021]
根据该接口信息和预先设置的接口测试脚本模板，生成接口测试脚本。
[0022]
与现有技术相比，本申请实施例主要有以下有益效果：
[0023]
本方案中，在获取到前端调用后端的所有请求中满足预设过滤规则的数据包，可以从这些数据包中解析确定接口信息，最后根据接口信息和预设的接口测试脚本模板，自动生成接口测试脚本。即提供了一种无需手动设置接口参数，而得到接口测试脚本的方法，减少了接口测试时人工的时间成本，提高了接口测试效率。
附图说明
[0024]
为了更清楚地说明本申请中的方案，下面将对本申请实施例描述中所需要使用的附图作一个简单介绍，显而易见地，下面描述中的附图是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
[0025]
图1是本申请可以应用于其中的示例性系统架构图；
[0026]
图2是根据本申请的接口测试脚本的生成方法的一个实施例的流程图；
[0027]
图3是图2中步骤s230之后的一个实施例的流程图；
[0028]
图4是根据本申请的接口测试脚本的生成方法的又一个实施例的流程图；
[0029]
图5是本申请实施例中的一种接口测试脚本的生成装置的一个结构示意图；
[0030]
图6是本申请实施例中的一种接口测试脚本的生成装置的又一个结构示意图；
[0031]
图7是本申请实施例中的一种接口测试脚本的生成装置的又一个结构示意图；
[0032]
图8是根据本申请的计算机设备的一个实施例的结构示意图。
具体实施方式
[0033]
除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同；本文中在申请的说明书中所使用的术语只是为了描述具体的实施例的目的，不是旨在于限制本申请；本申请的说明书和权利要求书及上述附图说明中的术语“包括”和“具有”以及它们的任何变形，意图在于覆盖不排他的包含。本申请的说明书和权利要求书或上述附图中的术语“第一”、“第二”等是用于区别不同对象，而不是用于描述特定顺序。
[0034]
在本文中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，本文所描述的实施例可以与其它实施例相结合。
[0035]
为了使本技术领域的人员更好地理解本申请方案，下面将结合附图，对本申请实施例中的技术方案进行清楚、完整地描述。
[0036]
如图1所示，系统架构100可以包括终端设备101、102、103，网络104和服务器105。网络104用以在终端设备101、102、103和服务器105之间提供通信链路的介质。网络104可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。
[0037]
用户可以使用终端设备101、102、103通过网络104与服务器105交互，以接收或发送消息等。终端设备101、102、103上可以安装有各种通讯客户端应用，例如网页浏览器应用、购物类应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等。
[0038]
终端设备101、102、103可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、电子书阅读器、mp3播放器(moving picture expertsgroup audio layer iii，动态影像专家压缩标准音频层面3)、mp4(moving pictureexperts group audio layer iv，动态影像专家压缩标准音频层面4)播放器、膝上型便携计算机和台式计算机等等。
[0039]
服务器105可以是提供各种服务的服务器，例如对终端设备101、102、103上显示的页面提供支持的后台服务器。
[0040]
需要说明的是，本申请实施例所提供的一种接口测试脚本的生成方法一般由服务器/终端设备执行。
[0041]
应该理解，图1中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。
[0042]
继续参考图2，示出了根据本申请的一种接口测试脚本的生成方法的一个实施例的流程图。所述的一种接口测试脚本的生成方法，包括以下步骤：
[0043]
步骤s210，获取从前端调用后端的所有请求中满足预设过滤规则的数据包。
[0044]
在本实施例中，一种接口测试脚本的生成方法运行于其上的电子设备(例如图1所示的服务器/终端设备)可以通过有线连接方式或者无线连接方式获取从前端调用后端的所有请求中满足预设过滤规则的数据包。需要指出的是，上述无线连接方式可以包括但不限于3g/4g连接、wifi连接、蓝牙连接、wimax连接、zigbee连接、uwb(ultra wideband)连接、以及其他现在已知或将来开发的无线连接方式。
[0045]
其中，首先可以调用浏览器的开发者工具记录前端调用后端的所有请求及后端对前端的响应，确定请求中包括的request信息，header(cookie，content-type)等接口请求中的关键信息。进而，采用抓包工具从这些请求中抓取满足预设过滤规则的数据包。该过滤规则可以包括待测试的系统域名，从而可以获取请求该待测系统域名对应的所有数据包，具体在抓取之前，还需要排除掉静态资源文件获取的请求，然后从剩余的请求中获取指向待测试的系统域名的请求的数据包。该过滤规则也可以包括某一待测接口的地址，可以获取请求该待测接口对应的所有数据包。或者，过滤规则也可以是请求类型，例如只获取get型接口请求的数据包。
[0046]
需要说明的是，这里的抓包工具可以选择fiddler抓包工具。fiddler是一个http协议调试代理工具，可以记录并检查所有客户端设备和互联网之间的http通讯，设置断点，查看所有的“进出”fiddler的数据(包含cookie,html,js,css等文件)。但由于fiddler抓包时什么请求都会抓取到，导致可能会抓取到很多不需要的请求，因此可以根据自定义的预设过滤规则对fiddler进行设置。
[0047]
具体的，在基于fiddler的fiddler scripteditor操作界面上，监听获取用户编辑
输入的过滤条件，以该过滤条件作为预设过滤规则，并在响应到用户保存过滤条件的指令后，保存并重启fiddler。设置好后，在浏览器上进行功能测试，利用设置完成的fiddler进行抓包，当测试完成后，响应用户的保存指令保存所有满足预设过滤规则的数据包。
[0048]
其中，具体设置过滤条件可以在onbeforerequest中对以下函数进行设置：
[0049]
设置需要保持的请求信息
[0050]
osession.fullurl.contains方法中添加需要抓取请求的域名；
[0051]
osession.url：添加请求地址；
[0052]
osession.orequest.headers：请求中的header信息；
[0053]
osession.getrequestbodyasstring()：请求中的请求参数；
[0054]
设置需要保存的响应信息
[0055]
osession.responsecode：请求响应值(200或404等)；
[0056]
osession.getresponsebodyasstring():请求的响应对象。
[0057]
上述设置完成后，在后续进行过滤时，可以将获取到的每个请求和响应根据上述在onbeforerequest中设置的具体规则进行比对，确定是否满足过滤规则。
[0058]
步骤s220，对所述数据包进行解析操作，确定接口信息。
[0059]
在本实施例中，其中，获取到这些数据包之后，可以对这些数据包进行解析操作，从而确定这些数据包所分别对应的各接口的接口信息，例如但不限于，每个接口的url对应属于什么类型的接口(例如get，post,delete，put等请求的接口类型)、每个接口请求的输入参数和响应信息中的响应参数，如响应状态码，请求对象以及接口输入参数中包括哪些类型、每种类型的参数是否为必须参数和输入参数的字段类型等。
[0060]
在一些可能的实现方式中，步骤s220，对所述数据包进行解析操作，确定接口信息，具体可以包括：
[0061]
根据所述数据包头部确定所述数据包对应的请求类型；
[0062]
按照预设的不同请求类型所对应的不同解析规则，对所述数据包进行解析操作，确定所述接口信息。
[0063]
其中，常见的请求类型可以分为get请求，post请求,delete请求和put请求等，其解析操作可以如下：
[0064]
具体的，进行解析操作时，可以根据请求的类型(例如get，post,delete，put等)来进行区分解析，下面对一些不同类型的常见接口请求的数据包进行解析的过程进行简要说明：
[0065]
(1)get请求，一般用于获取数据，形如：https://host:port/path？xxx＝aaa&ooo＝bbb。其中，http/https指协议类型；host指服务器的ip地址或者域名；port:http指服务器的端口号，默认端口是80，如果是默认，则端口号可能会省略，如果使用了别的端口，必须指明，例如：192.168.3.111:8080，这里的8080就是端口；path指访问资源的路径，？:url里面的“？”为分割线，用来区分问号前面的是path，问号后面的是参数；url-params:问号后面的是请求参数，格式：xxx＝aaa；&为多个参数用&符号连接。
[0066]
get请求抓取后是一个url的encode编码，需要对url进行解码，解码后才能看到url请求的参数，截取url？后的参数，通过正则表达式进行多个参数的截取，比如https://host:port/path？xxx＝aaa&ooo＝bbb从中截取成xxx＝aaa、ooo＝bbb然后将参数解析成
json格式。解析完成后，将url请求地址，请求方式，header参数，以及response的信息再封装成一个json对象进行保存。
[0067]
(2)pos请求，一般用于发送数据，其请求解析方式需要根据不同的contenttype类型进行解析，具体可以包括：
[0068]
第一种：application/json：这是最常见的json格式，采用键值对(key-value)存储结构，在解析时，可以分别解析key值和value值，key值对应参数名称，value值则为参数值。
[0069]
第二种：application/x-www-form-urlencoded：浏览器的原生form表单。其中，编码类型(enctype)是指定将数据回发到服务器时浏览器使用的编码类型，包括application/x-www-form-urlencoded、multipart/form-data和text/plain三种。若post请求未设置编码类型(enctype)属性，那么最终post请求就会以application/x-www-form-urlencoded方式提交，请求中提交的数据则按照key1＝val1&key2＝val2的方式进行编码，key和val都进行了url转码，进行解码时，对key1＝val1&key2＝val2这种格式数据进行提取key和value值。若设置了enctype属性，则按照设置的enctype属性类型进行解析。对应解析方法为现有技术中常见的技术手段，此处不做过多赘述。
[0070]
第三种：multipart/form-data表单方式提示，在解析时，遍历每行数据，通过正则表达式提取表单中字段name和value。具体的，以webkitfrombondary为关键字进行提取，每三行为一条数据，并放在一个list中，然后读取list，再读取每个list的内容，将list的内容以换行符进行分割成数组data[],并且读需要对data[1],data[2]进行处理，通过正则表达式提取name＝
“”
将请求参数的key提取出来，读取data[2]的内容作为key的value重新封装成请求json，后面再对该json进行读取并重新赋值，得到一个新的请求入参，重新生成multipart/form-data的数据格式。
[0071]
第四种：text/xml:类似这种直接传的xml格式，目前可以采用sax(simple api for xml)解析或文档对象模型(document object model，dom)解析的方式进行解析。
[0072]
(3)put请求：put请求专注于update操作，比如需要更新数据，可以使用put请求方式。
[0073]
(4)delete请求：用于执行相应的删除操作，配合数据库进行相应的删除动作。
[0074]
基于如上描述不同的请求形式，从不同的请求中解析获取对应的入参和对应的响应值。
[0075]
步骤s230，根据所述接口信息和预先设置的所述接口测试脚本模板，生成所述接口测试脚本。
[0076]
在本实施例中，用户可以预先在系统中设置接口测试脚本模板，在上述确定好各个接口的接口信息后，从而可以结合各个接口的接口信息，生成测试用例。其中，在测试用例中，接口信息中的入参的字段值可以设置为预先配置的基准值。得到测试用例后，再利用测试用例和接口测试脚本模板自动生成接口测试脚本。
[0077]
在一些可能的场景中，在步骤s220之后，还可以先获取预先在系统中配置的该接口信息中各个入参的类别对应的基准值，然后进一步确定预先配置的基准值是否满足测试要求，也即确定是否满足该各个入参在接口信息中的参数要求，例如，接口信息中对入参的字段值长度，字段值类型等的要求。若满足，则将各个入参的字段值设置为基准值，得到测
试用例；若不满足，即预设的基准值不满足所有入参的参数要求，或者预设的基准值不满足部分入参的参数要求，此时可以基于每个接口不同的请求入参进行解析判断入参中的字段的类型(如字符串，整型，list，json对象)，进而根据不同类型，为不满足上述参数要求的入参随机生成不同的字段值，如手机号，身份证号，邮箱地址，工作地，金额，姓名等，都可以随机生成不一样的值，为其余部分满足上述参数要求的入参同样也随机生成不同的字段值或者采用对应的基准值。设置完成之后，得到测试用例。
[0078]
在一些可能的实现方式中，在步骤s220之后，还可以对接口信息中所指示的接口参数进行类型识别，若解析确定接口信息所指示的接口参数中，包括list类型参数，则可以对该list类型参数进行解析操作，确定所述list类型参数中包括的子参数的信息。之后，在步骤s230中，进一步根据所述接口信息、所述子参数的信息和预先设置的所述接口测试脚本模板，生成所述接口测试脚本。具体的，list类型可以是包含多个子参数链表结构的结合，子参数的信息包括，子参数的名称、类型和是否为必须参数等。确定子参数信息后，在后续生成接口测试脚本时，还需要设置子参数的字段值，具体设置过程可以参照上述入参的字段值的设置方法，此处不做重复赘述。
[0079]
需要强调的是，为进一步保证上述接口测试脚本的私密和安全性，上述接口测试脚本还可以存储于一区块链的节点中。
[0080]
本申请所指区块链是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。区块链(blockchain)，本质上是一个去中心化的数据库，是一串使用密码学方法相关联产生的数据块，每一个数据块中包含了一批次网络交易的信息，用于验证其信息的有效性(防伪)和生成下一个区块。区块链可以包括区块链底层平台、平台产品服务层以及应用服务层等。
[0081]
与现有技术相比，本申请实施例主要有以下有益效果：
[0082]
本方案中，在获取到前端调用后端的所有请求中满足预设过滤规则的数据包，可以从这些数据包中解析确定接口信息，最后根据接口信息和预设的接口测试脚本模板，自动生成接口测试脚本。即提供了一种无需手动设置接口参数，而得到接口测试脚本的方法，减少了接口测试时人工的时间成本，提高了接口测试效率。
[0083]
在一些可能的实现方式中，上述的接口测试脚本模板可以针对不同测试工具设定得到，从而在步骤s230之后，参照图3，为步骤s230之后的一个实施例示意图，该接口测试脚本的生成方法还可以包括：
[0084]
s310，将所述不同的接口测试脚本，输入所述接口测试脚本模板对应的接口测试工具中，进行接口测试。
[0085]
本实施例中，可以在本地系统中预先配置各种接口测试工具对应的接口测试脚本的模板。例如，用户基于postman的接口文档和jmeter工具的接口文档的保存格式，将这2种文档分别生成标准的templete的实例对象，并以接口文档的标准配置并在系统保存对应的postman接口测试脚本模板和jmeter的接口测试脚本模板。
[0086]
之后，在确定各个接口的接口信息后，可以监听用户对接口测试工具的选择指令，确定指定的接口测试工具以及该接口测试工具对应的接口测试脚本模板，进而根据接口测试脚本模板和接口信息，生成该接口测试工具对应的接口测试脚本。
[0087]
最后，在生成用户指定的接口测试工具对应的接口测试脚本后，可以自动将该接
口测试脚本输入该接口测试工具中，自动进行接口测试，并可以输出接口测试结果。
[0088]
与现有技术相比，本申请实施例主要有以下有益效果：
[0089]
本方案中，在获取到前端调用后端的所有请求中满足预设过滤规则的数据包，可以从这些数据包中解析确定接口信息，最后根据接口信息和预设的接口测试脚本模板，自动生成接口测试脚本，并将接口测试脚本，输入接口测试脚本模板对应的接口测试工具中，实现接口的自动测试，从而减少了接口测试时人工的时间成本，提高了接口测试效率。
[0090]
在一些可能的实现方式中，若步骤s210中获取的数据包为加密数据包，则在步骤s210之后，s220之前，参照图4，为一种接口测试脚本的生成方法的又一个实施例示意图，该接口测试脚本的生成方法还可以包括：
[0091]
s410，对所述加密数据包进行解密操作，得到解密后的所述数据包。
[0092]
本实施例中，加密数据包，可以是前端通过对称加密、非对称加密或者随机密钥加密得到的数据包。若为对称加密或者非对称加密得到的加密数据包，则在解密时，可以显示解密界面，指示用户输入解密密钥，进而进行解密，得到解密后的数据包。若为采用随机加密得到的数据包，则在进行解密之前，还需要获取请求参数中的sign参数，根据sign从前端获取解密密钥，进而进行解密，得到解密后的数据包。
[0093]
与现有技术相比，本申请实施例主要有以下有益效果：
[0094]
如果获取到的数据包为加密数据包，则可以对其进行解密，进而可以实现对加密数据包的解析，扩大方案的适用范围。
[0095]
本申请可用于众多通用或专用的计算机系统环境或配置中。例如：个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、多处理器系统、基于微处理器的系统、置顶盒、可编程的消费电子设备、网络pc、小型计算机、大型计算机、包括以上任何系统或设备的分布式计算环境等等。本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
[0096]
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机可读指令来指令相关的硬件来完成，该计算机可读指令可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，前述的存储介质可为磁碟、光盘、只读存储记忆体(read-only memory，rom)等非易失性存储介质，或随机存储记忆体(random access memory，ram)等。
[0097]
应该理解的是，虽然附图的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，其可以以其他的顺序执行。而且，附图的流程图中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，其执行顺序也不必然是依次进行，而是可以与其他步骤或者其他步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。
[0098]
具体参照图5，图5为本申请实施例提供的一种接口测试脚本的生成装置的一个结构示意图，可以包括：
[0099]
第一获取单元510，用于获取从前端调用后端的所有请求中满足预设过滤规则的数据包；
[0100]
第一解析单元520，用于对该数据包进行解析操作，确定接口信息；
[0101]
生成单元530，用于根据该接口信息和预先设置的接口测试脚本模板，生成接口测试脚本。
[0102]
在一些可能的实现方式中，具体参照图6，图6为本申请实施例提供的一种接口测试脚本的生成装置的又一个结构示意图，还可以包括：
[0103]
测试单元540，用于将该不同的接口测试脚本，输入该接口测试脚本模板对应的接口测试工具中，进行接口测试。
[0104]
在一些可能的实现方式中，具体参照图7，图7为本申请实施例提供的一种接口测试脚本的生成装置的又一个结构示意图，还可以包括：
[0105]
解密单元550，用于识别该数据包是否为加密数据包；若该数据包为加密数据包，对该加密数据包进行解密操作，得到解密后的该数据包。
[0106]
在一些可能的实现方式中，该接口测试脚本的生成装置还可以包括：
[0107]
第一识别单元，用于对该接口信息所指示的接口参数进行类型识别；
[0108]
第二解析单元，用于若该接口信息所指示的接口参数中可以包括list类型参数，则对该list类型参数进行解析操作，确定该list类型参数中可以包括的子参数的信息；
[0109]
生成单元530，具体用于根据该接口信息、该子参数的信息和预先设置的该接口测试脚本模板，生成该接口测试脚本。
[0110]
在一些可能的实现方式中，第一解析单元520，具体可以包括：
[0111]
第二识别单元，用于根据该数据包头部确定该数据包对应的请求类型；
[0112]
解析子单元，用于按照预设的不同请求类型所对应的不同解析规则，对该数据包进行解析操作，确定该接口信息。
[0113]
在一些可能的实现方式中，生成单元530，具体可以包括：
[0114]
第一生成子单元，用于利用预先配置的基准值设置该接口信息中入参的字段值，得到测试用例；
[0115]
第二生成子单元，用于利用该测试用例和该接口测试脚本模板，生成接口测试脚本。
[0116]
在一些可能的实现方式中，接口测试脚本的生成装置还可以包括：
[0117]
第二获取单元，用于获取预先配置的该接口信息中各个入参的类别所对应的基准值；
[0118]
判断单元，用于确定该基准值是否满足该各个入参中每个入参的字段值要求；
[0119]
生成单元530，具体可以包括：
[0120]
第四生成子单元，具体用于若满足，则利用预先配置的基准值设置该接口信息中入参的字段值，得到该测试用例；若不满足，则对不满足的入参随机生成对应的字段值，得到该测试用例。
[0121]
与现有技术相比，本申请实施例主要有以下有益效果：
[0122]
本方案中，接口测试脚本的生成装置在获取到前端调用后端的所有请求中满足预设过滤规则的数据包，可以从这些数据包中解析确定接口信息，最后根据接口信息和预设
的接口测试脚本模板，自动生成接口测试脚本。即提供了一种无需手动设置接口参数，而得到接口测试脚本的方法，减少了接口测试时人工的时间成本，提高了接口测试效率。
[0123]
为解决上述技术问题，本申请实施例还提供计算机设备。具体请参阅图7，图7为本实施例计算机设备基本结构框图。
[0124]
所述计算机设备8包括通过系统总线相互通信连接存储器810、处理器820、网络接口830。需要指出的是，图中仅示出了具有组件810-830的计算机设备8，但是应理解的是，并不要求实施所有示出的组件，可以替代的实施更多或者更少的组件。其中，本技术领域技术人员可以理解，这里的计算机设备是一种能够按照事先设定或存储的指令，自动进行数值计算和/或信息处理的设备，其硬件包括但不限于微处理器、专用集成电路(application specific integrated circuit，asic)、可编程门阵列(field－programmable gate array，fpga)、数字处理器(digital signal processor，dsp)、嵌入式设备等。
[0125]
所述计算机设备可以是桌上型计算机、笔记本、掌上电脑及云端服务器等计算设备。所述计算机设备可以与用户通过键盘、鼠标、遥控器、触摸板或声控设备等方式进行人机交互。
[0126]
所述存储器810至少包括一种类型的可读存储介质，所述可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，sd或dx存储器等)、随机访问存储器(ram)、静态随机访问存储器(sram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、可编程只读存储器(prom)、磁性存储器、磁盘、光盘等。在一些实施例中，所述存储器810可以是所述计算机设备8的内部存储单元，例如该计算机设备8的硬盘或内存。在另一些实施例中，所述存储器810也可以是所述计算机设备8的外部存储设备，例如该计算机设备8上配备的插接式硬盘，智能存储卡(smart media card,smc)，安全数字(secure digital,sd)卡，闪存卡(flash card)等。当然，所述存储器810还可以既包括所述计算机设备8的内部存储单元也包括其外部存储设备。本实施例中，所述存储器810通常用于存储安装于所述计算机设备8的操作系统和各类应用软件，例如前述接口测试脚本的生成方法的计算机可读指令等。此外，所述存储器810还可以用于暂时地存储已经输出或者将要输出的各类数据。
[0127]
所述处理器820在一些实施例中可以是中央处理器(central processing unit，cpu)、控制器、微控制器、微处理器、或其他数据处理芯片。该处理器820通常用于控制所述计算机设备8的总体操作。本实施例中，所述处理器820用于运行所述存储器810中存储的计算机可读指令或者处理数据，例如运行所述接口测试脚本的生成方法的计算机可读指令。
[0128]
所述网络接口830可包括无线网络接口或有线网络接口，该网络接口830通常用于在所述计算机设备8与其他电子设备之间建立通信连接。
[0129]
本申请还提供了另一种实施方式，即提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机可读指令，所述计算机可读指令可被至少一个处理器执行，以使所述至少一个处理器执行如上述的接口测试脚本的生成方法的步骤。
[0130]
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如rom/ram、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服
务器，空调器，或者网络设备等)执行本申请各个实施例所述的方法。
[0131]
显然，以上所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例，附图中给出了本申请的较佳实施例，但并不限制本申请的专利范围。本申请可以以许多不同的形式来实现，相反地，提供这些实施例的目的是使对本申请的公开内容的理解更加透彻全面。尽管参照前述实施例对本申请进行了详细的说明，对于本领域的技术人员来而言，其依然可以对前述各具体实施方式所记载的技术方案进行修改，或者对其中部分技术特征进行等效替换。凡是利用本申请说明书及附图内容所做的等效结构，直接或间接运用在其他相关的技术领域，均同理在本申请专利保护范围之内。