接口用例设计

一、针对输入设计

1.1 数值型

• 1 ~ 35 范围内和范围外的值。

• 1 ~ 35 的边界：0、1、35、36。

• 类型的特殊值：-1、0。

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

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

• 常见问题和风险：

  • 特殊值处理不当导致程序异常退出。

  • 类型边界溢出。

  • 取值范围外值未返回正确的错误信息等。

1.2 字符串型

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

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

• 特殊值：空字符。

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

• 特殊字符。

• 业务枚举值。

• 如果是输入用户输入且其他用户可见的内容，则还需要考虑敏感字是否被正常过滤。

• 可能出现的问题和风险：

  • 传入非特定类型程序异常退出。

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

  • 其他用户可见设置的敏感字。

1.3 数组或链表类型

• 正常取值：1 ~ 5 个权限，范围外：6 个权限。
• 边界值：1 ~ 35 的边界值，请求允许最大最小值。
• 特殊值：0 个（即空集合）。
• 合法 ID 和不合法的。
• 重复的 ID 等。
• 可能存在的问题和风险：
  • 0 个 item 时程序异常退出。
  • 重复的 item 处理时未去重导致结果异常等。

二、针对业务逻辑

2.1 约束条件分析

约束条件的测试在功能测试中经常遇到，在接口测试中更为重要。它的意义在于：用户进行操作时，在该操作的前端可以已经进行了约束条件的限制，故用户无法直接触发请求该接口。但是实际上，如果有其他手段：例如 UI 有 bug 或者通过技术手段直接调用接口，那么接口是否针对这些条件进行了限制就尤为重要。

• 常见的例子：要兑换 5Q 币需要 200 积分，但是我积分不足，所以兑换按钮是灰色无法点击的状态。
• 正常用户是无法操作的，但是兑换其实是调后台的一个接口，如果绕过页面 按钮的限制，直接调用后台接口兑换呢？是否可以兑换？预期当然是不能兑换的。
• 因此积分这个数值限制就需要针对接口进行测试，并且非常重要。
• **数值限制：**分数限制、金币限制、等级限制等等。（例如：兑换 Q 币活动要求积分 > 50 才可参与。）
• **状态限制：**登录状态等。（例如：同步用户信息需要先登录账号。 ）
• **关系限制：**绑定的关系，好友关系等。（例如：帮家人防骗功能只能查询绑定家人的来电信息。 ）
• **权限限制：**管理员等。
• 其他约束条件类似（根据业务丰富设计）：
  • 时间约束：22：00 之前等。
• 常见的问题和风险：约束条件判断不足，导致用户可通过特殊手段获取利益。

2.2 操作对象分析

操作通常是针对对象的，例如用户绑定电话号码，电话号码就是操作对象，而这个电话号码的话费、流量也是对象。

• 对象分析主要是针对合法和不合法对象进行操作。例如下述用例子:

• 用户 A 查询电话 P1 话费：

• 用户 A 查询电话 P1 流量；

• 用户 A 查询电话 P2 话费；

• 用户 A 查询电话 P2 流量。

• 后台的逻辑处理，如果一个电话已经被绑定过，从后台的角度是可以查询到该电话的话费和流量的。但是在用户侧，应该是 **A 绑定了的电话，才能让 A 查询到该电话的话费。**故类似对象的测试也必不可少。

• 常见的问题和风险：

• 用户可访问非权限内的其他用户信息、敏感信息，从而利用这些信息谋取利益。

2.3 状态转换分析

被测逻辑可以抽象成状态机，各个状态之间根据功能逻辑从一个状态切换到另一个状态。如果我们打乱了这个次序，从一个状态切换到另一个不在它下一状态集中的状态 ，那么逻辑将会打乱，就会出现逻辑问题。

• 例如在做任务的时候，任务有三种状态：未领取，已领取未提交，已完成三种状态。
• 那么可以这样设计：
  • 正常的状态切换：未领取状态，领取任务后变为已领取状态；已领取满足任务条件提交后，变成已完成状态；完成后可以再次领取任务。
  • **非正常的状态切换：**未领取任务满足任务条件直接提交任务；已领取时再次领取任务等等。
• 常见的问题和风险 ：
  • 可通过特殊手段达到原本不能的状态，从而谋取利益。

2.4 时序分析

在一些复杂的活动中，一个活动是由一系列动作按照指定顺序进行的，这些动作形成一个动作流 ，只有按照这个顺序依次执行，才能得到预期结果。

• 在正常的流程里，这些动作是根据程序调用依次进行的，并不会打乱，在接口测试时，需要考虑如果不按照时序执行，是否会出现问题。
• 例如，客户端数据同步是由客户端触发进行的，期间的同步用户无法干预。功能测试的时候可见的就是是否能正常进行同步，而进一步分析，同步流程实际涉及了一组动作：
• 假设后台有 3 个接口：登陆获取用户 ID，上报本地数据，上报本地冲突。三个接口需要依次调用执行，才能完成同步。
• 那么在接口测试就可以考虑打乱上述接口的执行顺序去执行，会有怎样的结果，是否会出现异常。例如：获取用户 ID 后不上报本地数据而直接上报本地冲突。
• 常见的问题和风险：
  • 非顺序执行后，数据 出现异常 ，可能还会出现程序其他异常。
  • 通过打乱顺序获取利益。

三、针对输出设计

针对输出设计其实是针对接口返回的结果进行分析。

3.1 针对输出结果

