这个我们也做过，有 2 个思路给你参考
1、根据 Swagger 自动生成随机数据，但是这样的报文没有任何业务逻辑，没有太多意义
2、根据测试环境的日志，抓取每个接口的正常报文，处理后变成可用请求，然后对测试的版本进行验证，对返回报文内的关键信息进行比对，确保旧逻辑的正常和发现契约内的异常改动

很受用的参考。第二种可以作为后期目标研究研究。目前第一种作为能力范围内能尽快出结果，年底前也算个绩效

我们接口自动化也是利用 swagger 获取接口信息、参数信息，然后根据参数必填和类型填写随机值。这样做的目的不是用来冒烟的，而是为后续编写自动化用例提供参考，不过效果也不是太明显。想要直接生成可用的冒烟用例太难了，目前还没有好的方案

有个小建议
「部门的研发都比较随意，比如提测经常延期、没有自测、提测质量不理想，部门对线上问题也相对宽容，导致这一现象更加严重，部门新的空降老总一直想整顿...」
可以先去优化项目迭代流程，你给一个规范合适的方案，如：测试用例评审通过后，测试侧输出冒烟用例，增加研发提测流程，提测时带有冒烟用例的执行等等

然后让老总去推行这个事，从上往下推，这样子投入产出会更好一些，也能拿一个不错的绩效~~ 关于工具研发，前期准备一定要做充足，老总或更上级 确定方案可行性后再去做。

是的，这种随机异常参数组合只能验证下接口健壮性，所以我这冒烟就是保证提测的接口初步可用。业务逻辑还是需要自动化针对设计用例。

如果我来设计，那我会分两部分设计一个接口管理端，一个自动化执行引擎。接口管理端为从文件导入接口文档，手动维护接口依赖信息（人工维护），根据接口依赖生成冒烟用例。自动化引擎部分读取并按步骤执行用例，通过接口映射函数来处理对应接口参数和业务逻辑（人工维护）。这样整体维护的成本并不高，灵活性也好。因为是冒烟测试，全部用正常参数即可，需要异常参数那就是另一套设计了。

我不太明白你想做啥。
首先，你的自动生成接口测试用例，请求的字段是每次跑 smoke 测试的时候都会变的么？那你怎么去判断返回值是否是你想要的？
如过不变，那这套东西就无非是普通的接口自动化而已了吧？
而且冒烟测试更多的是看业务逻辑吧？随机生成的字段完全不会考虑到业务逻辑吧？

我们公司的模糊测试是你说的那套玩意，给个 seed，自动去生成一堆乱七八糟的测试数据（具体生成规则我也不清楚，不过应该是一个常用字典 + 一些随机生成方法），跑个 24 小时，狂暴鸿儒所有接口，然后看服务端是否抛出一些异常。

确实叫模糊测试可能更准确吧。这几天刚开始搞，目前发现 Schemathesis 这个库能满足期望，会为你生成各种输入进行测试。至于跑出来的结果校验，我目前只能 status_code != 500，暂时想不到更好的办法。接口业务逻辑的冒烟和回归就还是靠接口自动化用例去覆盖。

请问楼主方便加联系详细讨论吗,我也有这种情况,我主页有联系方式

我理解楼主的想法，但我有点疑问。
1、不同接口 - 不同的字段所需要验证的类型、长度都不一样，这个要怎么去定制处理呢？
2、业务上来说，接口需要传不一样的唯一值，如申请编号，这个应该也需要定制处理

之前我的设想的结果是自动生成不同的用例去调用接口后，记录所有的数据到表格上，然后再人工去查看结果是否符合预期

没有订制，现在统一校验 status_code >= 500 就失败。例如，如果接口期望一个字符串，会发送一个整数，空值等，以查看 API 如何响应。只要不报服务异常就通过，主打一个粗暴所以不进行任何业务逻辑校验，通过这里再进行后续的功能测试。

提供一个思路，可以看下是否能够符合你们的场景：参数随机生成不是很可靠，可以尝试从数据库方面对数据进行分析，了解下参数对应的数据库字段，在数据库里面分析历史的数据长度、类型，不同表的主外键，我们公司的测试数据都是从数据库中获取的，通过关联多张表拿到相关数据，提取到放到参数里面进行请求

难，还是老实做接口自动化