CN109032956A - 一种接口测试方法及装置 - Google Patents

Abstract

本发明实施例公开了一种接口测试方法，包括：获取目标测试用例和目标测试用例中的预设约束条件，预设约束条件用于约束测试的结果；向待测试的应用程序编程接口API发送目标测试用例；接收待测试的API发送的目标测试结果，其中，目标测试结果为待测试的API采用目标测试用例进行测试后得到的；若在执行测试脚本的过程中确定目标测试结果满足预设约束条件，则生成API测试成功的结果。本发明实施例在发送目标测试用例之前先从测试用例中获取预设约束条件，并在接收到目标测试结果时，执行测试脚本实现用例测试结果的条件验证，无需人力判断测试用例的接口测试结果是否满足一定的条件约束，降低了接口测试中的人力运维成本。

Description

一种接口测试方法及装置

技术领域

本发明涉及计算机安全领域，尤其涉及一种接口测试方法及装置。

背景技术

随着互联网发展脚步的加快，产品项目的迭代也随之加快，需要对产品的稳定提供一定的保障。其中直接与用户接触的前端应用一般都是通过应用程序编程接口(application programming interface，API)与后台交互。

为了保证API的安全性和可靠性，接口测试非常必要，运维人员自己设计测试用例，并通过接口测试工具获取接口在运行测试用例后得到的用例测试结果，运维人员通过判断用例测试结果是否满足一定的条件约束来得到接口的可靠性。

但是，上述的接口测试的方式还存在如下问题：由于接口测试的结果需要人力去判断是否满足一定的条件约束，浪费了人力运维成本。

发明内容

本发明实施例提供了一种接口测试方法及其装置，无需人力判断测试用例的接口测试结果是否满足一定的条件约束，降低了接口测试中的人力运维成本。

本发明的第一方面提供了一种接口测试方法，包括：

获取目标测试用例和所述目标测试用例中的预设约束条件，所述预设约束条件用于约束测试的结果；

向待测试的应用程序编程接口API发送所述目标测试用例；

接收所述待测试的API发送的目标测试结果，其中，所述目标测试结果为所述待测试的API采用所述目标测试用例进行测试后得到的；

若在执行测试脚本的过程中确定所述目标测试结果满足所述预设约束条件，则生成API测试成功的结果。

在第一方面的一种可能设计中，所述预设约束条件包括：数值约束或字符串约束；

相应的，所述若在执行测试脚本的过程中确定所述目标测试结果满足所述预设约束条件，则生成API测试成功的结果包括：

若所述预设约束条件为所述数值约束且在执行测试脚本的过程中确定所述目标测试结果为第一目标数值，则生成API测试成功的结果，其中数值过滤约束用于约束测试的结果为所述第一目标数值；

若所述预设约束条件为所述字符串约束且在执行测试脚本的过程中确定所述目标测试结果为第一目标字符串，则生成API测试成功的结果，其中字符串约束用于约束测试的结果为所述第一目标字符串。

在第一方面的一种可能设计中，所述预设约束条件包括：数值过滤约束或字符串过滤约束；

相应的，所述若在执行测试脚本的过程中确定所述目标测试结果满足所述预设约束条件，则生成API测试成功的结果包括：

若所述预设约束条件为所述数值过滤约束且在执行测试脚本的过程中确定所述目标测试结果不为第二目标数值，则生成API测试成功的结果，其中数值过滤约束用于约束测试的结果不为所述第二目标数值；

若所述预设约束条件为所述字符串过滤约束且在执行测试脚本的过程中确定所述目标测试结果不为第二目标字符串，则生成API测试成功的结果，其中字符串过滤约束用于约束测试的结果不为所述第二目标字符串。

在第一方面的一种可能设计中，所述预设约束条件包括：数量约束；

相应的，所述若在执行测试脚本的过程中确定所述目标测试结果满足所述预设约束条件，则生成API测试成功的结果包括：

若所述预设约束条件为所述数量约束且在执行测试脚本的过程中确定所述目标测试结果中参数的数量为目标数量，则生成API测试成功的结果，其中所述数量约束用于约束测试的结果中参数的数量为所述目标数量。

在第一方面的一种可能设计中，所述向待测试的应用程序编程接口API发送所述目标测试用例之前还包括：

接收所述API发送的验证信息，所述验证信息中携带有第一字符信息；

识别所述验证信息中的第二字符信息；

向所述API发送所述第二字符信息；

接收所述API在所述第二字符信息与所述第一字符信息相同时发送的授权认证。

本发明的第二方面提供了一种接口测试装置，包括：

获取模块，用于获取目标测试用例和所述目标测试用例中的预设约束条件，所述预设约束条件用于约束测试的结果；

第一发送模块，用于向应用程序编程接口API发送所述获取模块获取的所述目标测试用例；

第一接收模块，用于接收所述待测试的API发送的目标测试结果，其中，所述目标测试结果为所述待测试的API采用所述第一发送模块发送的所述目标测试用例进行测试后得到的；

第一处理模块，用于若在执行测试脚本的过程中确定所述第一接收模块接收到的所述目标测试结果满足所述预设约束条件，则生成API测试成功的结果。

在第二方面的一种可能设计中，所述预设约束条件包括：数值约束或字符串约束；

相应的，所述第一处理模块，用于若所述预设约束条件为所述数值约束且在执行测试脚本的过程中确定所述第一接收模块接收的所述目标测试结果为第一目标数值，则生成API测试成功的结果，其中数值过滤约束用于约束测试的结果为所述第一目标数值；

若所述预设约束条件为所述字符串约束且在执行测试脚本的过程中确定所述第一接收模块接收的所述目标测试结果为第一目标字符串，则生成API测试成功的结果，其中字符串约束用于约束测试的结果为所述第一目标字符串。

