接口测试用例设计总结

接口测试定义

接口测试主要验证点

针对输入，可按照参数类型进行设计；
针对接口处理，可按照逻辑进行设计；
针对输出，可根据结果进行分析设计。

接口测试用例设计

针对输入设计

数值型（int, long, float, double等）
- 如果参数规定了值的范围，则需要考虑等价类取值范围内、取值范围外，取值的边界，如有需要，可能会遍历取值范围内的各个值。
- 参数数据类型限制；
  - 逆向用例：针对每个参数都设计1条参数值类型不符的逆向用例
- 参数数据类型自身的数据范围值限制
  - 正向用例：针对所有参数，设计1条每个参数的参数值在数据范围内为最大值的正向用例
  - 逆向用例：针对每个参数(假设n个)，设计n条每个参数的参数值都超出数据范围最大值的逆向用例
  - 逆向用例：针对每个参数(假设n个)，设计n条每个参数的参数值都小于数据范围最小值的逆向用例
    常见问题和风险：
- 特殊值处理不当导致程序异常退出；
- 类型边界溢出；
- 取值范围外值未返回正确的错误信息等
字符串类型
- 边界值：string的最大长度；
- 特殊值：空字符；
- 字符串内容可考虑类型：数字，非数字；
- 特殊字符
- 如果是用户输入且其他用户不可见的内容，则还需要考虑敏感字是否被正常过滤
  可能出现的问题和风险：
- 传入非特定类型程序异常退出；
- 超长字符未进行处理，导致存储、显示等异常；
- 其他用户可见设置的敏感字
数组或链表
- 正常取值、范围外；
- 边界值；
- 特殊值：0个；
- 合法ID和不合法的；
- 重复的ID等
  可能存在的问题和风险：
- 0个item时程序异常退出；
- 重复的item处理时未去重导致结果异常等
结构体
- 结构体(struct)是一些元素的结合，元素实际也是数值型，字符串型，数组或链表。
是否满足前提条件
- 有些接口需要满足前置条件，才可成功获取数据。常见的，需要登陆Token。
  逆向用例：
- 针对是否满足前置条件(假设为n个条件)，设计0~n条用例
是否携带默认值参数
- 带默认值的参数都不填写、不传参，必填参数都填写正确且存在的“常规”值，其它不填写，设计1条用例；
业务规则、功能需求
- 这里根据实际情况，结合接口参数说明，可能需要设计n条正向用例和逆向用例
参数是否必填
逆向用例：
- 针对每个必填参数，都设计1条参数值为空的逆向用例
参数之间是否存在关联
- 有些参数彼此之间存在相互制约的关系
  逆向用例：
- 根据实际情况，可能需要设计0~n条用例

以上几个方面考虑全的话，基本可以做到如下几个方面的覆盖：

主流程测试用例：正常的主流程功能校验；
分支流测试用例：正常的分支流功能校验；
异常流测试用例：异常容错校验

针对逻辑设计

约束条件分析
- 数值限制：
- 状态限制：登录状态等
- 关系限制：绑定的关系，好友关系等。
  - 例如，应该只能查询有关联关系的账号的信息。
- 权限限制：需要对应权限才能操作对应的功能
  用户进行操作时，在该操作的前端可以已经进行了约束条件的限制，故用户无法直接触发请求该接口。但是实际上，如果有其他手段：例如UI有bug或者通过技术手段直接调用接口，那么接口是否针对这些条件进行了限制就尤为重要。
  常见的问题和风险：
- 约束条件判断不足，导致用户可通过特殊手段获取利益
操作对象分析
- 对象之间存在隔离，不能串
  常见的问题和风险：
- 用户可访问非权限内的其他用户信息、敏感信息，从而利用这些信息谋取利益。
状态转换分析
- 状态之间转换存在严格定义，不能随意变换
  常见的问题和风险：
- 可通过特殊手段达到原本不能的状态，从而谋取利益。
时序分析
- 客户端与服务端的交互用户可见的只有一次，期间存在着用户不可见的内部多次按顺序执行的调用逻辑，实际就是发起了一个有序的动作流，只有按照正确的顺序，才能得到正确的结果。
  常见的问题和风险：
- 非顺序执行后，数据出现异常，可能还会出现程序其他异常
- 通过打乱顺序获取利益

针对输出设计

针对输出结果
接口处理正确的结果可能只有一个，但是错误异常返回结果有很多情况很多值。如果知道返回结果有很多种，就可以针对不同结果设计用例。例如提交积分任务的时候我们通常能想到的是返回正确和错误，错误可能想到：无效任务，无效登录态，但是不一定能否完全覆盖所有错误码，而接口返回定义的返回码可以设计更多用例。
覆盖返回码也是用例设计的一种思路。
常见问题和风险：
- 错误前端处理不足，导致前端异常；
- 错误提示处理不当，导致用户看到晦涩的错误码；
- 错误提示不当，导致用户不知道哪里出了问题，如何解决。
接口超时
接口正常情况下是有返回的，那么如果接口不返回呢？也就是说接口超时后的处理也是测试需要考虑的部分。
常见的问题及风险：
- 未进行超时处理，导致整个流程阻塞
- 超时后又收到接口返回，导致逻辑出现错乱

其他测试设计

已废弃接口处理

已废弃协议，是指之前有定义，但是因为需求变更或其他原因，目前版本不用。这些接口虽然不再使用，但有可能代码并没有及时删除。如果利用技术手段调用这些接口，可能获取额外利益。
新版本在考虑兼容旧版本的同时，还应做好相关废弃接口的检查，避免用户获得额外利益。

接口设计合理性分析

接口字段是否冗余；
接口是否冗余；
接口是否返回了调用方期望得到的信息；
接口定义是否可满足所有调用需求；
接口定义调用是否方便。

接口用例设计精简和优化

在接口参数较多的情况下，如果每个参数都进行完整校验，将会是非常大的工作量，所以需要对接口用例进行精简和优化：

① 根据接口的使用对象(外部，系统内部)，有选择的去、留部分用例
  - 如果开发于系统内部调用的，开发过程中，开发者肯定需要调用这些接口，如果类型错了，他们也就获取不到预期的数据，这些错误，他们肯定可以发现，所以，他们传递的参数值一般能保证类型正确。
  - 内部调用，参数值不是外部手动输入的，输入数据长度、值大小可控，当然如果数据一直增长，那再大的类型可能都无法保证不超出，比如自动增长的商铺id
② 根据接口的是否核心接口，有选择的去、留部分用例
  - 核心接口，每个字段都需要验证
  - 非核心接口，接口核心字段验证完成就可以
③ 根据参数说明，及实际情况，有选择的去、留部分用例
  - 部分参数的参数值是自定义的，比如 订单时间类型，就那几种，除非传错了，不然不可能超出范围
④ 尽量在一个用例中验证尽量多的参数形式，但又得想办法尽量让验证范围最大化

转载与：接口测试用例设计