如果我说我已经几年没写过测试用例了， 大家是什么感觉 。 一个是我一直测试的模块比较特殊，都是可以自动化的，所以我的代码就是测试用例。 再一个也是因为忙起来没那个功夫和心情老老实实的写用例， 直接就上手写代码。

行情再不好也总有存活的培训机构的， 只是去上班，不是去创业。 就看到时候培训机构的面试能不能通过了

烂了的意思是？

先能干一年是一年， 外面的行业真没有这一行挣的多。 所以能多干一年都是赚的， 然后在干的过程中慢慢的去找适合自己的方向， 为 40 岁以后做准备。 我基本就是这么做的， 我现在觉得做培训讲师还是挺适合我的，也许有一天我岁数大到了没有互联网公司接收我的时候， 我就专职干培训去了。

我觉得有几点吧：

• 大家的眼界都提高了， 以前我刚加入社区的时候， 写个 UI 自动化或者接口自动化的框架分享就可以拿精华帖的，有时候写个 AI，大数据，docker 也可以。 但现在这些大家都见的太多了。 没办法再给这样的精华帖了。 这也是造成现在帖子少的原因之一吧， 毕竟感觉没啥好写的了，自己会的东西在大家眼里，也就那么一回事，所以就不写了。 我现在挺多时间想写点东西吧， 但觉得这东西写出来好像技术含量也不高，写出来也没多少人看，所以有时候想了想就拉倒了。
• 大家越来越忙，越来越卷， 行业越来越差，已经没精力没心情花大段的时间写优质的帖子了。 比如我越来越关心怎么保住饭碗，怎么做副业攒养老钱了。 PS：刚 30 来岁那会是真没想这些，但现在 37 岁了， 真要考虑自己还能干几年的问题了。
• 跟第一点有关系，就是大家的水平都提高了， 而我们知道水平越高，做的事情就是一些越深越细分领域的东西，这也就意味着受众更小。 咱们现在不管哪个公司里， 高职级的人怎么可能还在写 UI 自动化，接口自动化这些东西。 比如我们这高职级的基本都在研究 AI 大模型， 云原生，大数据这些领域。普通的自动化和性能基本都是丢给子公司和外包的。 所以这么小众的东西，写出来看的人也不多，产生不了共鸣，也无法讨论沟通。 所以也就不想写了

我个人不太看好 AI 生成测试用例，AI 精准测试这些方向的。 行业中没听说过有非常成功的案例。 搞这些的成本也很高， 你需要大量的很规范的产品文档和用例文档。 但这些都不是现在的国内公司有精力去搭建维护的。

有道理， 研究一下

各个大厂现在都这样，裁员，降本增效，之前我领导不小心 把我拉到一个大老板们的会上，大老板们就对着项目营收数字定团队规模。 有多少盈利对应多少人，如果人多了就减员。 很冰冷很残酷，但老板也说没办法，公司就是这个规定。 所以我们这种还盈利的产品算好的了， 基本没怎么裁员， 都是自己离职的，只是不怎么进人了。 像其他亏钱的产品， 指不定啥样了就。

安定在一个地方了， 就不是特别想走了， 我也有惰性 ，现在收入也不错的，去外面风险也不小。 所以先不动弹了

嗯， 有的

嗯那，十分卷了

这周日开，欢迎参加哈

真的花不了几个钱。。。。百川的最贵的模型， 也才 1 毛钱/千 token。 项目上连这点钱都不愿意出么。

目前已经都有现成的方案了， 你去百川也好， 百度的 appbuilder 也好， 阿里的千问也好， 都有大模型 + 知识库构建的能力了。 你需要做的就是整理好专业的文档上传到他们的知识库里，然后付费使用就行了，这玩意也不贵。 为啥要自己撸一套。 你要知道这东西它不是攒 3,5 个人就能搞定的。

就是怕继续跌下去，所以止损

我在天津买的房子刚卖出去， 腰斩了。 心疼的我几晚上没睡着

跟恒捷说的一样， 只有很少一部分人是在这种不碰业务的测试开发部门，我上面也说过大部分测开都是在业务里的， 自己开发工具， 简单的交给外包用， 困难的交给子公司或者自己用。 现在大厂业务部门里也基本没有那种只开发工具不做测试的岗位了。 我自己也是， 别看我现在级别上去了， 但是我还是需要在一线搞测试的。

@ZFW 的意思是： 大厂的标准模式就是一个正式的带一堆子公司和外包的模式。 正式员工很少来执行手工测试用例了， 只有一些难度比较高的，无法让外包和子公司人员来执行的测试会让正式员工来。 其他的工作正式员工主要是制定测试方案，开发测试工具，管控测试进度这样的事情。 所以按你的标准，大厂里正式的测试人员都是不务正业的。 你的观点过于极端了。

