CN110968505A - 一种api接口的自动化测试方法和系统 - Google Patents

Abstract

本发明公开了一种API接口的自动化测试方法，涉及自动化测试领域。该方法包括：根据新建的测试项目，建立对应的API；获取所述API对应的预设信息；根据所述预设信息调用预设的素材库或预设的方法库，并选择构建方式，构建所述API的测试用例；执行所述API的测试用例，将所述API的测试用例的执行结果保存到测试结果库中。本方案根据预设信息调用素材库或方法库，并选择构建方式，构建API的测试用例，使得测试工程师无需查找素材和方法，系统根据参数类型直接调用素材库或方法库，大大节省了测试工程师的时间，实现用例的自动构建，提高了测试用例的质量。从新建一个测试项目到用例构建、用例执行，不但实现了自动化测试，还提高了整个测试开发过程的效率。

Description

一种API接口的自动化测试方法和系统

技术领域

本发明涉及自动化测试领域，尤其涉及一种API接口的自动化测试方法和系统。

背景技术

目前，对于API(Application Programming Interface)的功能测试还停留在手工测试阶段，虽然有API自动化测试系统，但大部分均是用例执行的自动化实现，主要还是依赖于人工操作；当前虽然有一些API测试工具，如postman、soapUI、jmeter等，但是此类工具无法实现用例的自动构建，测试用例的质量依托于测试人员的水平，主观性较强，且批量用例执行需要编写脚本，对测试人员能力要求较高，因此，测试用例的质量无法保证、测试的效率也无法保证，整个测试的周期时间长，测试开发过程的效率低。

发明内容

本发明所要解决的技术问题是针对现有技术的不足，提供的一种API接口的自动化测试方法和系统。

本发明解决上述技术问题的技术方案如下：

一种API接口的自动化测试方法，包括：

S1，根据新建的测试项目，建立对应的API；

S2，获取所述API对应的预设信息；

S3，根据所述预设信息调用预设的素材库或预设的方法库，并选择构建方式，构建所述API的测试用例；

S4，执行所述API的测试用例，具体包括：单条执行或批量执行，将所述API的测试用例的执行结果保存到测试结果库中。

本发明的有益效果是：本方案，根据预设信息调用素材库或方法库，并选择构建方式，构建API的测试用例，使得测试工程师无需查找素材和方法，系统根据参数类型直接调用素材库或方法库，大大节省了测试工程师的时间，实现用例的自动构建，提高了测试用例的质量；从新建一个测试项目到用例构建、用例执行，不但实现了自动化测试，还提高了整个测试开发过程的效率。

在上述技术方案的基础上，本发明还可以做如下改进。

进一步地，所述S3，具体包括：

S31，逐个读取所述预设信息，所述预设信息包括：API基本信息和参数；

S32，判断所述参数的类型是否为文件，若为文件，则调用素材库，否则调用方法库，根据对应的所述素材库或方法库对所述参数进行赋值；

S33，判断是否存在未赋值的参数，若是，则返回S31步；若否，则参数取值完成；

S34，判断用例构建方式是否为复杂型构建方式，若否，则按照简单型构建方式自动生成所述测试用例；若是，则按照复杂型构建方式自动生成所述测试用例。

采用上述进一步方案的有益效果是：通过参数调用素材库或者方法库，不仅有正常场景，还有相应参数类型的各种异常场景。通过判断参数类型，可以自动匹配正、异常场景，可以生成尽可能多的测试用例，提高用例覆盖率；通过简单型构建方式或者复杂型构建方式，使得建立的测试用例，能够适应不同的测试项目需求。

进一步地，所述素材库包括多个类型的数据，所述多个类型的数据按照数据类型进行分类，每种类型的数据包括正常场景和异常场景；所述方法库包括多种黑盒测试方法，所述多种黑盒测试方法按照所述方法库中的数据类型进行分类，每种类型的数据包括正常场景和异常场景。

采用上述进一步方案的有益效果是：在素材库或者方法库中，不仅有正常场景，还有相应参数类型的各种异常场景。通过判断参数类型，可以自动匹配正、异常场景，可以生成尽可能多的测试用例，提高用例覆盖率，更易找出API接口存在的问题及缺陷，进一步提高了测试效率。

进一步地，所述简单型构建方式是部分量构建，包括每个参数的正常场景和异常场景；

