这就需要开发提供的接口文档了，接口文档和功能测试的需求说明书的功能是一样的。包括：接口说明、调用的url，请求方式（get or post），请求参数、参数类型、请求参数说明，返回结果说明。有了接口文档后，我们就可以设计用例了，一般接口测试的用例分为以下几种：
1、通过性验证，说白了就是传递正确的参数，是否返回正常的结果
2、参数组合，因为参数有必传和非必传，参数的类型和长度，以及传递时可能业务上的一些限制，所以在设计用例时，就要排列组合这些情况，保证所有情况都能覆盖到
3、接口的安全性，这个又分为几种情况：
1)绕过验证，比如提交订单时，在传递商品价格参数时，修改商品价格，就要看后端有没有验证了。或者我支付时，抓个包将订单金额一改，如果能以我改后的金额支付，那这个借口就有问题了。
2）绕过身份验证，就是某个功能只有有特殊权限的用户才能操作，那我传递一个普通的用户，是不是也能操作呢
3）参数是否加密，这个关系到一些账户的安全，比如我们在登录一些网站时，它要将我们的登录信息进行加密，如果不加密我们的信息就会暴露，危害性极大。
4) 密码安全规则，设置密码时复杂程度的校验。
4、根据业务逻辑来设计用例
接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。接口测试大体分为两类：模块接口测试和web接口测试。
WEB接口测试
web接口测试又可分为两类：服务器接口测试和外部接口测试。
服务器接口测试：是测试浏览器与服务器的接口。用户输入的数据是输入到的前端页面上，怎样把这些数据传递的后台的呢？通过http协议的get与post请求来实现前后端的数据传递。这也可认为是接口测试。
外部接口测试：这个很典型的例子就是第三方支付，比如在我们应用中在充流量时，交话费时，都会调用第三方支付接口。
主要测试要点如下：
请求是否正确，默认请求成功是200，如果请求错误也能返回404、500等。
检查返回数据的正确性与格式；json是一种非常常见的格式。
接口的安全性，一般web都不会暴露在网上任意被调用，需要做一些限制，比如鉴权或认证。
接口的性能，这直接影响用户的使用体验。
测试用例
正面测试用例：
覆盖所有的必选参数
组合可选参数
参数边界值
如果参数的取值范围是枚举变量，需要覆盖所有枚举值
还应考虑实际业务应用场景，去设计输入参数的组合。（这些用例可用来测试功能，作为SMOKE用例。也可将来用于压力测试模拟实际业务场 景，但要注意保证用例的独立性，因为压力测试是多线程的。比如我们测试ACCOUNT 创建接口，NAME是不能重的，在写测试用例时，给NAME赋值时可以加一个时间戳, 这样用例在多线程并发测试时也不会有问题）
负面测试用例：
空数据
包含特殊的字符
越界的数据
错误的数据
验证点：
status code （正常情况下，所有请求都应该返回200）
响应信息数据结构（目前大多数情况下，返回信息都是JSON, 我们应该验证相应的结构当数据信息发生改变时）
验证结点的类型
验证结点的值 （主要是针对固定的值或者值遵循某些规则，我们能知道预期的结果的）
对于列表，应该根据请求参数，也应该验证列表的长度是否与期望值一致
负面测试用例，应验证ERROR INFO是否与实际相匹配
接口测试用例的设计
1.1接口文档的特点
接口文档，顾名思义就是对接口说明的文档。好的接口文档包含了对接口URL，参数以及输出内容的说明，我们参照接口文档就能编写出一个个的测试用例。而且接口文档详细的话，测试用例编写简单，不会遗漏。
如果一个接口文档没有写清楚，你从文档中分不出哪些参数是必需的，哪些是非必须的，而且没有参数的取值说明，返回值的结构等信息的话，测试人员是无法 编写相应的测试用例的。但是由于开发人员不愿意写文档，所以很多接口文档相对来说比较简单，模糊不清，这对我们做接口自动化测试是很大的阻碍。
1.2 接口文档的结构
接口文档可以包含很多信息，有的愿意写就可以多写的，不太愿意写的话，就写的信息相对来说会少点儿。不过，下面几项内容必须有，这是我们使用接口中和测试接口的依据：
（1）接口名称。标识各个接口的简单说明，如登录接口，获取项目详情接口等。
（2）接口URL。接口的调用地址，在测试环境下前面的域名可能不一样，不过接口名是不会变的。
（3）调用方式。接口的调用方式：Post/Get方式，决定了如何调用接口及传递参数。
（4） 参数。接口需要传递的参数，参数需要增加些说明：
（a） 参数值类型说明：参数值要说明一下，只支持字母，数据，特殊字符或是字母数据混搭。
（b）参数长度说明：参数接收最大多少个的字符串，或是最大是多少的数值等。
（c） 参数取值范围：像枚举型的参数，只接收什么范围内的数据，如1-5等。
（d）参数的配合说明：有些参数需要配合起作用的，如：offset和count参数。
（e） 参数是必需的还是非必需的。
（5）返回值。接口的返回值说明需要包含正确和错误的情况，正确的情况下有哪儿数据，错误的情况下会有什么提示？
（6）其他的一些说明。上面的说明是通用的，还有其他的一些说明，如必须是登录状态调用，或是版本号等说明，在某些情况下也需要说明一下。
1.3 接口文档缺失的的解决方法
（1）完全没有接口文档。这个情况是最麻烦的，我们要找开发人员来商量 ，最好能补个接口文档，如果实在来不及那就给个调用接口的实例。实例中会有接口地址，参数等信息，我们去测试环境中调用一下，就能看到返回结果的情况。
（2）接口文档信息不全。信息不全这个最常见，像参数说明缺少啊，没有说明哪些是必需的参数，哪些是非必需的，或是没有说明取值范围等。此时我们能问开发就问开发，如果不太方便，就要做尝试：一般非必需的参数不会做容错的判断，必需的参数检测的方面比较全面。
（3）文档不是最新的。接口的后续的工作中被修改或是优化过，我们按接口文档上的说明去调用，返回和预期的不一样。通知开发更新文档，然后用最新的文档再去修改测试用例。
这个接口文档需要和接口开发人员做好约定，开发新接口时要把接口信息写清楚，如果更新原来的接口，要及时更新接口文档。同时在写接口自动化测试用例的时候，要多和开发人员沟通，过程中沟通到底的一些关键信息整理为文档留存。
2.接口测试用例设计
2.1 设计思路（策略）
1）优先级–针对所有接口
a、暴露在外面的接口，因为通常该接口会给第三方调用；
b、供系统内部调用的核心功能接口；
c、供系统内部调用非核心功能接口；
2）优先级–针对单个接口
a、正向用例优先测试,逆向用例次之(通常情况，非绝对)；
b、是否满足前提条件 > 是否携带默认参值参数 > 参数是否必填 > 参数之间是否存在关联 > 参数数据类型限制 > 参数数据类型自身的数据范围值限制
3）设计分析：通常，设计接口测试用例需要考虑以下几个方面：
a、是否满足前提条件
有些接口需要满足前置条件，才可成功获取数据。常见的，需要登陆Token。
逆向用例：针对是否满足前置条件(假设为n个条件)，设计0~n条用例
b、是否携带默认值参数
正向用例：带默认值的参数都不填写、不传参，必填参数都填写正确且存在的“常规”值，其它不填写，设计1条用例；
c、业务规则、功能需求
这里根据实际情况，结合接口参数说明，可能需要设计n条正向用例和逆向用例
d、参数是否必填
逆向用例：针对每个必填参数，都设计1条参数值为空的逆向用例
e、参数之间是否存在关联
有些参数彼此之间存在相互制约的关系
逆向用例：根据实际情况，可能需要设计0~n条用例
f、参数数据类型限制
逆向用例：针对每个参数都设计1条参数值类型不符的逆向用例
g、参数数据类型自身的数据范围值限制
正向用例：针对所有参数，设计1条每个参数的参数值在数据范围内为最大值的正向用例
逆向用例：针对每个参数(假设n个)，设计n条每个参数的参数值都超出数据范围最大值的逆向用例
针对每个参数(假设n个)，设计n条每个参数的参数值都小于数据范围最小值的逆向用例
以上几个方面考虑全的话，基本可以做到如下几个方面的覆盖：
主流程测试用例：正常的主流程功能校验；
分支流测试用例：正常的分支流功能校验。
异常流测试用例：异常容错校验
4） 测试用例基本上都包括以下五部分（根据项目情况进行增减）：
a.前置条件
b.输入参数
c.执行步骤
d.校验点
e.期望值
2.2 关注点
1）接口中所有的入参都要写测试用例。
2）每个入参的每个错误类型都要准备一个异常用例。如必须参数缺省、参数类型错误、参数范围错误、参数超过最大位数、参数没有达到最小指定位数、参数的无效值（有效状态外）、参数的小数点超过规定长度、参数含有非法字、参数含有违禁字、参数的关联性检查（如所在省、市，所在地不匹配）等等。
3）对于正常系的用例，要把所有入参的各种合法的有效值都执行到。所有入参的最大位可以用一个测试用例执行掉。所有可缺省的参数不要（只输入必须参数）的测试用例也要做一个。
4）对于搜索接口，应该把每个参数单独作为搜索条件来确认搜索结果是否正确，然后再确认多条件输入后的结果。
转自：https://blog.csdn.net/lestng/article/details/80229445