1. 测试周期短，测试时间少：有没有办法让研发分批提测，不要让研发全部搞完后一次性全怼过来。这里还涉及研发如何拆分需求的依赖关系，也不是说着这么轻巧；
2. 线上逃逸的接收程度：多和研发沟通变更，没有变更的地方，不回归在线上出问题可不可以接受？以这个原则去删减回归工作，可能有立竿见影的效果。和各方沟通，大胆接受线上出小问题，不然就接受一直这么累，或者跑路；
3. 低级工作下放：什么都要你一个人干，你累死；实习生永远只能点点点，别人也没积极性越干越不想干。一些只有你知道的，但也不依赖经验和判断力的业务知识沉淀成文档，一次过内部培训把大家教会，就再也不用被垃圾事情浪费时间；
4. 能力培养：在这样的环境和强度上，根本不存在能力提升一说，测试是一直是 “原地踏步 -> 人员流失 -> 放低要求紧急补充人员 -> 原地踏步” 循环，得发掘重点培养对象，建立人才梯队，做更多的工作下放；
5. 自动化：这种频繁迭代的短中期项目，我不建议自动化，最多就做一些简单的核心接口自动化，但如果解决不了人效问题那就去幻想自动化能有什么用；
6. 别全都要：有些工作是不是可以不做，或者简单做？比如各种报告是不是能简化，一些基本质量让研发保障（showcase 打回，如果测试有足够话语权）等……

1. AI 是真的能提效，对个人对老板都有收益，不要对 AI 有偏见，不要抗拒 AI 落地，要理解且拥抱，可以选择不做先锋布道者，但聪明人至少都做跟进者（有条件最好再理解一下 AI 底层进步迭代的逻辑，看论文看别人分析都好）
2. AI 在质量领域的落地实践，正被大厂迅速开发。可能再过一年半，AI 在质量中能玩的地方基本都走了个遍，那会就沉淀出和传统质量一样的质量框架/套路，大家就照着干就完了
3. 各行各业垂类领域的 AI 实践，肯定靠这个行业内的人去想，即使是传统质量也是一样，行内人是第一批知道痛点的，你可以骂你老板傻逼，但是不应该放弃思考（当然不思考也不代表什么）

能帮助好别人就好

1. 先从学习大纲入手 —— 搜索引擎搜索 + 多 AI 问学习大纲，最后自己把答案整合一下
2. 有了大纲后，明确学习先后顺序，大概画出初级、进阶路线（可以让 AI 帮忙划分）—— 基础概念优先学习，质量方向优先学习（如大模型评测，更接近测试思维，会更容易学进去），理出部分有互相依赖的概念一起学
3. 然后就是一个个学，看资料、找视频、学案例 —— 对于非严肃的学习来说，这个程度的知识储备就差不多了，如果要严肃地说，那就得看一些体系化的书籍了

那要看性能测试的人跟不跟业务，如果他们是一波独立于业务之外专职搞性能的人，不了解业务，你让他们评估也实在是为难别人（当然你可以对外沟通时给他们甩锅，看你自己怎么想）。

从我的角度看，业务最后出问题还是自己受损，你能评估到也是你的 goodcase，如果自己有能力评估还是要尽量参与。

改代码就让研发评估是否需要回归功能，但多数对自己没自信的研发为了保险起见更倾向让测试做冗余回归，这时测试人员能不能 review 研发的改动，评估改动影响大不大，要不要回归，回归多和少，就显得很重要了。

别把自己 pua 到抑郁了

先自查评审是不是复读机大会

我的评审，研发参与感都挺强，我会一直和研发互动，过重点抛问题讲测试思路，一些很常规 case 其实不需要研发 review

真实又真诚

1. 现在的岗位与你预期不符的具体是什么？是学不到新东西带来的焦虑？还是行业方向不对？还是薪资或其他问题？
2. 你能做出的改变可能是哪些？内部向上申请更多的机会？找厉害的同事学习？换一份工作？

上面的问题你想清楚，然后咨询一下 AI 估计就有思路了。