现在的 Java Web 项目大都是前后端分离的，需要的人员有：后端、前端、测试。这时，接口文档就特别重要。

本文介绍apifox、apipost、yapi这三款接口文档工具的区别。

apifox

一、apifox简介及下载：

1、apifox：是 API 文档、API 调试、API Mock、API 自动化测试一体化协作平台。

2、定位 ：Postman + Swagger + mock + JMeter。

3、下载与安装：

官网下载地址：

按照需要下载对应版本，下载完毕后解压安装即可。

二、apifox页面布局简介：

1、apifox几个简单概念：

（1）团队：该工具支持团队协同办公，可以根据需要 创建不同的团队，在工具页面左侧，显示自己的团队，也可新建团队

新建团队，需要一个团队 名称：

创建成功团队后，可以邀请成员、设置权限等，或删除团队

有了团队，就可以开始我们接口的管理及测试工作了。

2、项目：apifox是以团队下项目来管理接口的，将所需接口维护在项目中，在不同的项目中对 接口进行维护及操作。

3、点击项目后进入项目，在该项目下管理接口。

（1）新建接口：维护接口信息，包括接口URL，接口基础信息，请求参数等，需要注意的是，此处只维护接口信息，类似于接口文档，不运行接口

接口URL，http协议及域名部分，建议设置在环境中，页面右上角选择环境处，可维护环境信息，因为我们在测试工作中，往往会有多个环境，将协议及域名维护在环境中，测试不同环境的同一个接口时，只需要切换环境即可，不用不同环境维护不同的接口。

对于需要 Cookie 的接口，在维护接口时，请求参数中，别忘了维护cookie信息。

2、修改接口：

在接口管理-修改文档下，可修改已维护的接口信息

3、运行接口：

接口运行，往往是依据 测试用例 ，在接口测试中，可以简单地认为不同的传值即为不同的测试用例，apifox中，运行接口的入口在项目中，接口管理-运行下，在此处修改参数值，点击发送后，可已看到返回信息，此外，可将运行数据保存为用例，保存成功后，此次运行的数据会保存，下次打开该用例，其中参数值可复用（注：运行接口时，需要选择环境）。

若设置了断言，可根据断言判断此条用例是否通过：

修改了参数值信息，需要点击保存才能更新成功，若不保参数值依然为修改前值。

测试用例显示在接口的下一级，可通过复制用例的方式，维护多个用例。

4、断言：

对测试用例，可以设置其断言，即期望结果，apifox在后置操作中进行断言

apifox断言核心为提取表达式，该提取表达式很简单，即将目标返回字段提取出来，$及为根节点，一级一级定位到目标字段即可

举个例子：若返回信息如下图所示，我想通过 sort _finish字段值断言，则提取该字段的表达式为：$.data.sort_data.box_no

5、批量运行：apifox的批量运行，在自动化测试页面，可在该页面添加一个分组，在分组下添加测试用例，创建完测试用例后进入所创用例，即可添加步骤，此时可导入接口用例

导入用例后，可根据需要设置循环次数及线程数等信息，点击运行，即可批量执行，执行完成后，显示此次执行结果：

以上：为apifox基本使用功能，变量提取、套件使用等

apipost

apipost是一款国产的接口测试工具

什么是ApiPost

ApiPost = 接口调试+接口文档快速生成+接口文档规范化管理+Mock API+接口流程测试。

常见的接口管理方案

API文档

Swagger

调试 API

Postman

Mock API 数据

RAP

API 自动化测试

JMeter

ApiPost产生的初衷是为了提高研发团队各个角色的效率！产品的使用受众为由 前端开发 、后端开发和测试人员以及 技术经理 组成的整个研发技术团队。

APIPOST通过协作功能将研发团队的每个角色整合打通。

安装

ApiPost目前提供Window64位，Window32位、Mac、 Linux 版本的安装包下载。

使用

发送HTTP请求

API界面功能布局

API请求参数

header 参数

你可以设置或者导入 Header 参数，cookie也在Header进行设置

Query 参数

Query 支持构造URL参数，同时支持 RESTful 的 PATH 参数（如:id）

Body 参数

Body 提供三种类型 form-data / x-www-form-urlencoded / raw ，每种类型提供三种不同的UI界面

当你需要提交表单时，切换到 x-www-form-urlencoded

当你需要提交有文件的表单时，切换到 form-data

当您需要发送 JSON 对象或者其他对象时，切换到对应的 raw 类型即可

API 请求响应

点击发送按钮后，如果有数据返回，则会显示返回数据，响应时间，响应码，Cookie等。

注意：返回数据默认是Pretty模式，便于查看 json XML 格式。您可以通过切换 原生 或 预览 模式 查看其它类型的类型。