在第二方面的一种可能设计中，所述预设约束条件包括：数值过滤约束或字符串过滤约束；

相应的，所述第一处理模块，用于若所述预设约束条件为所述数值过滤约束且在执行测试脚本的过程中确定所述第一接收模块接收的所述目标测试结果不为第二目标数值，则生成API测试成功的结果，其中数值过滤约束用于约束测试的结果不为所述第二目标数值；

若所述预设约束条件为所述字符串过滤约束且在执行测试脚本的过程中确定所述第一接收模块接收的所述目标测试结果不为第二目标字符串，则生成API测试成功的结果，其中字符串过滤约束用于约束测试的结果不为所述第二目标字符串。

在第二方面的一种可能设计中，所述预设约束条件包括：数量约束；

相应的，所述第一处理模块，用于若所述预设约束条件为所述数量约束且在执行测试脚本的过程中确定所述第一接收模块接收的所述目标测试结果中参数的数量为目标数量，则生成API测试成功的结果，其中所述数量约束用于约束测试的结果中参数的数量为所述目标数量。

在第二方面的一种可能设计中，所述装置还包括：

第二接收模块，用于接收所述API发送的验证信息，所述验证信息中携带有第一字符信息；

第二处理模块，用于识别所述第二接收模块接收的所述验证信息中的第二字符信息；

第二发送模块，用于向所述API发送所述第二处理模块处理得到的所述第二字符信息；

第三接收模块，用于接收所述API在所述第二字符信息与所述第一字符信息相同时发送的授权认证。

本发明的第三方面提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述各方面所述的方法。

从以上技术方案可以看出，本发明实施例具有以下优点：

本发明实施例中，提供了一种接口测试方法，首先获取目标测试用例和所述目标测试用例中的预设约束条件，所述预设约束条件用于约束测试的结果；然后向待测试的应用程序编程接口API发送所述目标测试用例；然后接收所述待测试的API发送的目标测试结果，其中，所述目标测试结果为所述待测试的API采用所述目标测试用例进行测试后得到的；最后若在执行测试脚本的过程中确定所述目标测试结果满足所述预设约束条件，则生成API测试成功的结果。通过上述方式，在发送目标测试用例之前先从测试用例中获取预设约束条件，并在接收到目标测试结果时，执行测试脚本实现用例测试结果的条件验证，无需人力判断测试用例的接口测试结果是否满足一定的条件约束，降低了接口测试中的人力运维成本。

附图说明

图1为本发明实施例中用户现场展示的方法一个实施例示意图；

图2为本发明实施例中用户现场展示的方法一个实施例示意图；

图3为本发明实施例中用户现场展示的方法一个实施例示意图；

图4为本发明实施例中测试端的一个实施例示意图。

具体实施方式

本发明实施例提供了一种用户现场展示的方法、相关装置及系统，无需从大量的日志文件中查询目标用户的用户现场，可以基于用户特征信息快速地定位到目标用户的用户现场，再对用户现场进行还原，一方面有利于提升用户现场还原的实时性，另一方面降低了用户现场还原操作的难度。

本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例例如能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

参阅图1，本发明实施例中用户现场展示的方法一个实施例包括：

101、获取目标测试用例和目标测试用例中的预设约束条件，预设约束条件用于约束测试的结果；

本申请实施例中，在进行接口测试前，首先需要在测试端配置与待测试的应用程序编程接口API相适配的目标测试用例，为了方便叙述，下文将测试用例称为目标测试用例。其中，目标测试用例可以包括预先编制的一组或多组测试输入以及预期结果，具体的，测试人员需要根据待测试的API接口测试可能遇到的问题来确定一组或多组测试输入，测试输入可以从待测试的API接口的输入、接口处理和输出三方面考虑选择：

1)针对输入，可按照参数类型进行设计，例如若输入为数值型，待测试的API接口的输入参数规定了数值的范围，则可以将等价类取值范围内、取值范围外、取值的边界或取值范围内的各个值作为目标测试用例中的测试输入。若输入为字符串型，则可以将边界值：字符串的最大长度、特殊值、空字符、数字、非数字、特殊字符等作为目标测试用例中的测试输入。

2)针对接口处理，可按照逻辑进行用例的测试输入设计；

3)针对输出，可根据结果进行分析设计。

本申请实施例中，在确定了目标测试用例中的测试输入之后，需要确定待测试的API在输入了各个测试输入之后相对应的正常的预期结果，该正常的预期结果为当待测试的API没有异常时输出的目标测试结果。为方便理解，下文将测试用例中的预期结果称为预设约束条件。需要说明的是，测试端在获取目标测试用例中的预设约束条件时，可以识别目标测试用例中包含的语法特征，以输入为数值型为例，例如若待测试的接口类型为检查权限接口TaskChecker.checkTask：(int taskID)，其中输入taskID的取值范围是1-35，目标测试用例中的测试输入可以确定为1-35范围内的整数、1-35范围边界的数值(0、1、35、36)、特殊数值-1等，相应的，若该检查权限接口工作正常，则当测试输入为1-35范围内的整数时，相应正常的预设约束条件为可以代表“有权限”的数值或字符串，例如“输出＝1”或“输出＝T”等，当输入值为1-35范围外的整数时，相应正常的预设约束条件为可以代表“无权限”的数值或字符串，例如“输出＝0”或“输出＝F”等。具体的，测试端在获取目标测试用例中的预设约束条件时，可以识别目标测试用例中包含的语法特征可以是：测试端识别目标测试用力中的语法特征，以上述检查权限接口为例，此时目标测试用例中的语法特征为“输出＝1”、“输出＝T”、“输出＝0”或“输出＝F”，此外，在其他应用场景中，语法特征还可以大于、小于、数量等于、非空集等。需要说明的是，测试端在获取目标测试用例和目标测试用例中的预设约束条件后，可以在测试端构建预设约束条件和测试输入的对应关系，以上述检查权限接口为例，测试输入为1-35范围内的整数时，相对应的预设约束条件为“输出＝1”或“输出＝T”，输入值为1-35范围外的整数时，相对应的预设约束条件为“输出＝0”或“输出＝F”。本申请实施例中，在测试端将预先配置好的测试用例发送到待测试应用程序编程接口API之前，先获取目标测试用例中的预设约束条件，可以方便进行之后的目标测试结果的成功性判别。

