主要从四个方面来设计接口用例：功能，业务逻辑，异常，安全。

功能：是否符合需求

1）从用户角度出发看接口能否实现业务需求，功能是否正常；

2）功能是否按照接口文档实现；

举例：比如博客园添加随笔，需要登录才能添加。也就是业务要求不支持游客添加随笔功能，如果设计一个没有登录的用户，然后去测试添加随笔接口，结果接口能添加到随笔，说明功能不正常，不符合需求和接口文档描述。

业务逻辑：是否依赖业务

1）接口实现逻辑；

2）业务逻辑覆盖（语句/条件/分支/判定/…）；

举例：该接口调用之前，需要调用登录接口，如果不登录也能请求数据，不符合业务逻辑。

异常：参数异常和数据异常

1）参数异常：关键字参数，参数为空，多，少参数，错误参数；

2）数据异常：关键字数据，数据为空，长度不一致，错误数据；

举例：不管数据异常还是参数异常，测试点差不多，一个参数有key和value，key表示参数，value表示数据。第一，看看参数和数据能不能支持关键字，例如Java中的保留关键字等等；第二就是参数和数据都为空，看看是否做了判断；第三，参数多和少，例如有两个参数的接口，需要设计一个包含三个参数的用例，一个只有一个参数的用例。数据长度不一致，例如设计很长的字符串是否支持，因为数据库创建表过程都设置好了每个字段的长度。输入错误的参数和数据，如故意输错单词等等。

安全测试用例设计：

1)cookie：有cookie才能获取数据，如果不带cookie还有信息返回，说明有问题；

2)header：正常接口带header信息，删除header看是否能够返回数据；

3)唯一识别码：app手机识别码，一般是唯一的；

4)文本输入框sql注入和xss攻击。

接口的返回关键字段和字段值是需要校验的，不然接口测试就没有意义了。

一般有两种方式：

1）数据库预置数据，接口校验返回；

2）接口调用，比对数据库查询结果。

一般来说，从以下八个方面评估：

1. 业务功能覆盖是否完整；

2. 业务规则覆盖是否完整；

3. 参数验证是否达到要求（边界、业务规则）；

4. 接口异常场景覆盖是否完整；

5. 接口覆盖率是否达到要求；

6. 代码覆盖率是否达到要求；

7. 性能指标是否满足要求；

8. 安全指标是否满足要求；

造数据和数据清理，需用Python连数据库了，做增删改查的操作测试用例前置操作。

setUp做数据准备后置操作；
tearDown做数据清理；

解决方法如下：

使用单例模式；
使用自定义缓存机制；
使用测试框架中的 setup 机制；
pytest 中 fixture 机制；

接口测试断言可以从以下五个方面进行设计：
1）响应码：检查响应码是否符合预期，用来判断测试用例是否执行成功（针对http接口）；

2）关键字：验证关键字是否符合预期，用来判断测试用例是否执行成功；

3）正则匹配：当一个接口返回的内容较多，并且有一定规律时，可通过正则表达式来校验接口返回的信息来判定测试用例是否执行成功；

4）数据库匹配核对：比如对查询一个接口返回的数据进行验证时，可通过编写sql语句查询结果，然后将sql语句执行后数据库返回的结果与接口返回的结果进行核对，以此来判定测试用例是否执行成功；

5）通过相关接口进行辅助验证：比如，当测试一个删除接口时，删除一条记录后，想验证这条记录真的被删除，可调用查询接口，若删除的记录没被查询到，则说明删除这条记录成功。

可以利用一些Mock工具（如：JSON Server、Easy Mock）来模拟第三方的数据返回，最大限度的降低对第三方数据接口的依赖。Mock服务是指在测试过程中对于某些复杂（或者不太好构造）的对象，用一个虚拟的对象替代它。如现在有A和B两个接口， A需要调用接口B才能完成业务需求。这个时候B接口有如下三种情况：

