WEB接口测试简介及测试规范

引言

接口测试是测试系统组件间接口的一种测试。主要用于检测外部系统于系统之间以及系统内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等等，这要求对业务逻辑有一定程度上的理解，对数据流向有较好的定位。接口测试就是测试接口，尤其是那些与系统关联的外部接口。接口测试的核心战略在于：以保证系统的正确和稳定为核心，以持续集成为手段，提高测试效率，提升用户体验，降低产品研发成本。一般用于多个系统间的交互开发，或者拥有多个子系统的应用系统开发的测试。接口测试适用于为其他系统提供服务的底层框架系统和中心服务系统。主要测试这些对外部提供的接口的正确性和稳定性。它也同样适用于上层系统中服务层接口，测试难度随层级而上升，即越往上难度越大。

接口测试价值

1.不依赖前端页面，可以发现很多在页面上操作发现不了的bug  
2.检查系统的异常处理能力  
3.检查系统的安全性、稳定性，可以降低线上的风险  
4.前端随便变，接口测好了，后端不用变  
5.一般能集成自动化，能提高测试效率，用于冒烟测试和回归测试

接口测试原理

通过测试程序模拟客户端向服务器发送请求报文，服务器接收请求报文后对相应的报文做出处理然后再把应答报文发送给客户端，客户端接收应答报文这一过程(request→response)。

接口测试分类

web接口测试又可分为两类：服务器接口测试和外部接口测试。

• 服务器接口测试：是测试浏览器与服务器的接口。这个很容易理解，我们知道web开发一般分前端和后端，前端开发人员用html/css/javascript等技术。后端开发人用php/java/python/ruby等各种语言。用户输入的数据是输入到的前端页面上，怎样把这些数据传递的后台的呢？通过http协议的get与post请求来实现前后端的数据传递。这也可认为是接口测试，调用的登录接口还是查询接口，传参的是用户密码还是搜索关键字。
• 外部接口测试：这个很典型的例子就是第三方登录，比如你做的新系统免于新用户重新注册的麻烦会提供第三方登录，那用户在登录的时候调用的就是第三方登录的接口，由第三方验证用户名和密码并且返回给当前系统。

接口测试流程

类似于功能测试，需求讨论→评审需求→确定需求→研发输出接口文档→测试输出测试用例→评审用例→执行测试。

接口文档规范

需求确定后，需要研发输出最终的接口文档。接口文档可以包含很多信息，有的愿意写就可以多写的，不太愿意写的话，就写的信息相对来说会少点儿。不过，下面几项内容必须有，这是我们使用接口中和测试接口的依据：

1.接口名称：标识各个接口的简单说明，如登录接口，获取项目详情接口等。  
2.接口URL：接口的调用地址，在测试环境下前面的域名可能不一样，不过接口名是不会变的。  
3.调用方式：接口的调用方式，Post/Get方式，决定了如何调用接口及传递参数。  
4.参数：请求参数及返回参数，参数需要增加些说明：  
- 参数值类型说明：参数值要说明一下，只支持字母，数据，特殊字符或是字母数据混搭。  
- 参数长度说明：参数接收最大多少个的字符串，或是最大是多少的数值等。
- 参数取值范围：像枚举型的参数，只接收什么范围内的数据，如1-5等。  
- 参数的配合说明：有些参数需要配合起作用的，如：有的参数需要由其他参数组合后编码而成。  
- 参数是否必填：需标明参数是否必填。  
5.返回值：接口的返回值说明需要包含正确和错误的情况，正确的情况下有哪儿数据，错误的情况下会有什么提示。  
6.其他的一些说明：上面的说明是通用的，还有其他的一些说明，如必须是登录状态调用，或是版本号等说明，在某些情况下也需要说明一下。  

接口测试用例设计：

测试根据需求文档及接口文档设计测试用例，测试用例主要从业务场景，功能以及异常测试几个方面考虑。

1.设计思路
1）优先级–针对所有接口

- 暴露在外面的接口，因为通常该接口会给第三方调用；
- 供系统内部调用的核心功能接口；
- 供系统内部调用非核心功能接口；  
 

2）优先级–针对单个接口

- 正向用例优先测试,逆向用例次之(通常情况，非绝对)；
- 是否满足前提条件 > 是否携带默认参值参数 > 参数是否必填 > 参数之间是否存在关联 > 参数数据类型限制 > 参数数据类型自身的数据范围值限制  

