这就需要开发提供的接口文档。接口文档和功能测试需求规范的功能是相同的。包括：接口说明、调用URL、请求方法（get或post）、请求参数、参数类型、请求参数说明、返回结果说明。有了接口文档之后，我们就可以设计用例了。一般来说，接口测试的用例分为以下几种类型：

1. 通过性验证。说白了就是传递了正确的参数，是否返回正常的结果。

2.参数组合，因为参数有必选和可选，参数的类型和长度，以及传递时可能存在的一些业务限制，所以在设计用例时，需要对这些情况进行安排和组合，保证所有的情况都可以覆盖。到达

3.接口安全，分为几种情况：

1）绕过验证，例如提交订单时，传递产品价格参数时，修改产品价格取决于后端是否经过验证。或者当我付款时，我拿一个袋子并更改订单金额。如果我可以用更改后的金额付款，那么这个借口就有问题。

2）绕过认证是指某项功能只能由具有特殊权限的用户操作。如果我传给普通用户，也可以操作吗？

3）参数是否加密关系到部分账户的安全。例如，当我们登录某些网站时，它会对我们的登录信息进行加密。如果不这样做，我们的信息就会被暴露，这是极其有害的。

4）密码安全规则，设置密码时的复杂度验证。

4. 根据业务逻辑设计用例

接口测试是测试系统组件之间接口的一种测试。接口测试主要用于检测外部系统与系统之间、内部子系统之间的交互点。测试的重点是检查数据的交换、传输和控制管理流程，以及系统之间相互的逻辑依赖关系等。接口测试一般分为两类：模块接口测试和Web接口测试。

WEB界面测试

Web接口测试可以分为两类：服务器接口测试和外部接口测试。

服务器接口测试：测试浏览器与服务器之间的接口。用户输入的数据在前端页面上输入。如何将这些数据传输到后端？前后端数据传输是通过http协议的get和post请求来实现的。这也可以认为是接口测试。

对外接口测试：这个典型的例子就是第三方支付。比如我们的应用中，充流量或者交话费的时候，会调用第三方支付接口。

主要测试点如下：

检查请求是否正确。默认请求成功为200，如果请求错误，也可以返回404、500等。

检查返回数据的正确性和格式； json是一种非常常见的格式。

为了接口的安全，一般web不会暴露在互联网上，可以任意调用，需要做一些限制，比如认证或者认证。

界面的性能直接影响用户体验。

测试用例

阳性测试用例：

覆盖所有需要的参数

组合可选参数

参数边界值

如果参数的取值范围是枚举变量，则需要覆盖所有枚举值

还应考虑实际业务应用场景来设计输入参数的组合。 （这些用例可以作为用例来测试功能，也可以用于以后的压力测试，模拟实际业务场景，但要注意保证用例的独立性，因为压力测试是比如我们测试创建接口的时候，名字不能重复，在编写测试用例的时候，可以在给NAME赋值的时候加上时间戳，这样测试用例就不会出现问题。在多线程并发测试期间）

负面测试用例：

空数据

包含特殊字符

数据越界

错误的数据

验证点：

代码（通常，所有请求都应返回 200）

响应信息数据结构（目前大多数情况下返回的信息都是JSON，当数据信息发生变化时我们应该验证对应的结构）

验证节点类型

验证节点的值（主要针对固定值或者遵循一定规则的值，这样我们就可以知道预期的结果）

对于列表，您需要根据请求参数验证列表的长度是否与预期值一致。

负面测试用例，应验证 INFO 与实际情况相符

接口测试用例设计

1.1 接口文档特点

接口文档，顾名思义，就是描述接口的文档。一个好的接口文档包含接口URL、参数和输出内容的描述。我们可以参考接口文档来一一编写测试用例。而且，如果接口文档详细的话，测试用例就很容易写，不会被遗漏。

如果接口文档写得不明确，从文档中无法分辨哪些参数是需要的，哪些是不需要的，也没有参数值描述、返回值结构等信息，测试人员就无法编写相应的测试。用例。但由于开发人员不愿意写文档，导致很多接口文档都比较简单、不清晰，这对我们自动化接口测试来说是一个很大的障碍。

1.2 接口文档结构

接口文档可以包含很多信息。如果你愿意写，你可以写更多。如果你不愿意写，你写的信息就会相对较少。但是，必须存在以下项目。这是我们使用接口进行中和和测试接口的基础：