所述复杂型构建方式是全量构建，包括每个参数的单一测试场景、所有接口参数的组合场景和其他参数间的组合场景。

采用上述进一步方案的有益效果是：简单型构建方式在构建测试用例时，每个参数均考虑了正常和异常场景，并且每个异常场景均考虑了多种异常数据，尽量做到使用例既简单、数量少，又能包含各种主要的测试场景，使得在测试项目比较紧急，仅有较短的测试时间时，也能尽可能多的找出Bug。复杂型构建方式不仅包含简单型方式构建的用例，同时还包含了可选参数间的穷尽组合方式，自动构建的用例数据量较大，尽可能多的做到全量测试，发现隐藏的问题。当项目有较长的测试时间时，可以选用此方式构建用例。两种构建用例的方式，以适应不同的测试项目需求。

进一步地，在所述S4之后，还包括：S5，判断所述测试结果是否正确，若是，将正确的测试结果与测试用例存入回归库中，若否，将错误的测试结果与测试用例自动发送给所述测试项目人员，并做出测试报告。

采用上述进一步方案的有益效果是：通过对测试结果进行分析判断，将正确的测试结果和测试用例存入回归库，将错误的测试结果和测试用例发送给测试项目人员，实行机器判断+人工核查模式，使找出的Bug更精确、更多，提高测试质量；建立回归库，对每次执行结果进行标记，并根据标记结果自动分拣到测试回归库，缩短了回归周期，提高整个测试过程的效率。

本发明解决上述技术问题的另一种技术方案如下：

一种API接口的自动化测试系统，包括：

项目管理模块、API管理模块、用例构建模块和用例执行模块；

所述项目管理模块用于新建或编辑项目；

所述API管理模块用于对API进行增、删、改、查，具体用于输入API对应的预设信息；

所述用例构建模块根据所述预设信息调用预设的素材库或预设的方法库，并选择构建方式，构建所述API的测试用例；

所述用例执行模块用于按照设定的程序批量或单个执行所述API的测试用例，并将所述API的测试用例的执行结果保存到用例测试结果库中。

本发明的有益效果是：本方案，根据预设信息调用素材库或方法库，并选择构建方式，构建API的测试用例，使得测试工程师无需查找素材和方法，系统根据参数类型直接调用素材库或方法库，大大节省了测试工程师的时间，实现用例的自动构建，提高了测试用例的质量；从新建一个测试项目到用例构建、用例执行，不但实现了自动化测试，还提高了整个测试开发过程的效率。

在上述技术方案的基础上，本发明还可以做如下改进。

进一步地，所述用例构建模块具体用于逐个读取所述预设信息，所述预设信息包括：API基本信息和参数；判断所述参数的类型是否为文件，若为文件，则调用素材库，否则调用方法库，根据对应的所述素材库或方法库对所述参数进行赋值；判断是否存在未赋值的参数，若是，则继续逐个读取所述预设信息，重新判断；若否，则参数取值完成；判断用例构建方式是否为复杂型构建方式，若否，则按照简单型构建方式自动生成所述测试用例；若是，则按照复杂型构建方式自动生成所述测试用例。

采用上述进一步方案的有益效果是：通过参数调用素材库或者方法库，不仅有正常场景，还有相应参数类型的各种异常场景。通过判断参数类型，可以自动匹配正、异常场景，可以生成尽可能多的测试用例，提高用例覆盖率；通过简单型构建方式或者复杂型构建方式，使得建立的测试用例，能够适应不同的测试项目需求。

进一步地，所述素材库包括多个类型的数据，所述多个类型的数据按照数据类型进行分类，每种类型的数据包括正常场景和异常场景；所述方法库包括多种黑盒测试方法，所述多种黑盒测试方法按照所述方法库中的数据类型进行分类，每种类型的数据包括正常场景和异常场景。

采用上述进一步方案的有益效果是：在素材库或者方法库中，不仅有正常场景，还有相应参数类型的各种异常场景。通过判断参数类型，可以自动匹配正、异常场景，可以生成尽可能多的测试用例，提高用例覆盖率，更易找出API接口存在的问题及缺陷，进一步提高了测试效率。

进一步地，所述简单型构建方式是部分量构建，包括每个参数的正常场景和异常场景；

所述复杂型构建方式是全量构建，包括每个参数的单一测试场景、所有接口参数的组合场景和其他参数间的组合场景。

