史上最全,接口测试-用例设计总结(案例分析实例)一篇策底打通...

目录:导读

    • 前言
    • 一、Python编程入门到精通
    • 二、接口自动化项目实战
    • 三、Web自动化项目实战
    • 四、App自动化项目实战
    • 五、一线大厂简历
    • 六、测试开发DevOps体系
    • 七、常用自动化测试工具
    • 八、JMeter性能测试
    • 九、总结(尾部小惊喜)


前言

1、针对输入设计

1)数值型

  • 1 ~ 35 范围内和范围外的值。
  • 1 ~ 35 的边界:0、1、35、36。
  • 类型的特殊值:-1、0。
  • 数据类型的边界值:int 的最小值最大值。
  • 因为 1 ~ 35 代码的权限 ID 不同,可能需要遍历 1-35 的每个值。
  • 常见问题和风险:特殊值处理不当导致程序异常退出;类型边界溢出;取值范围外值未返回正确的错误信息等。

2)字符串型

  • 长度为 4 位,比 4 位少,比 4 位多。
  • 边界值:String 的最大长度。
  • 特殊值:空字符。
  • 字符串内容可考虑类型:数字,非数字。
  • 特殊字符。
  • 业务枚举值。
  • 如果是输入用户输入且其他用户可见的内容,则还需要考虑敏感字是否被正常过滤。
  • 可能出现的问题和风险:传入非特定类型程序异常退出;超长字符未进行处理,导致存储、显示等异常;其他用户可见设置的敏感字。

3)数组或链表类型

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

2、针对业务逻辑

1)约束条件分析

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

常见的例子:要兑换 5Q 币需要 200 积分,但是我积分不足,所以兑换按钮是灰色无法点击的状态。

正常用户是无法操作的,但是兑换其实是调后台的一个接口,如果绕过页面按钮的限制,直接调用后台接口兑换呢?是否可以兑换?

预期当然是不能兑换的。
因此积分这个数值限制就需要针对接口进行测试,并且非常重要。

数值限制:分数限制、金币限制、等级限制等等。(例如:兑换 Q 币活动要求积分 > 50 才可参与。)
状态限制:登录状态等。(例如:同步用户信息需要先登录账号。 )
关系限制:绑定的关系,好友关系等。(例如:帮家人防骗功能只能查询绑定家人的来电信息。 )
权限限制:管理员等。
其他约束条件类似(根据业务丰富设计):

时间约束:22:00 之前等。

常见的问题和风险:约束条件判断不足,导致用户可通过特殊手段获取利益。

2)操作对象分析

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

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

例如下述用例子:

用户 A 查询电话 P1 话费:
用户 A 查询电话 P1 流量;
用户 A 查询电话 P2 话费;
用户 A 查询电话 P2 流量。

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

常见的问题和风险:
用户可访问非权限内的其他用户信息、敏感信息,从而利用这些信息谋取利益。

3)状态转换分析

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

例如在做任务的时候,任务有三种状态:未领取,已领取未提交,已完成三种状态。

那么可以这样设计:

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

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

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

4)时序分析

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

在正常的流程里,这些动作是根据程序调用依次进行的,并不会打乱,在接口测试时,需要考虑如果不按照时序执行,是否会出现问题。

例如,客户端数据同步是由客户端触发进行的,期间的同步用户无法干预。

功能测试的时候可见的就是是否能正常进行同步,而进一步分析,同步流程实际涉及了一组动作:
假设后台有 3 个接口:登陆获取用户 ID,上报本地数据,上报本地冲突。三个接口需要依次调用执行,才能完成同步。

那么在接口测试就可以考虑打乱上述接口的执行顺序去执行,会有怎样的结果,是否会出现异常。例如:获取用户 ID 后不上报本地数据而直接上报本地冲突。

常见的问题和风险:
非顺序执行后,数据出现异常,可能还会出现程序其他异常。
通过打乱顺序获取利益。

3、针对输出设计

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

1)针对输出结果

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

2)接口超时

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

4、其他测试设计

1)已废弃接口测试

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

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。

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。、
  • 注意:针对处理逻辑的设计中,可能使用某一种或某几种方式就可以将用例覆盖前,故实际使用中,可能不会全部使用,只要找到最合适的方式覆盖用例即可。

3)针对输出分析

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

当测试时间紧任务重的情况下,用例设计需要具体情况具体分析。

下面是我整理的2023年最全的软件测试工程师学习知识架构体系图

一、Python编程入门到精通

史上最全,接口测试-用例设计总结(案例分析实例)一篇策底打通..._第1张图片

二、接口自动化项目实战

史上最全,接口测试-用例设计总结(案例分析实例)一篇策底打通..._第2张图片

三、Web自动化项目实战

史上最全,接口测试-用例设计总结(案例分析实例)一篇策底打通..._第3张图片

四、App自动化项目实战

史上最全,接口测试-用例设计总结(案例分析实例)一篇策底打通..._第4张图片

五、一线大厂简历

史上最全,接口测试-用例设计总结(案例分析实例)一篇策底打通..._第5张图片

六、测试开发DevOps体系

史上最全,接口测试-用例设计总结(案例分析实例)一篇策底打通..._第6张图片

七、常用自动化测试工具

史上最全,接口测试-用例设计总结(案例分析实例)一篇策底打通..._第7张图片

八、JMeter性能测试

史上最全,接口测试-用例设计总结(案例分析实例)一篇策底打通..._第8张图片

九、总结(尾部小惊喜)

无论身处何种困境,都要坚信自己有能力克服一切困难。要勇敢地追求自己的梦想,坚持不懈地努力下去,最终就能够取得非凡的成功。

每个成功的背后都离不开艰苦的努力和坚持。要相信自己有能力实现自己的梦想,不管前方有多少艰难险阻,都不能阻挡你的步伐,直至抵达目的地。

成功的路上充满了挑战和坎坷,但是只要我们有足够的勇气和毅力,敢于迎难而上,不断追求卓越,最终就能实现自己的梦想。

你可能感兴趣的:(软件测试,接口测试,测试用例,软件测试,软件测试工程师,接口测试,测试用例,接口自动化测试,功能测试,自动化测试)