随着互联网技术的飞速发展, 敏捷开发模式逐渐地流行和成熟. 在敏捷开发的每次迭代中都需要对以前交付的功能进行回归测试. 手工回归测试不仅成本高, 而且测试难度也较大, 因此敏捷开发对自动化测试技术提出了强烈的需求^{[1, 2]}.

传统的接口自动化测试工具很大程度上为自动化测试提供了方便, 但大部分测试工具的扩展能力不足, 例如无法将测试结果生成HTML形式的测试报告后发送到指定的邮箱^[3]、无法并行测试等.

处理上述问题的核心在于如何利用自动化测试高效地完成一些重复性较强的接口测试工作, 同时具有良好的可扩展性, 以确保产品能够满足用户的需求和期望从而提高软件的质量^[4]. 文献[2,5,6]基于测试数据和脚本分离的思想, 提出了不同的接口自动化测试框架, 减少了测试时间, 有效提高了测试效率. 文献[7, 8]提出了不同的接口自动化测试方法, 采用不同的方式优化了测试用例的生成过程; 文献[9-11]设计并实现了针对不同环境下的接口测试平台, 用户可以方便地在平台中完成测试用例的编写、执行及测试结果的查看.

现有的自动化测试工具主要包括3类^[12]. 以JUnit、TestNg为代表的开源单元测试框架, 能够支持开发人员编写和运行单元测试用例, 用户需要编写白盒测试代码, 要求用户具有一定的编程能力; 以Postman为代表的接口自动化测试工具, 可用于编写、管理和执行HTTP接口的测试用例, 也需要用户编写测试代码, 且只能进行串行测试; 以Selenium、Appium 为代表的图形用户界面测试工具, 可录制用户在界面上的操作, 因为要求系统必须有用户界面, 所以不适用于中台和基础子系统的测试. 另外, 由于系统界面往往变更频繁, 因此已完成的用例可能在下个版本就不适用, 导致维护用例的成本较高.

考虑到GUI测试维护成本高、局限性较大的问题, 从接口测试切入自动化测试是较为可行的办法, 主要原因是: 接口测试的投入产出比相对较高, 能够实现较高的自动化率; 接口体现了系统的行为, 接口测试能够覆盖系统的业务规则; 接口易于测试, 且需要时可并行测试; 接口测试的适用范围较广, 适用于前台、中台、基础子系统等多种类型的系统的测试.

因此, 本文提出并实现了一个接口测试平台OLa. 同时, 创新性地提出了基于C/S模式的用例执行流程和基于参数识别的自动匹配校验方法, 解决了传统的自动化测试工具无法并行测试的问题, 提高了测试的效率和灵活性.

相比于传统的自动化测试工具, OLa的优势主要包括: 用例集支持并行测试, 在用例之间无相互依赖的情况下, 测试效率较高; 平台中预设了多种校验方式和校验方法, 能够满足不同情况下的测试要求, 具有较高的测试灵活性; 平台支持将测试评估结果生成HTML形式的报告并发送至指定的邮箱, 以便其他人员可以及时、方便地查看测试报告.

OLa的主要功能包括: 能够在图形化界面中录入用例的参数、校验方法和内容, 支持实时地查看测试结果; 预设了多种校验方式和校验方法, 用户可以选择不同的校验方法对同一用例进行测试; 将用例编排为用例集, 可用于回归测试、新需求验收等多种场景; 用例集支持串行测试和并行测试; 实现了不同用户的用例数据隔离, 同时用户也可以主动地将自己的用例集共享到团队的项目中供其他项目成员使用.

1 系统架构

OLa平台的Web端采用分层的架构模式, 由用户展示层、应用逻辑层和数据服务层构成, 如图1所示.

用户展示层使用Vue CLI脚手架快速搭建Vue项目, 基于当下流行的前端开发框架Vue构建用户界面^[13], 同时搭配Vue Router创建单页应用, 使用Vuex集中式存储和管理应用中所有组件的状态. Vue组件库选用了Ant Design Vue和Element UI, 在此基础之上结合ECharts图表库实现了数据的可视化. 在用例管理、团队和项目管理、请求消息发送模块中都使用了Axios库来发送异步请求, 以提高系统的及时反应能力^[14]. 在测试客户端监控和测试客户端消息处理模块中采用了HTML5下的WebSocket技术, 实现了数据双向传输^[15].

应用逻辑层基于Spring Boot开发, 由Java语言实现. Spring Boot内嵌了Tomcat服务器, 通过Maven管理项目资源, 使得项目可以直接打成jar包, 从而简化了部署工作^[16]. SpringMVC框架是基于MVC设计模式的实现, 可以与Spring Boot框架无缝结合^[17].

