0%

接口测试总结

发表于 更新于 分类于

一、接口

  • 客户端与后台接口、服务器间接口、AB两个模块间接口、函数调用
    1577319964(1)

二、接口测试关注点

  • 格式、数据动态、接口间业务关联、接口响应如何验证

三、接口测试目的

  • 早于功能测试提前规范和消灭bug
  • 回归，减少测试人力同时保证系统每日的稳定运行

四、优先级

4.1 针对所有接口

  • 暴露在外面的接口，因为通常该接口会给第三方调用；
  • 供系统内部调用的核心功能接口；
  • 供系统内部调用非核心功能接口；

4.2 针对单个接口

  • 正向用例优先测试,逆向用例次之(通常情况，非绝对)；
  • 是否满足前提条件 > 是否携带默认参值参数 > 参数是否必填 > 参数之间是否存在关联 > 参数数据类型限制 >参数数据类型自身的数据范围值限制

四、接口测试的用例设计，主要从输入和接口处理两方面考虑：

  • 针对输入，可按照参数类型进行设计；

  • 针对接口处理，可按照逻辑进行用例设计；

  • 针对输出，可根据结果进行分析设计。

五、针对输入参数类型设计测试用例

5.1 数值型
1577321452(1)
例如检查权限的接口：TaskChecker.checkTask(int taskID) taskID的取值范围是1-35，那么设计时考虑：

  • 1-35范围内和范围外的值；

  • 1-35的边界：0，1,35,36；

  • 类型的特殊值：-1,0

  • 数据类型的边界值：int的最小值最大值；

  • 因为1-35代码的权限ID不同，可能需要遍历1-35的每个值。

　　常见问题和风险：

  • 任务ID>35也能提交成功

  • 类型边界溢出，比如int类型最大值时读出和写入不一致（原因：接口内对其处理，导致溢出）

  • 购买数量为负数也可以购买

5.2 字符串类型
字符串型的参数，主要考虑字符串的长度和内容：
1577322037(1)
例如接口转换设置闹钟的接口DateUtil.getDayOfDDHH(String ddhh)，用例可以考虑：

  • 长度为4位，比4位少，比4位多；

  • 边界值：String的最大长度；

  • 特殊值：空字符；

  • 字符串内容可考虑类型：数字，非数字；

  • 特殊字符（还包含关键字、转义字符比如//.、   （空格）），字符串未规定长度测试注意点
    1577239285(1)
    考虑字符串长度的原因是数据库创建表过程中都设置好了每个字段的长度，若前端提交很长，可能导致在数据库存储时截断。

  • 如果是输入用户输入且其他用户可见（昵称、评论、公告）的内容，则还需要考虑敏感字是否被正常过滤。

可能出现的问题和风险：

  • 修改公告可以超过限定120字

  • 超长字符未进行处理，导致存储、显示等异常

  • 【在特定类型中】获取日期接口入参是int类型，若传入String时会crash（从前端获取是String，若直接转换为int，里面有string就会crash）

5.3 数组或链表类型
1577322694(1)
例如批量提交任务的接口submitTask(int[] taskID)，参数用例设计考虑：

  • 正常取值：1-5个权限，范围外：6个权限；

  • 边界值：1-35的边界值，请求允许最大最小值；

  • 特殊值：0个；

  • 合法ID和不合法的；

  • 重复的ID等。

可能存在的问题和风险：

  • 0个item时程序异常退出；

  • 重复的item处理时未去重导致结果异常等。

六、日期类型

  • 年、月、日、时、分、秒、闰/平年2月
    • 日期的合理性
      1582387767(1)
  • 日期类型范围
    1582387717(1)

七、接口处理逻辑

7.1 约束条件分析

  • 数值限制：分数限制、金币限制、等级限制等等。

兑换Q币活动要求积分>50才可参与。

  • 状态限制：登录状态等。

同步用户信息需要先登录账号。

  • 关系限制：绑定的关系，好友关系等。

帮家人防骗功能只能查询绑定家人的来电信息。

  • 权限限制：管理员等。

7.2 操作对象
1577323243(1)
此时用户、电话、话费都是操作对象，正常情况用户A绑定P1，查询A&P1的话费
异常情况用户A绑定P1，查询P2的话费

  • 问题和风险
    可访问非权限内的其他用户信息、敏感信息，利用信息谋取利益