采用上述进一步方案的有益效果是：简单型构建方式在构建测试用例时，每个参数均考虑了正常和异常场景，并且每个异常场景均考虑了多种异常数据，尽量做到使用例既简单、数量少，又能包含各种主要的测试场景，使得在测试项目比较紧急，仅有较短的测试时间时，也能尽可能多的找出Bug。复杂型构建方式不仅包含简单型方式构建的用例，同时还包含了可选参数间的穷尽组合方式，自动构建的用例数据量较大，尽可能多的做到全量测试，发现隐藏的问题。当项目有较长的测试时间时，可以选用此方式构建用例。两种构建用例的方式，以适应不同的测试项目需求。

进一步地，所述系统还包括：用例测试结果分析与处理模块用于判断所述测试结果是否正确，若是，将正确的测试结果与测试用例存入回归库中，若否，将错误的测试结果与测试用例自动发送给所述测试项目人员，并做出测试报告。

采用上述进一步方案的有益效果是：通过对测试结果进行分析判断，将正确的测试结果和测试用例存入回归库，将错误的测试结果发送给测试项目人员，实行机器判断+人工核查模式，使找出的Bug更精确、更多，提高测试质量；建立回归库，对每次执行结果进行标记，并根据标记结果自动分拣到测试回归库，缩短了回归周期，提高整个测试过程的效率。

从新建一个测试项目到用例构建、用例执行，再到用例结果分析与处理、回归测试直至测试项目完结的整个过程考虑，建立了一套API测试系统，该系统包括项目管理、API管理、用例构建、用例执行、用例测试结果分析与处理、用例回归等模块。不但能实现API接口的自动化测试，提高测试效率；还能进行模块的人性化管理：项目管理模块、API管理模块及用例构建模块均能进行增删改查操作。

本发明附加的方面的优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本发明实践了解到。

附图说明

图1为本发明的实施例提供的API接口的自动化测试方法的流程示意图；

图2为本发明的其他实施例提供自动判断测试用例的测试结果流程图；

图3为本发明的其他实施例提供的构建API测试用例的流程图；

图4为本发明的其他实施例提供的素材库/方法库更新流程图；

图5为本发明的其他实施例提供的API接口的自动化测试方法的流程示意图；

图6为本发明的其他实施例提供的API接口的自动化测试方法的流程示意图；

图7为本发明的实施例提供的API接口的自动化测试系统的结构框图；

图8为本发明的其他实施例提供的API接口的自动化测试系统的结构框图；

图9为本发明的其他实施例提供的API接口的自动化测试系统的结构框图。

具体实施方式

以下结合附图对本发明的原理和特征进行描述，所举实施例只用于解释本发明，并非用于限定本发明的范围。

如图1所示，为本发明实施例提供的一种API接口的自动化测试方法，该方法包括：

S1，根据新建的测试项目，建立对应的API；

系统可以新建或编辑测试项目，即可以对项目进行增、删、改、查的操作。项目自测试结束日起算，6年后自动销毁，并设定每个季度自动集中处理一次。

在API管理模块12可以新建或编辑API，API属于测试项目，一个API只能属于一个测试项目，一个测试项目中会包含多个API。API管理可以对API进行增、删、改、查的操作。API新建或编辑后需要重新构建用例，反之，无需重新构建用例。

S2，获取所述API对应的预设信息；

预设信息包括：API基本信息和参数；

API基本信息包括：API名字、摘要、url、方法、扩展类型；

参数包括：参数名字、描述、是否必填、类型、默认值。被测API的url、参数及其属性可单条填写也可按照模板批量导入。参数名字：是指选填项或必填项的名称，例如必填项为姓名，参数名字是name；必填项为邮箱，参数名字是email。描述：对参数进行描述。是否必填：该参数是否是必须填还是选填。类型：该参数的数据类型；默认值：该参数对应的默认数据。

例如：可以将被测API的url、参数及其属性填写到Excel模板表中，便于批量导入。

模板格式除Excel表格外，还可以是Json/xml格式。

S3，根据预设信息调用预设的素材库或预设的方法库，并选择构建方式，构建API的测试用例；

在某实施例中，如图3所示，用例构建就是构建API测试用例。构建API测试用例包括两部分：参数赋值和生成用例。其构建步骤如下：

(1)逐个读取被测API基本信息和参数；

(2)判断参数类型是否为文件，若为文件，则调用素材库，否则调用方法库，根据对应的所述素材库或方法库对所述参数进行赋值；

