接口测试用例设计总结

接口测试定义

接口测试主要验证点

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

接口测试用例设计

针对输入设计
  1. 数值型(int, long, float, double等)
    • 如果参数规定了值的范围,则需要考虑等价类取值范围内、取值范围外,取值的边界,如有需要,可能会遍历取值范围内的各个值。
    • 参数数据类型限制;
      • 逆向用例:针对每个参数都设计1条参数值类型不符的逆向用例
    • 参数数据类型自身的数据范围值限制
      • 正向用例:针对所有参数,设计1条每个参数的参数值在数据范围内为最大值的正向用例
      • 逆向用例:针对每个参数(假设n个),设计n条每个参数的参数值都超出数据范围最大值的逆向用例
      • 逆向用例:针对每个参数(假设n个),设计n条每个参数的参数值都小于数据范围最小值的逆向用例
        常见问题和风险:
    • 特殊值处理不当导致程序异常退出;
    • 类型边界溢出;
    • 取值范围外值未返回正确的错误信息等
  2. 字符串类型
    • 边界值:string的最大长度;
    • 特殊值:空字符;
    • 字符串内容可考虑类型:数字,非数字;
    • 特殊字符
    • 如果是用户输入且其他用户不可见的内容,则还需要考虑敏感字是否被正常过滤
      可能出现的问题和风险:
    • 传入非特定类型程序异常退出;
    • 超长字符未进行处理,导致存储、显示等异常;
    • 其他用户可见设置的敏感字
  3. 数组或链表
    • 正常取值、范围外;
    • 边界值;
    • 特殊值:0个;
    • 合法ID和不合法的;
    • 重复的ID等
      可能存在的问题和风险:
    • 0个item时程序异常退出;
    • 重复的item处理时未去重导致结果异常等
  4. 结构体

    • 结构体(struct)是一些元素的结合,元素实际也是数值型,字符串型,数组或链表。
  5. 是否满足前提条件

    • 有些接口需要满足前置条件,才可成功获取数据。常见的,需要登陆Token。
      逆向用例:
    • 针对是否满足前置条件(假设为n个条件),设计0~n条用例
  6. 是否携带默认值参数
    • 带默认值的参数都不填写、不传参,必填参数都填写正确且存在的“常规”值,其它不填写,设计1条用例;
  7. 业务规则、功能需求
    • 这里根据实际情况,结合接口参数说明,可能需要设计n条正向用例和逆向用例
  8. 参数是否必填
    逆向用例:
    • 针对每个必填参数,都设计1条参数值为空的逆向用例
  9. 参数之间是否存在关联
    • 有些参数彼此之间存在相互制约的关系
      逆向用例:
    • 根据实际情况,可能需要设计0~n条用例

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

  • 主流程测试用例:正常的主流程功能校验;
  • 分支流测试用例:正常的分支流功能校验;
  • 异常流测试用例:异常容错校验
针对逻辑设计
  1. 约束条件分析
    • 数值限制:
    • 状态限制:登录状态等
    • 关系限制:绑定的关系,好友关系等。
      • 例如,应该只能查询有关联关系的账号的信息。
    • 权限限制:需要对应权限才能操作对应的功能
      用户进行操作时,在该操作的前端可以已经进行了约束条件的限制,故用户无法直接触发请求该接口。但是实际上,如果有其他手段:例如UI有bug或者通过技术手段直接调用接口,那么接口是否针对这些条件进行了限制就尤为重要。
      常见的问题和风险:
    • 约束条件判断不足,导致用户可通过特殊手段获取利益
  2. 操作对象分析
    • 对象之间存在隔离,不能串
      常见的问题和风险:
    • 用户可访问非权限内的其他用户信息、敏感信息,从而利用这些信息谋取利益。
  3. 状态转换分析
    • 状态之间转换存在严格定义,不能随意变换
      常见的问题和风险:
    • 可通过特殊手段达到原本不能的状态,从而谋取利益。
  4. 时序分析
    • 客户端与服务端的交互用户可见的只有一次,期间存在着用户不可见的内部多次按顺序执行的调用逻辑,实际就是发起了一个有序的动作流,只有按照正确的顺序,才能得到正确的结果。
      常见的问题和风险:
    • 非顺序执行后,数据出现异常,可能还会出现程序其他异常
    • 通过打乱顺序获取利益
针对输出设计
  1. 针对输出结果
    接口处理正确的结果可能只有一个,但是错误异常返回结果有很多情况很多值。如果知道返回结果有很多种,就可以针对不同结果设计用例。例如提交积分任务的时候我们通常能想到的是返回正确和错误,错误可能想到:无效任务,无效登录态,但是不一定能否完全覆盖所有错误码,而接口返回定义的返回码可以设计更多用例。
    覆盖返回码也是用例设计的一种思路。
    常见问题和风险:
    • 错误前端处理不足,导致前端异常;
    • 错误提示处理不当,导致用户看到晦涩的错误码;
    • 错误提示不当,导致用户不知道哪里出了问题,如何解决。
  2. 接口超时
    接口正常情况下是有返回的,那么如果接口不返回呢?也就是说接口超时后的处理也是测试需要考虑的部分。
    常见的问题及风险:
    • 未进行超时处理,导致整个流程阻塞
    • 超时后又收到接口返回,导致逻辑出现错乱

其他测试设计

已废弃接口处理

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

接口设计合理性分析
  • 接口字段是否冗余;
  • 接口是否冗余;
  • 接口是否返回了调用方期望得到的信息;
  • 接口定义是否可满足所有调用需求;
  • 接口定义调用是否方便。

接口用例设计精简和优化

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

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

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

Donate comment here