返回Headers

全局参数和目录参数

实际的企业级应用开发常见下，通常会约定一些通用的数据，比如token、时间、终端这些，如果每个接口都去独立去维护，势必会对开发、调试带来一些不必要的工作量；此时，我们就需要有一个能设置全局参数的地方来统一管理这些公共参数

全局参数

我们打开全局参数管理器，在全局header除填上token参数：

每次在接口请求的时候，就会自动带上这些公共配置的参数。

目录参数

目录参数和全局参数的作用一样，属于一个更细化的功能，可以通过目录，来区分全局参数的作用域；可以为不同的目录设置不用的公共参数：

参数的优先级

当全局参数、目录参数、接口中都使用了同一个参数时，最终会按照以下优先级读取参数值：

单个接口 > 目录参数 > 全局参数

响应和断言

响应

当Http请求发送之后，得到的服务端返回的结果表示一个响应；其中会得到状态码、数据、Headers、Cookie等。

Headers

断言

服务器返回了响应数据，并不代表着接口就一定正常了，很可能以为bug或者数据异常导致得到的结果并没有达到实际的预期；因此，我们就可以使用断言功能，来判断最终响应的结果是不是我们想要的；

常用断言表达式

1、检查response body中是否包含某个 string

 apt.assert('response.raw.responseText=="test"'); // 检查响应文本是否等于test字符串
apt.assert('response.raw.responseText.indexOf("test") > -1'); // 检查响应文本是否含有test字符串  

2、检测返回JSON中的某个值是否等于预期的值

 apt.assert('response.json.hasOwnProperty("errcode")'); // 检测返回json对象的是否含有errcode字段
apt.assert('response.json.errcode=="success"'); // 检测返回json对象的 err code字段是否等于success字符串
apt.assert('response.json.errcode.indexOf("success") > -1'); // 检测返回json对象的errcode字段是否含有success字符串
apt.assert('response.json.errcode!="success"'); // 检测返回json对象的errcode字段是否不等于success字符串
apt.assert('response.json.errcode>=1'); // 检测返回json对象的errcode字段是否大于1
apt.assert('response.json.errcode==null'); // 检测返回json对象的errcode字段是否是null  

3、测试response Headers中的某个元素是否存在(如:Content-Type)

 apt.assert('response.headers.hasOwnProperty("content-type")');  

4、验证Status code（响应码）的值是不是等于200

 apt.assert('response.raw.status==200');  

5、验证Response time（请求耗时）是否大于某个值

 apt.assert('response.raw.responseTime>=100');  

6、验证返回类型是不是json

 apt.assert('response.raw.type=="json"');  

一键文档生成

当通过上述的功能验证完接口之后，即可通过分享文档或者分享项目的方式，一键生成接口文档；

点击分享之后，即可拿到一个接口文档访问地址，详情如下：

为了让文档的请求和响应参数更加的清晰、明确；我们可以对header、query以及form-data和 urlencode 的body参数进行详细的描述

请求参数描述

响应参数描述

Mock

大部分企业的产品都采用的敏捷开发，为了能保证多端同步开展，当方案一旦确定，就需要通过Mock生成API的数据规则；这样多端就可以根据文档规则进行开发，不会因为团队见彼此的进度而互相干扰、互相影响。

编写Mock 规则

在APIPOST中，Mock 规则模板支持类型丰富（5.4版本起）。

基本数据(固定json结构)

 {
"code": "0",
"data": {
"name": "张三丰",
"age": 100
},
"desc": "成功"
}  

基本数据(Mock随机json结构)

 {
"code": "0",
"data": {
"list|20": [{
"name": "@name",
"age": "@ integer (2)"
}],
"url": "#34;
},
"desc": "成功"
}  

RESTFUL逻辑数据

某些场景中，我们可能需要根据接口的入参规则，加入适当的逻辑处理后再返回数据。一个简单的场景就是登录场景，需要根据用户名密码，判断是否登录成功。再或者，我们需要根据产品ID动态返回产品信息，等等。

现在，ApiPost 的Mock 服务提供了这种场景的解决方案。

以下示例中，我们用到了 _req.body对象，其含义是：

 { "code": "0000", "data": { "verifySuccess": function() { let body = _req.body; return body.username === 'admin' && body.password === '123456'; }, "userInfo": function() { let body = _req.body; if (body.username === 'admin' && body.password === '123456') { return Mock.mock({ username: "admin", email: "@email", address: "@address" }); } else { return null; } }, }, "desc": "成功"}  

1

获取Mock地址

切换到Mock环境进行测试

复制Mock地址

自动化测试

流程测试是针对一个接口集合的测试，选择相应的环境，可以作为一系列请求一起运行。

当您想要自动化API测试时，流程测试非常有用。