(3)判断是否存在未赋值的参数，若是，则返回第(1)步；若否，则表明参数取值完成，可直接选择用例构建方式；

(4)判断用例构建方式是否为复杂型构建方式，若否，则按照简单型方式构建方式自动生成测试用例；若是则按照复杂型构建方式自动生成测试用例。

在某实施例中，还可以根据以下步骤构建用例：

(1)逐个读取被测API基本信息和参数；

(2)判断参数类型是否为文件，若为文件，则调用素材库，否则调用方法库，根据对应的所述素材库或方法库对所述参数进行赋值；

(3)判断是否存在未赋值的参数，若是，则返回第(1)步；若否，则表明参数取值完成；

(4)判断参数的值是否正确，若是，则进入第(5)步；若否，则返回第(1)步；

(5)判断用例构建方式是否为复杂型构建方式，若否，则按照简单型方式构建方式自动生成测试用例；若是则按照复杂型构建方式自动生成测试用例。

S4，执行API的测试用例，具体包括：单条执行或批量执行，将API的测试用例的执行结果保存到测试结果库中。

自动执行测试用例，包括单条执行和批量执行两种。

某实施例中，例如，用mysql数据库存储数据，在执行用例时，可以单独执行某一条测试用例，也可在系统中选中要执行的用例进行批量执行。

用例执行的测试结果保存到API用例测试结果库中，以便于后续分析。

根据预设信息调用素材库或方法库，并选择构建方式，构建API的测试用例，使得测试工程师无需查找素材和方法，系统根据参数类型直接调用素材库或方法库，大大节省了测试工程师的时间，实现用例的自动构建，提高了测试用例的质量；从新建一个测试项目到用例构建、用例执行，不但实现了自动化测试，还提高了整个测试开发过程的效率。

优选地，在上述任意实施例中，S3，具体包括：

S31，逐个读取预设信息，预设信息包括：API基本信息和参数；

S32，判断参数的类型是否为文件，若为文件，则调用素材库，否则调用方法库，根据对应的所述素材库或方法库对所述参数进行赋值；

根据参数的不同类型，选择调用素材库还是方法库来自动生成参数，完成参数赋值；参数的赋值结果提供查看及修改功能；

S33，判断是否存在未赋值的参数，若是，则返回S31步；若否，则参数取值完成；

S34，判断用例构建方式是否为复杂型构建方式，若否，则按照简单型构建方式自动生成测试用例；若是，则按照复杂型构建方式自动生成测试用例。

某实施例中，当被测API的参数类型为图片文件，调用素材库中的数据，根据图片文件格式、数据量大小等进行参数赋值。对图片文件的文件格式、数据大小的赋值结果可以查看还可以再修改。

通过参数调用素材库或者方法库，不仅有正常场景，还有相应参数类型的各种异常场景。通过判断参数类型，可以自动匹配正、异常场景，可以生成尽可能多的测试用例，提高用例覆盖率；通过简单型构建方式或者复杂型构建方式，使得建立的测试用例，能够适应不同的测试项目需求。

优选地，在上述任意实施例中，素材库包括多个类型的数据，多个类型的数据按照数据类型进行分类，每种类型的数据包括正常场景和异常场景；方法库包括多种黑盒测试方法，多种黑盒测试方法按照方法库中的数据类型进行分类，每种类型的数据包括正常场景和异常场景。其中正常场景表示选填项或必填项的正常情况，异常场景表示选填项或必填项的非正常情况；例如：在某实施例中，选填项为身高：参数名称height、参数类型为int、默认值168；则参数正常场景为168，异常场景可以选：a、空、空格、-1、0、10.1、@等。

在某实施例中，素材库中包含各种类型的数据，比如：图片可以包括格式：bmp，gif，ico，jpeg，jpg，png，psd，tga，tif和webp等；视频可以包括格式：avi,flv,mkv，mov，mp4，mpg，qsv，webm和wmv等；文档可以包括格式：pdf，ppt，txt，word和xlsx等；各种大小的数据，比如：10G、1G、500M、1M、500K、1K等；各种异常数据，比如：空文件、损坏文件等，素材库按照数据的类型进行分类，每种类型的数据均包含正常和异常场景。

方法库中包含边界值、等价类、错误推测法、随机数法、场景法等黑盒测试方法，方法库按照数据类型进行分类，每种类型的数据均包含正常和异常场景。

