swagger-parser 包了解下

这东西是边搞边优化,主要是看哪用的不爽了,就拓展下的

都写,针对单接口的用例和业务流类型的用例

接口关联参数数据化, 这个我的实现是提供了多维度的数据保存模式,比如 saveMethod, saveClass,SaveThread,saveGlobal 等
多数据源可完全依靠 spring 的多数据源实现 每个数据源定义一个 beanName,注入的时候根据 beanName 注入即可
mock 和监控问题,这个怎么说呢 按我的理解这个属于一个测试环,而接口测试只是这一个环中的一块, 实现 mock 可以自建一个 mock 系统,至于监控 我觉得现在微服务情况下,即使测试环境也可上 skywalking 或者 pingpoint 等监控软件

3000+ 用例都没问题啊,调调 allure 的启动参数? 调调内存什么的,或者优化用例,堆栈信息只显示 message 等等优化下
第二个问题我感觉你思想出问题了 ,为什么不从源头解决问题呢,权限控制为什么不做到用例运行级别,比如每一块业务接口生成一个 allure 报告,如果硬是要纠结从 allure 上解决问题,我记得 allure 的数据结构是根据 uuid 与 parent 的 uuid 关联,然后保存 json 文件,我觉得可在运行期间记录 uuid,然后根据你的权限规则生成 allure 的 json 文件,可行?

开源地址:
https://github.com/luoylove/api-test

推广方面基本上公司需要回归的主要业务接口都接入了,稳定性方面还是可以的
postman 我理解是适合做新接口调试, 不适合做这些老接口的自动化回归, 有短板,有需要访问第三方中间件的时候我能想到的解决方案是我再写一个代理系统与第三方中间件通讯,然后开放 http 接口给 postman 调用
jmeter 确实很好用,感觉有点重
如果用我这套解决方案,从写用例来说其实难度不是特别大,即使没有代码基础的,另外当你写多了的时候总会遇到问题,然后会去翻源码,会去找找解决方案,这个时候也是一个学习的过程,等要换工作了也能说说
CI/CD 方面来说,这要看各个公司的一些尺度了,有些是项目重构就自动触发执行一次接口测试,有些是只有到最后的回归了才总体执行一次,还有一些可能类似线上巡检接口的,需要定时执行

之前设计的时候有参考过 httpruner

这个可以有,我准备实现下 swagger 抓取接口,生成 yaml 单接口测试文件,然后就可以根据生成的单接口组合用例流测试了

其实直接 springboot 的环境支持就支持 jenkins 的 pipeline, 因为运行是 mvn clean test -P uat -Dtestng.xmlFilePath=testng.xml
是通过指定-P 来指定读取的配置文件, 在 jenkins 定义一个变量选择环境的配置文件, 然后-P 里面调用变量就行,这样就可以动态选择环境

rest-assure 基本能满足所有测试 api 的需求吧, 而且还提供了各种 listener 以供拓展, 感觉我用下来唯一的缺点就是源码很多用 groovy 写的, 遇到问题看源码看的头疼

我们公司的配置中心用的 apollo,是可以接入 apollo 管理环境的,但是觉得太麻烦,用 springboot 的环境切分就足够满足需求了

通过兼容 spring 的环境管理来进行管理 application 文件区分

1. maven 运行时候通过 spring:profiles:active: #env# 来控制环境, mvn clean test -P uat -Dtestng.xmlFilePath=testng.xml, 通过-P 指定, 可集成 jenkins
2. 调试通过@SpringBootTest注解控制环境, @SpringBootTest(properties = {"spring.profiles.active=uat"})
3. baseUrl 一般写法都是会参数化的 ${base.url} 指向 application 文件