1.什么是接口？

接口主要用于系统与系统之间以及程序内部各个子系统之间的交互点，定义特定的交互点，然后通过这些交互点也就是协议，来进行数据之间的交互。

2.接口都有哪些类型？

接口一般分为两种：1.程序内部的接口 2.对外提供的接口

对外提供的接口：如:微信支付接口, 支付宝支付接口等

程序内部的接口：方法与方法之间，模块与模块之间的交互，程序内部抛出的接口，比如电商系统，有登录模块、提交订单模块等等，要支付就必须先登录，那么这两个模块就得有交互，系统内部就会通过一个接口进行数据交互。

接口的分类：1.webservice接口 2.http协议(api接口)

webService接口是走soap协议通过http传输，请求报文和返回报文都是xml格式的，我们在测试的时候可以借助SoapUI工具进行调用及测试。

api接口是走http协议，通过路径来区分调用的方法，请求报文都是key-value形式的，返回报文一般都是json串，有get,post,put,delete等四种常用请求方式。

json是一种通用的数据类型，所有的语言都认识它。（json的本质是字符串，它与其他语言无关，只是可以经过稍稍加工可以转换成其他语言的数据类型，比如可以转换成Python中的字典，key-value的形式。）

3.接口的本质及其工作原理是什么？

接口你可以简单的理解他就是发起请求获取响应数据，工作原理就是URL通过get或者post请求向服务器发送一些东西，然后得到一些相应的返回值，本质就是数据的传输与接收。

4.什么是接口测试？

百度百科的概述为: 接口测试是测试系统组件间接口的一种测试。

接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。

测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。

简单的说就是通过URL向服务器或者其他模块等，传输我们想传输的数据，然后看看他们返回数据的是不是预期想要的。

5.为什么要做接口测试？

5.1 越底层发现bug，它的修复成本是越低的。

5.2 前端随便变，接口测好了，后端不用变，前后端是两拨人开发的。

5.3 检查系统的安全性、稳定性，前端传参不可信，比如电商购物系统，前端价格无法实现传入数据为-1元，但是通过接口可以传入-1元。

5.4 如今的系统复杂度不断上升，传统的测试方法成本急剧增加且测试效率大幅下降，接口测试可以应对复杂度较高的测试场景,负载度越高接口测试效果越好

5.5 接口测试相对容易实现自动化持续集成，且相对UI自动化也比较稳定，可以减少人工回归测试人力成本与时间，缩短测试周期，支持后端快速发版需求。接口持续集成是为什么能低成本高收益的根源。

5.6 现在很多系统前后端架构是分离的，从安全层面来说：

(1)、只依赖前端进行限制已经完全不能满足系统的安全要求（绕过前面实在太容易）， 需要后端同样进行控制，在这种情况下就需要从接口层面进行验证。

(2)、前后端传输、日志打印等信息是否加密传输也是需要验证的，特别是涉及到用户的隐私信息，如身份证，银行卡等。

6.怎样做接口测试？

由于目前大部分项目前后端分离,调用接口主要是基于http协议的接口，所以测试接口时主要是通过工具或代码模拟http请求的发送与接收。工具有很多如：postman、jmeter、soupUI、java+httpclient/TestNG、robotframework等。

-- 也可以用代码实现接口自动化，框架和UI自动化差不多，发送请求用断言来判断

7.接口测测试点是什么？

目的：测试接口的正确性和稳定性；

原理：模拟客户端向服务器发送请求报文，服务器接收请求报文后对相应的报文做处理并向客户端返回应答，客户端接收应答的过程；

重点：检查数据的交换，传递和控制管理过程，还包括处理的次数；

核心：持续集成是接口测试的核心；

优点：为高复杂性的平台带来高效的缺陷监测和质量监督能力，平台越复杂，系统越庞大，接口测试的效果越明显（提高测试效率，提升用户体验，降低研发成本）；

用例设计重点：通常情况下主要测试最外层的两类接口:数据进入系统接口（调用外部系统的参数为本系统使用）和数据流出系统接口（验证系统处理后的数据是否正常）；

PS：设计用例时还需要注意外部接口提供给使用这些接口的外部用户什么功能，外部用户真正需要什么功能.

8. 对接口测试而言，持续集成接口自动化是核心内容, 接口自动化包含以下内容:

8.1 流程方面：在回归阶段加强接口异常场景的覆盖度，并逐步向系统测试，冒烟测试阶段延伸，最终达到全流程自动化。

8.2 结果展示：更加丰富的结果展示、趋势分析，测试数据统计和分析等

8.3 问题定位：报错信息、日志更精准，方便问题复现与定位。

8.4 结果校验：加强自动化校验能力，如数据库信息校验。

8.5 代码覆盖率：不断尝试由目前的黑盒向白盒下探，提高代码覆盖率。

8.6 性能需求：完善性能测试体系，通过自动化的手段监控接口性能指标是否正常。

9. 接口测试质量评估标准：

-- 业务功能覆盖是否完整

-- 业务规则覆盖是否完整

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

-- 接口异常场景覆盖是否完整

-- 接口覆盖率是否达到要求

-- 代码覆盖率是否达到要求

-- 性能指标是否满足要求

-- 安全指标是否满足要求

设计测试用例时我们主要考虑如下几个方面：

01

功能测试

接口的功能是否正确实现了

接口是否按照设计文档中来实现

（比如username参数写为了user，那么这就不符合，因为接口文档在整个开发中都需要使用，所以接口实际的设计要与接口设计文档中保持一致）

• 兼容性测试：
• 比如说今天接口进行了调整，但是前端没有进行变更，这时候需要验证新的接口是否满足旧的调用方式
• 错误码测试：
• 通用的错误码与业务错误码是否能够清晰的说明调用问题，错误码是否能够尽可能的全的覆盖所有的情况
• 返回值测试：
• 返回值除了内容需要是正确的，还需要类型也是正确的，保证调用方拿到这些参数能够正确的解析

参数边界值、等价类测试

• json格式测试：
• 通常我们的接口一般设计的都是传递json串，那么就需要去测试 如果传递非json的情况，这时候程序会不会正确的处理，返回相应的 error code
• 默认值测试：
• 很多情况一些非必填的参数会有默认值，比如说一个查询的接口，参数count为返回查询的结果数量， 默认为10，那么就应该有一条case来测试，当然前置条件是数据库里面必须要存在这样的数据超过10条。

02

逻辑业务

是否有依赖业务，比如查看订单，是需要用户首先登录的，所以肯定要保证登录了或有相应的cookie

业务逻辑测试：传递正确的参数，接口对数据库进行查询的操作，需要去验证数据库查询是否正确，接口对数据库进行 增删改的操作，也需要看数据库是否同步进行了这些操作

03

异常测试

异常分为两类，参数异常和数据异常

1、参数异常：

• 关键字参数：
• 将参数写为开发语言中的关键字
• 参数为空：
• 比如去掉了username参数
• 多或少参数：
• 多或者少参数的验证，现在还不确定如果一个接口多了参数如果没有报错是否是合理的，或者是否需要优化，因为就目前开发给予的答案是，一般不对接口多了参数的处理
• 错误参数：
• 比如将username参数写为了user等看是否能返回相应的error code

2、数据异常：

• 关键字数据：
• 将参数的值填为开发语言中的关键字
• 数据为空：
• 将参数的额值填为空
• 长度不一致：
• 因为数据库中每个字段都设置有字段长度，填写不符合的长度进行验证
• 错误数据：
• 就是将参数的值任意填写，或填写不存在的数值
• 异常类型测试：
• 比如count参数，这个参数的类型一定是可以转换为int类型的，这时候我们需要测试如果传的一些不可以 转换为int类型值来测试代码是否加入判断

04

性能测试

• 响应时间
• 吞吐量
• 并发用户数
• 占用内存，CPU等

05

安全性测试

敏感信息是否加密

必要参数是否后端也进行校验

（现在很多系统前后端架构是分离的，从安全层面来说，只依赖前端进行限制已经完全不能满足系统的安全要求（绕过前端太容易了）， 需要后端同样进行控制，在这种情况下就需要从接口层面进行验证）

接口是否防恶意请求（SQL注入）

• cookie：
• 将header中的cookie修改或删除后看是否能返回相应的error code
• header：
• 删除或修改header中部分参数的值，看是否能返回相应的error code
• 唯一识别码：
• 删除修改唯一识别码测试