由于每个API的参数数量不一致，因此需要判断是否存在未赋值的参数，若不存在则代表该API的所有参数都遍历了一遍，完成了参数赋值。另外，参数赋值结果，用户可根据自动赋值的结果进行编辑、补充、完善参数值，并进行保存。

在素材库或者方法库中，不仅有正常场景，还有相应参数类型的各种异常场景。通过判断参数类型，可以自动匹配正、异常场景，可以生成尽可能多的测试用例，提高用例覆盖率，更易找出API接口存在的问题及缺陷，进一步提高了测试效率。

优选地，在上述任意实施例中，简单型构建方式是部分量构建，包括每个参数的正常场景和异常场景；

复杂型构建方式是全量构建，包括每个参数的单一测试场景、所有接口参数的组合场景和其他参数间的组合场景。

在某实施例中，为减少漏测问题，测试用例可以以excle表格方式进行导出/导入，方便用例批量操作。

用例构建策略提供了两种方式，一种是简单型，一种是复杂型。

简单型构建方式：简单型构建方式构建的测试用例在构建时，每个参数均考虑了正常和异常场景，并且每个异常场景均考虑了多种异常数据，尽量做到使用例既简单、数量少，又全面，即能包含各种主要的测试场景，提高测试效率。当项目比较紧急，仅有较短的测试时间，可以选用此方式构建用例。

复杂型构建方式：复杂型构建方式是全量构建的一种方法，不仅包含了每个参数的单一测试场景和所有接口参数的组合场景，还包含了可选参数间的各种组合方式，自动构建的用例数据量较大，尽可能多的做到全量测试，发现隐藏的问题。当项目有较长的测试时间时，可以选用此方式构建用例。

在某实施例中，选用某网站注册API作为实例——必填项为姓名：参数名称name、参数类型string、默认值test；必填项为年龄：参数名称age、参数类型为int、默认值20；选填项为身高：参数名称height、参数类型为int、默认值168；选填项为邮箱：参数名称email、参数类型string、默认值888@qq.com；选填项为电话：参数名称phone、参数类型string、默认值18506386521；根据方法库，针对int型数据可以选：a、空、空格、-1、0、10.1、@等作为异常情况的输入值，针对string型数据可以选％、空、空格、2123928478、超长字符等作为异常情况的输入参数。以生成尽可能多的测试用例，达到提高用例覆盖率，提高测试结果可靠性的目的。

simple方式构建用例可以包括如下组合方式：

1.必填项的正、异常场景之间进行穷尽的排列组合，选填项：不赋值；

2.必填项：均为正常场景，任一选填项：正常及异常场景进行组合，直至所有选填项均能参与用例组合；

3.必填项和选填项全部为正常场景的组合；

4.必填项和选填项全部为缺省的组合。

某实施例中，选用某网站注册API作为实例，该例中有两个必填项，三个选填项，则用例组合方式如表1所示：

表1simple方式用例组合示例

注：表中正常场景一般指默认值，默认值可以是一个也可以是多个；异常场景则根据不同参数的类型选取不同的数据，当组合中仅有一个异常场景时，该异常场景应遍历所有异常数据，当组合中有两个及以上的异常场景时，该异常场景仅取第一个异常数据。

具体的按选用某网站注册API作为实例，simple方式进行用例组合，如表2所示：

表2simple方式具体的用例组合示例

参数类型	string	int	int	string	string
						用例序号	name	age	height	email	phone
1	test	20
						2	％	20
3	空	20
						4	空格	20
5	2123928478	20
						6	超长字符	20
7	test	a
						8	test	空
9	test	空格
						10	test	-1
11	test	0
						12	test	10.1
13	test	@
						14	％	a
15	test	20	168
						16	test	20	a
17	test	20	空
						18	test	20	空格
19	test	20	-1
						20	test	20	0
21	test	20	10.1
						22	test	20	@
23	test	20		888@qq.com
						24	test	20		％
25	test	20		空
						26	test	20		空格
27	test	20		2123928478
						28	test	20		超长字符
29	test	20			18506386521
						30	test	20			％
31	test	20			空
						32	test	20			空格
33	test	20			2123928478
						34	test	20			超长字符
35	test	20	168	888@qq.com	18506386521