1）B接口还没有开发完成：需要等待接口的数据来进行开发，这时候完善的接口Mock服务能大大缩短开发联调等待时间。

2）B的某些场景很难去模拟：比如超时、未知错误或者不稳定的第三方接口。

3）性能测试中隔离B接口(第三方接口)：在进行压测的时候就会遇到问题。

API是(Application Programming Interface)，即应用程序编程接口。API是一组用于构建软件应用程序的规程，协议和工具。API充当软件应用程序之间的接口，并允许两个软件应用程序相互通信。API是一组软件功能，可以由其他软件执行。

API测试具备如下优势：

更快及更高的测试覆盖率。
API测试有助于我们降低测试成本。通过API测试，我们可以在GUI测试之前找到小错误。在GUI测试期间，这些小错误将变得更大。因此，在API测试中发现这些错误将对公司具有成本效益。
API测试与语言无关。
API测试在测试核心功能方面非常有用。我们可以在没有用户界面的情况下测试API。在GUI测试中，我们需要等到应用程序可用于测试核心功能。
API测试有助于我们降低风险。

接口调不通的原因：
1）接口没有任何响应

很多时候在做接口测试时，会发现接口没有任何返回，比如浏览器一直在转圈，或者返回一个空白页面。用接口测试工具时，工具报错，提示“no response”。

排查思路：

1.先检查接口ip是否正确，可以通过在本机ping 接口的ip，检查网络是否通畅；

检查接口的端口号是否正确，可以通过在本机telnet接口的ip和端口号，检查端口是否能连通；
3.检查项目是否启动或者部署成功，可以找研发确认，或者自己登录到服务器上，通过ps命令检查项目的进程是否存在，然后用tail命令查看部署日志；

4.检查服务器防火墙是否关闭，如果因为安全或者权限问题不能关闭，需要找运维进行策略配置，开放对应的ip和端口号；

5.检查你的客户端（浏览器/测试工具），是否设置了网络代理，网络代理可能会造成请求失败；

6.检查操作系统的host文件，是否绑定了一个错误的ip映射；

2）接口有响应但是返回了错误的状态码

有些时候接口会返回一些错误的HTTP状态码，需要根据不同的状态码来确定具体的原因。

排查思路：

400：客户端请求错误，比如请求参数格式错误（如json字符串不合法）；

401：未授权，比如在请求header里，缺乏必要的信息头（如token、auth等字段）；

403：禁止，常见的原因是用户的账号没有对应的url权限，还有就是项目所用的中间件，不允许远程访问（比如Apache）；

404：资源未找到，导致这种情况的原因很多，比如：

url拼写错误；
url后有空格；
项目没有启动成功；
请求协议不对，如http/https；
405：方法不允许，常见的原因是请求方式不正确，比如GET类型接口，使用POST方式去请求；

415：不支持的媒体类型，常见原因是请求数据的类型和服务端支持的类型不匹配，比如json接口，需要添加一个信息头Content-type:application/json；

500：服务器内部错误，出现这种情况，说明服务端内部报错了，需要登录到服务器上，检查错误日志，根据具体的提示信息再进行排查；

502/503/504（Bad Gateway/错误的网关、Service Unavailable/服务无法获得、Gateway Timeout/网关超时）。

从以下两种情况分析：

如果单次调用接口就报该错误，说明是后端服务器配置有问题，或者服务不可用，挂掉了；
如果并发压测时出现此错误，说明是后端压力太大，出现异常，此问题一般是后端出现响应时间过长或者无响应造成。

总结：

感谢每一个认真阅读我文章的人！！！

作为一位过来人也是希望大家少走一些弯路，如果你不想再体验一次学习时找不到资料，没人解答问题，坚持几天便放弃的感受的话，在这里我给大家分享一些自动化测试的学习资源，希望能给你前进的路上带来帮助。

软件测试面试文档

我们学习必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有字节大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。

          视频文档获取方式：
这份文档和视频资料，对于想从事【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！以上均可以分享，点下方小卡片即可自行领取。