CN111143189A - 用于应用程序接口api测试的方法和设备 - Google Patents

Abstract

本发明提供一种用于应用程序接口API测试的方法和设备。该方法包括：根据cucumber规范确定关注restful API测试领域的业务规则的领域专用语言DSL语句；根据Blockly规范确定所述DSL语句对应的图形化的块Block，其中，所述图形化的块Block配置为在预定编辑器中能够被拖拽并且彼此组合。上述方法能够将restful API测试的业务规则根据DSL语句和Blockly规范表达为图形化的块，方便直观、简单地进行API测试。

Description

用于应用程序接口API测试的方法和设备

技术领域

本发明涉及计算机网络领域，更为具体而言，涉及一种用于应用程序接口API测试的方法和设备。

背景技术

Restful应用程序接口（Application program interface, 简称API）是一种轻量级的WEB服务，由于其简单轻量，大量应用于软件设计和实现。

Restful API的广泛使用带来了一些潜在的问题，Restful API的测试是其中的一个难题。Restful API需要在软件就绪之后，将软件作为黑盒进行测试。对于单个RestfulAPI的测试，缺乏统一、直观的测试方案，更别提对多个Restful API串联进行测试的方案。

发明内容

本发明提供一种用于应用程序接口API接口测试的方法和设备，可以根据cucumber规范定义关注Restful API测试领域的业务规则的DSL语句，并根据Blockly规范确定DSL语句对应的图形化的块Block，从而方便通过拖拽图形化的块进行restful API的测试，便于对Restful API进行统一、直观的测试。

第一方面，本发明实施方式提供一种用于应用程序接口API测试的数据处理方法，包括：根据cucumber规范确定关注restful API测试领域的业务规则的领域专用语言DSL语句；根据Blockly规范确定所述DSL语句对应的图形化的块Block，其中，所述Block配置为在预定编辑器中能够被拖拽并且彼此组合。

第二方面，本发明实施方式还提供一种计算机设备，包括处理器；和存储器，用于存储计算机指令，所述计算机指令适于被所述处理器加载以执行上述第一方面所述的方法。

第三方面，本发明实施方式还提供一种计算机可读介质，其存储有计算机可读指令，所述指令适于被处理器加载以执行上述第一方面所述的方法。

第四方面，本发明实施方式还提供一种应用程序接口API测试方法，包括：接收用户对应用程序接口API测试的图形化的块Blcok的拖拽请求，其中，所述块Block对应领域专用语言DSL的语句片段；

根据Blockly规范将所述拖拽请求对应的图形化的块转换为DSL脚本；将转换后的DSL脚本根据cucumber规范执行以完成对restful API的测试。

第五方面，本发明实施方式还提供一种计算机设备，包括处理器；和存储器，用于存储计算机指令，所述计算机指令适于被所述处理器加载以执行上述第四方面所述的方法。

第六方面，本发明实施方式还提供一种计算机可读介质，其存储有计算机可读指令，所述指令适于被处理器加载以执行上述第四方面所述的方法。

第七方面，本发明实施方式还提供一种应用程序接口API测试方法，包括：提供用于应用程序接口API测试的图形化的块Block；接收用户对所述图形化的块Blcok的拖拽请求，其中，所述块Block对应领域专用语言DSL的语句片段；根据Blockly规范将所述拖拽请求对应的图形化的块转换为DSL脚本；将转换后的DSL脚本根据cucumber规范执行以完成对restful API的测试。

第八方面，本发明实施方式还提供一种计算机设备，包括处理器；和存储器，用于存储计算机指令，所述计算机指令适于被所述处理器加载以执行上述第七方面所述的方法。

第九方面，本发明实施方式还提供一种计算机可读介质，其存储有计算机可读指令，所述指令适于被处理器加载以执行上述第七方面所述的方法。

附图说明

图1是根据本发明实施例的用于应用程序接口API测试的处理方法的流程示意图。

图2是根据本发明实施例的图形化的块的示意图。

图3示出了根据本发明实施例的应用程序接口API测试方法的流程示意图。

图4示出了根据本发明实施方式的应用程序接口API测试方法的流程示意图。

图5是根据本发明实施例的计算机设备的结构示意图。

具体实施方式

现参考示例性的实施方式详细描述本发明，一些实施例图示在附图中。以下描述参考附图进行，除非另有表示，否则在不同附图中的相同数字代表相同或类似的元件。以下示例性实施方式中描述的方案不代表本发明的所有方案。相反，这些方案仅是所附权利要求中涉及的本发明的各个方面的系统和方法的例子。