注：name的默认值test；age的默认值20；height的默认值168；email的默认值888@qq.com；phone的默认值18506386521，以默认值作为正常场景。针对int型数据会选{a、空、空格、-1、0、10.1、@}作为异常场景的输入参数，针对string型数据会选{％、空、空格、2123928478、超长字符}作为异常场景的输入参数。

complex方式是多个影响因子通过排列组合方式进行有机结合，用complex方式构建的测试用例是在simple方式的基础上，增加一些选填项的排列组合。即用complex方式构建组合原则是，如表3所示：

1.必填项正常、异常场景之间进行穷尽的排列组合，选填项：不赋值；

2.必填项均为正常场景，选填项：正常、异常之间进行穷尽的排列组合；

3.必填项和选填项全部为缺省的用例。

表3complex方式用例组合示例

注：表中正常场景一般指默认值，默认值可以是一个也可以是多个；异常场景则根据不同参数的类型选取不同的数据，当组合中仅有一个异常场景时，该异常场景应遍历所有异常数据，当组合中有两个及以上的异常场景时，该异常场景仅取第一个异常数据。

简单型构建方式在构建测试用例时，每个参数均考虑了正常和异常场景，并且每个异常场景均考虑了多种异常数据，尽量做到使用例既简单、数量少，又能包含各种主要的测试场景，使得在测试项目比较紧急，仅有较短的测试时间时，也能尽可能多的找出Bug。复杂型构建方式不仅包含简单型方式构建的用例，同时还包含了可选参数间的穷尽组合方式，自动构建的用例数据量较大，尽可能多的做到全量测试，发现隐藏的问题。当项目有较长的测试时间时，可以选用此方式构建用例。两种构建用例的方式，以适应不同的测试项目需求。

优选地，在上述任意实施例中，如图5所示，在S4之后，还包括：S5，判断测试结果是否正确，若是，将正确的测试结果与测试用例存入回归库中，若否，将错误的测试结果与测试用例自动发送给测试项目人员，并做出测试报告。

用例结果的判断与执行可以判断用例结果的准确与否，并进行标记，正确的测试结果与测试用例进入回归库中，为回归测试提供有效的测试用例；错误的测试结果与测试用例则将通过邮件自动发送给项目相关人员；本步骤中产出测试报告，报告中包括测试正确率、严重程度等。严重程度可以分为：崩溃、严重、一般和建议。

利用程序自动判断用例测试结果库中的测试结果，如图2所示，判断的过程可以为：

(1)逐条读取测试结果库中的数据；

(2)判断http返回状态码是否属于错误码库，错误码库中包含各种错误码，如500、404等，若http返回状态码存在错误码库中，则表明测试结果错误，将该条信息保存到Bug库；反之，若http返回状态码不存在错误码库中，则不能据此判断结果即为正确，将该条信息放到待核查数据库，以便于后续人工进一步核查；

(3)判断测试结果库是否还有数据，若有，则转到第(1)步，若无，则人工核查返回内容；

(4)判断返回内容是否正确，若正确，则将测试用例和测试结果保存到回归库；若错误，则将测试用例和测试结果保存到Bug库；

(5)判断待核查库是否还有待核查内容，若有，则转到第(3)步，若无，则将Bug库中的Bug信息以邮件方式发送给项目人员。

Bug库可以进行管理，例如，进行Bug信息统计分析、去重、更新、导出等操作。

邮件发送单元能直接从Bug库中调用数据，发送给项目人员。

Bug库+邮件发送单元能避免重复提出Bug，给开发人员造成麻烦。

通过对测试结果进行分析判断，将正确的测试结果和测试用例存入回归库，将错误的测试结果和测试用例发送给测试项目人员，实行机器判断+人工核查模式，使找出的Bug更精确、更多，提高测试质量；建立回归库，对每次执行结果进行标记，并根据标记结果自动分拣到测试回归库，缩短了回归周期，提高整个测试过程的效率。

在回归库中，对每次执行结果进行标记，并根据标记结果将正确的测试用例以及测试结果自动分拣到回归库，每次进行回归测试时可以直接调用回归库中的测试用例，并将该测试用例的执行结果与回归库中原有的测试结果进行比对。若比对一致，无需更新；若不一致，如有可能改出Bug，需要人工核查返回值，并将判断出的正确结果和测试用例保存到回归库，即回归库中均保存最新的测试结果，建立回归库可大幅缩短回归周期，提高整个测试开发过程的效率。

优选地，在上述任意实施例中，如图6所示，在S5之后，还包括：S6，根据测试结果，更新素材库或方法库。

