前言
本篇旨在让相关开发人员理解引入 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
参考资料
