接口测试知识汇总

概述

我做测试这些年，面试过很多童鞋。大部分人在我问到什么是接口测试时，都会侃侃而谈：我用jmeter/postman发送一个请求出去啦，看一下响应结果，如果200就算通过。如果不是200就记下来，有问题就扔给开发。最后出一份报告，这就是接口测试啦！

接下来我会问接口类型有哪些？接口场景怎么设计？接口用例怎么设计？接口响应码有哪些？前端和后端怎么用接口进行交互？往往问到第三个问题的时候，同学们就开始挠头，大脑出现宕机。

因此：补充一些接口测试理论知识是很有必要的哦！

什么是接口?

一般来说接口有两种，一种是程序内部的接口，一种是系统对外的接口。广义来说，客户端与后台服务间的协议；插件间通信的接口；模块间的接口；再小到一个类提供的方法；都可以理解为接口。

系统对外的接口：

如果我们要从网站或服务器上获取资源或信息，网站肯定不会把数据库共享给你，它只会给你提供一个写好的方法来获取数据，我们通过引用它提供的接口就能获取数据。

程序内部的接口：

它是方法与方法之间，模块与模块之间的交互，也是程序内部抛出的接口。比如一个web项目，有登录、新增，修改，删除等等，那么这几个模块会有交互，会抛出一个接口，供内部系统进行调用。

接口的组成

一个完整的接口应该包含以下内容：

1. 接口说明

2. 调用的url

3. 请求方法（get\post）

4. 请求参数、参数类型、请求参数说明

5. 返回参数说明

接口至少应有请求地址、请求方法、请求参数（入参和出参），部分接口有请求头header。header是服务器以HTTP协议传HTML资料到浏览器前所送出的字串，一般存放cookie、token等信息。

header和入参是有区别的。header一般存放的是一些校验信息比如cookie，它是为了校验这个请求是否有权限请求服务器。如果有权限它才能请求服务器，然后把请求地址连同入参一起发送到服务器，然后服务器会根据地址和入参来返回出参。也就是说，服务器是先接受header信息进行判断该请求是否有权限请求，判断有权限后，才会接受请求地址和入参。

常见的接口类型

1、webService接口

它使用soap协议并通过http传输，请求报文和返回报文都是xml格式的，我们在测试的时候通过工具才能进行调用。可以使用的工具有SoapUI、jmeter。

2、http-api接口

它使用http协议，通过路径来区分调用的方法，请求报文都是key-value形式的，返回报文一般都是json串，有get和post等方法，这也是最常用的两种请求方式。可以使用的工具有postman、jmeter等。

3、dubbo接口

 它是使用rpc协议传输，一般应用在微服务中

前端和后端

前端

咱们使用的网页，打开的网站，都是前端。包括Web页面的结构、Web的外观视觉表现以及Web层面的交互实现；

后端

我们在页面上进行操作的时候，这些业务逻辑、功能，比如说新增，修改，删除这些功能是由后端来实现的。后端更多的是与数据库进行交互去处理相应的业务逻辑。需要考虑的是如何实现功能、数据的存取、平台的稳定性与性能等。

前端和后端通过接口进行交互。前端页面通过调用后端接口来实现功能、数据的存取，将数据展现在用户面前。

接口测试定义

1、接口测试是测试系统组件之间接口的一种测试方法

2、它用于检测外部系统与系统之间以及系统内部各个子系统之间的交互

3、重点是要检查数据的交换，以及系统间的相互逻辑依赖关系等

4、接口测试就是通过测试不同情况下的入参与之相应的出参信息来判断接口是否符合或满足相应的功能性、安全性要求。

接口测试意义

1、系统复杂度不断上升，传统的测试方法成本急剧增加且测试效率大幅下降，所以要做接口测试。

2、接口测试相对容易实现。且接口自动化相对UI自动化也较稳定。减少人工回归测试人力成本与时间，缩短测试周期，支持快速迭代。

