基于模块化的接口协议测试平台设计与实现

陈威宇

（伦敦大学国王学院 信息学院，英国 伦敦 WC2R 2LS）

0 引言

接口是Web系统平台之间不同组成部分衔接的约定[1]，为了保证各接口运行的正确性和稳定性，开发完成的接口要先进行测试才能上线使用，接口测试的主要功能是用来检测各部分之间的交互点[2]，测试范围通常包括数据流的传递、交换和控制管理、功能的容错性及系统相互之间的逻辑依赖关系等等[3]。

接口测试属于功能测试的一类，测试流程也是测试人员根据接口文档定义的接口协议，设计接口测试用例，然后由执行人员执行测试。这也意味着每次都需要耗费很多精力和时间去编写这些测试报文[4]。参考文档的定义，这也意味着接口本身很容易存在一些描述上的缺陷，即接口信息不足而无法准确表达服务过程中的一些隐性约束限制条件，造成调用方和服务提供方对服务理解的不一致，导致用例设计错误或者用例覆盖不全面等问题，从而出现质量风险。

接口的测试方法多数是借助工具/框架，或者是通过编程语言去实现自定义的测试需求，现有的一些主流接口测试方法及实现方式存在以下的一些问题。（1）测试范围：多数测试方法，只能覆盖到接口表面的功能测试，无法深入接口内部进行一些更深层次的逻辑检查，比如接入数据库的数据更新或操作服务器模拟故障注入等行为，来提高接口测试场景的覆盖率；（2）测试效率：很多简单的接口测试工具/框架都可以做到快速完成接口测试工作，而且从效率上来看，UI > 脚本 > 编程语言，而测试覆盖率上，UI < 脚本 < 编程语言；综合分析可以看出覆盖范围越广的方法，实现效率上往往都比较低，即测试方法的能力水平通常与效率成反比；（3）测试门槛：通过UI操作的形式完成测试的执行要求相对较简单，入门门槛也比较低。但同样地，测试能覆盖的范围也相比脚本/代码实现的方法也小很多，而编写代码测试的门槛较高，这也意味着对执行人员的操作水平要求比较高，同时存在测试代码与测试框架无法分离的问题。另外，代码开发由于搭建调试运行环境，经常存在测试环境复杂的问题[5]。

接口协议包含的内容细分为以下几点：接口的功能、接口输入输出参数、服务之间的数据依赖与控制依赖关系，服务调用以及服务之间的协同合作所需的场景信息，场景执行完成预期结果的预言[6]。

考虑接口协议复杂的流程性和逻辑性，本文引入模块化的概念，模块化既是一种设计方法也是一种思维方式，Kirk Knoernschild[7]也强调过“分而治之”是解决复杂问题的有效方式。模块化在软件领域有着形式简单但意义比较深远的价值，有利于软件开发以及业务逻辑中比较复杂问题的解决[8]。

如今市场上的软件系统功能越来越复杂，迭代速度也越来越快，版本迭代速度和发布质量之间的矛盾也是日益突出。针对该问题，本文提出一种基于模块化的接口协议测试方法，它将接口协议抽象模块化成一个个单独的处理模块，每个模块单独负责一部分通用能力，让用户通过Web UI界面快速进行用例的编排操作，而后台则通过Python语言为其提供对应的强大的自动处理能力，让用户通过UI操作的方式就能达到纯语言开发的效果。本方法通过减少用户的协议参考、手工编写用例等时间，让用户聚焦于接口本身的具体逻辑流程，提升接口测试方法的覆盖率和测试速度，从而提升整体系统的交付质量和迭代速率。

从模块化的角度出发，把接口协议测试的过程，定义为“定义-组建-调用-检测”四部曲的方式，如图1所示。

图1 模块化接口协议测试过程

请求信息获取模块：该模块用于获取接口协议配置的请求信息(包括出入参数/调用依赖关系等)，并确定与所述信息相对应的一个或多个最小测试单元；场景用例组建模块：该模块按照测试顺序将所述的一个或多个最小测试单元组成场景测试用例；场景用例调用模块：该模块调用所述场景测试用例，通过所述场景用例执行待测试的接口协议，得到所述场景测试用例输出的响应数据；结果检测模块：该模块对所述响应数据进行结果检测，得到所述接口协议的测试结果。

