近期在做项目接口测试，参考网上资料和之前的项目经验对接口测试需注意的事项进行整理，以便后面查找。如有错误的地方，也欢迎指正。
感谢如下原创文章的帮助，牛人很多，收获很多，发现自己不会的东西真的太多了……
重点参考：https://blog.csdn.net/nikita1995/article/details/82494416
1 概述
1.1 什么是接口测试
简单来说接口测试就是对接口协议的一种测试，本质也是对发送和接收数据的测试。
考虑到至少如下原因，需要做接口测试：
- 开发前后端工作进不一致，需提前安排测试。
- 与第三方系统对接，需对接口是否满足要求进行验证。
- 从安全层面考虑，不能只依赖于前端处理，需从接口层面进行验证后端是否有相关验证及限制。
- 验证敏感信息是否进行加密传输。
通常优先针对两种类型的接口进行测试：
- 数据进入系统接口（调用外部系统的参数为本系统使用）
- 数据流出系统接口（验证系统处理后的数据是否正常）
此外，优先选择面向用户/客户的接口进行测试。
1.2 接口测试流程
需求评审-->编写用例-->准备数据-->执行测试
说明：为方便测试，在整理用例、准备数据、工具及脚本使用方面，尽量往方便转化为自动化的方式进行操作。
1.3 接口测试常用方式
通过工具模拟客户端向服务端发送请求并接受服务器返回的数据来对接口的功能、逻辑业务、异常、性能、安全等进行测试。
功能测试：测试接口的功能是否实现，是否按照接口文档完成开发。
逻辑业务：主要指逻辑业务依赖关系，包含系统内部的业务依赖、与外系统的业务依赖。
异常测试：通常需考虑参数异常、数据异常。参数异常如：关键字错误、参数为空、参数个数等；数据异常如：数据错误、数据为空、数据长度等。
1.4 接口测试常用工具
对基于http协议的接口，主要是通过工具或代码模拟http请求的发送与接收。
抓取请求常用工具：fiddler。
测试请求常用工具：postman、jmeter、soupUI、java+httpclient、robotframework+httplibrary等，也可用代码实现。
2. 接口需求评审
需从产品处获取接口应用的目的、使用场景、接口需求文档，在熟悉业务需求的同时，结合获得的文档、信息，从如下几方面进行分析、审核，为下一步的测试设计做准备：
- 接口文档是否提供完整说明：接口请求方式，传入参数的个数、名称、类型、限制、是否必选、默认值，返回参数的个数、名称、类型、限制、顺序，返回参数是否包含所有可能的业务逻辑情况等。
- 接口在系统内有哪些关联功能，是否有相应的需求实现，业务是否有走不通、不完整、不合理的地方，是否有潜在的性能、安全问题。
- 接口与外系统有哪些关联功能，是否有相关的需求实现，业务是否有走不通、不完整、不合理的地方，是否有潜在的性能、安全问题。
- 接口是否有缺失参数，包含必要的、或便于扩展应用的。
- 接口是否有多余参数，有无保留的必要。
- 接口实现方式是否具有扩展性。
3. 接口测试设计
接口测试思路可参考如下（借用了参考原创文章里的图，觉得比自己整理的好多了）：
3.1 业务功能测试
需针对接口应用的场景、逻辑、关联功能、关联系统进行分析，设计正常场景、异常场景的测试用例。
正常场景包括但不限于：
- 所有非异常类返回参数对应的场景。
- 受系统内关联功能的场景，如修改开关、修改参数、更新数据后，影响接口返回。
- 受其他系统影响的场景，如充值回调。
- 会影响系统内关联功能的场景，如通过接口进行开关控制、修改参数等。
- 会影响其他系统的场景，如通知其他系统进行操作。
异常场景包括但不限于：
- 所有异常类返回参数对应的场景。
- 请求超时。
- 频繁连续请求。
- 重复请求。
- 并发请求。
- 接口异常。
- 系统内关联功能、或其他系统出现异常，或传入未知数据。
3.2 边界分析测试
根据业务应用的特点，或输入、输出参数的类型或限制，有针对性地设计有效边界用例、无效边界用例。
3.2.1 业务规则边界分析
侧重于针对业务方面的限制设计的边界值，通常可能需要对系统配置特定的参数与输入输出参数进行组合设计。
需考虑如下角度进行设计：
- 业务规则为有限的几种情况：取所有情况进行测试。如：后台参数有多个值，不同值对应接口有不同的返回处理，则所有的值均应测试，另外补充无效的开关值。
- 业务规则为无限、但有特定范围：针对业务规则的范围取有效、无效边界值进行测试。
- 业务规则对输入输出参数的范围有影响的：设定特定业务规则（通常取常用、极端等个别情况），对输入输出参数取有效、无效边界值进行测试。如：数据查询天数限制在后台可进行设置，则日期参数需针对该参数设计取对应的有效、无效边界值。
- 参数间有业务制约关系：取所有情况交叉组合进行测试。
3.2.1 输入输出参数边界分析
侧重于针对参数本身限制设计的边界值。需考虑如下角度进行设计：
1. 参数是否必选：
- 均为必填：必填参数全缺、必填参数缺一、必填参数全填。
- 有可选：必填参数全缺、必填参数缺一、必填参数全填但无可选参数、必填参数加一个可选参数、必填参数加部分可选参数组合、必填参数加所有可选参数。
2. 参数默认值：
- 输入：有默认值（传值取指定值、不传取默认值）、无默认值（传值、不传）。
- 输出：默认值（可根据业务及需求确认）。
3. 参数为空、空字符串””。
4. 参数为null、”null”字符串。
5. 参数的顺序：
- 输入：有指定顺序（传正确顺序、传若干个错误顺序），无指定顺序（传若干个不同顺序）。
- 输出：有指定顺序（根据需求确认，尽可能有一定规则，避免乱序。如：参数顺序有一定规律；记录类型按ID或时间顺序返回等）。
- 特殊：数值、数值字符串的排序结果不同，若需对数值字符串按数值方式排序，需取特殊用例（关注第一个字符），如：100，2，80（按字符串排序80>2>100，按数值排序100>80>2）。
6. 参数的个数：不同的情况下对参数个数有无要求。
- 关键字的个数：通常与是否必选可一并测试。
- 参数值的个数：若参数值为不同类型参数，可参考参数嵌套处理。这里主要指同一个参数内有多个同类型的值的情况，需考虑：参数个数最小/最大有效值、最小/最大无效。如：接口需传多个账号组成的字符串，可设计用例包括0个、1个、最大个数、最大个数+1个。
7. 参数的类型：根据不同类型，参数的边界值设计需考虑的侧重点不同。
数值类型（数值字符串也可参考数值类型）：
- 数值长度（最小/最大有效值、最小/最大无效值、长串数字）
- 数值大小（最小/最大有效值、最小/最大无效值、数据类型支持的最小值/最大值、数据类型支持的最小值-1、数据类型支持的最大值+1）
- 数值格式（整数、小数、精度为X位小数、超过精度位数、科学计数法、十六进制、千分位符）
- 特定数值（负数、0、正数前面有+、数值前面加0、小于1小数整数0缺失、小数位后面补很多0）
- 非数值（数字字符串、英文、特殊符号）
- 超过精度处理（截取、四舍五入）
金额类型（金额格式字符串也可参考数值类型）：
- 格式通常带小数且有指定精度限制。
- 负数及0需重点关注是否正确。
- 是否有币种的概念，或需做相关转换。
字符串类型：
- 长度（最小/最大有效值、最小/最大无效值、超长字符串）
- 格式（所有符合的格式，不符合的格式可侧重选取：有少量偏差的格式、易混淆判断的格式、普通格式）
- 特定字符串（根据参数限制设计，但需考虑支持的字符集，再取有效值及无效值。如：支持中文或其他语言应取个别语种用例；支持英文字母应覆盖26个字符及大小写；支持数字字符串应覆盖0-9、小数点；支持邮箱应覆盖英文、数字、@及小数点等。另外，可用错误推测法适当相似字符串、可能出错的字符串等作为用例。
- 非字符串（数值类型）
时间类型：根据时间格式是数值类型、还是字符串类型进行参考设计。但需特别注意如下关注点：
- 数值大小（时间最小/最大有效值、最小/最大无效值，年份最小/最大有效值、最小/最大有效值，月份为0/1-12/13，日期为0/1-31/32，小时为0-23/24/25，分为0-59/60，秒为0-59/60）
- 格式
- 特殊情况（2月没有30/31日，闰年的2月才有29日，负数）
- 非时间格式
- 是否有时区概念，或需做相关转换
枚举类型：所有有效情况，抽样其他无效情况。
唯一性/校验类：根据时间格式是数值类型、还是字符串类型进行参考设计。但需特别注意：
- 校验参数有/无
- 校验参数正确/错误
- 是否需加密处理
参数有无包含特殊字符。
参数嵌套：若存在参数嵌套，即多个参数通过一定方式（如组装、编码、加密）合并成一个参数，可拆分三个角度设计用例：
- 一是把内部参数当作独立参数设计用例，方法与独立参数相同。
- 二是把外部参数作为整体设计用例，也参考独立参数。
- 三是分析内部参数组装成外部参数的过程设计用例（如：参数A和B以json格式组装后，进行base64编码得到参数C，则需考虑参数C不能按base64解码、以及base64解码后无法按json解析两种情况）。
3.3 参数组合测试
可结合多种方法对各类参数的组合方式进行设计：如正交法、因果图、场景分析法、错误推测法等。
3.4 异常情况测试
大部分异常测试在业务功能、边界分析、参数组合、性能测试、安全测试中均有覆盖，通常根据实际情况另外补充。
3.5 性能测试
以后整理后再补充。
3.6 安全测试
手工测试方面：侧重于对业务、场景进行分析，一定程度地模拟和检查接口设计和实现是否存在隐患和漏洞。如：
敏感信息方面：参数是否可由前端传给后端；参数信息是否可作为参数返回；数据传输是否应进行编码或加密；加密方式是否使用正确。
越权访问：通过异常方式修改或查询非权限范围数据。如：A账号登录后，通过修改某些接口的ID信息，可查看或修改其他非权限范围内其他用户的数据。
异常篡改：
- 注册/登录方面：是否可绕过部分限制或判断异常注册成功、或未登录的情况下进地操作、或可非法登录其他账号。
- 充提：可通过特殊方法、或绕过常规操作和判断异常充值或提现成功、异常修改金额。
- 修改信息方面：通过异常方式实现信息篡改。
SQL注入，通过各种SQL查询业务信息，甚至破坏系统表。（不完善，后续整理后再补充）：
- SQL拼接
- 使用第三方组件
- 可参考的建议（是参考其他人整理的，比较实在呢。https://www.cnblogs.com/emily-qin/p/8042154.html）：
1. 永远不要信任用户的输入。对用户的输入进行校验，可以通过正则表达式，或限制长度；对单引号和双"-"进行转换等。
2. 永远不要使用动态拼装sql，可以使用参数化的sql或者直接使用存储过程进行数据查询存取。
3. 永远不要使用管理员权限的数据库连接，为每个应用使用单独的权限有限的数据库连接。
4. 不要把机密信息直接存放，加密或者hash掉密码和敏感的信息。
5. 应用的异常信息应该给出尽可能少的提示，最好使用自定义的错误信息对原始错误信息进行包装。
3.7 测试用例模板表（建议用excel）
XX接口测试用例：
| 用例ID | 用例名 | 请求参数（根据情况可一列或多列） | 预期结果 | 测试结果 | 备注 |
4. 接口测试需关注的预期结果
接口返回与预期一致。
服务端、数据库无异常报错。
不会导致本系统内、外系统出现异常的业务流程，或产生异常数据。