3、由于很多系统前后端是分离的，所以从安全层面来说，只依赖前端进行限制已经完全不能满足系统的安全要求（绕过前端很容易）， 需要后端也进行校验，在这种情况下就需要从接口层面进行验证。前后端传输、日志打印等信息是否加密传输也是需要验证的，特别是涉及到用户的隐私信息，如钱，身份信息等。

接口测试的价值

1、更早发现问题

测试应该更早的介入到项目开发中，因为越早的发现 bug，修复的成本越低。然而功能测试必须要等到系统提供可测试的界面才能对系统进行测试。而接口测试可以功能界面开发出来之前对系统进行测试。系统接口是上层功能的基础，接口测试可以更早更低成本的发现和解决问题。然而，在实际的开发过程中，开发人员并没有充足的时间去编写单元测试，并且他们往往对自己编写的代码迷之自信，不愿意花时间在编写单元测试上。这个时候接口测试的作用就会变得更加重要。

2、缩短产品研发周期

对于产品研发周期来说，如果将所有测试工作都集中在功能测试阶段。那么测试的问题和修复周期就会变长。因为测试可以更早的介入产品开发中，所以，可以有效的控制功能阶段 bug的数量；从而有效的缩短产品开发周期。

3、发现更底层的问题

系统的有些底层逻辑是在UI功能测试中不太容易触发的，那么这些逻辑可能会存在问题。接口测试可以更容易更全面的测试到这些底层的逻辑。

4、检查服务器的异常处理能力

通常把前端的验证称为弱验证，因为它很容易被绕过，这个时候如果只站在功能的层面进行测试，就很难发现一些安全的问题。不以功能为入口的接口测试就会很容易的验证这些异常情况。

常见请求

GET和POST请求

如果是get请求的话，直接在浏览器里输入就可以，只要在浏览器里面直接能请求到的，都是get请求，如果是post的请求的话就得借助工具来发送。

GET请求和POST的区别

1、GET使用URL或Cookie传参。而POST将数据放在BODY中。

2、GET的URL会有长度上的限制，则POST的数据则可以非常大。

3、POST比GET安全，因为数据在地址栏上不可见。

4、一般get请求用来获取数据，post请求用来发送数据

常见问题：

（1）传入参数处理不当，导致程序异常； 

（2）类型溢出，导致数据读出和写入不一致；

（3）因对象权限未进行校验，可以访问其他用户敏感信息；

（4）状态处理不当，导致逻辑出现错乱；

（5）逻辑校验不完善，可利用漏洞获取非正当利益等

接口测试场景设计

1. 接口文档的规范性检查

2. 接口前置的检查

3. 接口逻辑实现功能的检查

4. 请求参数合法性的检查

5. 请求参数属性的检查

6. 请求参数异常处理的检查

7. 响应体的结构性检查

8. 响应数据的正确性检查

9. 异常响应的检查

10. 响应图片的检查

11. 对旧版本的兼容性检查

12. 业务逻辑中的角色权限检查

13. 业务逻辑中的参数依赖性检查

接口测试流程

• 接口测试的流程其实和功能测试的流程类似，它依赖的主要对象是需求说明书，所以，最初流程是参与需求评审。

• 需求确定以后，开发会根据需求进行接口设计，会给出接口定义。在开发设计过程中，测试可以给出一些针对设计的建议，提高可测性，针对需求及设计，指定测试计划。

• 在开发完成接口定义之后，需要根据需求文档及接口定义设计测试用例与导图。测试用例设计主要从业务场景，功能，以及异常测试几个方面考虑。

• 测试用例设计完成后，针对测试用例进行评审。测试人员可以提前介入开发的接口联调阶段。

• 在项目结束后，需要对每个项目进行总结。

接口响应状态码

http请求状态码详细

使用ASP.NET/PHP/JSP 或者javascript都会用到http的不同状态，一些常见的状态码为：200 – 服务器成功返回网页 404 – 请求的网页不存在 503 – 服务不可用。

