那你可以讲 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，你不配叫中年人！

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

有这个需求就会啊

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

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

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

典型的沉浸在提问者世界的提问者。。。

监控和自动化测试完全是两码事。。。。

非常不建议自动化测试在生产环境跑，根据我的经验，自动化测试，基本不会被测试。。。你还想在线上跑涉及到钱的接口，这就是传说中的吃雷公屙火闪吧

封基本操作，跟业务有啥关系。。业务和检查点不应该是用例层才考虑的么。

我一般就按页面来，里面的内容不会单独拎出来