本申请实施例中，测试人员可以通过Excel来配置目标测试用例，在Excel中除了输入上述的一组或多组测试输入以及预期结果之外，还可以包括测试端需要连接待测试的API时所需要的用户名、密码、授权方式、请求方式等。在测试人员通过Excel来配置目标测试用例之后，相当于在测试端完成了接口测试的准备工作，由于待测试的API只能识别固定格式的目标测试用例，可选地，在测试人员通过Excel来配置目标测试用例之后，向待测试的应用程序编程接口API发送目标测试用例之前，测试人员可以通过Excel用例读取工具，将目标测试用例的Excel数据转换为待测试API可以识别的java bean格式数据，本申请实施例中，测试人员不直接利用java代码进行目标测试用例的编写，而是利用excel编写目标测试用例，再通过Excel用例读取工具，将目标测试用例的Excel数据转换为待测试API可以识别的java bean格式数据，使得不会写java代码的测试人员也可以编写目标测试用例，且当需要修改目标测试用例时，可以直接在excel的相应数据位置修改，不需要重新用java代码编码和编译打包。

102、向待测试的应用程序编程接口API发送目标测试用例；

本申请实施例中，在获取目标测试用例和目标测试用例中的预设约束条件，预设约束条件用于约束测试的结果之后，测试端需要向待测试的应用程序编程接口API发送目标测试用例，以使得待测试的应用程序编程接口API可以通过测试该目标测试用例得到目标测试结果。

103、接收待测试的API发送的目标测试结果，其中，目标测试结果为待测试的API采用目标测试用例进行测试后得到的；

本申请实施例中，在向待测试的应用程序编程接口API发送目标测试用例，以使得待测试的应用程序编程接口API可以通过测试该目标测试用例得到目标测试结果之后，测试端可以接收待测试的API发送的目标测试结果，其中，目标测试结果为待测试的API采用目标测试用例进行测试后得到的。

104、若在执行测试脚本的过程中确定目标测试结果满足预设约束条件，则生成API测试成功的结果。

本申请实施例中，在接收待测试的API发送的待测试的API采用目标测试用例进行测试后得到的目标测试结果之后，就可以根据预先获取的预设约束条件对待测试API返回的目标测试结果进行正确性的判别。

本申请实施例中，可以在测试端预先编写一个测试脚本，该测试脚本可以在接收待测试的API发送的目标测试结果之后执行，在执行测试脚本的过程中自动确定目标测试结果是否满足预设约束条件。目标测试结果可以符合预设约束条件也可以不符合预设约束条件，当待测试的API正常工作时，目标测试结果符合预设约束条件，当待测试的API异常工作时，目标测试结果不符合预设约束条件。以上述检查权限接口为例，当测试输入为30，即测试输入为1-35范围内的整数，相对应的预设约束条件为“输出＝1”或“输出＝T”，此时接收到的目标测试结果中的输出为“1”，即在执行测试脚本的过程中确定目标测试结果“1”满足了对应的预设约束条件“输出＝1”或“输出＝T”，则生成API测试成功的结果。当测试输入为36，即测试输入为1-35范围外的整数时，相对应的预设约束条件为“输出＝0”或“输出＝F”，此时接收到的目标测试结果中的输出为“1”，即在执行测试脚本的过程中确定目标测试结果“1”不满足对应的预设约束条件“输出＝0”或“输出＝F”，则生成API测试失败的结果，此时测试人员可以对该异常API进行故障排查。

本申请实施例中，提供了一种接口测试方法，首先获取目标测试用例和目标测试用例中的预设约束条件，预设约束条件用于约束测试的结果，然后向待测试的应用程序编程接口API发送目标测试用例，之后接收待测试的API发送的目标测试结果，其中，目标测试结果为待测试的API采用目标测试用例进行测试后得到的，最后若在执行测试脚本的过程中确定目标测试结果满足预设约束条件，则生成API测试成功的结果。通过上述方式，在发送目标测试用例之前先从目标测试用例中获取预设约束条件，并在接收到目标测试结果时，执行测试脚本实现目标测试结果的条件验证，无需人力判断测试用例的接口测试结果是否满足一定的条件约束，降低了接口测试中的人力运维成本。

可选地，在上述图1对应的实施例的基础上，本发明实施例提供的接口测试方法的第一个可选实施例中，预设约束条件包括：数值约束或字符串约束；

相应的，若在执行测试脚本的过程中确定目标测试结果满足预设约束条件，则生成API测试成功的结果包括：

若预设约束条件为数值约束且在执行测试脚本的过程中确定目标测试结果为第一目标数值，则生成API测试成功的结果，其中数值约束用于约束测试的结果为第一目标数值；

若预设约束条件为字符串约束且在执行测试脚本的过程中确定目标测试结果为第一目标字符串，则生成API测试成功的结果，其中字符串约束用于约束测试的结果为第一目标字符串。

