如果去产品位置，能得到更多的资源和空间（如人脉资源、晋升加薪空间、能力成长空间），为什么不去呢？
如果只是听上头大老板一言堂说做什么就做什么，完全没有自己的空间，也没有更资深的产品能一起协作（让别人带带），那就没必要去了。

现在的本科，北上广深杭一类的互联网大厂，校招入职就 20+k

也不能这样算，本身这个 1 里面就有水分，有潜在干到 130% 的潜力，我个人感觉只是用大模型为幌子先来榨干这一块水分（卷大家）

有自学能力和动力，苟着多学点准备好就面试走。
没自学能力和动力，就尽快离职，换个让你更有动力的工作环境。

感觉问这个问题，大概率是第二种情况，多呆一天都是浪费时间，除非生活所迫。

建议趁机看看能不能在这里转研发

有了 AI 后，无论研发还是测试，相同能力下，同一个人单位时间能完成的事情变得更多，说不卷那是假的。

同意，其实很多知识并不难，不是说懂不懂，而是知道不知道 或 了解不了解 的问题而已，只要基础没问题，脑子灵活愿意学习，有上进心，就这些东西每天都接触，一两个月都基本能掌握到独立完成的程度

尬了兄弟 我就是最应该被面挂的

SQL 是我的弱点，一般要用直接大模型解决问题就好，原理层的东西确实没多了解。

1. （count（*）和 count（1）有啥区别 —— 这个大概是我本科毕业时的八股文了，如果是 mysql ，只记得 count(*) 是直接获取 mysql 内部统计的一个属性值会块一些，比 count(字段名) 性能快

2. 索引有哪几种，怎么看索引 —— 什么聚簇索引什么鬼的那种，答不上，也不知道有啥区别；怎么看索引是什么意思呢？是 explain 一条语句是否命中索引？还是建表有没有索引？我都不会

3. 怎么查询一个班级每科前三的人的姓名学号 —— order by 知道，怎么选择前三不知道

4. sql where 和 having 执行顺序 —— 瞎猜，能说中，原理比较直观，瞎猜个差不多

5. k8s 网络服务几种模式 —— 完全不会

6. 性能是怎么做的 —— 缺了点语境，如果是 k8s 容器的性能测试，没做过但能瞎说一下，但是常规性能测试能答上

7. 自动化异步接口是怎么做的 —— 是指 async、await、接口回调那一类的知识？不太清楚问什么

某大公司的部某大部门，说做 AI 能提升 30% 的人效，结果今年的目标就是裁 30% 的研发和测试。
包真实故事

认同，自动化本身这个环节并不难，难还是落地，落地其实是一整套东西，而不仅仅是把执行用例的过程自动化这么简单

AI 自动修复缺陷，这个在大模型时代之前已经很多地方都有探索了，不过没有什么拿得出手的实践。大模型时代应该能做得更好。

AI 自动验证 bug，最近开始陆陆续续听到有业务团队在探索，主要是又大模型之后，面向自然语言的图文理解简单很多，比如移动端只要解决 “点击驱动” 问题，就能开始尝试搞这类课题。

剩余的什么更新测试环境、通知，这些用不上 AI，基础的工程开发就能解决。

AI 调试也是一个新课题，不过目前没关注到身边有人在搞，部分场景下和 AI 自动验证 bug 有一定重叠。

表的设计规范，不用学得太深入，因为在生产环境中彻底落实规范很可能导致性能损失。

我建议更多结合业务场景去学，某类型业务的表怎么设计（如电商，就涉及常规的货物库存管理、订单管理等），多看几个案例，就有概念了。

只对着教科书学，真的没用。

主要还是来自外部认可，得到合作的其他研发测试认可还是很快乐的，又或者了解新业务的过程也比较有意思。

工作 8 年，身边同事年纪都不大，基本工作 6 年或以下，没人考虑这个问题，结合身边还有一眼大龄的研发测试，所以我对 “职业危机” 不太深刻。

实话说，我不太相信自己的职业生涯会定格在 35，身边的研发测试产品一级管理者，很多是 90 后（如 91~93）。

自己不相信 35 危机，不代表真的就不存在 35 危机。还是尽量赚钱存钱，平时克制大花销，存下的钱转化为实际资产（最简单就是买房，理想是有俩房一个自住一个收租，安全苟下来），尽量不负债，这是多数普通人的倾向。这个目标都还够我和对象再努力个小十年了。当有了些稳定的睡后收入之后，上限就再探索吧，主要是保收入下限。

回到工作的主线，个人感觉就两条路：

1. 你点子多，脑袋灵活，敢于面对风险，喜欢业余折腾，就尝试轻资产创业。如高飞的写小说就是典型轻资产，身边同事有渠道买卖珠子首饰，回归技术本线也可以写软件写游戏。
2. 没什么点子，比较本分，倾向平淡规律生活，就在本职工作里尽量提升核心竞争力，发展核心竞争力来涨薪资。【也是我走的路线】

当然会投资会玩钱敢打敢拼还很能操作，那就很大空间了。

国庆期间我连带请假前后放了 15 天假，去玩了两个地方，都已经给我玩到想上班了。有时候上班简单的两点一线生活反而是最舒服的

如果不搞繁文缛节的话，就几个关键点：

1. 压测背景 —— 为什么要压测，需求哪里来
2. 压测对象和压测目标 —— 要测什么，指标去到多少算完成
3. 压测环境 —— 整体说明一下压测环境，得保障你的发压机没有瓶颈，同时压测对象的环境和线上可以比对，可能还需要关注压测是否对线上造成影响（如影子数据库等压测改造一类的事宜）
4. 发压过程 —— 这一个是最复杂的，你的压测策略（如 qps 变化梯度），压测场景（先压 A 再压 B 然后压 C）都要体现
5. 数据回收 —— 收集压测对象的性能指标，确认是否有非预期的报警，分析数据给出压测结论

缺 base 地

showcase 就是给大家当面演示一遍主流程，一般是用来传达核心功能已经准备好

1. 既然他都说是复制粘贴性的迁移逻辑，这么简单的事情为啥还要测试来测问题，他敢不敢直接上线？
2. 【研发主管的说法是 show case 等于帮测试执行了测试用例，测试就不用工作了，因此拒绝 show case】这观点可太强了，没见过这么头铁的，给我整不会了

另外说个笑话，我刚毕业第一年那会，公司内有个工作六七年的开发，还是那种比较爱钻研技术受其他开发敬佩的类型，他当时多次表达过这么一个观点：【技术方案没必要和测试过得太细，不然测试的思维就变得和研发一样，那就测不出问题了】。现在回想，简直放屁。

你这么说倒也是

我自己就接到三次不同前同事的背调电话，当然别人都跟我提前打好招呼了

这种就只能 case by case 讨论了，一般被裁其实也没多少时间给你留着，基本就是几天内走人，这种情况也没条件做啥事无巨细的交接，肯定是要先保证自己尽快找到下一份工作。不适用我上面说的。

倒不能这么说，我对自己的职场体验还是有要求的，自己也想尽量做好一点，得到更高的评价

我在意自己的职场口碑，也想梳理自己在这家公司做做过的重要事情，我会主动完成沉淀并确保自己对这一次交接满意。

反正每天也是来工位坐着没事干，整一下这些也就顺带的，玩手机反而更无聊。

像上面的案例，如果有背调公司打电话过来了解，你也不能怪别人说不好的话。