单个接口的测试内容：

• API 接口文档内容，以及示例确保准确无误，且有文档修改记录
• 接口字段类型和限制必须和文档保持一致(包括字段前后加空格等)
• 接口请求的 Log 记录( 敏感字段需脱敏显示)
• 单个参数以及相应的参数组合请求正确无误(正常和异常情况下都正确，且无系统错误提示)
• 与已有接口处理风格保持一致，包括接口和字段命名，字段类型，报错处理方式，中英文报错等
• 必要的并发测试
• 特殊字符如 & % # $ < 》！* \n \" 等
• 创建/更新之后立即查询
• 特殊字符和 SQL 注入，验证是否可以成功过滤掉特殊字符和sql语句
• 数据库命名规范，统一前缀，默认值，长度限制，字段备注说明，多表中关联字段长度类型一致
• 是否需要 Redis 相关的测试
• 是否有数据需要脱敏存储
• 权限控制
• 幂等性(幂等的方法意味着请求成功执行所得到的的结果不依赖于该方法被执行的次数)
• 注意检测表的主键值是否有可能重复

接口测试注意点：

• 调用创建或者更新接口之后，立即调用查询接口，看是否报错
• 接口地址(资源)中不能有动词，只能是名词，且是复数
• 列表查询默认返回10条，且按创建时间倒序排列，时间戳校验
• 统计类接口返回信息按一定顺序显示(总和－分项)
• String 类型长度限制均一样，中英文是否都算一个字符
• 返回信息 int 类型字段有值 Or 0(时间戳无值时为 null)，string 类型字段有值 Or null
• 错误信息必须容易理解，无论来自第三方还是系统自身
• 查询接口 bool 类型参数需支持 true/false, 1/0
• 不同方法/接口/模块之间的调用应有既定的协议
• 接口升级要考虑兼容性和是否有数据需要修复
• 已经删除的id再次删除时应该报错，逻辑删除的可以报“已经删除”，物理删除可以报“未找到”
• 表示 Id 字段的参数报错规则，请求参数字段会先做有效性校验，所以报错信息分为两种：
  • 1. 不满足规则则报错“无效的 xxx"; 
  • 2. 满足规则但是不存在则“未找到 xx”。比如 URL 中的参数不正确则只会报错 "未找到 xx"；
• 统计类接口中的 amount 类型均为 bigint
• 所有表示 金额 字段的单位均应该为 分，最大值为 1000000000
• 并发限制，同一接口并发，不同接口并发，比如 订单创建的并发，订单支付和取消的并发
• 接口涉及的 JSON 对象必须是格式化的

• 存储在 DB 中的 json 对象或者 json 数组都不能是转义后的，必须保持正确的 JSON 格式(即在 JSON Editor 中可以格式化)

• Optional/Required 字段填写为 “” 或 null，或者不传该字段，一般情况下均应视为不传处理

  • Optional 字段， 对于填写 “”， null，和不传都当作不传处理， 不报错；Required 字段报错提示 “缺少请求参数”

  • 填写该字段，但是值不对，则报错；

• 指定字段未变化时，则 Update 语句中最好不更新该字段

• 转账/红包/提现确认等出钱的动作不要重试，失败就失败，没响应就没响应，牵涉出钱的动作均应该交由客户决定该如何做

• 转账/红包/提现确认等出钱接口的字段最好不要有默认值，同样应交由客户自己做决定

• SQL 查询到的数据要有限制(where 或 limit 等)，避免因查询数据量过大而导致的内存溢出

• 同一字段在不同表中的长度和类型定义要尽量保持一致(如 user_id 在不同表中的长度应该都是 64 位)，防止溢出

• 应根据具体业务情况和需要为 redis key 设置过期时间，避免应该设置的不设置

• 对于需要校验支付金额的测试，请测试支付金额分别为 0.29 元(29) 和 0.14元(14)，检查是否可以更新成功(避免浮点数精度问题)

0.29 * 100 = 28.999999999999996
0.14 * 100 = 14.000000000000002

以上是我做 Web API 测试时的总结，书写于此，以飨读者！