本申请实施例中，分别说明了当预设约束条件为数值约束以及字符串约束两种情况时，在执行测试脚本的过程中如何确定目标测试结果满足预设约束条件，接下来说明预设约束条件为数值约束时，确定目标测试结果满足预设约束条件的具体方式：

本申请实施例中，测试端在获取目标测试用例中的预设约束条件时，可以识别目标测试用例中包含的语法特征，可选地，语法特征可以包括操作符和期望值，其中操作符可以包括大于、小于、不大于、不小于或等于等，期望值类型可以为数值型、字符串型、数值集合型或字符串集合型等。例如，当识别出一个测试用例中与输入为30对应的语法特征为“等于3”，其中“等于”为操作符，3为数值型期望值，相应的，该预设约束条件为数值约束。

本申请实施例中，若预设约束条件为数值约束且在执行测试脚本的过程中确定目标测试结果为第一目标数值，则生成API测试成功的结果，其中数值约束用于约束测试的结果为第一目标数值。测试端在接收到目标测试结果后，需要执行测试脚本，该测试脚本可以确定目标测试结果是否为第一目标数值。具体的，该测试脚本在接收到目标测试结果后，可以首先确定目标测试结果中的操作符以及结果值，然后分别和预先获取到的目标测试用例中语法特征的操作符和期望值分别进行比对，得到如下四种比对结果：

1)、若操作符不一致而期望值一致，则生成API测试异常的结果；

2)、若操作符一致而期望值不一致，则生成API测试异常的结果；

3)、若操作符不一致且期望值不一致，则生成API测试异常的结果；

4)、若操作符一致且期望值一致，则生成API测试正常的结果。

本申请实施例中，只有当操作符一致且期望值一致，才会生成API测试正常的结果。例如，预先识别出的一个测试用例中与输入为30对应的语法特征为“等于3”，其中“等于”为操作符，3为数值型期望值，当测试端接收到目标测试结果为1时，即确定目标测试结果中的操作符为“等于”，期望值为“1”，则操作符一致而期望值不一致，生成API测试异常的结果。

以上说明了预设约束条件为数值约束时，确定目标测试结果满足预设约束条件的具体方式，接下来说明预设约束条件为字符串约束时，确定目标测试结果满足预设约束条件的具体方式：

本申请实施例中，测试端在获取目标测试用例中的预设约束条件时，可以识别目标测试用例中包含的语法特征，可选地，语法特征可以包括操作符和期望值，其中操作符可以包括大于、小于、不大于、不小于或等于等，期望值类型可以为数值型、字符串型、数值集合型或字符串集合型等。例如，当识别出一个测试用例中与输入为40对应的语法特征为“等于null”，其中“等于”为操作符，null为字符串型期望值，相应的，该预设约束条件为字符串约束。

本申请实施例中，若预设约束条件为字符串约束且在执行测试脚本的过程中确定目标测试结果为第一目标字符串，则生成API测试成功的结果，其中字符串约束用于约束测试的结果为第一目标字符串。测试端在接收到目标测试结果后，需要执行测试脚本，该测试脚本可以确定目标测试结果是否为第一目标字符串。具体的，该测试脚本在接收到目标测试结果后，可以首先确定目标测试结果中的操作符以及结果值，然后分别和预先获取到的目标测试用例中语法特征的操作符和期望值分别进行比对，只有当操作符一致且期望值一致，才会生成API测试正常的结果。例如，预先识别出的一个测试用例中与输入为40对应的语法特征为“等于null”，其中“等于”为操作符，null为字符串型期望值，当测试端接收到目标测试结果为1时，即确定目标测试结果中的操作符为“等于”，期望值为“1”，则操作符一致而期望值不一致，生成API测试异常的结果。

本申请实施例中，当预设约束条件分别为数值约束或字符串约束时，测试端在执行测试脚本时，可以针对两种不同的预设约束条件而采用不同的目标接口结果条件验证方法，提升了方案的灵活性。

可选地，在上述图1对应的实施例的基础上，本发明实施例提供的接口测试方法的第二个可选实施例中，预设约束条件包括：数值过滤约束或字符串过滤约束；

相应的，若在执行测试脚本的过程中确定目标测试结果满足预设约束条件，则生成API测试成功的结果包括：

若预设约束条件为数值过滤约束且在执行测试脚本的过程中确定目标测试结果不为第二目标数值，则生成API测试成功的结果，其中数值过滤约束用于约束测试的结果不为第二目标数值；

若预设约束条件为字符串过滤约束且在执行测试脚本的过程中确定目标测试结果不为第二目标字符串，则生成API测试成功的结果，其中字符串过滤约束用于约束测试的结果不为第二目标字符串。

本申请实施例中，分别说明了当预设约束条件为数值过滤约束以及字符串过滤约束两种情况时，在执行测试脚本的过程中如何确定目标测试结果满足预设约束条件，接下来说明预设约束条件为数值过滤约束时，确定目标测试结果满足预设约束条件的具体方式：

本申请实施例中，测试端在获取目标测试用例中的预设约束条件时，可以识别目标测试用例中包含的语法特征，可选地，语法特征可以包括操作符和期望值，其中操作符可以包括大于、小于、不大于、不小于或等于等，期望值类型可以为数值型、字符串型、数值集合型或字符串集合型等。例如，当识别出一个测试用例中与输入为30对应的语法特征为“不等于3”，其中“不等于”为操作符，3为数值型期望值，相应的，该预设约束条件为数值过滤约束。