下面对本申请中将会使用的术语进行简要的解释和说明，需要说明的是，这些解释或说明仅是为了便于理解本发明的方案，而不应理解为是对这些术语的限定，这些术语的含义仍然在本领域通常的含义之内。

Restful API，可以指具有Rest风格的应用程序或软件设计。其中，Rest，全称为Representational State Transfer，描述了一个架构样式的网络系统，例如，web 应用程序。REST 可以指一组架构约束条件和原则，满足这些约束条件和原则的应用程序或设计就可以认为是 Restful。

Cucumber，是一个能够理解用普通语言描述的测试用例的支持行为驱动开发（Behavior Driven Development, BDD）的自动化测试工具，用Ruby编写，支持Java和·Net等多种开发语言。

DSL，全称为Domain specific language，领域专用语言，其基本思想是“求专不求全”，不像通用目的语言那样,目标范围能够涵盖一切软件问题，而是专门针对某一特定领域的计算机语言。

参见图1，图1是根据本发明实施例的用于应用程序接口API测试的处理方法的流程示意图，该处理方法可用于设计应用程序接口API的测试软件。

该处理方法100可包括：步骤110和步骤120。接下来结合具体的例子对这些步骤进行说明。

步骤110，根据cucumber规范确定关注restful API测试领域的业务规则的领域专用语言DSL语句片段。

如上所述，DSL作为一种针对特定领域的计算机语言。通过DSL对restful API进行程序实现，首先需要确定该特定领域的业务规则。对于Restful API，其是基于超文本传输协议（Hyper Text Transfer Protocol，HTTP）。

在一些实施例中，restful API测试领域的业务规则可以包括对单个restful API测试的业务规则。对单个的restful API测试的业务规则，具体而言，可包括多个方面，一个方面可以由对应的一个DSL语句片段关注。在一些实施例中，DSL语句片段可以是DSL脚本的一个动作Action行，以诸如given、when、and和then等动作引导词开头的行。

对于单个restful API测试的业务规则可包括下述两个以上方面的组合：指定待测试的restful API的超文本传输协议HTTP请求的方法；指定HTTP请求的统一资源定位符URL；指定请求的参数；指定请求负载；指定请求头信息；校验restful API被调用之后的HTTP请求的响应码；校验restful API被调用之后的HTTP请求的响应头；校验restful API被调用之后的HTTP请求的响应负载。需要说明的是，restful API测试领域的业务规则并不限于上述的方面，根据具体测试的需要，还可以确定其他的业务规则。对于单个restfulAPI的测试，需要确保测试的数据符合预定要求，否则测试查询时可能会查不到相应的数据。

restful API是构建在HTTP协议基础之上，根据HTTP的规范，包含两部分，请求部分和应答部分。

对于HTTP请求，必须指定：

请求的方法，比如GET/POST/PUT/或者其他扩展方式；

请求的URL，是全球统一的应用于资源请求的资源标识符，用于标识restful API的位置，例如HTTP://www.ebaocloud.com/api/mock；

请求的头header，本质是key-value键值对，在HTTP规范中，预定义了部分header，但是restful API的实现过程中可以自行定义一些header，例如，token，一个请求可以支持多个header；

请求的参数，本质也是key-value键值对，可以出现在路径上，比如

，上述路径中定义了两个参数，其中， name参数的值为foo，version参数的值为1；对于某些请求method，参数将被编码到请求负载(body)中；

请求的负载，存放于HTTP协议的请求体body中，对于restful API一般是json形式的文本，代表了业务数据。

对于应答部分，一般包括:

响应码，通常为一个数字，代表这个请求的响应状态，比如200代表响应成功，404代表资源(url)未找到，500代表服务端内部错误等；

响应头header，如同请求的header，本质是键值对，服务器端实现可以放置多个应答header；

响应负载，在HTTP协议的响应体body中，对于restful API，一般是json形式的文本，代表了业务数据。

Restful API 被调用之后，需要校验HTTP响应码、响应头和响应负载。也就是说，服务端提供了restful API，客户端来调用这个restful API，需要检查当前调用的结果是否符合测试者的预期，例如，响应码是否一致，特定的响应头header是否存在或者其值是否和期望的值相符，响应负载中的内容是否含有关心的业务数据或者和与期望的值相符。