数据服务层基于MyBatis-Plus和Spring Data框架开发. MyBatis-Plus内置JDBC, 支持定制化SQL、存储过程以及高级映射^[18]. Spring Data可以简化构建基于Spring框架应用的数据访问技术, 从而提高开发效率.

数据服务层中使用了关系型数据库MySQL以及非关系型数据库MongoDB. 其中, MySQL是一个开源的数据库管理系统, 具有性能高、跨平台的特点^[19], 主要用于存储系统中的用例、用例集、团队和项目的基本信息以及中间表的数据; MongoDB是一个面向文档存储的数据库^[20], 主要用于存储系统中用例的请求信息.

2 用例执行流程

本文提出的基于C/S模式的用例执行流程支持自动地将测试请求分配给空闲的测试客户端、自动地将跨端请求分配给对应的请求处理器、自动地识别用例参数并对接口响应内容进行校验、实时地将测试结果呈现给用户. 用例执行流程的流程图如图2所示.

在进行用例测试前, 需要启动至少一个测试客户端, 并成功连接至测试平台, 平台中的测试客户端管理器会为每一个连接成功的客户端分配一个线程进行通信.

2.1 单用例测试的执行流程

(1) 当用户点击浏览器页面中的发送测试按钮后, Web前端程序会通过调用JavaScript生成为一个异步的HTTP请求, Web后端程序接收到此请求后, 会从测试客户端管理器中自动选择该用户的一个空闲的测试客户端并通过输出流将执行用例所需的数据以及Handler路径封装为一个ModelAndHandler 类型的对象发送至该客户端.

(2) 测试客户端收到测试请求后, 首先根据Handler路径信息自动匹配相应的请求处理器, 处理器负责执行用例并从测试客户端窗口中输出执行日志. 执行用例结束后测试客户端会将执行结果以及Handler路径封装为一个ModelAndHandler类型的对象发送至测试客户端管理器中与该客户端通信的线程, 该线程收到消息后, 首先根据Handler路径信息自动匹配相应的请求处理器, 然后通过ServerEndpoint中存储的用户的WebSocket Session将执行结果发送至Web前端程序. 此时, 前端程序中的WebSocket对象的onmessage事件会被触发, 从而接收到实时的执行结果, 最后调用JavaScript将执行结果分析并处理后呈现给用户.

2.2 用例集测试的执行流程

用例集测试的执行流程与单用例测试的执行流程基本相同, 不同之处如下.

(1) 执行用例集测试时, Web后端程序首先需要根据测试请求内容中包含的用例ID列表从MongoDB中查询出对应的用例数据, 然后再请求用户的测试客户端执行用例集.

(2) 用例集中的全部用例都执行完成后, 测试客户端管理器需要调用Web后端服务将用例集的执行结果统计数据保存至MySQL中, 以便用户可以查询到用例集的历史执行结果.

用例集的执行方式有串行执行和并行执行两种. 串行执行是指按照用例在用例集中的位置顺序一个接着一个地执行; 并行执行是指通过多线程技术异步执行多个用例, 相比于接口测试工具Postman采用的串行测试而言, 并行测试能够降低用例集的执行耗时, 从而提高测试效率.

2.3 Web后端程序与测试客户端之间的数据交互流程

Web后端程序与测试客户端之间的数据交互流程参考了前端控制器设计模式, 如图3所示.

在架构设计层面, 测试客户端独立于Web项目开发, 其主要功能是执行用例或用例集的同时在窗口中输出执行日志, 并将执行结果发送至Web后端程序. 测试客户端与Web后端程序之间通过Socket进行连接, 之后通过Socket的IO流进行通信.

(1) Web后端程序向测试客户端发送测试请求之前, 会先将执行用例所需的数据以及Handler路径封装为一个ModelAndHandler 类型的对象, 再将该对象通过输出流发送至测试客户端.

(2) 测试客户端中的Dispatcher通过输入流读取到ModelAndHandler 类型的对象后, 会根据Handler路径信息自动匹配请求处理器, 同时将执行用例的任务分配给相应的Handler. 执行用例结束后, 以相同的方式将ModelAndHandler 类型的对象发送至Web后端程序.

(3) Web后端程序中负责接收ModelAndHandler 类型对象的Dispatcher也会先根据Handler路径信息自动匹配请求处理器, 再将通知执行结果的任务分配给相应的Handler.

这种设计的创新之处在于将Web后端业务逻辑与用例测试过程进行了充分的解耦, 使得测试客户端不但可以在服务器上运行, 也可以在用户电脑上运行, 从而不仅减少了Web服务器的压力, 而且提高了测试的灵活性. 用户只需要在电脑上运行测试客户端程序, 就可以开始测试本地应用.

3 基于参数识别的自动匹配校验方法