1 系统平台方案设计

1.1 系统架构设计

图2所示是本接口协议测试平台的底层架构。其中，用户界面用于接收并显示用户的输入，以获取用于测试接口协议的请求信息，确定与请求信息相对应的一个或多个最小测试单元。场景用例中可以包括一个或多个最小测试单元，每个最小测试单元中均配置有元参数、预设输出数据和其他相关参数。平台中还包括有设置台和报告输出模块，设置台用于对平台进行界面设置，报告模块用于输出场景用例调用并执行完成之后产生的测试报告。平台支持的协议包括一些基础的函数调用功能、对响应数据进行结果检测的功能以及基础的脚本程序执行功能等。

图2 基于模块化的接口协议测试平台底层架构

平台的接口协议执行模块用于执行待测试的接口协议，其中包括API(application programming tnterface，应用程序接口)、CGI(common gateway interface，公共网关接口)、数据库以及脚本程序等功能模块，以及对最小测试单元的逻辑操作。例如，可以对场景用例中的某个最小测试单元配置逻辑操作参数，比如配置执行预设次数。假设预设次数为RunCount，初始的当前运行次数RunTime为0，每当完成一次对场景用例中的某个最小测试单元执行过程，则令RunTime自增加1，直到RunTime等于RunCount时，完成对该最小测试单元的预设次数的执行。平台的定时任务模块用于按照定时规则每隔预定时间调用最小测试单元。平台的异步接口模块用于执行测试步骤中的异步请求的相关事宜，可以根据逻辑关键字控制请求的执行过程，例如控制请求执行过程的条件判断、中断和循环等。平台的并行控制单元用于控制并行的请求任务同时执行。

数据中心中存储有场景用例调用过程中的全局变量、关联字段和一些用于进行结果检测的伪代码，例如“$res==0”就是判断检测变量$res是否等于预设输出数据0的伪代码，便于场景用例决定请求完成后的具体操作。

1.2 系统流程设计

一个场景用例从被调用开始,首先会载入CGI/API数据等测试平台预设好的元数据，其中包括了请求和应答的协议元数据，以便正确解析场景用例中的请求并应答。接着对场景用例中由各个请求组成的测试流程进行解析，以形成确定的测试顺序；再对场景用例中的数据进行解析，生成对应的变量支持后续测试进行。基于解析后的测试流程依次发起请求，并输出表示成功接收到该请求的应答回包。

测试过程需要判断当前请求是否为异步请求，若当前的请求是为异步请求，则将请求加入到异步测试队列中，同时开始执行该请求，并继续调用场景测试流程中的下一请求。若当前请求是同步请求，则直接执行该请求，等待该请求响应后，再调用下一请求。在异步测试队列中，需要每隔预设时间查询队列中的异步测试请求的任务状态(即轮询操作)，并在异步测试单元的任务已完成或超时的时候，生成响应信息。在请求响应之后，若响应信息中包括有数据，则将该数据输出到数据中心中存储，若响应信息中包括有函数调用，则将该响应信息输出到函数中心中调用执行对应的函数。

在请求生成响应信息之后，获取返回数据，执行对响应信息进行结果检测的步骤。其中，获取返回数据可以是包括以下几种方式：①脚本运行结果；②数据库访问指令的访问结果；③通过CGI接口获取外界的数据；④将响应信息输出到函数中心中调用对应的函数得到的计算结果。获得返回数据之后，可以执行结果检测，例如将返回数据与场景用例包含的预设输出数据进行匹配检测，并根据匹配结果输出测试结果。

事件桩用于在预设的特定条件下执行某个请求。当一个请求的测试结果输出之后，可能会触发事件桩执行特定的预设指令，例如重新发起该请求。在测试流程依次发起请求之后，也可以将其中的某个请求加载进事件桩中，等到某个预设条件下再执行该请求。事件桩还可以用于在场景用例开始/结束执行时调用事件、在最小测试单元开始/结束执行时调用事件、在结果检测开始/结束时调用事件等。其中，事件可以为请求、函数、指令或者脚本程序等，也可以是空操作。