本申请实施例中，若预设约束条件为数值约束且在执行测试脚本的过程中确定目标测试结果不为第二目标数值，则生成API测试成功的结果，其中数值约束用于约束测试的结果不为第二目标数值。测试端在接收到目标测试结果后，需要执行测试脚本，该测试脚本可以确定目标测试结果是否为第一目标数值。具体的，该测试脚本在接收到目标测试结果后，可以首先确定目标测试结果中的操作符以及结果值，然后分别和预先获取到的目标测试用例中语法特征的操作符和期望值分别进行比对，只有当操作符一致且期望值一致，才会生成API测试正常的结果。例如，预先识别出的一个测试用例中与输入为30对应的语法特征为“不等于3”，其中“不等于”为操作符，3为数值型期望值，当测试端接收到目标测试结果为1时，即确定目标测试结果中的操作符为“等于”，期望值为“1”，则操作符不一致且期望值不一致，生成API测试异常的结果。

以上说明了预设约束条件为数值过滤约束时，确定目标测试结果满足预设约束条件的具体方式，接下来说明预设约束条件为字符串过滤约束时，确定目标测试结果满足预设约束条件的具体方式：

本申请实施例中，若预设约束条件为字符串约束且在执行测试脚本的过程中确定目标测试结果不为第二目标字符串，则生成API测试成功的结果，其中字符串约束用于约束测试的结果不为第二目标字符串。测试端在接收到目标测试结果后，需要执行测试脚本，该测试脚本可以确定目标测试结果是否为第一目标字符串。具体的，该测试脚本在接收到目标测试结果后，可以首先确定目标测试结果中的操作符以及结果值，然后分别和预先获取到的目标测试用例中语法特征的操作符和期望值分别进行比对，只有当操作符一致且期望值一致，才会生成API测试正常的结果。例如，预先识别出的一个测试用例中与输入为40对应的语法特征为“不等于null”，其中“不等于”为操作符，null为字符串型期望值，当测试端接收到目标测试结果为1时，即确定目标测试结果中的操作符为“等于”，期望值为“1”，则操作符不一致且期望值不一致，生成API测试异常的结果。

本申请实施例中，当预设约束条件分别为数值过滤约束或字符串过滤约束时，测试端在执行测试脚本时，可以针对两种不同的预设约束条件而采用不同的目标接口结果条件验证方法，提升了方案的灵活性。

可选地，在上述图1对应的实施例的基础上，本发明实施例提供的接口测试方法的第三个可选实施例中，预设约束条件包括：数量约束；

相应的，若在执行测试脚本的过程中确定目标测试结果满足预设约束条件，则生成API测试成功的结果包括：

若预设约束条件为数量约束且在执行测试脚本的过程中确定目标测试结果中参数的数量为目标数量，则生成API测试成功的结果，其中数量约束用于约束测试的结果中参数的数量为目标数量。

本申请实施例中，测试端在获取目标测试用例中的预设约束条件时，可以识别目标测试用例中包含的语法特征，可选地，语法特征可以包括结果对象、操作符和期望值，其中结果对象可以为一个集合，操作符可以包括大于、小于、不大于、不小于或等于等，期望值类型可以为数值型、字符串型、数值集合型或字符串集合型等。例如，当识别出一个测试用例中与输入为30对应的语法特征为“输出集合A的元素数量等于3”，其中“输出集合A的元素数量”为结果对象，“等于”为操作符，3为期望值，相应的，该预设约束条件为数量约束。

本申请实施例中，若预设约束条件为数量约束且在执行测试脚本的过程中确定目标测试结果中参数的数量为目标数量，则生成API测试成功的结果，其中数量约束用于约束测试的结果中参数的数量为目标数量。测试端在接收到目标测试结果后，需要执行测试脚本，该测试脚本可以确定目标测试结果中参数的数量是否为目标数量。具体的，该测试脚本在接收到目标测试结果后，可以首先确定目标测试结果中的结果对象、操作符以及结果值，然后分别和预先获取到的目标测试用例中语法特征的结果对象、操作符和期望值分别进行比对，得到如下八种比对结果：若结果对象不一致、

1)、若结果对象不一致、操作符不一致且期望值一致，则生成API测试异常的结果；

2)、若结果对象不一致、操作符一致且期望值不一致，则生成API测试异常的结果；

3)、若结果对象不一致、操作符不一致且期望值不一致，则生成API测试异常的结果；

4)、若结果对象不一致、操作符一致且期望值一致，则生成API测试异常的结果。

5)、若结果对象一致、操作符不一致且期望值一致，则生成API测试异常的结果；

6)、若结果对象一致、操作符一致且期望值不一致，则生成API测试异常的结果；

7)、若结果对象一致、操作符不一致且期望值不一致，则生成API测试异常的结果；

8)、若结果对象一致、操作符一致且期望值一致，则生成API测试正常的结果。

本申请实施例中，只有当结果对象一致、操作符一致且期望值一致，才会生成API测试正常的结果。例如，预先识别出的一个测试用例中与输入为30对应的语法特征为“输出集合A的元素数量等于3”，其中“输出集合的元素数量”为结果对象，“等于”为操作符，3为期望值，当测试端接收到目标测试结果为“输出集合A的元素数量等于2”时，即确定目标测试结果中的“输出集合的元素数量”为结果对象，“等于”为操作符，2为期望值，则结果对象一致、操作符一致且期望值不一致，生成API测试异常的结果。

本申请实施例中，当预设约束条件为数量约束时，测试端在执行测试脚本时，可以对该类型的预设约束条件采用相应的目标接口结果条件验证方法，提升了方案的灵活性。

可选地，在上述图1对应的实施例、第一个可选实施例、第二个可选实施例和第三个可选实施例的基础上，本发明实施例提供的接口测试方法的第四个可选实施例中，向待测试的应用程序编程接口API发送目标测试用例之前还包括：

接收API发送的验证信息，验证信息中携带有第一字符信息；

识别验证信息中的第二字符信息；