3）设计分析：通常，设计接口测试用例需要考虑以下几个方面：

- 是否满足前提条件：有些接口需要满足前置条件，才可成功获取数据。常见的，需要登陆Token。 
- 是否携带默认值参数  
- 业务规则、功能需求
- 参数是否必填 
- 参数之间是否存在关联
- 参数数据类型限制  
- 参数数据类型自身的数据范围值限制

以上几个方面考虑全的话，基本可以做到如下几个方面的覆盖：
主流程测试用例：正常的主流程功能校验；
分支流测试用例：正常的分支流功能校验。
异常流测试用例：异常容错校验

4） 测试用例基本上都包括以下部分（根据项目情况进行增减）：功能点，测试环境，测试数据，执行操作以及预期结果。如下：

• 接口测试测试的功能点：如果一个接口功能过于复杂时，可以对接口用例进行结构划分（如根据层次，平台，功能点等等），这样用例具有更好的可读性(接口划分原则为：以接口提供的功能点的不同进行合适粒度的划分，同一功能点的用例又可根据测试环境的不同，数据的不同进行用例的填充)；
• 接口测试用例的环境：程序内部环境和程序所调用的外部接口的环境；
• 关于接口测试测试数据：分为两部分：接口参数数据和用例执行所需系统数据。数据的设计、准备测试用例的数据不可马虎。通过好的测试数据查找问题，能极大的提高工作效率。接口参数数据需要对每个参数根据测试接口的实际功能进行分析，在符合业务逻辑的情况下进行逻辑组合排列，不要遗漏某些边界值和错误点的数据，这样用例更容易发现问题；
• 执行操作：即对所测接口的调用；
• 预期结果：根据需求进行验证，是衡量软件是否达到预期的标准。应该着重细致，每个用例均需验证，应该避免一个用例重复做相同的验证，提高测试用例的效率。

2.关注点

• 接口中所有的入参都要写测试用例。
• 每个入参的每个错误类型都要准备一个异常用例。如必须参数缺省、参数类型错误、参数范围错误、参数超过最大位数、参数没有达到最小指定位数、参数的无效值（有效状态外）、参数的小数点超过规定长度、参数含有非法字、参数含有违禁字、参数的关联性检查（如所在省、市，所在地不匹配）等等。
• 对于正常系的用例，要把所有入参的各种合法的有效值都执行到。所有入参的最大位可以用一个测试用例执行掉。所有可缺省的参数不要（只输入必须参数）的测试用例也要做一个。
• 对于搜索接口，应该把每个参数单独作为搜索条件来确认搜索结果是否正确，然后再确认多条件输入后的结果。

3.测试点

1）检查接口返回的数据是否与预期结果一致。
- 验证接口基础功能能否实现，输入参数能否为数组、缺少必要字段能否请求成功等，具体功能与页面是否符合。
- 验证接口返回参数的正确性，是否包含必要的message、返回的message和操作或原因是否一致、缺少的必要message需要添加。
2）检查接口的容错性，假如传递数据的类型错误时是否可以处理。
- 输入不合法的参数或页面限制的参数，查看返回参数是否符合逻辑，如果不合法的参数是查询的key值，可以视具体场景直接返回报错信息结束查询。
3）接口参数的边界值。例如，传递的参数足够大或为负数时，接口是否可以正常处理。
4）检查身份验证，即需要登录才能操作的功能，验证在未登录状态下是否不可以操作
5）查看权限是否影响后端请求参数，某些接口在没有特意请求权限外数据时返回正常，特意请求权限外数据时会返回权限外数据。
6）用户能否操作权限外的模块或第三方接口，对于页面上隐藏的内容，用户调用接口能否编辑，删除权限外的内容。
7）确保接口功能做部分功能上的限制，如：部分状态如审核通过，不应通过接口可以再次修改为审核拒绝，某些结算数据生成后不应该再次生成等。
8）部分写入数据库，页面不可见的字段需要到数据库确认值是否正确。如：更新时间，操作人等。
9）测试文档验证，验证接口说明文档与接口实际是否一致，必填项，其他字段，请求头，请求方式，返回数据格式等。
10）接口的性能，web接口同样注重性能，这直接影响用户的使用体验。如果搜索一个关键字半天结果都没返回，果断弃用。