在另外一些实施例中，restful API测试领域的业务规则可包括对多个关联的restful API测试的业务规则。对多个关联的restful API测试的业务规则，具体而言，可包括下述多个方面：指定待测试的restful API的超文本传输协议HTTP请求的方法；指定HTTP请求的统一资源定位符URL；指定请求的参数；指定请求负载；指定请求头信息；校验restful API被调用之后的HTTP请求的响应码；校验restful API被调用之后的HTTP请求的响应头；校验restful API被调用之后的HTTP请求的响应负载；获取restful API被调用之后的响应体的部分数据；设置restful API被调用之后的响应体的部分数据以用于与所述restful API关联的下一个restful API的测试。需要说明的是，restful API测试领域的业务规则并不限于上述的方面，根据具体测试的需要，还可以确定其他的业务规则。其中，指定待测试的restful API的超文本传输协议HTTP请求的方法、请求的统一资源定位符URL、请求的参数、请求负载和请求头信息；校验restful API被调用之后的HTTP响应码、响应头和响应负载，与上面用于单个restful API测试领域的业务规则类似，在此不再赘述。

获取restful API被调用之后的响应体的预定部分数据并设置以用于与所述restful API关联的下一个restful API的测试，具体而言，可包括：在restful API被调用之后，获取响应体中的预定的部分数据（例如，文本形式的数据），确定该部分数据是否满足预定的期望值；提取响应体中的该部分数据并存储，以用于本次restful API测试关联的下一个restful API的测试。例如，定义一个测试流程，测试用户的创建、查询和删除，对应三个restful API。按测试场景组合API进行测试，就可以采用删除-创建-查询-删除-查询测试流程，从而保证是可以重复运行，这样对测试环境的数据准备或者其他先决条件的依赖较少。继续上述的例子，在这个测试流程中，创建了user，在响应的负载中，包含了新建user的id，而查询API是正是采用id作为参数来查询的，因此,我们需要从创建API的响应body中提取用户id，放在测试场景的上下文(可以称为变量池)中，下一个api测试(用户查询)时,去引用这个变量，从而获取到要查询的用户id。继续上述的例子，如果创建之后的查询是成功的，证明创建是有效的，删除操作如果成功，后面的查询应该查不到该用户，从而证明删除操作是有效的。

根据cucumber规范确定restful API测试的业务规则对应的DSL语句片段，其中，业务规则可包括多个方面，对应多个DSL语句片段，一个DSL语句片段关注业务规则的一个方面。一些实施例中，DSL语句片段可以是DSL脚本的一个动作Action行。

一些实施例中，DSL语句片段关注业务规则的下述多个（例如，大于或等于2）方面的组合：指定超文本传输协议HTTP请求的方法；指定超文本传输协议HTTP 请求的统一资源定位符URL；指定超文本传输协议HTTP请求头的名称和值；指定restful API请求的参数的名称和值；指定超文本传输协议HTTP请求的请求负载；校验超文本传输协议HTTP请求的响应码；校验超文本传输协议HTTP请求的响应头是否存在或者是否与期望的值匹配。

在另外一些实施例中，DSL语句片段关注业务规则的下述多个方面：指定超文本传输协议HTTP请求的方法；指定超文本传输协议HTTP 请求的统一资源定位符URL；指定超文本传输协议HTTP请求头的名称和值；指定restful API请求的参数的名称和值；指定超文本传输协议HTTP请求的请求负载；校验超文本传输协议HTTP请求的响应码；校验超文本传输协议HTTP请求的响应头是否存在或者是否与期望的值匹配；校验超文本传输协议HTTP请求的响应体中的部分数据是否满足预定期望值；提取所述响应体中的部分数据并存储。

下面以基于DSL的测试例子说明DSL语句片段和对应的业务规则的方面。

Feature: Bose Api test

定义测试流程，以Feature:关键字开头，流程名称是Bose Api test，这个测试流程测试了配置中心服务的profile的删除、创建和查询。

Scenario: remove the profile shawn-test-001

定义了一个场景，场景名称是 remove the profile shawn-test-001

Given variable apiBase with default http://172.25.12.166:7101

Given variable profile with default shawn-test-001

该DSL语句片段用于给两个变量赋予缺省值，变量的apiBase的默认值是http://172.25.12.166:7101，变量的 profile 的默认值是shawn-test-001，当这个DSL脚本被Cucumber引擎执行时，可以传递全局变量给执行引擎，如果没有定义特定的变量，就用DSL中定义的默认值。

When test post for ${apiBase}/configs/clear

该DSL语句片段定义要测试的url和http方法名称，其中url是${apiBase}/configs/clear ,${}表示到变量池中解析。http方法在这里是post。

And param profile is ${profile}

And param application is public

And param label is snapshot

该DSL语句片段添加请求的参数，其中参数名称是profile, 值为${profile}，即到变量池中获取profile变量。

Then check response

该DSL语句片段向服务器端发起请求。

And response status is 200

该DSL语句片段验证响应码是200, 即成功，如果响应码不是200, 该测试流程报错。

Scenario: add config to profile shawn-test-001

Given variable apiBase with default http://172.25.12.166:7101