向API发送第二字符信息；

接收API在第二字符信息与第一字符信息相同时发送的授权认证。

本申请实施例中，在测试端向待测试的应用程序编程接口API发送目标测试用例之前，需要进行待测试的API接口的授权认证。需要说明的是，开放的API接口在接口测试前都需要测试端的权限验证，在权限验证通过(授权)后，测试端可以获得向待测试的应用程序编程接口API发送目标测试用例的权限。目前授权方式有表单式，即用户名密码方式，需要交互的是用户名密码得到会话地址(session id)，而表单方式需要验证码验证。

本申请实施例中，在进行权限验证时，测试端首先会接收API发送的验证信息，验证信息中携带有第一字符信息。验证信息可以为图片信息或语音信息，其中图片包含有第一字符信息，具体的，该图片可以显示有第一字符信息。其中语音包含有第一字符信息，具体的，该语音可以包含有第一字符的语音信息。第一字符信息可以为验证码，例如文字、字符串或数字。

本申请实施例中，测试端在接收API发送的验证信息后，可以识别验证信息中的第二字符信息。需要说明的是，测试端可以预先通过机器学习的方式训练大量的字符信息，具体的，可以通过机器学习的方式，学习大量图片信息中的字符信息，使得测试端可以准确识别出任意图片中的字符信息。例如，测试端可以预先获取大量具有字符信息的图片，并将该图片转换为灰度图片，获取其中的灰度信息，输入与该图片对应的字符，使得测试端可以建立该灰度信息与字符的对应关系。在经过大量的对应关系建立后，测试端就可以准确识别出任意图片中的字符信息。需要说明的是，测试端可以预先通过机器学习的方式训练大量的字符信息，具体的，可以通过机器学习的方式，学习大量语音信息中的字符信息，使得测试端可以准确识别出任意语音中的字符信息。例如，测试端可以预先获取大量具有字符信息的语音片段，并获取各语音片段中的音频信息，输入与该语音对应的字符，使得测试端可以建立该音频信息与字符的对应关系。在经过大量的对应关系建立后，测试端就可以准确识别出任意语音中的字符信息。

本申请实施例中，在测试端识别验证信息中的第二字符信息后，可以向API发送第二字符信息，并接收API在第二字符信息与第一字符信息相同时发送的授权认证。需要说明的是，进行第二字符信息与第一字符信息的一致性比对可以是与该待测试的API接口相连接的业务服务器，具体的，业务服务器在确认第二字符信息与第一字符信息相同时，即确认测试端通过了验证码认证。

本申请实施例中，测试端在进行验证码认证时，可以识别API发送的验证信息中的字符信息，并自动向API发送第二字符信息，不需要手动输入验证字符，进一步节省了运维成本。

请参阅图2，图2为本发明实施例中接口测试装置一个实施例示意图，接口测试装置包括：

获取模块201，用于获取目标测试用例和所述目标测试用例中的预设约束条件，所述预设约束条件用于约束测试的结果；

第一发送模块202，用于向应用程序编程接口API发送获取模块201获取的目标测试用例；

第一接收模块203，用于接收待测试的API发送的目标测试结果，其中，目标测试结果为待测试的API采用第一发送模块202发送的目标测试用例进行测试后得到的；

第一处理模块204，用于若在执行测试脚本的过程中确定第一接收模块203接收到的目标测试结果满足预设约束条件，则生成API测试成功的结果。

本实施例中，获取模块201获取目标测试用例和所述目标测试用例中的预设约束条件，所述预设约束条件用于约束测试的结果，第一发送模块202向应用程序编程接口API发送获取模块201获取的目标测试用例，第一接收模块203接收待测试的API发送的目标测试结果，其中，目标测试结果为待测试的API采用第一发送模块202发送的目标测试用例进行测试后得到的，第一处理模块204若在执行测试脚本的过程中确定第一接收模块203接收到的目标测试结果满足预设约束条件，则生成API测试成功的结果。

本发明实施例中，提供了一种接口测试装置，首先获取模块201获取目标测试用例和所述目标测试用例中的预设约束条件，所述预设约束条件用于约束测试的结果；之后第一发送模块202向应用程序编程接口API发送获取模块201获取的目标测试用例；之后第一接收模块203接收待测试的API发送的目标测试结果，其中，目标测试结果为待测试的API采用第一发送模块202发送的目标测试用例进行测试后得到的；最后第一处理模块204若在执行测试脚本的过程中确定第一接收模块203接收到的目标测试结果满足预设约束条件，则生成API测试成功的结果。通过上述方式，在发送目标测试用例之前先从目标测试用例中获取预设约束条件，并在接收到目标测试结果时，执行测试脚本实现目标测试结果的条件验证，无需人力判断测试用例的接口测试结果是否满足一定的条件约束，降低了接口测试中的人力运维成本。

可选地，在上述图2所对应的实施例的基础上，本发明实施例提供的接口测试装置的另一实施例中，预设约束条件包括：数值约束或字符串约束；

相应的，第一处理模块204，用于若预设约束条件为数值约束且在执行测试脚本的过程中确定第一接收模块203接收的目标测试结果为第一目标数值，则生成API测试成功的结果，其中数值过滤约束用于约束测试的结果为第一目标数值；

若预设约束条件为字符串约束且在执行测试脚本的过程中确定第一接收模块203接收的目标测试结果为第一目标字符串，则生成API测试成功的结果，其中字符串约束用于约束测试的结果为第一目标字符串。

本申请实施例中，当预设约束条件分别为数值约束或字符串约束时，测试端在执行测试脚本时，可以针对两种不同的预设约束条件而采用不同的目标接口结果条件验证方法，提升了方案的灵活性。