(1) 接口名称。简单的描述，标识各个接口，例如登录接口、获取项目详情的接口等。

(2) 接口网址。测试环境中接口的调用地址可能与之前的域名不同，但接口名称不会改变。

(3)调用方法。接口的调用方式：Post/Get方法，决定了如何调用接口并传递参数。

(4) 参数。接口需要传递的参数需要添加一些说明：

(a) 参数值类型说明：参数值应有解释。它仅支持字母、数据、特殊字符或字母和数据的混合。

(b) 参数长度说明：参数接收最大数量的字符串，或者最大数量的值等。

(c) 参数取值范围：与枚举参数一样，只接收一定范围内的数据，如1-5等。

(d) 参数配合说明：有些参数需要配合使用，如： 和 参数。

(e) 该参数是必需的还是可选的。

(5)返回值。接口的返回值描述需要包括正确和错误的情况。正确情况下的数据在哪里？错误的情况下会有什么提示？

(6)其他一些说明。以上说明是通用的，还有其他说明，比如调用必须登录，或者版本号等，在某些情况下也需要说明。

1.3 接口文档缺失的解决办法

(1)根本没有接口文档。这种情况是最麻烦的。我们需要和开发商讨论一下。最好提供接口文档。如果为时已晚，请提供调用该接口的实例。实例中会有接口地址、参数等信息。如果我们在测试环境中调用它，我们可以看到返回的结果。

(2)接口文档信息不完整。信息不充分是最常见的，比如缺少参数说明，没有说明哪些参数需要哪些参数不需要，或者没有说明取值范围等，这时候可以向开发询问。如果不方便的话，我们应该尝试一下：一般情况下，非必要参数不会进行容错判断，必要参数的检测比较全面。

(3) 文件不是最新的。后续工作中对该界面进行了修改或优化。我们按照接口文档中的说明调用，但是返回结果与预期不一样。通知开发更新文档，然后使用最新的文档修改测试用例。

这个接口文档需要得到接口开发者的同意。开发新的接口时，接口信息一定要写清楚。如果原有接口有更新，必须及时更新接口文档。同时，在编写接口自动化测试用例时，需要与开发人员进行更多的沟通，过程中沟通的一些关键信息都被整理并保留在文档中。

2. 接口测试用例设计

2.1 设计思路（策略）

1) 优先级 – 对于所有接口

一个。对外暴露的接口，因为该接口通常是由第三方调用的；

b.系统内部调用的核心功能接口；

c.提供系统内部非核心功能调用的接口；

2) 优先级 – 对于单个接口

一个。首先测试正向用例，然后测试反向用例（通常不是绝对的）；

b.是否满足前提》参数是否携带默认参数值》参数是否必填》参数之间是否存在关联性》参数数据类型限制》参数数据类型本身的数据范围值限制

3）设计分析：通常，设计接口测试用例时需要考虑以下几个方面：

一个。是否满足先决条件

有些接口需要满足前置条件才能成功获取数据。通常需要登录。

逆向用例：根据前置条件是否满足（假设为n个条件）设计0~n个用例

b.是否携带默认值参数

正向用例：没有填写任何有默认值的参数，也没有传递任何参数。所有必需的参数均已正确填写，并且具有存在的“常规”值。其他不填。设计1个用例；

c.业务规则和功能需求

这里，根据实际情况，结合接口参数描述，可能需要设计n个正向用例和反向用例。

d.参数有要求吗？

反向用例：对于每个需要的参数，设计一个参数值为空的反向用例

e.参数之间有相关性吗？

有些参数之间存在相互制约的关系

逆向用例：根据实际情况，可能需要设计0~n个用例。

f.参数数据类型限制

反向用例：对于每个参数，设计一个参数值类型不一致的反向用例。

g。参数数据类型本身的数据范围值限制

正向用例：对于所有参数，设计一个正向用例，其中每个参数的参数值为数据范围内的最大值。

反向用例：对于每个参数（假设n），设计n个反向用例，其中每个参数的参数值超过数据范围的最大值。

对于每个参数（假设n），设计n个反向用例，其中每个参数的参数值小于数据范围的最小值。

如果考虑到以上几个方面，基本上可以涵盖以下几个方面：

主流程测试用例：正常的主流程功能验证；

支流测试用例：正常支流功能验证。

异常流程测试用例：异常容错验证

4）测试用例基本包括以下五个部分（根据项目情况增减）：

一个。前提条件

b.输入参数

c.执行步骤

d.检查站

e.期望值