Given variable profile with default shawn-test-001

When test post for ${apiBase}/configs/update

And param profile is ${profile}

And param application is public

And param label is snapshot

And param key is test

And param value is 1111

Then check response

And response status is 200

定义测试场景，向配置中心添加配置。

Scenario: get config of profile shawn-test-001

Given variable apiBase with default http://172.25.12.166:7101

Given variable profile with default shawn-test-001

定义测试场景， 获取上一过程添加的配置。

When test get for ${apiBase}/configs

And param profile is ${profile}

And param application is public

And param label is snapshot

Then check response

And response status is 200

And response json data.test is 1111

验证响应的负载中, json的path data.test对应的值是1111。如果不是1111, 那么测试将在此步骤报错。

Scenario: clean the profile shawn-test-001

Given variable apiBase with default http://172.25.12.166:7101

Given variable profile with default shawn-test-001

When test post for ${apiBase}/configs/remove

And param profile is ${profile}

And param application is public

And param label is snapshot

And param key is test

Then check response

And response status is 200

移除前述场景创建的数据，恢复测试环境的数据。

在一些实施例中，根据cucumber规范确定关注restful API测试领域的业务规则的领域专用语言DSL语句片段包括：根据cucumber规范确定关注restful API测试领域的业务规则的多个方面对应的多个DSL语句片段，一个方面对应一个DSL语句片段，该一个DSL语句片段可以是一个动作Action行。

步骤120，根据Blockly规范确定所述DSL语句片段对应的Block。

在本发明的一些实施例中，根据Blockly规范确定DSL语句对应的block可包括根据Blockly规范将DSL语句中的一个DSL语句片段（例如，一个动作Action行）转换为一个block，一个DSL语句片段对应一个block。通过推拽不同的block，可以获得所述不同的block对应的DSL语句片段，组合后可以交给cucumber工具执行，通过块的拖拽即可简单、直观地进行restful API测试。

而且，通过关注多个关联的restful API测试领域的业务规则，可以简单、直观地进行多个串联的restful API的测试。

DSL语句片段对应的块Block，为图形化的块，可以在预定编辑器的画布界面上进行拖拽。每个块具有描述该块的用于拖拽的元素的可见文本部分和可输入部分，以及该块的上下左右衔接的设置。

如图2所示，在预定的编辑器中，在画布界面通过块的上下左右衔接设置可以将不同的块进行组合，从而完成各个不同块的图形化的组合，无需代码编写，即可简单、直观地完成restful API的测试，降低了根据DSL进行restful API测试的应用难度。而且，图形化的块在被拖拽到画布界面上时能够将其可输入部分呈现在画布的交互界面上，接收用户的输入，改善了应用图形化的块进行restful API测试的灵活性。

在拖拽的界面上，一个块Blcok可对应一个Block的实例，例如，

Given variable apiBase with default http://172.25.12.166:7101

除开引导词Given，变化的部分是可输入部分，这些由用户自行填写，用户可填写apiBase与http://172.25.12.166:7101 ；其他的部分，实际上是可见文本部分，这部分是固定不变的，是用户没法改变的，主要作用是让用户了解该Block的语义，可见文本部分并不需要和DSL 行的文本对应，可见文本部分仅仅用来辅助用户了解块的含义。

参见图3，图3示出了根据本发明实施例的应用程序接口API测试方法的流程示意图，该方法300可包括：步骤310、步骤320和330，下面结合具体的例子对上述步骤进行说明。

步骤S310，接收用户对应用程序接口API测试的图形化的块Blcok的拖拽请求，其中，所述Block对应领域专用语言DSL的语句片段。

DSL是针对特定领域的语言。在本发明实施例中，DSL是针对restful API测试领域的。

在本发明的一些实施例中，步骤310中的图形化的块可以根据图1所示的方法产生的图形化的块。在本发明的一些实施例中，步骤310中的图形化的块可以是根据不同于图1所示方法的其他方法产生的图形化的块。

在本发明的一些实施例中，restful API测试领域的业务规则可以包括对单个restful API测试的业务规则。对单个的restful API测试的业务规则，具体而言，可包括下述多个方面：指定待测试的restful API的超文本传输协议HTTP请求的方法、请求的统一资源定位符（Universal resource Locator, URL)、请求参数、请求负载和请求头信息；校验restful API被调用过之后的HTTP响应码、响应头和响应负载。需要说明的是，restful API测试领域的业务规则并不限于上述的方面，根据具体测试的需要，还可以确定其他的业务规则。对于单个restful API的测试，需要确保测试的数据符合预定要求，否则测试查询时可能会查不到相应的数据。