目前, 平台中提供了3种用于校验接口响应内容的方式, 每一种校验方式中包含一种或多种校验方法, 如图4所示. 对于某一个用例, 用户可以选择其中一种方法对接口的响应内容进行校验.

平台中提供的3种校验接口响应内容的方式分别是JSON校验、Assert校验和Include校验. 其中, JSON校验适用于响应内容是JSON格式的情况, 它可以校验响应内容的格式和组成结构、响应内容中值的结果和类型, 同时支持使用正则表达式对响应内容中的值进行匹配; Assert校验适用于响应内容的格式比较简单, 但对结果的准确性要求较高的情况, 图4中列出了几个常用的断言方法; Include校验适用于验证响应内容中是否包含指定的字符串的情况, 即对响应内容与指定的字符串进行模糊匹配.

用例测试请求的内容中包含两个用于自动匹配校验方式和校验方法的参数, 分别是校验方式的实现类名称和校验方法的编号.

(1) 在测试客户端的实现代码中使用了序列化和反序列化工具jackson中的@JsonTypeInfo和@Json-SubTypes两个注解用于识别请求内容中的参数、处理多态类型的序列化和反序列化, 从而达到自动匹配校验方式的目的.

(2) 校验方式匹配成功后, 再根据校验方法的编号自动选择相应的校验方法对响应内容进行校验. 这样做的好处是测试客户端在对响应内容进行校验时, 只需要调用校验类实例的校验入口方法, 即可获得校验结果, 而不需要关心抽象校验类型变量的具体子类型, 同时也便于扩展更多的校验方法.

4 系统实现 4.1 测试用例设计

测试用例的主要信息可由如下四元组表示:

$ <Identifier, \;Protocal,\; Init,\; Validation> $

其中, Identifier是用例编号, 唯一地标识一个用例; Protocal是接口的协议类型; Init是用例请求数据的初始化步骤; Validation是响应校验, 按照预先设定的校验方法对接口的响应内容进行校验.

基于用例可以将用例集的主要信息表示如下:

