如果项目规模非常大，相关较大的子项目都有几十个，涉及到开发人员几百上千，线上非核心业务 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 好方便。。。有些套话他比我还溜

军火，能源，石油，通讯，粮食行业进入其中之一。。。

身体健康就是最大的财富

还没 30，你不配叫中年人！

在想什么技能在乱世能混的。。。

有这个需求就会啊

有点像掩耳盗铃~只要测试不提缺陷，就没有缺陷。哈哈

用户：这里有空子，赶紧钻一波

有时候明知道指标不合理也没办法。。。感觉就是为了度量而度量。
你看我司上周新增了 “测试用例密度”（测试用例对应版本有效代码量，是的代码量，不是覆盖率！），我不知道这玩意儿有啥用，完全像外行人在操作这个。