在某实施例中，如图4所示，素材库/方法库更新过程可以为：

(1)每个项目完成测试后，均需要对素材库和方法库进行更新。

(2)测试过程中，会将用户输入的默认值及修改的参数赋值保存在默认值库中，包括文件以及一些测试数据。

(3)调用默认库中的内容与素材库/方法库中的内容进行比对；

(4)判断素材库/方法库中是否有默认库中内容，若否，则将该默认库中的数据添加到素材库/方法库中，对素材库/方法库进行更新；反之，判断默认库中是否还存在未比较的对象；

(5)判断默认库中是否还存在未比较对象，若是，返回第(3)步，否则结束。

通过更新素材库/方法库的目的在于进一步丰富完善素材库/方法库，使素材库在后续API接口测试时，能测的更全面，测试结果更可靠、更有价值，提高整个测试开发过程的效率。

在某一实施例中，给出了一种API接口的自动化测试系统，如图7所示，该系统包括：

项目管理模块11、API管理模块12、用例构建模块13和用例执行模块14；

项目管理模块11用于新建或编辑项目；

API管理模块12用于对API进行增、删、改、查，具体用于输入API对应的预设信息；

用例构建模块13根据预设信息调用预设的素材库或预设的方法库，并选择构建方式，构建API的测试用例；

用例执行模块14用于按照设定的程序批量或单个执行API的测试用例，并将API的测试用例的执行结果保存到用例测试结果库中。

优选地，在上述任意实施例中，用例构建模块13具体用于逐个读取预设信息，预设信息包括：API基本信息和参数；判断参数的类型是否为文件，若为文件，则调用素材库，否则调用方法库，根据对应的所述素材库或方法库对所述参数进行赋值；判断是否存在未赋值的参数，若是，则继续逐个读取预设信息，重新判断；若否，则参数取值完成；判断用例构建方式是否为复杂型构建方式，若否，则按照简单型构建方式自动生成测试用例；若是，则按照复杂型构建方式自动生成测试用例。

通过参数调用素材库或者方法库，不仅有正常场景，还有相应参数类型的各种异常场景。通过判断参数类型，可以自动匹配正、异常场景，可以生成尽可能多的测试用例，提高用例覆盖率；通过简单型构建方式或者复杂型构建方式，使得建立的测试用例，能够适应不同的测试项目需求。

优选地，在上述任意实施例中，素材库包括多个类型的数据，多个类型的数据按照数据类型进行分类，每种类型的数据包括正常场景和异常场景；方法库包括多种黑盒测试方法，多种黑盒测试方法按照方法库中的数据类型进行分类，每种类型的数据包括正常场景和异常场景。

优选地，在上述任意实施例中，简单型构建方式是部分量构建，包括每个参数的正常场景和异常场景；

复杂型构建方式是全量构建，包括每个参数的单一测试场景、所有接口参数的组合场景和其他参数间的组合场景。

优选地，在上述任意实施例中，如图8所示系统还包括：用例测试结果分析与处理模块15用于判断测试结果是否正确，若是，将正确的测试结果与测试用例存入回归库中，若否，将错误的测试结果与测试用例自动发送给测试项目人员，并做出测试报告。

用例结果的判断与执行可以判断用例结果的准确与否，并进行标记，正确的测试结果与测试用例进入回归库中，为回归测试提供有效的测试用例；错误的测试结果与测试用例则将通过邮件自动发送给项目相关人员；本步骤中产出测试报告，报告中包括测试正确率、严重程度等。严重程度可以分为：崩溃、严重、一般和建议。

优选地，在上述任意实施例中，如图9所示，系统还包括：更新模块16用于根据测试结果，更新素材库或方法库。

通过更新素材库/方法库的目的在于进一步丰富完善素材库/方法库，使素材库在后续API接口测试时，能测的更全面，测试结果更可靠、更有价值，提高整个测试开发过程的效率。

可以理解，在一些实施例中，可以包含如上述各实施例中的部分或全部可选实施方式。

需要说明的是，上述各实施例是与在先方法实施例对应的产品实施例，对于产品实施例中各可选实施方式的说明可以参考上述各方法实施例中的对应说明，在此不再赘述。

读者应理解，在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

在本方案所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的方法实施例仅仅是示意性的，例如，步骤的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个步骤可以结合或者可以集成到另一个步骤，或一些特征可以忽略，或不执行。

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