4.具体测试用例参考

• 输入参数测试：针对输入参数进行的测试，也可以说是假定接口参数的不正确性进行的测试，确保接口对任意类型的输入都做了相应的处理：输入参数合法（不合法），输入参数为空，为null，输入参数超长等等；
• 功能测试：接口是否满足了所提供的功能，相当于正常情况测试，如果一个接口功能复杂时推荐对接口用例进行结构划分，这样子用例觉有更好的可读性和可维护性；
• 逻辑测试：逻辑测试严格讲应为单元测试，单元测试应保持内部逻辑的正确性，可单元测试和接口测试的界限并不是那么清楚，所以我们也可以从给出的设计文档中考虑内部逻辑错误的分之情况和异常；
• 异常情况测试：接口实现是否对清楚情况都进行了处理，接口输入参数虽然合法，但是在接口实现中，也会出现异常，因为内部的异常不一定是输入的数据造成的，而有可能是其他逻辑造成的，程序需要对任何异常都进行处理。

接口测试工具

接口测试的工具很多，比如 postman、RESTClient、jmeter、loadrunner、SoapUI等，这些常见的测试工具使用方法，都可以在网上搜索到使用方法，就不一一介绍。这里简单介绍一下本人现在使用的接口测试工具Insomnia（下载地址：https://insomnia.rest/）

1.请求及响应如下图：

2.可导入接口请求内容
用F12找到待测接口→copy as cURL(bash)→粘贴至文本文件，保存→insomnia工具中选择Import Data→导入文本文件→导出成功后可看到请求所需的所有内容（请求方法、接口地址、参数、请求头）

3.发送请求后可在右侧窗口看到响应内容

接口测试中常见Bug

- 特殊值处理不当导致程序异常退出或者崩溃
- 类型边界溢出，导致数据读出和写入不一致
- 取值边界外值未返回正确的错误信息
- 权限未处理，可以访问其他用户的信息。例如:无权限可以访问，或者 一般用户可以访问管理员权限）
- 逻辑校验不完善，可利用漏洞获取非正当利益。例如：某网站兑换1块钱需要100币，当小于100币时调用后台，接口是否可以兑换
- 状态处理不当，导致逻辑出现错误
- 必填参数未做必填校验

前端页面测试与接口测试对比

1.前端页面测试特点

• 前端页面测试可以发现页面展示逻辑的问题。如按钮是否可以点击、前端有没有对输入框做字符长度和类型的限制、提示信息有没有错误等。
• 对于涉及大量数据的页面，前端页面测试的测试效率比较高。前端可以快速的进行大量数据与数据库的比对，检查数据的排序是否正确，数据查询逻辑是否正确等。

2.接口测试特点

• 前端页面无法验证页面上无法展示或者无法修改的字段值。部分接口提供了前端页面没有显示的字段，这些字段没有办法通过页面进行输入，因此无法进行前端的验证。
• 接口测试可以验证接口有没有对自己接受的参数做验证。部分参数虽然已经经过前端的验证，后端依然需要进行验证。而且有时即使是接口做了限制也有可能会出现问题。

3.接口测试的必要性

• 接口安全测试是WEB安全测试的重要组成部分，验证接口的安全性，可以降低线上的风险。接口是实现WEB页面信息收集、信息下发的通道，一旦接口出现安全问题，那就意味着整个WEB系统都有较为严重的安全问题的。比如用户可能可以通过开放的接口修改其他用户的数据、通过接口返回的信息获取敏感数据等。
• 接口的功能是WEB系统实现功能的途径，因此必须实现相关的功能。直接通过页面进行接口输入输出数据的验证覆盖率很低，很容易有所疏漏。但是通过接口测试工具直接访问接口，可以极大地提升接口测试效率，增大用例覆盖率，也就增大了问题发现的概率。此外，仅仅针对前端的输入输出检查，也无法判定接口是否对输入输出数据进行了充分的验证。接口可能会由其他人有意或无意的直接访问，未经过验证的数据输入不仅不能实现相应的功能，同时也是巨大的安全风险。

参考链接：
https://www.cnblogs.com/sunshine2016/p/5581217.html
https://www.cnblogs.com/feng0815/p/7509541.html