接口：主要是子模块或者子系统间交互并相互作用的部分，这里说的接口是广义的，客户端与后台服务间的协议；插件间通信的接口；模块间的接口；再小到一个类提供的方法；都可以理解为接口。 接口测试：是指针对模块或系统间接口进行的测试，我们也可以理解为端到端的测试，只不过是前端到后段-后段到中台的测试。

在功能测试的过程中，我们的case设计思路一般都是模块化编写，或者是用户的体验过程编写，然后我们加上接口返回参数的容错性测试，网络异常的兜底，兼容其他状态等等。 那么在接口测试的case里，这种用例的设计思路只占其中一部分，需要结合前端的prd与接口的技术文档与接口文档并行去完成。（这里是个人case设计习惯与思路，欢迎参考与补充～）

首先我们可以在一级标题下面拆分成两个子模块，分别是接口格式与需求模块内容。 顾名思义就是接口内格式的case与需求的case分别放在对应不同的模块内。 这里可以参考养成一个好习惯，在最上方的位置单独拉出模块记录文档与地址内容，功能case可以粘贴prd地址与需求背景目的(需求目的可以让我们更好的理解需求的侧重点)，这里是以前的一个端上需求case，可以对比一下出入。 “开宝箱”与“拉新红包回流”是两个接口，那么我们就按照接口来拆分一级标题。并且能看到一级标题下接口格式的子标题是通用的。

对照接口文档内编写接口格式内case 能很直观的看出架构的拆分，首先是接口的url地址，然后是请求参数的格式（接口请求类型，入参，强制登陆效验与请求头），最后是返回参数。

必须就是入参与返回参数内比带的字段，不带就会引发接口报错或者前段找不到对应字段报错。 非必须是在特定的场景下才会触发相对的字段上传或者返回，比如我开宝箱，开出了道具类奖品那么我接口返回的就会是道具类相关的非必传字段。那如果我开出了现金红包，那么就会返回红包相关的非必传字段，这时候就不会返回道具类相关的非必传字段了（这里稍微强调一下，必传与非必传的字段确定是前后端通过协商决定的）。

强制登陆效验是个测试点，比如一定要验证用户的信息与状态，通常是存储在cookie内。

接口测试内需要测试入参的字段正确性、错误性、边界值与容错性，返回正确与错误还有错误码。 容错性测试其实就是值的各种状态（可以参考一下以前客户端的case） 这里的不会出现异常指的是客户端无法解析server返回参数，从而出现crash。 边界值在接口测试内需要注意的主要就是数据类型的边界值，数据类型在后面的“接口字段的数据类型内会有比较详细的介绍”。

技术文档内会有流程路，方便我们更好的理解实现过程与经过。

首先我们能看到接口与各个中台rpc交互的过程，并且也能看到先后顺序，结合流程图写出测试case。 如：客户端点击功能进行了请求 那么这时候就会请求接口 这就是流程图内其中的一步。

前段到后段如果有问题，过程可能是 前段->后段 请求有问题 也有可能是 前段