实在搞不懂贴这种代码的意义是什么

1、你面对的不是接口，而是接口背后的服务或平台。只关心接口（出参 入参）本身，不去深入了解接口背后的技术实现逻辑、方案以及数据流，是不可能设计出有深度有质量的测试用例的。不少人甚至市面上一些文章都认为 接口测试就是发送请求，验证响应，再发送请求，验证响应......这是一种严重的误导

2、从 bug 数量上，服务端测试发现的问题肯定是不如前端交互和 UI 的；但从 bug 价值上，绝对是优于前端的

3、其他的问题，如接口变化频繁、什么时候介入... 这些都是考验 lead 管理智慧的问题

4、最后再说一句：没有一支强悍的服务端测试团队，测试是很难跟其它团队抗衡的。

1、性能测试中常见的 IO 问题。性能测试过程中，除了常见的 CPU、Memory 资源占用，如果加入 IO、带宽的观察，这类问题的发现就相对容易得多。
2、很多初学者以为性能测试就是拿工具发送压力（跟一部分人理解的 “API 测试就是发送请求” 一样），其实事前有很多知识需要了解和准备, 例如端口范围、文件/TCP 链接最大限制、TCP 超时时间、存活间隔... 当然这也是系统/网络调优的一部分
3、性能测试什么时候开始做，跟测试的对象和目的有关。可以只对单个协议进行测试，可以只对单个中间件进行测试，可以只对某段代码进行测试，当然也可以对业务场景进行测试

1、高质量的软件，是设计出来的。依靠测试去保证，太晚。
2、质量永远是第一位的。不要陷入 一些 “政治正确” 的陷阱，诸如：“按时交付，XXX 对质量负责...”
3、按时交付低质量的产品：政治正确，但属于短视行为，长期等于自杀
4、责任与权利对等，跟利益/回报挂钩：
1）彪悍团队，可以左渗右渗到每一个环节，就像基地组织，敢对每一起事件负责。
2）优秀团队：见招拆招，能够快速地分析和溯源出质量问题的本质，建立有效的防范纠错机制。不该我负责的绝不背锅，该我背锅的也要找个垫背的。
3）普通团队：爱咋咋地，活总要有人干，锅总得有人背。通常被一句 “测试为什么没有测试出来？” 直接怼死

5、项目管理、过程管理、流程规范，甚至论坛里的各种自动化框架/工具/平台... 所有的一切都是手段，不是目的。
6、目的：提供价值。

我当前的做法是：
1）后端使用规则引擎或者 DSL，前端拖拽
2）antlr 可以用来 实时语法/输入验证，提供更好的体验。

至于文中提到的手段 1 和手段 2 哪个更好，要看你的具体实现需求，手段 1 也可以做得非常灵活和通用。

论坛里低代码这块的讨论不多，有经验的同学们可以一起多多探讨和分享

楼主归纳得不错

测试用例如果聊的话还是有很多方面值得探讨，简单地说下：
1、测试用例其实是一种智慧传承和管理思想
2、测试用例必须写，而且要不断的维护....
1）如果项目时间紧张，前期用 xmind 等代替和指导测试，后期再补详细
2）如果项目时间宽裕，直接按要求写详细用例

换个思路，在@Before里产生修改数据后 作为 dataProvider

就问题本身而言，目前并没有很好的高效的方法。
1、3 楼 接口文档 diff 的强依赖开发提供的接口文档，一个文字的修改都可能产生消息通知，实际执行中效果并不好。
2、8 楼 @Chenkl 的方法只对出参有效，无法对入参变更进行检测

如果问题的出发点是为了获得变更，精准有效的测试：
1、开发主动 announce 告知
每个人在工作中都是一个节点，要做到 “服务好你的下游，对接好你的上游”。
一个接口无论是入参或出参有变更，或者该接口背后对应的程序代码、实现逻辑有变更，一个职业的开发 应有义务通知相关干系人；靠测试自身去 diff，去挖掘是不可取的。

2、使用发布系统
任何模块/组件的上线都需提交到发布系统（发布内容&影响范围&风险等需要有较详细说明），测试只对发布系统中提交的项目进行评估和测试。前提是公司有一套好的发布系统和流程

什么问题

先抛个砖 ：-）