restful API是构建在HTTP协议基础之上，根据HTTP的规范，包含两部分，请求部分和应答部分。

对于HTTP请求，必须指定：请求的方法，请求的URL，请求的头header，请求的参数，请求的负载。

对于应答部分，一般包括:响应码，响应头header，响应负载。

Restful API 被调用之后，需要校验HTTP响应码、响应头和响应负载。也就是说，服务端提供了restful API，客户端来调用这个restful API，需要检查当前调用的结果是否符合测试者的预期，例如，响应码是否一致，特定的响应header是否存在或者其值是否和期望的值相符，响应负载中的内容是否含有关心的业务数据或者和与期望的值相符。

在另外一些实施例中，restful API测试领域的业务规则可包括对多个关联的restful API测试的业务规则。对多个关联的restful API测试的业务规则，具体而言，可包括下述多个方面：指定待测试的restful API的超文本传输协议HTTP请求的方法、请求的统一资源定位符URL、请求的参数、请求负载和请求头信息；校验restful API被调用之后的HTTP响应码、响应头和响应负载；获取restful API被调用之后的响应体的预定消息并设置以用于与所述restful API关联的下一个restful API的测试。需要说明的是，restful API测试领域的业务规则并不限于上述的方面，根据具体测试的需要，还可以确定其他的业务规则。其中，指定待测试的restful API的超文本传输协议HTTP请求的方法、请求的统一资源定位符URL、请求的参数、请求负载和请求头信息；校验restful API被调用之后的HTTP响应码、响应头和响应负载，与上面用于单个restful API测试领域的业务规则类似，在此不再赘述。

获取restful API被调用之后的响应体的预定消息并设置以用于与所述restfulAPI关联的下一个restful API的测试，具体而言，可包括：在restful API被调用之后，获取响应体中的预定的部分文本，确定该部分文本是否满足预定的期望值；提取响应体中的该部分文本数据并存储，以用于本次restful API测试关联的下一个restful API的测试。例如，定义一个测试流程，测试用户的创建、查询和删除，对应三个restful API。按测试场景组合API进行测试,就可以采用删除-创建-查询-删除-查询测试流程，从而保证是可以重复运行，这样对测试环境的数据准备或者其他先决条件的依赖较少。继续上述的例子，在这个测试流程中，创建了user，在响应的负载中，包含了新建user的id，而查询API是正是采用id作为参数来查询的，因此,我们需要从创建API的响应body中提取用户id，放在测试场景的上下文(可以称为变量池)中，下一个api测试(用户查询)时,去引用这个变量，从而获取到要查询的用户id。继续上述的例子,如果创建之后的查询是成功的，证明创建是有效的，删除操作如果成功,后面的查询应该查不到该用户,从而证明删除操作是有效的。

在一些实施例中，restful API测试领域的业务规则可包括多个方面，一个DSL语句片段关注restful测试领域的业务规则的一个方面。在一种具体的例子中，所述多个方面为：

所述多个方面包括：

指定待测试的restful API的超文本传输协议HTTP请求的方法；

指定HTTP请求的统一资源定位符URL；

指定请求的参数；

指定请求负载；

指定请求头信息；

校验restful API被调用之后的HTTP请求的响应码；

校验restful API被调用之后的HTTP请求的响应头；

校验restful API被调用之后的HTTP请求的响应负载；

获取restful API被调用之后的响应体的部分数据；

设置restful API被调用之后的响应体的部分数据以用于与所述restful API关联的下一个restful API的测试。

一些实施例中，步骤S310可包括：接收用于对API测试的一个或多个图形化块的拖拽请求，其中，一个图形化的块对应一个DSL语句片段，不同的块对应不同的DSL语句片段。在一种具体的实施例中，DSL语句片段是一个动作Action行。

一种图形化的块的编辑界面可以如图2所示。图2的左侧为工具栏，其中，包括各种图形的块，右侧为画布界面。接收用户对API测试的图形化的块的拖拽请求可包括在预定编辑器中的交互界面，接收用户的API测试的图形化的块的拖拽请求。在图形化的块被拖拽到该交互界面的画布中时，将产生该块在该交互界面的画布中的布局描述数据和该块对应的DSL语句片段两份数据，其中，布局描述数据可用于重现画布和图形化的块的布局，DSL语句片段是该图形化的块对应的DSL脚本。该块的DSL语句片段可以根据Blockly规范通过翻译函数转换得到，也就是说，根据bockly规范将所述拖拽请求对应的图形化的块转换为DSL脚本包括：根据Blockly规范通过翻译函数将拖拽请求对应的图形化的块转换为DSL语句片段。翻译函数是将图形化的块转换为DSL的工具，该翻译函数的结果是一个符合语法要求的DSL行。在画布界面上拖拽图形化的块时，在图形化的块的预定区域呈现可输入部分，接收用户的输入。