可选地，在上述图2所对应的实施例的基础上，本发明实施例提供的接口测试装置的另一实施例中，预设约束条件包括：数值过滤约束或字符串过滤约束；

相应的，第一处理模块204，用于若预设约束条件为数值过滤约束且在执行测试脚本的过程中确定第一接收模块203接收的目标测试结果不为第二目标数值，则生成API测试成功的结果，其中数值过滤约束用于约束测试的结果不为第二目标数值；

若预设约束条件为字符串过滤约束且在执行测试脚本的过程中确定第一接收模块203接收的目标测试结果不为第二目标字符串，则生成API测试成功的结果，其中字符串过滤约束用于约束测试的结果不为第二目标字符串。

本申请实施例中，当预设约束条件分别为数值过滤约束或字符串过滤约束时，测试端在执行测试脚本时，可以针对两种不同的预设约束条件而采用不同的目标接口结果条件验证方法，提升了方案的灵活性。

可选地，在上述图2所对应的实施例的基础上，本发明实施例提供的接口测试装置的另一实施例中，预设约束条件包括：数量约束；

相应的，第一处理模块204，用于若预设约束条件为数量约束且在执行测试脚本的过程中确定第一接收模块203接收的目标测试结果中参数的数量为目标数量，则生成API测试成功的结果，其中数量约束用于约束测试的结果中参数的数量为目标数量。

本申请实施例中，当预设约束条件为数量约束时，测试端在执行测试脚本时，可以对该类型的预设约束条件采用相应的目标接口结果条件验证方法，提升了方案的灵活性。

可选地，在上述图2所对应的实施例的基础上，参照图3，本发明实施例提供的接口测试装置的另一实施例中，接口测试装置还包括：

第二接收模块301，用于接收API发送的验证信息，验证信息中携带有第一字符信息；

第二处理模块302，用于识别第二接收模块301接收的验证信息中的第二字符信息；

第二发送模块303，用于向API发送第二处理模块302处理得到的第二字符信息；

第三接收模块304，用于接收API在第二字符信息与第一字符信息相同时发送的授权认证。

本申请实施例中，测试端在进行验证码认证时，可以识别API发送的验证信息中的字符信息，并自动向API发送第二字符信息，不需要手动输入验证字符，进一步节省了运维成本。

本发明实施例还提供了一种测试端，如图4所示，为了便于说明，仅示出了与本发明实施例相关的部分，具体技术细节未揭示的，请参照本发明实施例方法部分。该测试端可以为包括手持电脑、个人数字助理(Personal Digital Assistant，PDA)、销售终端(Pointof Sales，POS)、车载电脑等任意终端设备，以终端为手持电脑为例：

图4示出的是与本发明实施例提供的终端相关的手持电脑的部分结构的框图。参考图4，手持电脑包括：射频(Radio Frequency，RF)电路410、存储器420、输入单元430、显示单元440、无线保真(wireless fidelity，WiFi)模块450、处理器460、以及电源470等部件。本领域技术人员可以理解，图4中示出的手持电脑结构并不构成对手持电脑的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

下面结合图4对手持电脑的各个构成部件进行具体的介绍：

RF电路410可用于收发信息过程中，信号的接收和发送。此外，RF电路410还可以通过无线通信与网络和其他设备通信。上述无线通信可以使用任一通信标准或协议。

存储器420可用于存储软件程序以及模块，处理器460通过运行存储在存储器420的软件程序以及模块，从而执行手持电脑的各种功能应用以及数据处理。存储器420可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序等；存储数据区可存储根据手持电脑的使用所创建的数据等。此外，存储器420可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

输入单元430可用于接收输入的数字或字符信息，以及产生与手持电脑的用户设置以及功能控制有关的键信号输入。

显示单元440可用于显示由用户输入的信息或提供给用户的信息以及手持电脑的各种菜单。显示单元440可包括显示面板441，可选的，可以采用液晶显示器(LiquidCrystal Display，LCD)、有机发光二极管(Organic Light-Emitting Diode，OLED)等形式来配置显示面板441。

WiFi属于短距离无线传输技术，手持电脑通过WiFi模块450可以帮助用户收发电子邮件、浏览网页和访问流式媒体等，它为用户提供了无线的宽带互联网访问。虽然图4示出了WiFi模块450，但是可以理解的是，其并不属于手持电脑的必须构成，完全可以根据需要在不改变发明的本质的范围内而省略。

处理器460是手持电脑的控制中心，利用各种接口和线路连接整个手持电脑的各个部分，通过运行或执行存储在存储器420内的软件程序和/或模块，以及调用存储在存储器420内的数据，执行手持电脑的各种功能和处理数据，从而对手持电脑进行整体监控。可选的，处理器460可包括一个或多个处理单元；可选的，处理器460可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器460中。

手持电脑还包括给各个部件供电的电源470(比如电池)，可选的，电源可以通过电源管理系统与处理器460逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。

在本发明实施例中，该手持电脑所包括的处理器460还具有以下功能：

获取目标测试用例和目标测试用例中的预设约束条件，预设约束条件用于约束测试的结果；

向待测试的应用程序编程接口API发送目标测试用例；

接收待测试的API发送的目标测试结果，其中，目标测试结果为待测试的API采用目标测试用例进行测试后得到的；

若在执行测试脚本的过程中确定目标测试结果满足预设约束条件，则生成API测试成功的结果。

可选地，处理器460还用于执行如下步骤：

接收API发送的验证信息，验证信息中携带有第一字符信息；

识别验证信息中的第二字符信息；

向API发送第二字符信息；