在一个请求输出对应的测试结果之后，将判断场景用例是否结束，即判断场景用例中配置的所有最小测试单元是否均已执行完毕并得到对应的测试结果。若判定场景用例已结束，则根据所有最小测试单元对应的测试结果生成本次测试对应的输出报告并结束本次测试。否则，则根据测试流程继续发起或执行对应的请求。

图3是测试平台的测试流程示意图，展示了场景用例从被调用开始，到获得场景用例输出的返回数据，并根据数据分析计算得到接口协议的最终测试结果。

图3 测试平台流程示意图

1.3 系统流程设计

Django是一个基于MVT设计模式实现的Python Web框架，具有构建快速、功能强大、稳定等优点[9]。本文提出的测试平台是基于Django框架来搭建后台服务，在框架层面完成了包括但不限于用户鉴权、日志记录、序列化等通用基础功能，并通过装饰器形式对每个业务模块提供能力，这样的好处是开发过程中能更加聚焦每个模块具体业务逻辑的实现。

LayUI是一款遵循原生网页HTML/CSS/JS的书写与组织习惯的国产前端UI框架[10]。控制台的模块化能力主要是基于一款Web脑图可视化应用——My-Mind.js实现的，和LayUI搭载使用能快速方便地对我们场景用例的构建和调用进行可视化操作。前端页面和后台服务的请求负载均衡是通过Nginx[11]做反向代理实现的，数据是通过RESTful API[12]进行交互的。系统基于B/S架构[13]实现了前后端分离的结构，基于MVC模式[14]进行开发，目的也是降低系统各个组件间的耦合度。

存储方面，持久化数据使用了MySQL数据库进行存储，后台通过Django自带的ORM模型操作数据库实现增删改查。文件类数据则使用了腾讯云的对象存储服务COS，后台可以通过XML API或者腾讯云通用SDK完成COS的基础操作(包括读写改删等)。整体的系统实现如图4所示。

图4 接口协议测试平台系统实现架构

2 系统实现

以一次基于HTTP协议的GET请求为例，来详细说明由一个最小测试单元组成的场景测试用例的实现过程。该请求的数据格式见表1。

表1 接口协议请求数据格式

以请求“http://www.qq.com”为例，场景用例定义如图5所示。

图5 基于HTTP 协议的GET 请求示例

接口协议从请求信息获取模块解析到的参数数据如下：

{"url":"http://www.qq.com","headers":{"Content-Type":"application/json"},"version":"HTTP/1.1","met hod":"GET"}

通过场景用例组建模块组建这个最小的测试单元，并将组建后的场景测试用例通过接口协议执行模块进行调用，并返回结果。结果数据内容如下：

{"List":[[{"Request":{"url":"http://www.qq.com","headers":{"Content-Type":"application/json"},"version":"HTTP/1.1","method":"GET"},"Action":"Ht tpGet","Runtime":"1/1","StartTime":"","EndTime":"","Result":true,"Response":{"text":"…","code":200}}]],"Result":true,"Report":"/autotest/report/xxx","Begi nTime":"","EndTime":""}

请求获得返回数据之后，将返回数据赋值给检测变量$res，然后判断检测变量$res是否等于预设输出数据0。如果检测变量$res等于预设输出数据0，则判定请求对应的测试通过。反之，则判定此次测试失败。

此外，场景用例还可以包括一个或多个基于HTTP的POST请求，对远程服务器进行Shell操作请求，对MySQL的增删改查请求等，通过模块化操作可以提高复杂场景测试执行的便捷性和多样性。图6演示的就是模块化接口协议测试平台系统如何去构建一个复杂的场景测试用例。

图6 模块化接口协议测试平台

当任务测试完成后，平台会将各种测试数据及结果聚合成测试报告，并生成HTML邮件发送到用户在系统里预设好的邮箱，测试报告展示内容如图7所示。

图7 测试报告内容详情页

3 结论

本文基于模块化的思想，提出了一种“各司其职”的接口协议测试方法，并详细介绍了该方法的设计和实现思路。实践证明，该可视化平台的易操作性可以协助测试执行人员更好地保证产品的交付质量和交付节奏。

下一阶段的研究目标是期望针对不同的接口协议、不同的测试用例自动生成对应的测试场景，以此来进一步提高接口测试的工作效率和平台的自动化能力。