步骤320，根据Blockly规范将所述拖拽请求对应的图形化的块转换为DSL脚本。

在本发明的实施例中，图形化的块包括可输入部分和可见文本部分，以及上下左右衔接的设置。

根据blockly规范将图形化的block转换为DSL语句可包括：根据blockly规范，调用block的API来将图形化的块转换为DSL片段（例如，一行），一个图形化的块通过该块的翻译函数翻译成对应的DSL片段，多个图形化的块，通过这些块之间的上下左右的衔接设置进行组合，形成多个DSL语句片段的组合，得到完整的DSL脚本。

每个块可对应于DSL脚本的每一行，比如说

Given variable apiBase with default http://172.25.12.166:7101

Given variable profile with default shawn-test-001

上述DSL语句对应于同一个Block的定义,但是在拖拽的界面上，是两个Block的实例。除开引导词Given，变化的部分是可输入部分，这些由用户自行填写，用户可能填写apiBase与http://172.25.12.166:7101 或者用户填写 profile 和shawn-test-001；其他的部分，实际上是可见文本部分,这部分是固定不变的，是用户没法改变，主要作用是让用户了解该Block的语义。可见文本部分并不需要和DSL 行的文本对应，可见文本仅仅用来辅助用户了解块的含义。

当处理任意图形时，将调用该块的翻译函数来翻译成特定的DSL语句片段。其中，翻译函数的结果是一个正确的，符合要求的DSL 行。所有的Block块都正确翻译了DSL行，那么就最终得到了完整的DSL脚本。

在一些实施例中，图形化的块的拖拽请求包括对多个图形化的块的拖拽请求，所述方法还包括：将所述拖拽请求对应的多个图形化的块，根据各图形化的块的上下左右衔接的设置，进行组合，得到多个DSL语句片段，作为DSL脚本。

步骤330，将转换后的DSL语句根据cucumber规范执行以完成对restful API的测试。

通过步骤320转换得到的完整的DSL脚本可以根据cucumber规范执行，从而完成对restful API的图形化测试。

DSL语句片段对应的块Block，为图形化的块，可以在编辑器的画布界面上进行拖拽。每个块具有描述该快的用于拖拽的元素的可见文本部分和可输入部分，以及该块的上下左右衔接的设置。通过块的上下左右衔接的设置，可完成各个不同块的图形化的组合，无需代码编写，即可完成restful API的测试，辅助了基于DSL的代码编写，降低了采用DSL实现相关功能处理的技术难度。

参见图4，图4示出了根据本发明实施方式的应用程序接口API测试方法的流程示意图，该方法400可包括：步骤410、步骤420、步骤430和步骤440，接下来结合具体的实施例对上述步骤进行说明。

步骤S410，提供用于应用程序接口API测试的图形化的块Block。

在本发明的一些实施例中，步骤410中，提供的用于API测试的图形化的块可以是根据图1所示的方法产生的图形化的块。在另外一些实施例中，步骤410中提供的用于API测试的图形化的块可以是根据其他方法产生的图形化的块。

在本发明的一些实施例中，步骤410可包括：根据cucumber规范确定关注restfulAPI测试领域的业务规则的领域专用语言DSL语句片段；根据Blockly规范将所述DSL语句片段转换为图形化的块Block。关于这些步骤的具体说明可参考关于图1的相关描述，在此不再赘述。

在本发明的一些实施例中，步骤410可包括：在预定的编辑器中，部署restful API测试的图形化的块，例如，可以部署restful API测试的通用版的图形化的块，也可以部署restful API测试的包含特定图形化的块的定制版的图形化的块。

在本发明的一些实施例中，通过DSL语句片段关注restful API测试领域的业务规则，所述业务规则可包括多个方面，例如，大于或等于2个方面。一个DSL语句片段关于业务规则的一个方面。

在本发明的一些实施例中，根据cucumber规范确定关注restful API测试领域的业务规则的领域专用语言DSL语句片段包括：根据cucumber规范确定关注restful API测试领域的业务规则的多个方面对应的多个DSL语句片段，每个方面分别对应一个DSL语句片段。

在本发明的一些实施例中，DSL语句片段可以是一个DSL的动作Action行。在DSL语句片段为DSL的动作Action行的情况下，根据Blockly规范将所述DSL语句片段转换为图形化的块Block可包括：根据Blockly规范将一个DSL的动作Action行转换为一个图形化的块Block。

