CN117215910A - 接口测试框架生成方法、测试方法、电子设备及存储介质 - Google Patents

Abstract

本申请涉及软件测试领域，提供了一种接口测试框架生成方法、测试方法、电子设备及存储介质，方法包括：获取的http请求包，并转化为接口模板；对接口模板进行维护、分类，并设置业务属性；使用接口模板构造多种用例场景，形成包含多个测试用例的用例库；将测试用例进行组合，形成适配不同场景的测试集合；定义接口，并设计该接口调用后的返回参数。本方案对接口模板进行高效维护；使用接口模板快速构造用例场景；对接口测试的参数进行维护实现接口关联接口测试用例的无缝拼接；测试人员只要选取模板即可使用，对模板进行编排即可实现接口测试自动参数获取，自动入参，自动获取返回结果，提高了工作效率减少了重复开发的人力投入。

Description

接口测试框架生成方法、测试方法、电子设备及存储介质

技术领域

本申请涉及软件测试技术领域，尤其是涉及一种接口测试框架生成方法、测试方法、电子设备及存储介质。

背景技术

接口测试是测试***组件间接口的一种测试，主要用于检测外部***与***之间以及内部各个子***之间的交互点。其测试的重点是要检查数据的交换，传递和控制管理过程，以及***间的相互逻辑依赖关系等。当前的接口测试框架可以分为线性自动化测试框架、模块化自动化测试框架、库体系自动化测试框架、数据驱动自动化测试框架、关键字驱动自动化测试框架及混合自动化测试框架。

其中，线性自动化测试框架它是一种基本的入门级测试框架。测试人员按照顺序创建和编写测试脚本，针对每个测试用例分别执行该脚本，从而进行记录和回放。最适合小型功能或应用，优点是流程快速简单。而数据驱动自动化测试框架它是将测试脚本代码逻辑与测试数据分开维护，其允许测试人员将测试数据维护在外部文档、配置或者数据库中。当测试人员需要执行测试时只要将准备好的数据与结构化的测试脚本结合就可以执行测试，使测试脚本实现了最大限度的可重用性。由于数据没有硬编码到脚本中，因此可以根据需要简单对脚本进行更改，而不必同时处理数据。因此测试更加快速和高效。

但是，线性自动化测试框架的硬编码数据已内置在测试脚本中，导致其脚本无法重复使用，需要手动对参数进行处理，效率不高。而数据驱动自动化测试框架，其前期需要对测试脚本进行分层设计和大量的基础封装，这种框架更加复杂，初始建立时间较长，要求测试人员具有丰富编码经验，其对测试人员要求较高，导致人力成本较高。

发明内容

为了有助于改善现有接口测试中重复开发、框架建立对人员要求较高的问题，本申请提供了一种接口测试框架生成方法、电子设备及存储介质。

第一方面，本申请提供一种接口测试框架生成方法，采用如下的技术方案：

S10：获取的http请求包，并转化为接口模板；

S20：对接口模板进行维护、分类，并设置业务属性；

S30：使用接口模板构造多种用例场景，形成包含多个测试用例的用例库；

S40：将测试用例进行组合，形成适配不同场景的测试集合；

S50：定义接口，并设计该接口调用后的返回参数。

通过采用上述技术方案，脚本可重复利用、测试参数的自动填充，测试效率高，且可减少了重复开发的人力投入。

第二方面，本申请提出了一种接口测试方法，包括步骤：

运行如上所述的接口测试框架生成方法所生成接口测试框架；

将用户关联的需求转化为测试任务，并进行测试；

形成测试报告，对测试报告进行存档、展示、推送和\或告警。

第三方面，本申请提供一种电子设备，采用如下的技术方案：

一种电子设备，该电子设备包括：

至少一个处理器；

存储器；

至少一个应用程序，其中至少一个应用程序被存储在存储器中并被配置为由至少一个处理器执行，所述至少一个应用程序配置用于：执行接口测试框架生成方法。

第四方面，本申请提供一种计算机可读存储介质，采用如下的技术方案：

一种计算机可读存储介质，其上存储有计算机程序，当所述计算机程序在计算机中执行时，令所述计算机执行第一方面提供的任一种接口测试框架生成方法。

综上所述，本技术方案将接口报文录下来后通过加工形成模板，实现了自动签名、自动参数化、自动添加基础断言、自动提取关键参数，形成了接口测试模板，形成了测试用例的录制，实现了测试脚本的快速开发；测试人员使用时只要选取模板即可使用，大大提高了工作效率；接口测试框架通过脚本转化可以直接对接jmeter等测试工具，减少了重复开发的人力投入。

