三种常见类型的接口测试工具架构对比

Posted 2021-04-24 测码奔跑

在我们的测试过程中接口测试是比较常见的方式，同时测试人员 也经常会设计开发一些基于接口调用的测试工具来帮助进行数据准备，故障数据模拟，流程驱动等操作。本文对三种常见类型的接口测试架构进行对比，分析各自的优劣及使用场景。

传统的接口测试工具架构

架构说明：

首先说一下传统的接口测试工具架构指的是当前最常见的测试工具一般采取的架构，一般会采用类似mvc的框架，这类工具往往以单页Web应用（SPA）的形式出现，通过封装业务依赖的RPC或者DB的操作，在页面上提供功能给测试使用。类似下图：

实现方式：

实现方式比较多，这里只罗列一种比较常见的.

• 后端：spring-boot/spring mvc,mybaits...

• 前端：react + react-router+ webpack,antd/bootstrap...

跑一下题：

这种类型的测试工具后台，也可以直接用node.js来直接搭建。公司内可以使用类似egg的框架，已经很好的封装了阿里内部的常用中间件，这里选spring来做后端服务，主要还是考虑到大多数的接口测试人员对java类的技术更熟悉一些。

优缺点：

• 优点：

• 结构简单，开发成本低。

• 业务逻辑可以定制，可以封转实现比较复杂的业务逻辑。

• 缺点：

• 扩展性价较差，每个业务都要定制才能对外提供服务。

• 各个业务之间相对是隔离的。

基于核心代理的接口测试工具架构

架构说明：

针对第一种框架比较难扩展的劣势，我们再看一下第二种常见的架构，针对各种复杂的RPC接口，在测试工具平台中定义proxy，通过页面操作传入接口定义以及参数，然后通过proxy的泛化调用就可以去驱动不同类型的接口，实现相关的功能。

实现方式：

RPC的调用主要通过泛化调用实现，其他的和方法1类似，但是一般来说前端部分比较简单.

• 后端：spring-boot,泛化调用...

• 前端：react，antd/bootstrap...

跑一下题：

类似这种思路在测试工具或者架构设计时，其实使用非常普遍，核心的思想是关注过程中的单点，对其进行扩展。类似的例子还有很多，从远的说类似windows的MFC中的消息驱动型的系统中，在消息的while循环中，mock消息进行各种消息的模拟。到现在用的比较多的偏向切面的代码注入，都可以在系统的核心逻辑上扩展测试的功能，达到相关的目的。

优缺点：

• 优点：

• 一次开发，终身使用，没有什么后续跟随业务调整而持续的开发维护工作量。

• 业务扩展性高，几乎可以覆盖所有的rpc接口。

• 缺点：

• 业务封装内容少，无法把复杂的业务逻辑封装到相关的后台服务里，只能在调用时去写业务逻辑。

• 安全性存在一定问题，直接对外暴露的一些接口存在权限控制等问题。

基于微服务架构的接口测试工具

架构说明：

此方案可以针对各个业务封装各自的测试服务。服务通过微服务的架构，可以互相调用，并且单独发布，不影响其他的服务。非常适合较大规模的使用场景，业务直接的隔离，以及业务的可扩展性都比价好。

实现方式：

可以使用类似OSGI的技术来把每个服务作为一个bundle进行热插拔，不过本文建议使用类似spring-cloud来搭建相关的服务，成本比较低。其他的和方案一类似。

• 后端：spring-boot,spring-cloud,mybaits...

• 前端：react，antd/bootstrap

跑一下题：

用springcloud来搭建微服务结构的程序其实挺方便的，试了一下Eureka，搭建了一个服务端，注册了2个测试的服务，不到30分钟就可以搭好，几乎没什么配置的工作量，就实现了具有服务发现，注册，负载均衡等功能的服务。

优缺点：

• 优点：

• 不同业务之间的隔离也非常好，互不影响。各业务服务可以分别独立开发部署，各业务的测试负责人可以根据自己的业务逻辑开发自己的服务，在自己的业务逻辑中可以调用其他的服务。 ＊ 扩展性好，不仅仅是业务上的扩展性，要增加新的业务时，对原有业务不影响，

• 缺点：

• 分布时部署，架构的复杂度相对较高一些。

总结：

下面对三种类型的设计进行一下一些各个维度的对比，可以根据需要在不同的场景下选择相应的方案。

更多测试技术文章，微信扫以下二维码，欢迎关注

测码奔跑-让测试技术奔跑起来