在本发明的一些实施例中，在对单个restful API进行测试的场景下，restfulAPI测试领域的业务规则的多个方面可包括下述的两个或更多个方面的组合：指定待测试的restful API的超文本传输协议HTTP请求的方法；指定HTTP请求的统一资源定位符URL；指定请求的参数；指定请求负载；指定请求头信息；校验restful API被调用之后的HTTP请求的响应码；校验restful API被调用之后的HTTP请求的响应头；校验restful API被调用之后的HTTP请求的响应负载。在一些实施例中，restful API测试领域的业务规则的多个方面为上面列出的所有方面。

在本发明的一些实施例中，在对多个连续的restful API进行测试的场景中，restful API测试领域的业务规则的多个方面包括下述两个或更多个方面的组合：指定待测试的restful API的超文本传输协议HTTP请求的方法；指定HTTP请求的统一资源定位符URL；指定请求的参数；指定请求负载；指定请求头信息；校验restful API被调用之后的HTTP请求的响应码；校验restful API被调用之后的HTTP请求的响应头；校验restful API被调用之后的HTTP请求的响应负载；

获取restful API被调用之后的响应体的部分数据；设置restful API被调用之后的响应体的部分数据以用于与所述restful API关联的下一个restful API的测试。在本发明的一些实施例中，多个连续的restful API测试的业务规则包括上面列出的所有方面。

在本发明的一些实施方式中，图形化的块可包括可输入部分和可见文本部分，以及上下左右衔接的设置。

步骤420，接收用户对所述图形化的块Blcok的拖拽请求，其中，所述块Block对应领域专用语言DSL的语句片段。

在本发明的一些实施例中，步骤420接收用户对图形化的块的拖拽请求可包括在预定编辑器的交互界面，接收用户对API测试的图形化的块的拖拽请求。其中，预定的编辑器的交互界面可以是如图2所示的交互界面。该预定编辑器可包括多个图形化的块，每个块都可以进行拖拽操作。在该编辑器的交互界面中，存在编辑界面，在该编辑界面中，可以对一个图形化的块进行多次拖拽。在一些实施例中，还可以对组合的图形化的块进行整体拖拽。

在本发明的一些实施例中，在执行步骤420的同时，还可以包括：在图形化的块被拖拽到预定编辑器的交互界面的画布中时，产生该图形化的块在该交互界面的画布中的布局描述数据和图形化的块对应的DSL语句片段。也就是说，在图形化的块在交互界面的画布中拖拽时，同时产生两份数据，一份数据为布局描述数据，用于描述图形化的块在画布中的位置等信息，另一份数据为DSL语句片段，用于产生对应的DSL脚本。

如上所述，图形化的块包括可输入部分和可见文本部分，以及上下左右衔接的设置。在本发明的一些实施例中，本发明的方法还可包括：在画布界面上拖拽图形化的块时，在图形化的块的预定区域呈现所述可输入部分，接收用户的输入。在本发明的一些实施例中，图形化的块的拖拽请求可包括对多个图形化的块的拖拽请求，在对多个图形化的块进行拖拽的情形下，本发明的方法可包括：将拖拽请求对应的多个图形化的块，根据各图形化的块的上下左右衔接的设置，进行组合。

步骤430，根据Blockly规范将所述拖拽请求对应的图形化的块转换为DSL脚本。

在本发明的一些实施例中，步骤430根据Blockly规范将所述拖拽请求对应的图形化的块转换为DSL脚本可包括：根据Blockly规范通过翻译函数将所述拖拽请求对应的图形化的块转换为DSL语句片段。在一些实施例中，图形化的块可包括两个或更多个图形化的块。这些图形化的块分别通过对应的翻译函数翻译，得到多个DSL语句片段，形成DSL测试脚本。

步骤440，将转换后的DSL脚本根据cucumber规范执行以完成对restful API的测试。

在本发明的一些实施例中，转换后的DSL脚本，例如，可包括多个DSL语句片段。在一些实施例中，转换后的DSL脚本可以是对一个restful API测试的DSL脚本，在另外一些实施例中，转换后的DSL脚本是对多个关联的restful API测试的DSL脚本。根据cucumber规范执行转换后的DSL脚本，完成对一个restful API或多个关联的restful API的测试。

本发明实施方式提供的restful API测试方法，根据Blockly规范将restful API测试的业务规则关注的DSL语句片段转换为图形化的块，方便用户利用预定编辑器拖拽图形的块，进行组合，通过翻译函数形成DSL脚本进行restful API的测试。通过图形化的拖拽即可完成restful API的测试，简单直观，而且形成DSL的图形化辅助测试方案，降低了采用DSL实现测试处理的技术难度。

本发明实施方式还提供一种计算机设备。如图5所示，该计算机设备500可包括处理器521、输入/输出（I/O）设备522、存储器523、数据库524和显示器525。