创建一个测试流程

步骤：

新建接口，并添加断言

打开流程测试，新建一个流程

向流程添加测试接口

选择环境，点击开始测试

查看返回的测试接口

yapi

YApi 已在去哪儿大面积使用，对 200+ 项目接口进行管理，每周有上万次 mock 请求。在开源以后，越来越多的公司和团队使用 YApi， github star 数已经上升到 1.1k了。YApi 在未来还将继续专注于接口管理方面的功能，让 YApi 成为各位开发者的好帮手。

可视化 表达主要是为了方便用户生成自动化测试所用到的参数，通过一个树形选择性，快速引用所依赖的参数值。

在所有的需要测试的接口配置完成后，点击开始测试，就会按照指定的顺序依次测试所有接口，测试完成后，可查看测试报告。

相关产品调研

我们迫切希望有一款产品能够满足我们的诉求，于是开始寻找市面上类似产品，经过一段时间的分析，最终我们找到了几个比较有代表性的产品 Rap，Nei，Easy-Mock。同时我们按照自己的诉求列出了一些关键的特征：

clipboard.png

Nei 是网易前端事业部的产品，在这些产品中算是做得比较好的， nei 是专注做 saas 服务这块，没有开源版本。对于去哪儿内部，肯定不会把公司机密的接口数据放到第三方平台。

Rap 是阿里妈妈 MUX 团队2013年出的一款产品，从时间上看是同类产品中最早的。Rap 是后端工程师基于 java 开发的，如果想定制部分功能，还需要学习 java，而我们部门大家对 java 都不熟悉。另一方面 Rap 没有接口测试功能，而后端使用其他工具（postman， restlet ）测试接口，将导致不能及时更新接口文档。

Easy-mock 是 大搜车 无线团队出的一款产品，Easy-mock 定位是接口数据的模拟，解决前端依赖后端接口数据的问题，在同类产品中 mock 服务做得比较好。Easy-mock 专注于前端数据的模拟，但无法解决去哪儿现有的问题。

Nei，Rap 接口管理平台共同存在的问题是不易维护接口返回数据。笔者曾跟一个使用过 Rap 的后端工程师聊过，他说每次定义后端接口返回数据字段，好几个百个字段需要更新很长时间。Nei，Rap 是基于维护一个 json-schema 方式定义后端返回数据结构，我们假设某个接口有100个字段，如果基于 json-shema 那么就要维护差不多 600 多左右字段的更新。这么大工作量的，很可能导致后端工程师根本没有动力去维护。

比较遗憾的是，这几款优秀的产品，都缺失了一些我们在意的关键特征。我们可能需要做比较大的改动才能够基本满足自己的需求，这个工作量很有可能会超过重新开发一次。所以我们开始自主研发一个全新的接口管理平台，我们希望它能够提供接口 文档管理 ，接口数据模拟（Mock），接口调试，自动化测试等功能，让前后端接口相关的工作进行的更加高效。这就是 YApi 接口管理平台斐然由来，下面简要聊聊 YApi 是如何实现上述这些特征的。

YApi 解决方案

1. 共同维护一份接口定义，连接前后端

大家看下图，在后端开发接口过程中，接口开发和测试接口这是必不可少的环节，但文档因为没有跟接口开发和测试联系到一起，被孤立。后端要维护对于他们冗杂繁琐的文档，是件收益很低的事情。没有人喜欢做收益低的事情，所以最终的解决办法就是要提高收益。下面详细说明解决方案。

在接口开发过程中，后端通常都会使用 postman 等类似的工具测试接口，而测试接口是在开发过程中一个必要的过程。假如参数有改动，大家肯定会在 postman 等工具上更新字段和测试接口。由此可以联想到，

如果能有一款工具既可用来做测试接口，又能作为接口文档工具，将接口文档和接口测试连接到一起，不就解决了此问题。YApi 解决方案是将接口文档和测试通过单一数据源连接到一起，如果有改动，因为改的是单一的数据源，就不会出现更新滞后和不及时问题。

2. 前端 Mock Server 方案

数据 Mock 服务在开发前期是非常头疼的一个问题。大多数情况下，接口请求参数和返回数据都是后端规定的，在后端接口没有完成之前，接口对于前端就是一个黑洞，可能最初对接口的定义跟实际后端做出的接口会有非常大的不同。这个时候就需要有一个工具，不仅能模拟真实接口的情况，还能关联接口文档，在后端开发过程中，可以随时调整接口定义，并通知给前端开发者改动信息。

在 YApi 平台，前后端只要维护接口定义的响应数据，就可以生成需要的模拟数据，下面这段代码定义了生成数据模板：

 {
    "errcode": 0,
    "errmsg": "@string",
    "data": {
        "type":"@pick(1,2,3)",
        "list|1-10": [{
            "uid": "@id",
            "username": "@name"
        }]
    }
}  