附图说明

图1是本申请实施例提供的一种接口测试框架生成方法的流程示意图；

图2是本申请实施例提供的接口测试框架示意图；

图3是本申请实施例提供的参数填充与获取逻辑示意图；

图4是本申请实施例提供的一种电子设备的原理示意图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图1-4及实施例，对本申请进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本申请，并不用于限定本申请。

本申请实施例提供一种接口测试框架生成方法，用于软件测试***中。

具体参照图1，一种接口测试框架生成方法，该法包括：

S10：获取的http请求包，并自动转化为接口模板；

其中，步骤S10中还包括以下步骤：

建立参数池，将需要参数化的变量放置于参数池中；

变量的初始值为空，当获取到数据模板时，为参数池的变量赋值；

预设映射关系表，当一变量被赋值，其映射关系的变量也同步进行赋值；

当参数传输至其他接口模板时，接口模板的参数在测试执行过程中进行替换；查找与参数的变量名或别名相匹配的参数，如无匹配的参数，则使用默认参数进行测试。

将测试工具的所有测试组件拆分成对应的xml节点，每个xml节点通过一个类型区分，定义每个xml节点需要传入的参数；执行接口测试时，如有数据模板，则替换参数；如无数据模板，则使用默认参数；

将脚本以数据的形式存在数据库中。

S20：对接口模板进行维护、分类，并设置业务属性；

S30：使用接口模板构造多种用例场景，形成包含多个测试用例的用例库；

S40：将测试用例进行组合，形成适配不同场景的测试集合；

S50：定义接口，并设计该接口调用后的返回参数；当调用该模板后，如变量名一致，则传入参数；如果变量名不一致，则将参数池的变量与映射关系变量比对，比对成功后将变量对接到对应测试的接口中。

本技术方案将接口报文录下来后通过加工形成模板，实现了自动签名、自动参数化、自动添加基础断言、自动提取关键参数，形成了接口测试模板，形成了测试用例的录制，实现了测试脚本的快速开发；测试人员使用时只要选取模板即可使用，大大提高了工作效率；接口测试框架通过脚本转化可以直接对接jmeter等测试工具，减少了重复开发的人力投入。

在本发明实施例的基础上，进一步地，每一参数池中的参数都设有变量名及类型；

类型包括由多个接口使用的公有类参数及由特定一接口使用的私有类参数；

当两个接口参数重名时，使用私有类参数进行定义；

当同时匹配到两种类型的参数时，选择私有类参数；

当多个接口使用同一个参数且参数名互不相同时，为参数定义对应数量的别名。

在本发明实施例中，由于许多接口的断言是一致的，其也会用到相同的方法，通过统一封装和调用，将状态码、json对象处理结果、预设参数及预设业务状态中的相同断言进行统一封装。

本发明还提出了一种接口测试方法，包括步骤：

运行如上所述的接口测试框架生成方法所生成接口测试框架；

将用户关联的需求转化为测试任务，并进行测试；

对测试报告进行存档、展示、推送和\或告警。

该方案通过接口录制器实现了接口测试脚本的快速录制生成，并根据参数池对接口进行自动参数化。在执行脚本的过程中通过拉取数据模板实现测试参数的自动填充，填充时根据参数池匹配到变量名后填充。测试模板的参数化和测试参数池的管理，实现了接口测试脚本的无缝对接。

参照附图2及附图3所示的，本发明另一实施例提出的接口测试框架，采用分层设计的方式将接口测试框架分为：测试对象录制器、测试对象层、测试用例层、测试集合层、测试方法层、数据层(包括文件数据源，数据库数据源及数据模板)、断言层、测试脚本转化器、测试参数池、测试报告。

第一部分为测试对象录制器，用于测试脚本的录制，将抓到的http请求包进行编辑和改造，并自动转成测试模板。

编写脚本转换逻辑，将模板转换成jmeter脚本，当然，此步骤也可以可在后端进行处理，用户在组合脚本完成后调用脚本转换方法进行脚本转换，此步骤的具体设计如下：

首先将jmeter的所有测试组件拆分成对应的xml节点，每个节点通过一个类型来区分，定义每个节点需要传入的参数。脚本中存在的可参数化的key无需编辑。接口测试执行过程中：如果获取数据模板，参数则自动替换；如果没有获取数据模板，则使用默认自带的参数。

后端的判断逻辑设计为：首先建立变量池，根据业务特性分析哪些参数需要参数化，将其放在变量池中，初始化值为空，当获取到数据模板就给变量池的变量赋值。

