前言
本篇旨在让相关开发人员理解引入 yapi
的目的以及对 mock 测试和 yapi 的功能有宏观的了解。
至于如何使用,相信通过本文的描述和参考文档即可平滑上手,请自行学习,不再赘述。
背景、现状、意义
目前公司内涉及到云端和客户端(APP和web)的对接开发,都是客户端通过调用服务端提供的API获取相关数据或者借由云端执行相关指令。如果将云端的返回响应信息全部看作是数据的话,那么这一过程就可以抽象成图1.1所示:
所以在项目开发的时候,理想状态是作为数据提供端的服务端只要拟定好API文档,然后客户端和服务端即可针对该文档分别开发,最终两端分别开发完成,然后对接进行实际测试即可。
但是实际上,这一过程中会出现很多问题,比如:
- 客户端先完成了所有功能的开发,但是服务端还未完成,此时就会产生阻塞。
- 客户端需要测试某些API,但是服务器端还未完成,导致测试不了。
- 客户端需要测试某个API的边界条件、正常条件、异常条件,需要服务器端进行大量的配合,耦合较大。
- 服务器端开发完某项API后,需要进行测试,但是客户端还未完成。此时只能通过
postman
等工具进行测试,当请求参数特别多的时候,构造一个请求浪费时间。而且在服务端制定API文档的时候已经输入过这些参数了,这里测试时又要写一遍,产生大量重复工作。 - …
以上问题出现在了目前项目的不同阶段上,核心的问题是三点:耦合,重复,阻塞。恰恰在软件开发中,一个设计良好的软件包括其软件系统都是尽力的去避免产生耦合,尽量的复用,并引入多种非阻塞机制。
所以,我们需要一个API管理平台,其提供的能力能够解决上述问题。通过多方调研和尝试,我们最终选择了使用 yapi
作为接口管理平台。
mock测试
图1.1中,对客户端来说并不在乎到底 数据提供者
是谁,只要其能够对客户端发起的请求返回对应的数据即可。所以如果构造一个"假"的服务端,该服务端实际上不和数据库等进行对接,只是能够针对客户端发起的不同请求返回相关数据,那么对于客户端来说,就可以认为服务端是真实存在的。
简单的例子,如果我开发了一个服务端程序,该程序提供两个功能:
- 可根据传入的用户ID返回用户的年龄(每次请求,年龄值随机产生)
- 可根据开发者的配置,将随机产生的年龄值限定在一个范围内。
此时,客户端开发者可以直接传入一个用户ID,随后收到随机产生的年龄值响应。或者开发者利用第二个功能对年龄进行配置,设置成 0<年龄<120,那么再次请求时就会收到一个年龄在设置范围内的响应,而不会收到500岁这种响应值。
上述的过程就是描述了一个最简单的 mock 测试的过程,其中:
- 开发的服务端称为:mock 服务器(mock server)
- 整体过程称为:mock 测试
- 配置随机产生的年龄,这一(些)方法可以称为:mock 脚本
- 简单情况下,比如客户端传入一个用户ID,只需要收到固定的90岁,此时构造的返回值就可以称为:mock 期望
yapi
前言中已经把核心的东西说了,那么 yapi 到底是什么?个人将其分为三大功能:
- mock 服务器:比前言例子中的高级的许多,但是基本概念是一样的
- API接口在线管理
- 基于项目的管理
这三大块功能组合起来就是 yapi 。
基于项目的管理
核心三点:
- 可以将成员拉入某个(些)项目中,并对成员角色进行分配
- 全局环境配置:比如该项目的生产环境请求地址和测试环境请求地址;再比如该项目各个API通用的请求头设置
- 其他全局配置
在每个项目中将服务端开发者设置为项目组长权限,然后客户端开发者设置为开发者权限
API接口管理
仍然按照功能划分:
- API接口的制定:该部分由服务器开发者制定,由于开发者权限也能够修改添加接口,所以此处注意,客户端开发者不应该针对接口进行操作。
- 运行接口,即在线发起请求,可针对实际服务器地址发起请求
- 自动化测试:这部分由服务器开发者负责构建
- mock构建与测试:这部分主要由客户端开发者负责构建,即构建自己想要的 mock 数据
mock 服务器
不是显示存在的,而是对接到了API管理中的mock测试部分。
其 mock 的构建提供了 期望和脚本两种方式,期望返回的是固定值,脚本返回的更具有动态性。
使用
服务端使用路径
- 创建项目
- 配置环境
- 制定接口
- 编写测试集合
客户端使用路径
- 查看收到的项目
- 进入项目,针对API接口进行编程
- 需要一些测试数据的时候,对某个未完成或者已完成的API进行 mock 构建
- 需要从实际服务器查看响应时,可以在线运行某个已完成的API