自动生成用例这个功能我之前二开 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 完全可以用我这里的 接口混沌测试，你只要配置参数规侧 ；我来排列组合后去调用
只需要配置好混沌规则 ，然后以 “撞库” 的形式排列组合，替换掉正向接口用例中的参数值去执行撞库，瞬间完成接口健壮性测试 “撞库时” 先单个一个一个去换， 然后再排例组合。