维护映射关系表，如果一个变量被赋值映射关系变量同时赋值，参数传给其他接口模板时，接口模板的参数在测试执行过程中会进行替换优先找key名称或别名相匹配的变量，如果找不到就直接使用默认参数进行测试。

其次将用户的脚本以数据的方式存在数据库中，列举关键的字段信息如下：

case_id表示接口模板定义被哪个用例引用。

step_name用于存储测试用例的名称，通常记录一个接口测试场景的名称。

step_url用于存储接口测的url，通常在接口测试过程中不填写具体的url字符，而是全局变量。

step_status用于存储接口的状态，在前端维护时，可以设置执行或不执行，以方便调试或注释。

step_body用于存储接口的body，通常不需要编写，由录制时自动带入。

step_header用于存储接口的请求头信息，通常不需要编写，由录制时自动带入。

step_method用于存储接口的请求方法类型，通常不需要编写，由录制时自动带入。

step_port用于存储接口请求的端口，通常不需要编写，由录制时自动带入。

step_path用于存储接口的path，通常不需要编写，由录制时自动带入。

step_param用于存储接口请求的url参数，通常不需要编写，由录制时自动带入。

step_id表示接口模板定义的id用户，方便测试用例的增加、删减、改写、查询等维护。

get_param表示需要从接口请求的返回结果中获取哪些信息，可使用正则、jsonpath等抓取方式，同时支持自定义代码抓取所需要的测试数据。

step_type表示记录的是接口模板、逻辑控制器还是数据模板。

step_discribe用于编写自定义后置处理代码，由于本实施例对接的是jmeter测试工具，故本实施例中仅支持java脚本。

第二部分为测试对象层，此层为维护接口录制器所录制的接口定义模板，对接口模板进行维护和归类，并可设置属性，例如：接口名称如何命名、接口的用途、需要使用什么样的配置和公参等。

第三部分为测试用例层，此层将拉入接口定义模板，并构造各种用例场景，例如：正确的输入一个用例、错误的输入一个用例等，并将用例维护为一个用例库。

第四部分为测试集合层，此层可将测试用例进行组合，形成各种测试集合来执行各种流程场景测试。

第五部分为测试方法层，此层可封装常用的测试方法，例如：字符的处理、对象的处理、字符格式化序列化、参数的提取、参数的计算和维护等。

第六部分为测试数据层，此层主要提供数据源的处理，用于帮助测试人员获取批量的测试数据，从数据库获取、从csv获取、从redis和mongdb获取数据等。

此层具体的设计方式为：定义一个接口，并设计该接口调用后返回的参数，在前端将接口模板显示为一个前端控件，例如：需要一本任意科普类型的书，价格不低于10元，且不参与打折，接口处理完后固定返回一本书的id、价格及章节信息。

当用户调用此模板后：如变量名一致，则无缝传入；如果变量名不一致，则将变量池的变量与映射列表进行比对，映射成功后将变量无缝对接到所需测试的接口中。

第七部分为断言层，由于许多接口的断言是一致、通用的，且也会用到相同的断言方法，故通过统一封装和调用可以将状态码、json对象处理结果、特定属性和参数、特定的业务状态等相同的断言进行统一封装。

第八部分为测试报告，此层实现了测试报告的存档和展示，同时也包括了测试报告推送和告警，便于测试人员进行问题排查，问题可及时告知相关人员，并提供测试报告，以向管理人员反馈长期的软件质量趋势和测试接口测试执行情况。

测试执行器将测试结果推送给kafka，每个队列带有测试报告的id、case的id及其他属性，测试报告实时的从kafka将测试结果同步到测试报告中。

第九部分为测试脚本转换器，当用户运行测试时，其会根据用户脚本主键关联的case或者场景转化成测试任务推送给kafka，其生成jmeter测试脚本放置在对应的目录。测试执行为全天候监控队列，当监控到kafka中的任务，则获取队列中的脚本路径信息并执行。当然，执行器中还集成了定时任务模块，以进行定时任务。

本实施例的技术方案，通过接口录制器实现了接口测试脚本的快速录制生成，并根据参数池对接口进行自动参数化。在执行脚本的过程中通过拉取数据模板实现测试参数的自动填充，填充时根据变量池匹配到变量名后填充。测试模板的参数化和测试参数池管理实现了接口测试脚本的无缝对接。

本申请实施例还提供一种电子设备，如图4所示，图4所示的电子设备700包括：处理器701和存储器703。其中，处理器701和存储器703相连，如通过总线702相连。可选地，电子设备700还可以包括收发器704。需要说明的是，实际应用中收发器704不限于一个，该电子设备700的结构并不构成对本申请实施例的限定。

