你只是厌恶这种人而已。。。这种人也可以是主管、经理等等，所以不用强调架构师啦。。。。
从楼主的描述看，你可以送他一本《傲慢与偏见》

你挑版主们有空的时间发撒~不匿名没准可以更快

哈哈 让我想起一句话，质量是建设出来的，不是测出来的~

换个角度，有没有可能是因为以下原因：

1. 测试技术迭代频率低
2. 测试业务相关性较强
3. 测试能力要求相差过于巨大（高的要求很高，低的懂的都懂），内容深的容易曲高和寡，内容普通的大家觉得又有点 low 等因素导致论坛测试板块活跃度相对其他低很多，热度起不来的话板块就慢慢没了

这其实和公司大不大没啥关系。。。看愿不愿意在规范上花功夫~
这些东西其实也花不了多少成本，但是会避免很多坑

工作是为了生活，更好的工作是为了更好的生活

以后这些是不是都是 AI 来排查了。。。

如果项目规模非常大，相关较大的子项目都有几十个，涉及到开发人员几百上千，线上非核心业务 BUG 几十，还算可以接受吧
但是如果项目规模一般，比如就十来个开发，核心业务相关 BUG 几十个，那这项目估计是自身自灭的项目，趁早跑路。。。

应对的话

1. 先看资源配置是否合理，10 个经验开发的活要求让 1 个初学者干了，这没得玩
2. 进度是否合理。。。两周一个迭代是不是要做两三个月做的。。。
3. 如果以上都满足，那就看整个研发流程是不是有问题，每个环节挨个梳理一下，针对性解决

我们有维护统一的数据字典，统一的异常信息列表，对接口定义、数据类型、粒度、分类、编号统一管理，每种业务流程也会有相应接口流程对应的文档，感觉还好

看了日志才能确定问题

摆摊

没看过 无法给出意见

那你可以讲 10 年以上了。。。

简单 做成系列就行，比如 Junit5 源码解读系列一~十二，可以搞一年。
然后再选个开源项目进行源码解读，再搞一年。
有用没？肯定有用，对自己有很好的提升。对别人来说，愿意听的也有收获，不愿意听的那就更无所谓了。

我一般只关注业务有没有实现，特别是一些隐藏的要做的。比如报错、异常流处理等，比较多的是报错提示的友好性，这个主要从运维角度出发。
代码本身我不发表任何意见，随便哪个 sonar 或者 ChatGPT 提的建议都比我强

一般不单独测这玩意儿，合并到 UI 测试。

当我看到这个的时候，我觉得有些人不一定会很难过~~

业务逻辑是业务逻辑，用例是用例。A 调 B，调的是 B 的逻辑，把业务逻辑和校验分开就行。

比如你想分析和追踪往昔的自动化测试执行情况的时候。

50 岁的软件测试，也就是 1973 年生，22 岁左右开始工作，1995 年就开始做软件测试，工作到现在一共 28 年。这个时间各个互联网大厂还没出生（腾讯 1998 年、阿里 1999 年、百度 2000 年、网易 97 年、新浪 98 年），要待应该也是待一些通信大厂，我估计纯软件测试那会儿也比较少。

6~10 年后，应该 50 岁的就开始多了。

问就是 100% 咯

接口测试要结合功能来，而不是仅仅针对参数的测试。可测的点很多，举个简单例子，你的用例没有多个 fileids 情况，没有 tid 和所有 fileids 不匹配或者部分 fileids 不匹配情况，没有对不存在的 tid 和 fileids 情况的覆盖。这几种哪怕我没看到需求，也觉得是应该要覆盖的。

至于你列的各种类型的 tid 和 field，我反而觉得可以归入到等价类，合并成一个就行。

生成简单的可以，开创性的东西还是要靠人。另外生成的东西，并不一定能直接用，还是要调试

和 AI 的对话，本质上是对 AI 结果的一个测试过程。

测试人员可能会消失，但是测试本身并不会。

不过有 AI 好方便。。。有些套话他比我还溜