一
请问你是如何做接口测试的？
大致说来，经过了以下过程。 接口需求调查、接口测试工具选择、接口测试用例编写、接口测试运行、接口测试回归、接口测试自动化持续集成。 具体来说，接口测试过程分为以下九个步骤。
第1步(请分析测试要求，开发并提供接口说明书。
步骤2 )从接口说明文档中整理接口测试用例，详细条目(正常情况，异常情况考虑输入参数个数、类型、可选/必填项，参数存在互斥或相关情况)和输出数据
步骤3 :与开发一起评审接口测试用例；
步骤4 )结合开发库，准备接口测试用例的参数数据和参数数据，并整理成Excel格式的文件
步骤5 :将接口的测试用例文档与Excel格式的数据文档相结合，生成接口自动化测试的业务逻辑代码；
步骤6 :开始运行接口自动化测试用例
步骤7 :执行中存在漏洞时，提交缺陷管理平台；
步骤8 :开发修改完成后，返回错误并跟踪状态；
步骤9 :完成后进行持续的自动化集成
二
接口测试如何设计测试用例？
主要从功能、业务逻辑、异常、安全四个方面设计界面用例。
功能：是否符合需求
1 )从用户角度看界面能否实现业务需求，功能是否正常
2 )功能是否按接口文档实现；
例如，在博客圈添加随笔时，需要登录才能添加。 这意味着业务要求不支持添加随笔功能。 当您设计未登录的用户并测试添加随笔接口时，该接口将添加到随笔中。 这表示功能不正常，不符合需求和接口文档的描述。
业务逻辑：是否依赖业务
1 )接口实现逻辑
2 )业务逻辑覆盖(语句/条件/分支/判定/…)；
示例)如果在调用此接口之前必须调用登录接口，并且无需登录就可以请求数据，则这不符合业务逻辑。
异常：参数异常和数据异常
1 )参数异常)关键字参数、参数为空、多、少参数、错误参数
2 )数据异常)关键词数据，数据为空，长度不一致，错误数据
例如，无论是数据异常还是参数异常，测试点都差不多，一个参数有key和value，key表示参数，value表示数据。 第一，检查参数和数据是否支持关键字，例如Java保留关键字。 二是参数和数据为空，看是否判断出来；三是参数多与少。 例如，一个有两个参数的接口需要设计一个包含三个参数的用例和一个只有一个参数的用例。 由于数据库创建表时设置了各字段的长度，因此数据的长度不一致，例如是否支持长字符串的设计。 输入错误的参数和数据，例如故意弄错单词。
安全测试用例设计：
1 ) cookie :有cookie以获取数据。 如果没有cookie也会返回信息，表示有问题
2 )头)普通接口带有头信息，看能否删除头返回数据；
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测试有哪些优势？
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，检查网络是否通畅；
2. 检查接口的端口号是否正确，可以通过在本机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/网关超时）。从以下两种情况分析：
如果单次调用接口就报该错误，说明是后端服务器配置有问题，或者服务不可用，挂掉了；
如果并发压测时出现此错误，说明是后端压力太大，出现异常，此问题一般是后端出现响应时间过长或者无响应造成。