处理器701可以是CPU(Central Processing Unit，中央处理器)，通用处理器，DSP(Digital Signal Processor，数据信号处理器)，ASIC(Application SpecificIntegratedCircuit，专用集成电路)或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框，模块和电路。处理器701也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，DSP和微处理器的组合等。

总线702可包括一通路，在上述组件之间传送信息。总线702可以是PCI(Peripheral Component Interconnect，外设部件互连标准)总线或EISA(ExtendedIndustry Standard Architecture，扩展工业标准结构)总线等。总线702可以分为地址总线、数据总线等。为便于表示，图4中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

存储器703可以是ROM(Read Only Memory，只读存储器)或可存储静态信息和指令的其他类型的静态存储设备，RAM(Random Access Memory，随机存取存储器)或者可存储信息和指令的其他类型的动态存储设备，也可以是EEPROM(ElectricallyErasableProgrammable Read Only Memory，电可擦可编程只读存储器)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。

存储器703用于存储执行本申请方案的应用程序代码，并由处理器701来控制执行。处理器701用于执行存储器703中存储的应用程序代码，以实现前述方法实施例所示的内容。

其中，电子设备包括但不限于：移动电话、笔记本电脑、PDA(个人数字助理)、PAD(平板电脑)等等的移动终端以及诸如数字TV、台式计算机等等的固定终端。还可以为服务器等。图4示出的电子设备仅仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

本申请实施例还提供一种计算机可读存储介质，其上存储有计算机程序，当计算机程序在计算机中执行时，令计算机执行上述实施例提供的接口测试框架生成方法。

应该理解的是，虽然附图的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，其可以以其他的顺序执行。

以上仅是本申请的部分实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。

Claims (10)

1.一种接口测试框架生成方法，用于软件测试中，其特征在于，所述方法包括：

S10：获取的http请求包，并转化为接口模板；

S20：对接口模板进行维护、分类，并设置属性；

S30：使用接口模板构造多种用例场景，形成包含多个测试用例的用例库；

S40：将测试用例进行组合，形成适配不同场景的测试集合；

S50：定义接口，并设计该接口调用后的返回参数。

2.根据权利要求1所述的接口测试框架生成方法，其特征在于，步骤S10中：

S11：将测试工具的所有测试组件拆分成对应的xml节点，每个xml节点通过一个类型区分，定义每个xml节点需要传入的参数；

S12：将脚本以数据的形式存在数据库中。

3.根据权利要求2所述的接口测试框架生成方法，其特征在于，步骤S11中，执行接口测试时，如有数据模板，则替换参数；如无数据模板，则使用默认参数。

4.根据权利要求3所述的接口测试框架生成方法，其特征在于，步骤S11之前，还包括步骤：

建立参数池，将需要参数化的变量放置于参数池中；

变量的初始值为空，当获取到数据模板时，为参数池的变量赋值；

预设映射关系表，当一变量被赋值，其映射关系的变量也同步进行赋值。

5.根据权利要求4所述的接口测试框架生成方法，其特征在于，步骤S50中，当调用该模板后，如变量名一致，则传入参数；如果变量名不一致，则将参数池的变量与映射关系变量比对，比对成功后将变量对接到对应测试的接口中。

6.根据权利要求1所述的接口测试框架生成方法，其特征在于，每一参数池中的参数都设有变量名及类型；

所述类型为由多个接口使用的公有类参数或由特定一接口使用的私有类参数；

当两个接口参数重名时，使用私有类参数进行定义；

当同时匹配到两种类型的参数时，选择私有类参数；

当多个接口使用同一个参数且参数名互不相同时，为参数定义对应数量的别名。

7.根据权利要求1所述的接口测试框架生成方法，其特征在于，将状态码、json对象处理结果、预设参数及预设业务状态中的相同断言进行统一封装。

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

运行如权利要求1至7任一项所述的接口测试框架生成方法所生成接口测试框架；

将用户关联的需求转化为测试任务，并进行测试；

形成测试报告，对测试报告进行存档、展示、推送和\或告警。

9.一种电子设备，其特征在于，该电子设备包括：

至少一个处理器；

存储器；

至少一个应用程序，其中至少一个应用程序被存储在存储器中并被配置为由至少一个处理器执行，所述至少一个应用程序配置用于：执行权利要求1至7任一项所述的接口测试框架生成方法。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，当所述计算机程序在计算机中执行时，令所述计算机执行权利要求1至7任一项所述的接口测试框架生成方法。