现在的Java Web项目大都是前后端分离的，需要的人员有：后端、前端、测试。这时，接口文档就特别重要。
本文介绍apifox、apipost、yapi这三款接口文档工具的区别。
apifox
一、apifox简介及下载：
1、apifox：是 API 文档、API 调试、API Mock、API 自动化测试一体化协作平台。
2、定位 ：Postman + Swagger + mock + JMeter。
3、下载与安装：
官网下载地址：https://www.apifox.cn/
按照需要下载对应版本，下载完毕后解压安装即可。
二、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
当您需要发送 ON对象或者其他对象时，切换到对应的raw类型即可
API 请求响应
点击发送按钮后，如果有数据返回，则会显示返回数据，响应时间，响应码，Cookie等。
注意：返回数据默认是Pretty模式，便于查看 ON 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、检测返回 ON中的某个值是否等于预期的值
apt.assert('response.json.hasOwnProperty("errcode")'); // 检测返回json对象的是否含有errcode字段 apt.assert('response.json.errcode=="success"'); // 检测返回json对象的errcode字段是否等于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": "https://echo.apipost.cn" }, "desc": "成功" }
RESTFUL逻辑数据
某些场景中，我们可能需要根据接口的入参规则，加入适当的逻辑处理后再返回数据。一个简单的场景就是登录场景，需要根据用户名密码，判断是否登录成功。再或者，我们需要根据产品ID动态返回产品信息，等等。
现在，ApiPost 的Mock 服务提供了这种场景的解决方案。
以下示例中，我们用到了 _req.body对象，其含义是：
当 post 请求以 x-www-form-urlencoded 或者application/json 方式提交时，我们可以拿到请求的参数对象。
{ "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选择等等，都可以通过后台私信交流。需要学习资料或者帮忙修改简历也可以私信！！也可百度搜索“特斯汀软件测试腾讯课堂”或关注公众号“特斯汀软件测试”，里面涵盖很多精彩免费视频或干货知识