$\left\{ \begin{array}{l} <{\textit{TestCaseSet}}>::=<Ordered><{\textit{TestCaseItem}}>\\ <{\textit{TestCaseItem}}>::=<{\textit{TestCase}}><Position>\\ Ordered::={\textit{True}}|False \end{array}\right. $

用例集是一组用例的集合, 其可以引用多个测试用例, 并指定其中用例的执行方式^[12]. Ordered默认为True, 即串行执行, 适用于用例之间存在依赖的场景, 对于用例之间无相互依赖的场景, 可以将Ordered设置为False, 即并行执行. Position是用例在用例集中的位置, 用户可以在用例集测试页面中设置用例集中每个用例的位置.

4.2 单用例和用例集测试

用例是测试客户端执行测试的最小实体^[21], 单用例和用例集测试基于okhttp3、fastjson、jackson等工具和JavaScript提供的WebSocket对象及其API实现.

4.2.1 单用例测试

当用户在用例列表中选定某个用例后, Web前端程序会根据用例的协议类型将浏览器页面切换到相应协议接口的编辑及测试视图, 如图5所示.

用户可以在此视图中完成请求信息和测试信息的录入、保存及执行用例测试等操作, 当用户输入有效的请求信息并点击发送按钮后, 平台就会开始执行该用例.

4.2.2 用例集测试

(1) 开始新的用例集测试前需要将待测的用例添加到用例集中. 为了记录每个用例在用例集中的位置, 在用例集与用例的中间表中增加了一个位置列, 表示用例在用例集中所处的位置, 向用例集中添加用例或更改用例在用例集中的位置时需要维护此列. 在用例集测试页面的编辑页签中可以搜索并添加用例至用例集、删除已添加的用例或调整已添加的用例的位置, 如图6所示.

(2) 用户可以在用例集测试页面中选择用例集的执行方式(串行执行或并行执行), 串行执行即一个用例执行完成后再执行下一个用例, 并行执行基于JDK1.8中引入的CompletableFuture类实现, 支持多个用例同时执行, 当所有用例都执行完成后, 返回执行结果的统计数据. CompletableFuture类默认的执行器是ForkJoin-Pool, 因此默认的并发线程数等于Java虚拟机可用的最大处理器数减一. 当用户选择执行方式并点击页面中的执行按钮后, 平台会按照用户选择的执行方式对用例集进行测试, 同时自动切换至实时执行进度页签, 如图7所示.

(3) 用例集执行过程中, 用户可以在用例执行进度框内查看每个用例的执行进度和测试结果. 对于校验错误的用例, 用户可以将鼠标移至校验结果标签上查看提示信息, 方便用户了解校验错误的原因, 如图8所示.

4.3 实时监控和管理测试客户端

为了让用户可以实时地查看测试客户端的信息以及能够同时使用多个测试客户端执行用例或用例集, 通过WebSocket和Callback (回调函数)等技术实现了测试客户端的实时监控和管理.

(1) 当用户启动新的测试客户端并成功连接至服务器时, 负责与该客户端通信的线程会通过回调函数将用户名和客户端的信息发送至测试客户端管理器, 由其统一管理. 同时, 测试客户端管理器通过相应的ServerEndpoint将测试客户端上线的消息通知给Web前端程序, 前端程序收到通知后, 将数据更新并呈现给用户, 如图9所示.

(2) 当用户的某个测试客户端断开与服务器的连接时, 负责与该客户端通信的线程会通过回调函数将测试客户端下线的信息发送至测试客户端管理器, 测试客户端管理器会将原先存储的与该客户端相关的信息删除, 同时通过相应的ServerEndpoint将测试客户端下线的消息通知给Web前端程序. 前端程序收到通知后, 将数据更新并呈现给用户.

除了直接关闭测试客户端以外, 平台中还提供了一个强制客户端下线的方式, 即通过点击浏览器页面中的下线按钮, 强制指定的测试客户端下线, 其基于WebSocket和Axios等技术实现.

5 系统测试

为了验证接口测试平台OLa的有效性, 分别采用单用例测试和用例集测试对OLa平台的测试效率进行了评估.

5.1 单用例测试

本次实验中, 选用Excel函数计算接口和表达式计算接口进行单用例测试.

(1) Excel函数计算接口的协议类型是HTTP, URL为“ http://ip:port/calc/function”, 请求方法为“POST”, 功能是根据操作数和Excel函数获取计算结果. 设置该用例的内容类型(content type)为“application/JSON”, 操作数为“A1=1.0、A2=2.0、A3=3.0”, Excel函数为“SUM(PRODUCT(A1, A2), 3)”, 即计算“A1×A2+A3”, 设置校验方法为“JSON校验方式中的值的结果校验”, 设置校验内容为“5.0”, 设置响应超时时间为“10 s”, 测试结果如图10所示.

(2) 表达式计算接口的协议类型是HTTP, URL为“ http://ip:port/calc/expression”, 请求方法为“GET”, 功能是根据操作数和表达式获取计算结果. 设置该用例的请求参数“variables”和“expression”分别为“x=2, y=3”和“7×#{y}+(163–5×2)/#{x}+sin(0)”, 设置校验方法为“Assert校验方式中的assertEquals校验”, 设置校验内容为“97.5”, 设置响应超时时间为“10 s”, 测试结果如图11所示.

从图10和图11中可以看出, 当用例执行结束后, 平台会给出用例的测试结果, 如果测试正确则会给出正确提示, 否则会提示失败并告知失败的具体原因.

5.2 用例集测试

本次实验中, 选用公式计算接口集合进行用例集测试, 该用例集中包含的用例为: Excel计算接口和表达式计算接口.

在相同的测试环境下, 分别执行用例集中的用例各1次, 再使用串行执行和并行执行两种方式执行该用例集, 循环10次, 平均耗时如表1所示.

由于串行执行需要等待前一个用例执行结束后才能执行下一个用例, 而并行执行则支持多个用例同时执行, 在用例之间无相互依赖的场景下, 理论上执行效率会高于串行执行. 在本次实验中, 用例集采用并行执行的方式比串行执行在时间上平均缩短了约26.2%.

通过以上实验证明, 本文实现的接口测试平台OLa具有一定的实用性, 提出的用例执行流程和自动匹配校验方法可行, 不仅能够降低接口测试的难度, 而且可以根据实际情况选择不同的用例执行方式, 提高了用例集测试的灵活性.

本文OLa与现有的自动化测试工具的对比结果如表2所示.

从对比结果的表格中可以看出, OLa相对于单元测试框架和传统的自动化测试工具来说, 不仅降低了测试难度, 而且具有更高的测试效率, 同时也有较强的用例可维护性.

6 结语

本文采用分层开发的思想设计并实现了一个支持用例集并行测试的接口测试平台(OLa), OLa平台中只需要录入用例的参数、校验方法以及校验内容后即可进行测试, 相比于手工测试来说, 不仅节省了编写大量测试代码的时间, 而且降低了测试的难度. 另外, 平台采用SpringMVC、MyBatis-Plus、Vue等框架进行开发, 降低了系统各模块之间的耦合度, 提高了系统的可维护性, 解决了传统的接口自动化测试工具扩展能力不足的问题.

平台测试结果表明, OLa不仅具有较高的测试效率, 而且具有良好的交互体验, 但是平台仍然还有一些不足和需要优化的地方, 在接下来的工作里将会为接口测试平台添加组合校验, 接口参数自动生成, 不同协议接口测试等功能, 以满足更多的测试需求.