然后我的意见是业务里的测试开发挺常见的， 自己业务的测试工具自己来开发，简单的交给外包来执行，困难的交给子公司或者自己来执行。 完全不碰业务的测试开发即便在大厂里也是很少见的。就像我们测试模型是完全没有图形界面的，甚至连个 http 接口都没有，只能调 SDK 或者 gprc 和 trpc 协议来测试。 所以即便其实测试用例挺简单的， 就把数据给模型然后通过结果统计评估指标么。 但没有代码能力的外包人员， 你让他们写 trpc 调用实在太难为人家了。 所以我们正式员工来写工具，外包只需要按场景挖掘数据，审核数据，与算法人员讨论 badcase 等等这些事情。 这是一个在业界里十分有效的工作模式。 尤其是在降本增效的大环境下，已经是主流的方法了。 就算是那种完全不碰业务的测试开发，也是在一个单独的部门里， 他们负责的是大部门级别，或者公司级别的测试基础建设，并不是大家理解的随便开发个跟 pytest 差不多的框架，那是小厂子里的人搞过家家的手段，大厂里的这部分人要负责打通网络，环境，权限等关要（在大厂里，环境不是那么好搞的，不同的云里面， 不同的机房里，IDC 里，公有云，私有化，开发机，这些环境的网络可能都不通，权限可能都是不开放的，做测试的时候就需要有相关的基础设施来搞定这些，因为这不是给业务团队开发权限和网络来做的， 这事关安全）。 当然确实有些不误正业的地方跟过家家似的搞个类似 pytest 的框架，封装个前端就当平台的。 但在大厂里，人家测试开发部门就不是搞这些小家子气的东西的。

所以有一些人不务正业搞花活这种情况是存在的， 但别太极端， 还是有很多的测试开发在认认真真为公司提供价值的。

说的非常对

别闹， 在会议那好好干~~~

我们通常都是几十个群里滴滴个不停。 光一个子系统可能就拉好几个群。 不重要的我都设置成消息不打扰了， 不艾特我就不看的。 大厂里降本增效的太厉害了， 我们现在测试开发比 1:15 了

-1， 天天忙的像狗一样， 需求越来越多。 刚才看了一下手里的事：

1. 原始多模态大模型提测了
2. 知识问答多模态大模型提测了（测试数据还没弄， 很烦）
3. 文档解析引擎提测了
4. 文档拆分引擎提测了
5. AI 平台混沌工程提测了。

我已经想掀桌子了。 不过侧面说明一件事， 那就是公司不肯加人来解决这些事情了， 即便现有的人已经忙死了。 降本增效最有效的方式就是裁员然后剩下的人使劲加班

1. 上游幂等，下游重试，保证数据强一致性
2. 上游不幂等， 下周也重试（会数据重复）。 但是再下游做去重，保证最终一致性。

一般就上面两种方式。

在大厂都有这个问题，一个产品套一个产品的来实现的。 我给现在负责的某个产品做混沌工程， 测试出一个边缘计算的 bug，产品研发排查说是底层问题，底层研发排查说是 k8s 底座问题，k8s 底座研发排查说是 superedge 的问题。 就这么一层套一层的，一个产品底下 N 多个产品共同支撑。 我去年测试一个版本的时候前后折腾了 2 个月就是因为这个原因。 我觉得对于个人来说是无解的，除非个人魅力强到了可以让其他团队的人都迁就你（你别说我还真遇见过一个，是一个特别漂亮的妹子，这个妹子去找谁解决问题一般都很顺利）。 否则其他团队的人凭什么高优解决你的问题呢， 毕竟大家都那么忙。 所以我们一般就上升， 先上升到项目经理那，不行再上升到总监那， 最严重的一次我上升到了两边团队的 GM 那里。 就是上升这个事可以是很心平气和的， 在大厂大家都这样， 互相理解大家都很忙，手里的事肯定得有个优先级， 所以心平气和的抛给领导解决， 领导决策好优先级以后，自然就有人来解决了。 要是领导也不解决怎么办？ 那就说明这事也没那么重要， 让项目慢慢等呗。 就是你要知道， 咱们是大头兵，项目延期最着急的不是咱们。 咱们把风险抛出来以后会有人比咱们还着急的。

短期不靠谱，长期太艰难， 行业太内卷，环境太浮躁， 躺平不甘心，拼搏怕辛苦，这样也不行， 那样也不行。 所以还是毁灭吧。 还是等着彩票中 500w 比较好，但是中奖 500w 的前提是先从买一张彩票开始，而不是在家里纳闷怎么还不中奖。

毕竟我们总得迈出去一步或者几步才能期盼好运砸在头上吧， 就像谈恋爱， 好姑娘是需要运气去碰的， 但就像明明跟董宇辉说的：你想要因缘你得出门啊，天天憋在家里怎么认识女人，难道靠女劫匪入室抢劫么。