接口测试初认知

接口测试初认知

一、概念

根据分层自动化测试中的定义，最底层由开发人员编写的单元测试保证代码质量，最上层由功能测试人员手工+UI自动化进行大量的自动化功能测试保证功能的可用，则中间层的接口测试是什么作用呢？接下里我们就学习接口测试。

那说到接口测试，那什么是接口呢？

语法接口：编程语言语法上定义的接口，具体到程序中的一般就是提供了输入输出的类、方法或函数。对于接口的测试，一般需要使用与开发程序接口相同的编程语言，通过不同的传入不同的参数，来验证程序接口的功能。

协议接口：一般指系统通过不同的协议来提供的接口，例如http/soap协议等。这种类型接口对底层代码做了封装，会写好接口路径和接口方法名的映射，然后前端通过接口路径来调用方法。我们接口测试，就是测试协议接口。

二、接口测试的意义

1、更早的发现问题

测试左移提倡测试应该更早的介入到项目开发中，因为越早的发现bug，修复的成本越低。然而功能测试必须要等到系统提供可测试的界面才能对系统进行测试。系统接口是上层功能的基础，接口测试可以更早更低成本的发现和解决问题。

而且，在我们实际工作经历中，你会发现，由于时间、资源和其他原因，开发人员大部分是不会编写单元测试，所以接口测试就更为重要。

2、缩短产品研发周期

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

结合实际来说，有一个查询功能，后端接口已经做好了，但是前端页面还没设计好。如果是功能测试，那你只能是等待前端页面做好才能进行。如果有接口测试，就直接通过输入参数进行接口测试。更早介入测试，再等前端页面开发，能减少功能测试阶段的bug，就可以缩短产品开发周期。我认为，接口测试可以看成是简单的部分并行工作流程。

3、发现更底层的问题：

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

eg：在工作中，有一个优惠检验功能，分别由两个参数控制，一个A是控制是否使用，一个B是具体的优惠详情。在正常的功能测试中，前端传入的参数是正确且对应关系是一致。但是异常情况下，前端由于某种原因，缓存清理B出现问题，还是保留了B，但是A是0，后端的校验机制竟然通过了，并且使用了B优惠。这种情况就是底层逻辑的校验没有做好，并且这种异常情况，功能测试下是无法去手动实现异常场景的。

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

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

5、个人经历

在工作中，公司某一项目：平台的代码是二期的，但是客户端是一期的。实现的支付接口，平台在二期有改动，使用二期客户端没有问题。但是在只上平台代码，客户端还是一期的版本，就会出现一期中控调用二期平台的场景，接口没有向下兼容，所以测试左移是很重要的。

三、接口测试用例设计

接口测试用例设计有三个模块：前端测试、后端测试、接口文档

• 前端测试，进行响应数据的改写，验证不同的响应下前端的展示效果

• 后端测试，依据“输入–处理–输出”这样的模式，检查输出结果跟期望是否一致

• 接口文档，需要检查实际开发和接口文档是否统一

测试用例设计思路

从输入参数进行考虑设计

优先级-针对所有的接口：

• 1、暴露给其他系统、第三方调用的接口

• 2、系统内部调用的核心功能接口

• 3、系统内部调用的非核心功能接口

优先级-针对单个接口

• 1、正向测试用例优先，逆向测试用例次之（一般情况）
• 2、是否需要满足前提条件（token）> 是否携带默认值参数 > 参数是否必填 > 参数之间是否存在关联 > 参数数据类型限制校验 > 参数数据类型自身的数据范围值限制校验

用例设计分析

从接口后端业务逻辑出发，设计接口测试用例需要考虑以下几个方面：

1、是否满足前提条件

• 有些接口是需要满足一定条件，才可以成功获取数据。最常见的就是需要用户登录信息的接口（token）

• 逆向用例：设计不满足前置条件的用例

2、是否携带默认值参数

• 正向测试用例：

  存在默认值的参数都不填写、不传参，必填参数都填写正确并且存在正确的常规值

3、业务逻辑、功能需求

• 这个环节需要根据具体的业务需求，结合接口定义文档，可设计出多条正向用例和逆向用例

4、参数是否必填

• 针对每个必填参数，设计一条或多条参数值为空的逆向测试用例

5、参数之间是否有关联

• 可根据参数之间的相互关联关系设计一条或多条用例

6、参数数据类型限制

• 针对每个参数类型设计与定义的类型不符的逆向测试用例

7、参数自身的数据范围值限制校验

• 针对所有的参数，设计每个参数在数据范围内为最大或最小的正向测试用例

总结：如果以上几个方面考虑全面，基本可以覆盖三个点：

a、主流程测试用例：正常的主流程业务需求校验

b、分支流程测试用例：正常的分支流程需求校验

c、异常流程测试用例：异常业务场景的容错校验

从输出参数进行考虑设计

1、输出结构是否与接口文档定义的一致

2、输出的各个字段类型是否与接口文档定义的一致

3、输出的各个字段的值是否符合逻辑且值正确

测试方式

手工测试

手工测试就是借助浏览器或部分测试工具（postman、jemter等）手动执行测试用例的过程。针对新开发接口，建议首先进行全面的手工测试后再将部分可重复执行用例加入自动化测试。开源的：postman、jmeter、meterSphere、SoapUI等，商业的有LoadRunner等

自动化测试

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

一个好的接口自动化测试框架应该涵盖以下几点：

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

a、结果展示：更加丰富的结果展示、趋势分析，质量统计和分析等

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

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

四、接口测试：HTTP协议

HTTP协议

声明：本文章的内容来源有：TestHome的《接口白皮书》和虫师的《Web接口开发与自动化测试-基于Python语言》