• 接口处理正确的结果可能只有一个，但是错误异常返回结果有很多情况很多值。如果知道返回结果有很多种，就可以针对不同结果设计用例。例如提交积分任务的时候我们通常能想到的是返回正确和错误，错误可能想到：无效任务，无效登录态，但是不一定能否完全覆盖所有错误码，而接口返回定义的返回码可以设计更多用例：
• 覆盖返回码也是用例设计的一种思路。
• 常见问题和风险：
  • 错误前端处理不足，导致前端异常。
  • 错误提示处理不当，导致用户看到晦涩的错误码。
  • 错误提示不当，导致用户不知道哪里出了问题，如何解决。

3.2 接口超时

• 接口正常情况下是有返回的，那么如果接口不返回呢？也就是说接口超时后的处理也是测试需要考虑的部分。
• 如果超时处理不当，可能会引起以下问题：
  • 未进行超时处理，导致整个流程阻塞。
  • 超时后又收到接口返回，导致逻辑出现错乱。

四 、其他测试设计

4.1 已废弃接口测试

• 已废弃协议，是指之前有定义，但是因为**需求变更或其他原因，目前版本不用。**这些接口虽然不再使用，但有可能代码并没有及时删除。如果利用技术手段调用这些接口，可能获取额外利益。
• 例如，任务之前有个清理任务，在一个版本需求里将清理任务替换为下载任务。在新版本客户端已不再调用完成清理任务的接口；但是如果该接口未关闭，用户就可以继续请求 submitTask(int taskID) 接口完成清理任务获得积分。
• 因此新版本在考虑兼容旧版本的同时，还应做好相关废弃接口的检查，避免用户获得额外利益。

4.2 接口设计合理性分析

• 接口定义是否合理可以从以下几个方面分析：
  • 接口是否冗余。
  • 接口字段是否冗余。
  • 接口是否返回了调用方期望得到的信息。
  • 接口定义是否可满足所有调用需求。
  • 接口定义调用是否方便。

五、一个完整的例子

下面举一个完整例子，通过上述方法来分析如何对接口进行用例设计。

某模块提供了一个接口给其他模块，用户请求任务。

5.1 针对输入设计

针对长度：

• 正常（基本流）；
• 边界：
  • 一个字符。
  • 长度非常长。
• 特殊：空字符串。

针对内容：

• 特定类型：中文，英文，数字等；
• 特殊字符：/n/r/t ,.><?*$&%~"ஜღ℡♬€✎等；
• 敏感字符：非用户设置，不涉及。

等价类：

• 取值范围内：1、5、10 等；
• 取值范围外：0、99。

边界法：

• 取值范围边界：0、1、38、39、40。
• 数据类型边界：-2147483648、2147483648。
• 特殊值：0、-1 等。

遍历法：

• 1、2、3、4、5...38、39 对应每种不同 ID。

5.2 针对逻辑设计

约束条件分析：

• 去引导某功能需要：未完成过任务，任务有任务数据。
• 未使用过有任务数据时；
• 未使用无任务数据时；
• 使用过有任务数据时；
• 使用过无任务数据时。

操作对象分析：

• 调用请求接口后，会显根据任务数据，引导对应的任务。任务数据，任务操作方式，任务功能都可以是对象。
• 任务数据：
  • 数据类型：本地，云端等。
  • 数据有效性：正确数据，错误数据。
• 操作方式：
  • 方式：安装，下载，打开等等 。
• 任务功能：
  • 功能：用户操作了该功能，未正常操作该功能；什么都不操作；完成一个任务功能；完成多个任务功能；任务功能使用顺序等等。
  • 对象：还需要关注，会不会操作到不合法的对象，例如任务数据和功能不对应等问题。

状态转换分析：（假设，功能是有 4 个状态的：完成，未完成，未知。）

• 针对该状态：
  • 正常状态转换：未完成状态请求并完成任务后是否可变成完成状态；未完成状态请求但不完成，还是未完成状态。
  • 走不到的状态路径：未知和完成状态请求任务，不能进行进行该任务。

时序分析：

• 从时序的角度分析，调用请求接口前需要以下 2 步动作：
  • 拉取任务数据；
  • 判断任务状态。
• 正常时序：按照正常时序请求 1 -> 2 -> 3；
• 缺失的时序。
• 缺少动作 1 调 2、3；缺少动作 2 调 1、3；缺少动作 1 和 2 直接调。
• 打乱的时序：2 -> 1 -> 3，还可以有 1 -> 3 -> 2；2 -> 3 -> 1；3 -> 1 -> 2；3 -> 2 -> 1。、
• 注意 ：针对处理逻辑的设计中，可能使用某一种或某几种方式就可以将用例覆盖前，故实际使用中，可能不会全部使用，只要找到最合适的方式覆盖用例即可。

5.3 针对输出分析

• 请求任务接口返回的数据是任务完成结果，即返回完成，未完成两种状态（未知都作为完成返回）。
• 从结果可以考虑遍历：
  • 未完成。
  • 完成。
  • 完成 - 未知。
• 从接口处理时间分析，考虑：请求后快速返回，很长时间才返回，甚至不返回结果的情况。

六、总结

• 接口用例设计方法中，针对输入、输出的设计 是通用的 ，接口设计时都可用到。对于接口逻辑的设计 可能会应用比较适合的一种或几种方法 ，在接口用例设计时，需要选取最合适的方法去覆盖被测逻辑。
• 当测试时间紧任务重的情况下，用例设计需要具体情况具体分析。

七、结束语

"-------怕什么真理无穷，进一寸有一寸的欢喜。"

微信公众号搜索：饺子泡牛奶。