7.3 状态转换分析
1577323792(1)
测试点：

  • 状态为2，调用Fun23，状态切换到3

  • 状态为1,3时，调用Fun23，状态不能切换
    1577341809(1)
    那么可以这样设计：

  • 正常的状态切换：未领取状态，领取任务后变为已领取状态；已领取满足任务条件提交后，变成已完成状态；完成后可以再次领取任务。

  • 非正常的状态切换：未领取任务满足任务条件直接提交任务；已领取时再次领取任务等等。

常见的问题和风险：
问题和风险
可通过特殊手段达到访问原本不能的状态，从而谋取利益

举例：已经加入家族的玩家（未退出家族），还可以申请加入其它家族

7.4 时序分析
1577324168(1)

  • 从时序图可以看出，后台有3个接口：登陆获取用户ID，上报本地数据，上报本地冲突。三个接口需要依次调用执行，才能完成同步。那么在接口测试就可以考虑打乱上述接口的执行顺序去执行，会有怎样的结果，是否会出现异常。例如：获取用户ID后不上报本地数据而直接上报本地冲突。

常见的问题和风险

  • 非顺序执行后，数据出现异常，可能还会出现程序其他异常
  • 通过打乱顺序获取利益

    八、其它

8.1 已废弃接口
1577324333(1)
- 问题和风险：接口未及时处理，可继续访问，调用接口，获取额外利益
- 已废弃的接口不维护 那么旧版本无法兼容怎么办？
答：已废弃的接口，指之前有使用，由于一些原因不再使用的接口。一些情况下确实还需要考虑旧版本兼容的问题，这种情况通常的处理方式有几种：
（1） 旧版本不支持继续访问，提醒用户升级版本；
（2） 接口请求时判断版本号，只有特定的版本才能访问。
8.2 接口设计合理性
1577324538(1)

8.3 单独接口字段间逻辑
有些参数需要相互配合着才起作用，如“offset”和“count”组合起来进行翻页，这个时候要组合起来进行测试；参数之间关联：省，市，县（区），尤其注意非法（无效）的关联
8.4 绕过验证

  • 提交订单时，在传递商品价格参数时，修改商品价格
  • 支付时，抓个包将订单金额一改，如果能以修改后金额进行支付，则接口有问题

也就是说数据库取出的数据，在业务流使用时，不能被用户随意修改

九、接口测试中常见问题

9.1 异常的测试有必要做那么多吗？*
答：一些情况下异常测试是非常必要的，而在一些情况下的确是不需要这么多。
例如，在游戏测试中，客户端和后台的接口，需要要做充分的异常测试。协议通常有加密，但是因为游戏有利益可图，总有一些人去破解（协议都是可被破解的，只是时间和成本问题），那么一旦破解，就可以绕过客户端直接访问后台接口，如果后台逻辑有漏洞，就有利可图了。因此在很多游戏中，需要保证后台逻辑的健壮性。还有，一些提供给外部使用的接口，也需要做好异常测试，因为你不清楚调用者会怎么使用，那么作为一个可靠的提供方，保证自己的稳定和健壮是非常有必要的。另外一些情况，可能这些异常是外部无法触发的，那么这种情况下，异常问题就没有那么高的优先级去解决。
测试中，通常需要去权衡测试成本和产品质量，找到一个平衡点。

9.2 接口测试断言时，需要与数据库记录比对吗？

答：接口测试中，测试一个接口的时候预期得到什么结果，设计的时候是清楚的。这个预期结果可能是返回成功或某个错误码；可能接口需要对某个数据进行操作，那么这个时候接口测试也是同时需要验证数据的正确性，这种情况就需要校验数据（校验数据库或者数据存储）。其他需要检查的预期也是类似，在接口测试时同时检查。

9.3 单元测试与接口测试区别
答：接口测试的测试对象是接口，单元测试指对软件中的最小可测试单元进行检查和验证。从概念上来讲，接口测试比单元测试更广泛。单元测试的测试单位通常是函数，也就是说广泛意义的接口测试，包含了单元测试。接口测试用例设计思想不单单是针对接口的功能，还需要考量跟接口相关调用者或者多个接口交互；单元测试用例可能更多的是针对该函数内部处理逻辑。接口测试通常是测试人员来进行，单元测试更多是开发来进行。

9.4 接口测试是否有必要测试人员阅读源码，再根据源码设计测试用例？

答：最好可以阅读源码，这可以帮助测试人员更好的了解被测系统和程序实现。还有一个额外收益：测试在阅读源码（CodeReview）的时候也可以发现一些缺陷。我们可以根据源码来设计测试用例，同时，测试人员也需要特别注意避免被开发的思维限制，也需要跳出源码，从黑盒测试的角度出发，去设计和思考用例。