以上，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以权利要求的保护范围为准。

Claims (10)

1.一种API接口的自动化测试方法，其特征在于，包括：

S1，根据新建的测试项目，建立对应的API；

S2，获取所述API对应的预设信息；

S3，根据所述预设信息调用预设的素材库或预设的方法库，并选择构建方式，构建所述API的测试用例；

S4，执行所述API的测试用例，具体包括：单条执行或批量执行，将所述API的测试用例的执行结果保存到测试结果库中。

2.根据权利要求1所述的一种API接口的自动化测试方法，其特征在于，所述S3，具体包括：

S31，逐个读取所述预设信息，所述预设信息包括：API基本信息和参数；

S32，判断所述参数的类型是否为文件，若为文件，则调用素材库，否则调用方法库，根据对应的所述素材库或方法库对所述参数进行赋值；

S33，判断是否存在未赋值的参数，若是，则返回S31步；若否，则参数取值完成；

S34，判断用例构建方式是否为复杂型构建方式，若否，则按照简单型构建方式自动生成所述测试用例；若是，则按照复杂型构建方式自动生成所述测试用例。

3.根据权利要求2所述的一种API接口的自动化测试方法，其特征在于，所述素材库包括多个类型的数据，所述多个类型的数据按照数据类型进行分类，每种类型的数据包括正常场景和异常场景；所述方法库包括多种黑盒测试方法，所述多种黑盒测试方法按照所述方法库中的数据类型进行分类，每种类型的数据包括正常场景和异常场景。

4.根据权利要求3所述的一种API接口的自动化测试方法，其特征在于，所述简单型构建方式是部分量构建，包括每个参数的正常场景和异常场景；

所述复杂型构建方式是全量构建，包括每个参数的单一测试场景、所有接口参数的组合场景和其他参数间的组合场景。

5.根据权利要求1-4任一项所述的一种API接口的自动化测试方法，其特征在于，在所述S4之后，还包括：S5，判断所述测试结果是否正确，若是，将正确的测试结果与测试用例存入回归库中，若否，将错误的测试结果与测试用例自动发送给所述测试项目人员，并做出测试报告。

6.一种API接口的自动化测试系统，其特征在于，包括：项目管理模块、API管理模块、用例构建模块和用例执行模块；

所述项目管理模块用于新建或编辑项目，建立对应的API；

所述API管理模块用于获取所述API对应的预设信息；

所述用例构建模块根据所述预设信息调用预设的素材库或预设的方法库，并选择构建方式，构建所述API的测试用例；

所述用例执行模块用于按照设定的程序批量或单个执行所述API的测试用例，并将所述API的测试用例的执行结果保存到用例测试结果库中。

7.根据权利要求6所述的一种API接口的自动化测试系统，其特征在于，所述用例构建模块具体用于逐个读取所述预设信息，所述预设信息包括：API基本信息和参数；判断所述参数的类型是否为文件，若为文件，则调用素材库，否则调用方法库，根据对应的所述素材库或方法库对所述参数进行赋值；判断是否存在未赋值的参数，若是，则继续逐个读取所述预设信息，重新判断；若否，则参数取值完成；判断用例构建方式是否为复杂型构建方式，若否，则按照简单型构建方式自动生成所述测试用例；若是，则按照复杂型构建方式自动生成所述测试用例。

8.根据权利要求7所述的一种API接口的自动化测试系统，其特征在于，所述素材库包括多个类型的数据，所述多个类型的数据按照数据类型进行分类，每种类型的数据包括正常场景和异常场景；所述方法库包括多种黑盒测试方法，所述多种黑盒测试方法按照所述方法库中的数据类型进行分类，每种类型的数据包括正常场景和异常场景。

9.根据权利要求8所述的一种API接口的自动化测试系统，其特征在于，所述简单型构建方式是部分量构建，包括每个参数的正常场景和异常场景；

所述复杂型构建方式是全量构建，包括每个参数的单一测试场景、所有接口参数的组合场景和其他参数间的组合场景。

10.根据权利要求6-9任一项所述的一种API接口的自动化测试系统，其特征在于，所述系统还包括：用例测试结果分析与处理模块用于判断所述测试结果是否正确，若是，将正确的测试结果与测试用例存入回归库中，若否，将错误的测试结果与测试用例自动发送给所述测试项目人员，并做出测试报告。

Images