接收API在第二字符信息与第一字符信息相同时发送的授权认证。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

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

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

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

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(read-only memory，ROM)、随机存取存储器(random access memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (10)

1.一种接口测试方法，其特征在于，包括：

获取目标测试用例和所述目标测试用例中的预设约束条件，所述预设约束条件用于约束测试的结果；

向待测试的应用程序编程接口API发送所述目标测试用例；

接收所述待测试的API发送的目标测试结果，其中，所述目标测试结果为所述待测试的API采用所述目标测试用例进行测试后得到的；

若在执行测试脚本的过程中确定所述目标测试结果满足所述预设约束条件，则生成API测试成功的结果。

2.根据权利要求1所述的方法，其特征在于，所述预设约束条件包括：数值约束或字符串约束；

相应的，所述若在执行测试脚本的过程中确定所述目标测试结果满足所述预设约束条件，则生成API测试成功的结果包括：

若所述预设约束条件为所述数值约束且在执行测试脚本的过程中确定所述目标测试结果为第一目标数值，则生成API测试成功的结果，其中数值过滤约束用于约束测试的结果为所述第一目标数值；

若所述预设约束条件为所述字符串约束且在执行测试脚本的过程中确定所述目标测试结果为第一目标字符串，则生成API测试成功的结果，其中字符串约束用于约束测试的结果为所述第一目标字符串。

3.根据权利要求1所述的方法，其特征在于，所述预设约束条件包括：数值过滤约束或字符串过滤约束；

相应的，所述若在执行测试脚本的过程中确定所述目标测试结果满足所述预设约束条件，则生成API测试成功的结果包括：

若所述预设约束条件为所述数值过滤约束且在执行测试脚本的过程中确定所述目标测试结果不为第二目标数值，则生成API测试成功的结果，其中数值过滤约束用于约束测试的结果不为所述第二目标数值；

若所述预设约束条件为所述字符串过滤约束且在执行测试脚本的过程中确定所述目标测试结果不为第二目标字符串，则生成API测试成功的结果，其中字符串过滤约束用于约束测试的结果不为所述第二目标字符串。

4.根据权利要求1所述的方法，其特征在于，所述预设约束条件包括：数量约束；

相应的，所述若在执行测试脚本的过程中确定所述目标测试结果满足所述预设约束条件，则生成API测试成功的结果包括：

若所述预设约束条件为所述数量约束且在执行测试脚本的过程中确定所述目标测试结果中参数的数量为目标数量，则生成API测试成功的结果，其中所述数量约束用于约束测试的结果中参数的数量为所述目标数量。

5.根据权利要求1至4任一所述的方法，其特征在于，所述向待测试的应用程序编程接口API发送所述目标测试用例之前还包括：

接收所述API发送的验证信息，所述验证信息中携带有第一字符信息；

识别所述验证信息中的第二字符信息；

向所述API发送所述第二字符信息；

接收所述API在所述第二字符信息与所述第一字符信息相同时发送的授权认证。

6.一种接口测试装置，其特征在于，包括：

获取模块，用于获取目标测试用例和所述目标测试用例中的预设约束条件，所述预设约束条件用于约束测试的结果；

第一发送模块，用于向应用程序编程接口API发送所述获取模块获取的所述目标测试用例；

第一接收模块，用于接收所述待测试的API发送的目标测试结果，其中，所述目标测试结果为所述待测试的API采用所述第一发送模块发送的所述目标测试用例进行测试后得到的；

第一处理模块，用于若在执行测试脚本的过程中确定所述第一接收模块接收到的所述目标测试结果满足所述预设约束条件，则生成API测试成功的结果。

7.根据权利要求6所述的装置，其特征在于，所述预设约束条件包括：数值约束或字符串约束；

相应的，所述第一处理模块，用于若所述预设约束条件为所述数值约束且在执行测试脚本的过程中确定所述第一接收模块接收的所述目标测试结果为第一目标数值，则生成API测试成功的结果，其中数值过滤约束用于约束测试的结果为所述第一目标数值；

若所述预设约束条件为所述字符串约束且在执行测试脚本的过程中确定所述第一接收模块接收的所述目标测试结果为第一目标字符串，则生成API测试成功的结果，其中字符串约束用于约束测试的结果为所述第一目标字符串。

8.根据权利要求6所述的装置，其特征在于，所述预设约束条件包括：数值过滤约束或字符串过滤约束；

相应的，所述第一处理模块，用于若所述预设约束条件为所述数值过滤约束且在执行测试脚本的过程中确定所述第一接收模块接收的所述目标测试结果不为第二目标数值，则生成API测试成功的结果，其中数值过滤约束用于约束测试的结果不为所述第二目标数值；

若所述预设约束条件为所述字符串过滤约束且在执行测试脚本的过程中确定所述第一接收模块接收的所述目标测试结果不为第二目标字符串，则生成API测试成功的结果，其中字符串过滤约束用于约束测试的结果不为所述第二目标字符串。

9.根据权利要求6所述的装置，其特征在于，所述预设约束条件包括：数量约束；

相应的，所述第一处理模块，用于若所述预设约束条件为所述数量约束且在执行测试脚本的过程中确定所述第一接收模块接收的所述目标测试结果中参数的数量为目标数量，则生成API测试成功的结果，其中所述数量约束用于约束测试的结果中参数的数量为所述目标数量。

10.根据权利要求6至9任一所述的装置，其特征在于，所述装置还包括：

第二接收模块，用于接收所述API发送的验证信息，所述验证信息中携带有第一字符信息；

第二处理模块，用于识别所述第二接收模块接收的所述验证信息中的第二字符信息；

第二发送模块，用于向所述API发送所述第二处理模块处理得到的所述第二字符信息；

第三接收模块，用于接收所述API在所述第二字符信息与所述第一字符信息相同时发送的授权认证。