接口测试实战接口测试用例的编写

Posted 黑黑白白君

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了接口测试实战接口测试用例的编写相关的知识，希望对你有一定的参考价值。

文章目录


前情：

《【接口测试实战(零)】接口测试简介》

《【接口测试实战(一)】搭建接口测试环境》

《【接口测试实战(二)】根据接口文档使用postman测试》

相关文档：

《【自动化测试】接口测试基础》

《【自动化测试】接口测试的具体内容和流程》

1）接口测试发现的典型问题

接口测试经常遇到的bug和问题，如下：

  • 传入参数处理不当，导致程序crash
  • 类型溢出，导致数据读出和写入不一致
  • 因对象权限未进行校验，可以访问其他用户敏感信息
  • 状态处理不当，导致逻辑出现错乱
  • 逻辑校验不完善，可利用漏洞获取非正当利益等

2）接口测试用例设计

一个接口通常是有输入输出的，输入就是我们常见的入参，输出有时有，有时没有。调用相关接口，接口会执行相关处理逻辑。

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

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

2.1 针对输入设计

对于接口来说，输入就是入参。

常见参数类型有:

  • 数值型(int、long、float、double等）
  • 字符串类型
  • 数组或链表
  • 结构体：结构体(struct)是一些元素的结合，元素实际也是数值型，字符串型，数组或链表。

2.1.1 数值型

如果参数规定了值的范围，则需要考虑等价类取值范围内、取值范围外，取值的边界，如有需要，可能会遍历取值范围内的各个值。

  • 常见问题和风险：
    • 特殊值处理不当导致程序异常退出
    • 类型边界溢出
    • 取值范围外值未返回正确的错误信息等
  • 设计举例：
    检查权限的接口：TaskChecker.checkTask(int taskID)，taskID的取值范围是1-35，那么设计时考虑：
    • 1-35范围内和范围外的值
    • 1-35的边界：0、1、2、34、35、36
    • 类型的特殊值：-1、0、非数字、特殊字符
    • 数据类型的边界值：int的最小值最大值
    • 因为1-35代码的权限ID不同，可能需要遍历1-35的每个值

2.1.2 字符串型

字符串型的参数，主要考虑字符串的长度和内容。

  • 常见问题和风险：
    • 传入非特定类型导致程序异常退出
    • 超长字符未进行处理，导致存储、显示等异常
    • 其他用户可见设置的敏感字
  • 设计举例：
    接口转换设置闹钟的接口DateUtil.getDayOfDDHH(String ddhh)，用例可以考虑：
    • 长度为4位，比4位少，比4位多
    • 边界值：String的最大长度
    • 特殊值：空字符
    • 字符串内容可考虑类型：数字，非数字
    • 特殊字符
    • 如果是输入用户输入且其他用户可见的内容，则还需要考虑敏感字是否被正常过滤

2.1.3 数组或链表类型

  • 常见问题和风险：
    • 0个item时程序异常退出
    • 重复的item处理时未去重导致结果异常等
  • 设计举例：
    批量提交任务的接口submitTask(int[] taskID)，参数用例设计考虑：
    • 正常取值：1-5个权限，范围外：6个权限
    • 元素边界值：1-35的边界值，请求允许最大最小值
    • 特殊值：0个
    • 合法ID和不合法的
    • 重复的ID等

2.2 针对逻辑设计

接口需要进行一些逻辑处理的，那么按逻辑设计用例可以从以下几个角度分析。

2.2.1 约束条件分析

约束条件的测试在功能测试中经常遇到，在接口测试中更为重要。

  • 它的意义在于：

    • 用户进行操作时，在该操作的前端可能已经进行了约束条件的限制，故用户无法直接触发请求该接口。
    • 但是实际上，在其他情况下，例如UI有bug或者通过技术手段直接调用接口，那么接口是否针对这些条件进行了限制就尤为重要。

  • 常见的约束条件：
    • 数值限制：分数限制、金币限制、等级限制、时间限制等等。（例如：兑换Q币活动要求积分>50才可参与。）
    • 状态限制：登录状态等。（例如：同步用户信息需要先登录账号。）
    • 关系限制：绑定的关系，好友关系等。（例如：帮家人防骗功能只能查询绑定家人的来电信息。）
    • 权限限制：管理员等。

  • 常见的问题和风险：
    • 约束条件判断不足，导致用户可通过特殊手段获取利益
  • 设计举例：
    要兑换5Q币需要200积分，但是由于积分不足，所以兑换按钮是灰色无法点击的状态。
    • 正常用户是无法操作的，但是兑换其实是调后台的一个接口，如果绕过页面按钮的限制，直接调用后台接口兑换呢？是否可以兑换？
    • 预期当然是不能兑换的。因此积分这个数值限制就需要针对接口进行测试，并且非常重要。

2.2.2 操作对象分析

操作通常是针对对象的，对象分析主要是针对合法和不合法对象进行操作。

  • 常见的问题和风险：
    • 用户可访问非权限内的其他用户信息、敏感信息，从而利用这些信息谋取利益
  • 设计举例：
    用户绑定电话号码，电话号码就是操作对象，而这个电话号码的话费、流量也是对象：
    • 用户A查询电话P1话费
    • 用户A查询电话P1流量
    • 用户A查询电话P2话费
    • 用户A查询电话P2流量
  • 后台的逻辑处理，如果一个电话已经被绑定过，从后台的角度是可以查询到该电话的话费和流量的。
  • 但是在用户侧，应该是A绑定了的电话，才能让A查询到该电话的话费。故类似对象的测试也必不可少。

2.2.3 状态转换分析

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

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

从某状态改变到新的状态，依赖于转换接口。而对于某转换接口，其输入状态是确定的，比如Fun23这个函数只能把状态2转换为状态3，而不能把状态1转换为状态3。那么测试点就可以是：

  • 状态为状态2，调用接口Fun23（），状态切换到状态3；
  • 状态为1,3等，调用接口Fun23（），状态不能切换。

设计举例：

在做任务的时候，任务有三种状态：未领取，已领取未提交，已完成三种状态。那么可以这样设计：

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

2.2.4 时序分析

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

  • 在正常的流程里，这些动作是根据程序调用依次进行的，并不会打乱。

  • 在接口测试时，需要考虑如果不按照时序执行，是否会出现问题。

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

2.3 针对输出设计

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

2.3.1 针对输出结果

接口处理正确的结果可能只有一个，但是错误异常返回结果有很多情况很多值。如果知道返回结果有很多种，就可以针对不同结果设计用例。覆盖返回码也是用例设计的一种思路。

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

2.3.2 接口超时

接口正常情况下是有返回的，但如果接口不返回呢？也就是说接口超时后的处理也是测试需要考虑的部分。

  • 常见的问题和风险：
    • 如果超时处理不当，可能未进行超时处理，导致整个流程阻塞
    • 如果超时处理不当，可能超时后又收到接口返回，导致逻辑出现错乱

2.4 其他测试设计

2.4.1 已废弃接口测试

已废弃协议，是指之前有定义，但是因为需求变更或其他原因，目前版本不用。这些接口虽然不再使用，但有可能代码并没有及时删除。如果利用技术手段调用这些接口，可能获取额外利益。

  • 常见的问题和风险：
    • 如果利用技术手段调用这些接口，可能获取额外利益。

因此新版本在考虑兼容旧版本的同时，还应做好相关废弃接口的检查，避免用户获得额外利益。

  • 设计举例：
    任务之前有个清理任务，在一个版本需求里将清理任务替换为下载任务。
    • 在新版本客户端已不再调用完成清理任务的接口；
    • 但是如果该接口未关闭，用户就可以继续请求submitTask(int taskID)接口完成清理任务获得积分。

2.4.2 接口设计合理性分析

接口定义是否合理可以从以下几个方面分析：

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

3）接口功能测试用例模板

接口测试的步骤中最重要的是向接口发送预设请求，结果则要关注响应信息及后续处理。

所以接口功能测试用例编排可以考虑下列两种形式：

1、用例名称、用例编号、接口地址、请求方式、前置条件、步骤（描述、请求头、请求参数、状态码）、预期结果和实际结果。
在这里插入图片描述
2、用例编号、标题、模块、优先级、描述、前置条件、请求类型、请求参数、步骤、结果。
在这里插入图片描述

  • 要特别注意的是，实际工作场景中我们可能还会对接口之间的串联和混合场景进行测试。就是上一个接口返回的数据有可能作为后边的接口的参数传入后边的接口。

4）测试报告模板

测试报告是指把测试的过程和结果写成文档，对发现的问题和缺陷进行分析，为纠正软件的存在的质量问题提供依据，同时为软件验收和交付打下基础。

  • 测试报告是测试阶段最后的文档产出物。
  • 优秀的测试经理或测试人员应该具备良好的文档编写能力。
  • 接口测试报告很多时候会和接口性能测试报告一起。

单独报告的话，可以考虑以下内容：

4.1 系统接口概况

简要描述与测试项目相关的一些背景资料，如被测系统简介，项目上线计划等。

对于系统接口的定义和设计做出介绍。

  • 比如系统一共有多少个接口？
  • 采用哪种协议？
  • 都涉及到哪些发送方法？
  • 采用怎样的请求格式？
  • 使用怎样的返回标准？

可用表格说明。

4.2 测试目的与范围

描述本次接口测试的目的、范围与目标，内容应与本次接口测试的《接口测试实施方案》中的对应内容保持一致。

  • 测试目的：本次测试的目的在于确保系统接口功能和逻辑处理已验证，符合《接口定义说明书》的定义和要求，满足系统需要。
  • 测试对象范围（测试用例设计）：简要介绍测试用例的设计方法。例如：等价类划分、边界值、因果图，以及用这类方法(3-4句)。
  • 测试指标范围：被测接口接收请求和返回报文、被测接口返回状态、被测接口对应业务逻辑处理、涉及数据沉淀的处理、复杂场景下多接口串联交互

4.3 测试工具及资源

简要介绍测试中采用的方法(和工具)。

4.4 测试记录及结果分析

4.5 测试问题及结果分析

结合测试中发现的问题对于整体测试结果进行分析，做出判断：

  • 接口业务功能错误类缺陷情况
  • 接口异常处理类缺陷情况
  • 接口处理数据沉淀缺陷类情况
  • 接口安全性缺陷情况
  • 混合接口业务功能错误类缺陷情况
  • 混合接口业务数据传递类缺陷情况

4.6 测试结论

给出本次性能测试的测试总结论，一般以测试结果与测试目标的比较结果作为测试结论。

  • 测试执行是否充分（可以增加对安全性、可靠性、可维护性和功能性描述）。
  • 对测试风险的控制措施和成效。
  • 测试目标是否完成。
  • 测试是否通过。
  • 是否可以进入下一阶段项目目标。

【部分内容参考自】

  • 接口测试用例设计（详细干货）：https://blog.csdn.net/u011001084/article/details/79102967
  • 接口测试用例和接口测试模板：https://www.cnblogs.com/jingdenghuakai/p/10815008.html

以上是关于接口测试实战接口测试用例的编写的主要内容，如果未能解决你的问题，请参考以下文章

接口测试实战接口测试之sandbox(沙盒)

接口测试实战接口测试之断言实战

接口测试实战postman之Collections和数据驱动测试实战

接口测试实战postman之变量与沙盒实战

[接口测试_B] 12 如何编写接口测试用例

Jmeter接口测试系列之测试用例编写和调用