1xx（临时响应）表示临时响应并需要请求者继续执行操作的状态代码

• 100（继续）请求者应当继续提出请求。服务器返回此代码表示已收到请求的第一部分，正在等待其余部分。

• 101（切换协议）请求者已要求服务器切换协议，服务器已确认并准备切换。

 

2xx （成功）表示成功处理了请求的状态代码

• 200（成功）服务器已成功处理了请求。通常，这表示服务器提供了请求的网页。

• 201（已创建）请求成功并且服务器创建了新的资源。

• 202（已接受）服务器已接受请求，但尚未处理。

• 203（非授权信息）服务器已成功处理了请求，但返回的信息可能来自另一来源。

• 204（无内容）服务器成功处理了请求，但没有返回任何内容。

• 205（重置内容）服务器成功处理了请求，但没有返回任何内容。

• 206（部分内容）服务器成功处理了部分 GET 请求。

3xx （重定向）表示要完成请求，需要进一步操作。通常，这些状态代码用来重定向

• 300（多种选择）针对请求，服务器可执行多种操作。服务器可根据请求者 (user agent) 选择一项操作，或提供操作列表供请求者选择。

• 301（永久移动）请求的网页已永久移动到新位置。服务器返回此响应（对 GET 或 HEAD 请求的响应）时，会自动将请求者转到新位置。

• 302（临时移动）服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。

• 303（查看其他位置）请求者应当对不同的位置使用单独的 GET 请求来检索响应时，服务器返回此代码。

• 304（未修改）自从上次请求后，请求的网页未修改过。服务器返回此响应时，不会返回网页内容。

• 305（使用代理）请求者只能使用代理访问请求的网页。如果服务器返回此响应，还表示请求者应使用代理。

• 307（临时重定向）服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。

4xx（请求错误）这些状态代码表示请求可能出错，妨碍了服务器的处理

• 400（错误请求）服务器不理解请求的语法。

• 401（未授权）请求要求身份验证。对于需要登录的网页，服务器可能返回此响应。

• 403（禁止）服务器拒绝请求。

• 404（未找到）服务器找不到请求的网页。

• 405（方法禁用）禁用请求中指定的方法。

• 406（不接受）无法使用请求的内容特性响应请求的网页。

• 407（需要代理授权）此状态代码与 401（未授权）类似，但指定请求者应当授权使用代理。

• 408（请求超时）服务器等候请求时发生超时。

• 409（冲突）服务器在完成请求时发生冲突。服务器必须在响应中包含有关冲突的信息。

• 410（已删除）如果请求的资源已永久删除，服务器就会返回此响应。

• 411（需要有效长度）服务器不接受不含有效内容长度标头字段的请求。

• 412（未满足前提条件）服务器未满足请求者在请求中设置的其中一个前提条件。

• 413（请求实体过大）服务器无法处理请求，因为请求实体过大，超出服务器的处理能力。

• 414（请求的 URI 过长）请求的 URI（通常为网址）过长，服务器无法处理。

• 415（不支持的媒体类型）请求的格式不受请求页面的支持。

• 416（请求范围不符合要求）如果页面无法提供请求的范围，则服务器会返回此状态代码。

• 417（未满足期望值）服务器未满足”期望”请求标头字段的要求。

5xx（服务器错误）这些状态代码表示服务器在尝试处理请求时发生内部错误。这些错误可能是服务器本身的错误

• 500（服务器内部错误）服务器遇到错误，无法完成请求。

• 501（尚未实施）服务器不具备完成请求的功能。例如，服务器无法识别请求方法时可能会返回此代码。

• 502（错误网关）服务器作为网关或代理，从上游服务器收到无效响应。

• 503（服务不可用）服务器目前无法使用（由于超载或停机维护）。通常，这只是暂时状态。

• 504 （网关超时）服务器作为网关或代理，但是没有及时从上游服务器收到请求。

