接口测试 一个接口入参很多,怎么设计接口测试用例

退之 · 2022年11月30日 · 最后由 itest work 回复于 2022年12月02日 · 4741 次阅读

我们现在在做接口自动化测试,有些接口入参比较多(最多的一个接口有 20+ 参数,其中必填的 8+,非必填的 10+),如果每个入参都按照全量覆盖的方法去设计用量(比如:每个参数都校验,不填、填 null,-1、0、100 这 5 个用例),那么一个接口只算参数的基本校验,用例都要达到 100+ 了,这样的用例编写成本会变得很高,投入产出比太低,并且价值可能很小。

问题 1:像这种入参非常多的接口,测试用例一般怎么设计,覆盖到什么程度比较合适?

问题 2:我了解到有些公司是做了一个工具来自动生成测试用例,全量覆盖所有校验,虽然用例量大,但不花费人力和时间成本,又能比较全面覆盖,算是一种比较可行的方案,如果我们自己开发这样的工具,目前没有思路如何来做,不知道你们之前有没有这方面的经验? 或者有没有开源/收费的工具可以直接生成测试用例的可以推荐?

共收到 10 条回复 时间 点赞

自动生成用例这个功能我之前二开 ms 做过。我自己开源的平台也准备做这个功能,不用生成一百个用例,一个用例请求 100 个接口也一样。
原理也很简单,先生成一条正向用例,然后在此基础上针对每个参数不同校验替换值并且换断言就行。

提供另外一个角度,从代码走查角度,结合源码去考虑。现在很多框架对于接口的入参都有注解型的检查了,可以看下开发的源码,对应的接口上的注解/或者检查规则是否正确,对应参数上的注解是否完备,规则是否合理等等。如果这些完全没有问题,似乎也可以稍稍的对这个接口放心些。

分享学习下,有好的思路也跟大佬们学习下
目前我这面的场景:最多的参数可能有 5 个,然后每个参数可能有多个场景,日常迭代测试中只会去完全覆盖比较核心的参数(完全校验参数返回的结果及入参场景),不是很核心的参数只会去用 python 脚本参数化笛卡尔积组合测试,采用 json 断言关键字/数据体;
异常场景:提取通用异常场景的参数,采用脚本去校验对应的 case 和数据;
JMeter 参数化:会用 JMeter 再去参数化跑一段时间参数随机组合的数据,防止有遗漏的场景;

1.覆盖核心场景和关键参数,这个可以跟开发一起讨论
2.这个以前有实现过,主要分两部分,一个是生成测试用例,一个是生成测试数据,先进行请求参数规则配置,然后生成一条正向的用例,最后分别替换各个字段各种类型的数据,并且生成对应的断言

扒代码分析接口逻辑或与前后端研发确认接口规范,明确关键参数,以及参数对应的业务处理逻辑

  • 根据具体业务逻辑来确认需要覆盖的参数场景
  • 根据前端调用规范,构造参数场景

接口 20+ 参数,一般都是数据采集类型吧?确认下接口用途,采集类型 的话,只需要关注关键参数逻辑,确保所有参数都能采集就完事了

问题 1:像这种入参非常多的接口,测试用例一般怎么设计,覆盖到什么程度比较合适?

我的经验是有几个思路

  1. 从代码覆盖率上去看,你的用例是否达到一定水平的覆盖率,比如 80% 以上;是否覆盖了关键业务路径,如果对代码熟悉可自行判断,不行的话可以拉开发一起过一下
  2. 和开发一起评估对齐出哪些优先覆盖,哪些可以不覆盖那么全,其实就是用例评审的时候强调好测试的取舍
  3. 其实这类参数校验,开发的代码一般就是一个 validator 定义好校验逻辑,或者开发框架上有提供对应的校验功能,基本是可复用的,直接白盒看代码去确定自己有没有必要搞这么多用例。如果参数校验很完整,其实可以适当删减无效用例

问题 2:工具生成用例

很多公司都有实践,如果要自己做也不难,大体思路是定义好不同参数类型的取值集合,如 int 就对应整型最大最小值、0、正负数、不同形式的整数写法等,预定义好一些取值,这些预定义的取值去替换测试用的 json 数据。再实现一个 json 解析替换的功能就可以是一个简单版工具了。最后的目标就是通过输入一个 json 范例,或一个 json scheme,自动生成不同的 json 数据供测试输入。开源工具不了解,我自己没有找过

问题 1:我司的实践就是代码走查,直接查看相关 entity 中对象的定义,lombok 用的规范,其实简单的等价和边界都不太会存在问题,反而更应该关注的是数据权限是否合理(是不是返回了太多的数据)、业务权限是否合法(是否有对应的功能权限),数据结构是否规范;

问题 2:这个现在有蛮多的工具都有类似的功能,以体现自动化测试用例的 “智能”,个人认为意义不大,纯粹的是为了数量好看。

来说说我的感受吧~
问题 1:代码走读即可。开发基本上基础校验方法是通用的,没必要对每个接口都做重复的内容,即使工具自动生成 case,也会存在维护和编写成本。其次,也会遇到非关键参数基础校验不完整的情况,从实际业务上看可能校验意义不大,让开发补充校验是否有必要、开发是否配合,反推下用例是否需要完善到这种地步呢?
问题 2:如果问题 1,结合公司实际情况已有了论断,那工具的必要性就看自己的了。

https://testerhome.com/topics/30495 完全可以用我这里的 接口混沌测试,你只要配置参数规侧 ;我来排列组合后去调用
只需要配置好混沌规则 ,然后以 “撞库” 的形式排列组合,替换掉正向接口用例中的参数值去执行撞库,瞬间完成接口健壮性测试 “撞库时” 先单个一个一个去换, 然后再排例组合。



需要 登录 后方可回复, 如果你还没有账号请点击这里 注册