接口自动化精选面试干货，助你离Offer又近一步！

只要技术过硬，准备充分，任何时候都是找工作的黄金时期。

请问你是如何做接口测试的？

大体来说，经历以下过程：接口需求调研、接口测试工具选择、接口测试用例编写、接口测试执行、接口测试回归、接口测试自动化持续集成。具体来说，接口测试流程分成以下九步：

第一步：分析出测试需求，并请开发提供接口说明文档；
第二步：从接口说明文档中整理出接口测试用例，里面要包括详细的入参（正常情况，异常情况包括输入参数个数，类型，可选/必选，考虑参数有互斥或关联的情况）和出参数据（符合接口文档需求）以及明确的格式和检查点；
第三步：与开发一起对接口测试用例进行评审；
第四步：结合开发库，准备接口测试用例中的入参数据和出参数据，并整理成Excel格式的文件；
第五步：结合接口测试用例文档和Excel格式的数据文档，编写接口自动化测试的业务逻辑代码；
第六步：开始执行接口自动化测试用例；
第七步：执行如有bug，提交至缺陷管理平台；
第八步：开发修改完成后，回归bug，跟踪状态；
第九步：完成后进行自动化持续集成；

接口测试如何设计测试用例？

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

功能：是否符合需求

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接口有如下三种情况：

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/网关超时）。从以下两种情况分析：

• 如果单次调用接口就报该错误，说明是后端服务器配置有问题，或者服务不可用，挂掉了；

• 如果并发压测时出现此错误，说明是后端压力太大，出现异常，此问题一般是后端出现响应时间过长或者无响应造成。