可生成如下的模拟数据：

 {
  "errcode": 0,
  "errmsg": "^*!SF)R",
  "data": {
    "type": 2,
    "list": [
      {
        "uid": "370000200707276255",
        "username": "Ruth Clark"
      },
      {
        "uid": "650000200211185728",
        "username": "Anthony Martin"
      },
      {
        "uid": "370000199201143855",
        "username": "Laura Rodriguez"
      },
      {
        "uid": "610000198704072775",
        "username": "Anthony Perez"
      }
    ]
  }
}  

以往的数据 mock 方案难免会影响项目源码，yapi 使用了服务器代理的方案，只需要在你的开发机做下服务器反向代理配置，不用修改项目一行源代码，即可获取到所有的 mock 数据。

基础的 Mock 工具已经能满足大部分的需求了，但有些复杂场景是无法实现的。例如：当我做一个数据列表页面，需要测试某个字段在各种长度下的 ui 表现，还有当数据为空时的 ui 表现。YApi 提供了期望和自定义脚本的功能。

本文主要介绍自定义 脚本 功能，期望功能可参考 yapi 平台文档。

自定义脚本可根据请求的参数，cookie 信息，使用 js 脚本自定义返回的数据。我们假设有个场景，我希望通过 cookie “_type” 控制列表页面数据显示，假设 _type 是 error，那么列表显示异常错误信息；假设 _type 是 empty ，列表显示为空。可使用下面代码实现：

 if(cookie._type == 'error'){
mockJson.errcode = 400;
}

if(cookie._type == 'empty'){
mockJson.data.list = [];
}  

3.自动化测试

接口开发完成后，后续的迭代是非常多的，每次对源码的修改，都需要大量的测试才能确保接口是否正确。人工判断肯定是不好的，最好的办法是做成自动化，但自动化测试又是一件成本非常高的事情，需要后端人员和QA人员学习相关的框架，和写大量的代码。YApi 简化了这一个过程，基于一个可视化界面，就算不懂 程序开发 ，只需配置相关的参数和断言语句，就能实现自动化测试，非常的易用。

除了基本的功能外，YApi 还提供了强大的 pre- script 和可视化表达式功能，pre-script 包括请求参数处理脚本和响应数据处理脚本两部分。通过自定义 js 脚本方式改变请求的参数和返回的 response 数据。他的使用场景如下：

接口请求参数需要加密及返回 response 解密

接口请求参数需要添加计算 token

4.插件机制

YApi 最强大的一点莫过于他的插件机制，我们去哪儿各个业务线有不同的需求，通过 YApi 预留的钩子，开发不同的插件解决，比如我们现有的 qsso 登录，swagger 数据导入就是通过插件机制实现的，我们团队最近还在跟业务部门讨论使用插件实现压力测试功能等。总得来说，YApi基于插件机制，既满足了产品需求的多样性，又保证了内核足够易用和简洁。

5. 开源和易部署

为了帮助更多开发者和提升大家的工作效率，YApi 不仅开源到 github，还提供了一个 cli 工具方便广大开发者部署。使用 yapi-cli 提供的可视化部署方案，即便你不懂任何 nodejs 、 mongodb 的知识，也能轻松一键部署。

对于前端工程师，后端提供的接口文档，大多是不规范的，有使用 wiki 的，有 word 文档的，甚至还有用即时聊天软件沟通的，后端接口对于前端就像一个黑盒子，经常遇到问题是接口因未知原因增加参数了，参数名变了，参数被删除了。对于后端工程师，接口对接时总是需要写冗杂繁琐的文档，需要大量时间去维护接口文档。

前端开发的功能在后端功能还没完成前，因为前端的功能依赖于后端的数据，导致工作无法顺利展开。为了解决这个问题，有些前端工程师在代码注入 json，还有后端工程师临时搭建一套测试数据服务器，这种情况下势必会影响工作效率和代码质量，也不能及时进行字段的更新。

接口数据正确性无法得到保证。前端调用后端的接口数据渲染到 视图，数据一旦出错，将会导致视图和交互也出现问题，保证后端接口数据正确性变的愈来愈重要。接口自动化测试就是用来解决这个问题，但传统的 接口测试 框架使用成本很高，很多团队采用肉眼比对方式，效率很低。

最后，关于 软件测试 学习，offer选择等等，都可以通过后台私信交流。需要学习资料或者帮忙修改简历也可以私信！！也可百度搜索“特斯汀软件测试腾讯课堂”或关注公众号“特斯汀软件测试”，里面涵盖很多精彩免费视频或干货知识