• 505（HTTP 版本不受支持）服务器不支持请求中所用的 HTTP 协议版本。

• 511 Network Authentication Required (要求网络认证)

接口用例设计

一个接口通常是有输入输出的，输入就是我们常见的入参，输出则时有时无。调用相关接口，接口会执行相关处理逻辑。

接口测试的用例设计，主要从输入和接口处理两方面考虑：

1）针对输入，可按照参数类型进行设计；

2）针对接口处理，可按照逻辑进行用例设计；

3）针对输出，可根据结果进行分析设计

针对输入设计

对于接口来说，输入就是入参。常见参数类型有:

（1）数值型(int,long,float,double等）

（2）字符串类型

（3）数组或链表

（4）结构体

可能出现的问题和风险

• 传入非特定类型程序异常退出

• 超长字符未进行处理，导致存储、显示等异常

• 其他用户可见设置的敏感字

• 数组或链表类型

• 参数类型为数组或链表时，用例可以考虑

例如批量提交任务的接口，参数用例设计考虑：

• 正常取值：1-5个权限，范围外：6个权限；

• 边界值：1-35的边界值，请求允许最大最小值；

• 特殊值：0个；

• 合法ID和不合法的；

• 重复的ID等。

• 可能存在的问题和风险：

• 0个item时程序异常退出；

• 重复的item处理时未去重导致结果异常等。

针对逻辑设计

接口需要进行一些逻辑处理的，那么按逻辑设计用例可以从以下几个角度分析：

（1）数值限制、分数限制、等级限制等等。例如：兑换Q币活动要求积分>50才可参与

（2）状态限制：登录状态等例如：同步用户信息需要先登录账号。

（3）权限限制：管理员等。

约束条件的测试在功能测试中经常遇到，在接口测试中更为重要。它的意义在于：用户进行操作时，在该操作的前端可以已经进行了约束条件的限制，故用户无法直接触发请求该接口。但是实际上，如果有其他手段：例如通过技术手段直接调用接口，那么接口是否针对这些条件进行了限制就尤为重要。

例如常见的例子：要兑换5Q币需要200积分，但是我积分不足，所以兑换按钮是灰色无法点击的状态。但是我是否可以绕过前端直接调用接口去兑换？预期当然是不能兑换的。因此积分这个数值限制就需要针对接口进行测试，并且非常重要。

针对输出设计

针对输出设计其实是针对接口返回的结果进行分析：

输出结果

接口处理正确的结果可能只有一个，但是错误异常返回结果有很多情况很多值。如果知道返回结果有很多种，就可以针对不同结果设计用例。我们不一定能完全覆盖所有错误码，但是根据接口返回定义的返回码可以设计更多用例。

常见问题和风险

（1）错误前端处理不足，导致前端异常；

（2）错误提示处理不当，导致用户看到晦涩的错误码；

（3）错误提示不当，导致用户不知道哪里出了问题，如何解决。

针对接口超时设计

接口正常情况下是有返回的，那么如果接口不返回呢？也就是说接口超时后的处理也是测试需要考虑的部分。如果超时处理不当，可能会引起以下问题：

（1）未进行超时处理，导致整个流程阻塞

（2）超时后又收到接口返回，导致逻辑出现错乱

针对废弃接口设计

已废弃协议，是指之前有定义，但是因为需求变更或其他原因，暂时不用。这些接口虽然不再使用，但有可能代码并没有及时删除。如果利用技术手段调用这些接口，可能产生风险。因此新版本在考虑兼容旧版本的同时，还应做好相关废弃接口的检查，避免风险。

常见的问题和风险：约束条件判断不足，导致用户可通过特殊手段获取利益。

针对接口合理性设计

接口定义是否合理可以从以下几个方面分析：

（1）接口字段是否冗余；

（2）接口是否冗余；

（3）接口是否返回了调用方期望得到的信息；

（4）接口定义是否可满足所有调用需求；

（5）接口定义调用是否方便。