处理器521可为一个或多个已知的处理装置，其可以加载存储器523中存储的用于实现上述方法的计算机指令以使计算机设备执行上述的方法。

I/O设备522可被配置以允许数据被接收和/或传输。I/O设备522可包括一个或多个数字和/或模拟通信设备，其允许计算机设备500与其他机器和设备通信。计算机设备500还可包括一个或多个数据库524，或通过网络与一个或多个数据库524通信连接。例如，数据库524可以是适于进行上述所描述的方法的关联数据处理的任意合适的数据库。

显示器525可包括显示屏，其可用于显示输入/输出设备522的输出结果以及数据处理过程中的中间结果。

本发明还提供一种计算机可读的存储介质，其上存储有计算机指令，所述计算机指令被处理器执行时实现上面所描述的用于应用程序接口API测试的方法。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本发明可借助软件结合硬件平台的方式来实现。基于这样的理解，本发明的技术方案对背景技术做出贡献的全部或者部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，智能手机或者网络设备等）执行本发明各个实施例或者实施例的某些部分所述的方法。

本发明说明书中使用的术语和措辞仅仅为了举例说明，并不意味构成限定。本领域技术人员应当理解，在不脱离所公开的实施方式的基本原理的前提下，对上述实施方式中的各细节可进行各种变化。因此，本发明的范围只由权利要求确定，在权利要求中，除非另有说明，所有的术语应按最宽泛合理的意思进行理解。

Claims (12)

1.一种用于应用程序接口API测试的数据处理方法，其特征在于，包括：

根据cucumber规范确定关注restful API测试领域的业务规则的领域专用语言DSL语句片段；

根据Blockly规范将所述DSL语句片段转换为图形化的块Block，其中，所述Block配置为在预定编辑器中能够被拖拽并且彼此组合。

2.根据权利要求1所述的方法，其特征在于，所述块Block包括用于拖拽的元素的可见文本部分和可输入部分，以及上下左右衔接设置。

3.根据权利要求1所述的方法，其特征在于，所述restful API测试领域的业务规则包括多个方面，一个方面由对应的DSL语句片段关注。

4.根据权利要求3所述的方法，其特征在于，所述多个方面包括下述两个以上方面的组合：

指定待测试的restful API的超文本传输协议HTTP请求的方法；

指定HTTP请求的统一资源定位符URL；

指定请求的参数；

指定请求负载；

指定请求头信息；

校验restful API被调用之后的HTTP请求的响应码；

校验restful API被调用之后的HTTP请求的响应头；

校验restful API被调用之后的HTTP请求的响应负载。

5.根据权利要求1所述的方法，其特征在于，所述Restful API测试领域的业务规则包括多个关联的Restful API测试的业务规则，所述多个关联的restful API测试的业务规则包括：

指定待测试的restful API的超文本传输协议HTTP请求的方法；

指定HTTP请求的统一资源定位符URL；

指定请求的参数；

指定请求负载；

指定请求头信息；

校验restful API被调用之后的HTTP请求的响应码；

校验restful API被调用之后的HTTP请求的响应头；

校验restful API被调用之后的HTTP请求的响应负载；

获取restful API被调用之后的响应体的部分数据；

设置restful API被调用之后的响应体的部分数据以用于与所述restful API关联的下一个restful API的测试。

6.根据权利要求3所述的方法，其特征在于，所述DSL语句片段为DSL的动作Action行。

7.根据权利要求3所述的方法，其特征在于，所述根据cucumber规范确定关注restfulAPI测试领域的业务规则的领域专用语言DSL语句片段包括：

根据cucumber规范确定关注restful API测试领域的业务规则的多个方面对应的多个DSL语句片段。

8.根据权利要求6所述的方法，其特征在于，所述根据Blockly规范确定所述DSL语句片段对应的图形化的块Block包括：

根据Blockly规范将一个DSL的动作Action行转换为一个图形化的块Block。

9.根据权利要求2所述的方法，其特征在于，所述图形化的块Block配置为在所述预定编辑器的画布界面根据该块Block的上下左右衔接设置进行组合。

10.根据权利要求9所述的方法，其特征在于，所述图形化的块Block配置为在被拖拽到所述画布界面时将所述可输入部分呈现在交互界面上，接收用户的输入。

11.一种计算机设备，其包括：

处理器；和

存储器，用于存储计算机指令，所述计算机指令适于被所述处理器加载以执行权利要求1至10的任何一项所述的方法。

12.一种计算机可读介质，其存储有计算机可读指令，所述指令适于被处理器加载以执行权利要求1至10的任何一项所述的方法。

Images