1、接口测试的分类
接口测试通常分为单接口的健壮性测试,和多接口的场景测试。
单接口的健壮性测试更多关注底层业务逻辑,保证接口的健壮性和准确性;
多接口的场景测试更多站在用户角度去设计可能发生的场景。
在写单接口用例时,很多人只会关注简单的出入参验证,忽略了像日志、安全、组件等维度的思考,从而导致设计出的接口用例不能很好的发现问题。下面说说单接口用例设计要关注的点。
2、异常参数验证
2.1 基础类型
- 字符串:null、空串、空白符号、长度限制校验、中文、全角半角、特殊字符
- 整型:最大最小值限制、0和负数的限制
浮点型:最大最小值限制、0和负数的限制、小数点后位数的限制(这里需要考虑字符类型的最大最小值,和业务字段的最大最小值)
2.2 对象类型
整个对象为 null
- 对象不为 null,里面某个成员为 null
- 空集合
- 集合的 size 校验
2.3 枚举类型
2.4 必传参数验证
注:上面提到的几点,其实都可以通过自动化去校验,不用每个接口都重复去验证3、正常功能逻辑校验
正常功能逻辑就比较简单了,相信大家都是会验证的,但还是要额外注意几点:
- 抛异常
- 超时
- 返回失败:有明确返回失败信息的、返回 null、http 返回没有 body、部分成功部分失败
- 重试机制
- http url 的正确性验证
入参的正确性 与 完整性验证。如分页信息、是否查了多余信息。可以通过 debug 方式,模拟一次失败,再模拟一次成功
4.2 中间组件
DB 读写、redis 读写等,一般通过第三方来模拟
抛异常
- 超时
4.3 循环内中断
注:上面几点,可以结合 sandbox 和 mock 系统做自动化测试,外部接口用 mock 系统实现,外部组件用 sandbox5、日志检查
主要检查以下几个点:
- 有没有,需不需要(要对外部接口的入参、出参做日志记录;info、error 告警必须要有)
- 信息够不够,有没有多余
- 日志级别对不对
- 需不需要开关(日志打印是会消耗新能的,因此日志大/核心接口 要考虑添加开关)
- 有没有敏感信息(某个表某个字段,由业务来判断是否为敏感;不要打印敏感信息,会有安全合规风险)
6、性能
7、配置的验证
- 配置取值的优先顺序
- 配置多重
- 默认值是啥,是否合理
- 验证配置是否生效
- 验证不同配置的不同逻辑
8、通过场景反推和检查方法
- 通过 sql 语句的过滤条件去反推业务场景和开发要筛选的数据是否批量(一般“状态”、“删除”类的字段,容易出问题)
- 重点关注字段:sql 涉及的表中表示删除状态的字段、sql 涉及的表中表示状态的字段
- 检查思路:过滤条件是否足够,及该过滤的数据有没有被过滤,比如删除状态的数据要不要过滤,禁用状态的数据要不要过滤
注:通过代码走查,发现疑问和开发确认;新增 sql 可以在设计方案评审和开发核对
9、上下游设置一致性
注:这种情况很难测,真的很难测。但在压测和代码走查的时候,还是要关注一下
11、sdk 新旧版本兼容性
12、写接口额外关注
12.1 幂等校验
12.2 事务验证:
- 关注主从延迟(用2个不同权限的账号,从库只有读权限)
- 主从配置是否正确
注:事务验证的测试方法:只能测试回滚操作,可以 debug 断点往后模拟,也可以通过 sandbox 注入异常代码自动化实现,其它情况测试很难去关注
主从延迟一般在设计方案评审时考虑;主从配置是否正确可以通过自动化去测试
