如果工作让自己不开心，那就尝试在生活中让自己开心点~
要找到一份让自己满意的工作其实很难，无论是薪资、职责、内容、领导等，尽人事听天命吧。

有时很羡慕网上大佬和身边的朋友，他们成长很快，收入也很高，做事很专注，履历很闪光。深入看一下，除了别人本身能力过硬外，在环境上多杀也比自己更有优势。接受自己的平庸，和自己和好，是咱们奔三人士的重点事项

看完 3 楼和 15 楼的答案后若有所思：

1. 在当前的平台上努力扎根，基于当前平台的规则，尽量往下钻，目标是在这个平台上尽量做成关键角色，把已知的方方面面做好 —— 对应就是产研团队到底需要什么样的测试，需要测试干什么活，整明白后就去努力实现交付，去做别人心中最想要的测试角色。已经不再是学习自动化的范畴
2. 面向外面的大平台，基于外面的要求去学习，让自己的能力达到外头要求 —— 是社区的普遍观点，也是大多数手工测试转型自动化的初衷。虽然无可厚非，但有时所谓的 “要求” 可能仅仅是面试造火箭进去拧螺丝的敲门砖。要实打实地对整个项目有质量贡献，还得是多元化发展，让自己在项目中成为关键角色。对此我反而觉得广度比深度重要，先横再纵，是更适合现在环境的 T 字型人才

对的，字节做 UI 自动化的就是从腾讯过来的人，就是 QTA 做封装和二次开发。

也算能用，解决特定场景下的问题也管用，但是无法铺量，还没见过哪个业务可以大批量用这些 UI 自动化，基本上都是给自己维护死。

只要一个密码泄露，一堆 app 账号一起死亡

承接上面的用例设计话题。

用例设计是给自己看和给别人看的（保证思路和场景正确，没有明显漏覆盖），而具体的用例细节可能只有测试自己知道。我还是很支持提前做用例设计，如果上手就是直接开测，那大概率是场景逻辑的分支不会很繁乱，这种情况下不设计其实也没事。

• 你打算在这个行业从业多久？
• 你对自己未来还会成长的信心大不大？
• 你能否做到比现在更快速更高强度时间更长的学习？
• 你能否扩展到一些更高级的行业人脉？
• 月收入多少能满足当前基本生活，预期的生活月收入要渠道多少，现在两者有没有差距？
• 家庭和工作的时间投入要怎么分配？

可以试着想想这些问题，再问问自己怎么选 offer

我是三十岁才和对象一起啃了四个老人才凑齐首付……

别说测试这个行业，我就想问什么行业的什么公司可以稳定干到退休……

是他，感兴趣的同学咨询他就对了

早期热爱分享的那群人，随着工龄提升，往上爬的过程工作也会越来越忙，分享变少了也是正常的。期望的是社区有新的分享力量

有，老板已经在鼓励我们去发现工作中的问题，落地 AI 去提效实际工作，已经有同事在跟进调研了

还得再加上工资一千八

七楼八楼答得非常好了。总结一下就是：

1. 先做好测试评估，思路是先拉研发一起看达成测试范围共识（评估的过程中要抛出时间限制，以及明确出质量问题要供共同承担的意思），有余力再做测试覆盖率的验证。
2. 建立好基本的研发提测流程，约束研发提测的自由度，明确你下班前半小时提测，我就是无法测试完成上线。记录好研发开发工时和测试工时，逐渐平衡出一个相对合理的研发测试工时占比，没理由每次都是研发改 10 分钟，你就要测半小时。
3. 线上漏测 bug 重点分析原因，如果明确是新需求改老代码导致老功能出问题，很大一部分是可以评估出来然后做回归的；如果是评估不出来的问题，要不就是研发对代码不够了解（在只有一个测试的情况下，更别说让测试能评估出来），要不就是边界 case。以上都不是你做自动化能解决的问题。
4. 前端自动化没必要做，尤其是这类内部系统，一方面变更成本低，另一方面大家对这个系统不够敬畏重视，做前端自动化大概率是负 ROI 的事情。

无效上班，很真实

是说上班摸鱼么？逛逛 TesterHome，刷刷抖音（因为我们本身就在测抖音，刷抖音就很自然了 ）

下班，健身、打游戏、玩变形金刚

你需要事先让开发去评估工时，如果对方是一个工作多年的开发，他应该对 bug 解决有基本的耗时评估。
我们也先不用管他评估得准不准，反正是开发说的，到时候你计算出来结果被别人质疑（比如为什么评估要这么久），你可以说是开发给的解决工时就是这么久。这样也能倒逼开发去认真看待评估这个事情

不好意思，随口的回答的确有点太抽象。可以参考 6 楼恒捷的答案，已经是 100 分答案了。

技术方向上，如果不考虑具体业务属性的技术：

1. 优先会基础前后端开发，因为前后端开发能力是把方案具象化成可交互的工具的基础。至于前后端再来是什么技术，我的观点是随便挑，网上搜哪个热门就学哪个
2. 在这个层面上拓展对应的业务技术

测开，个人理解是能通过技术手段解决业务质量问题的人群。

1. 和会什么语言一点关系都没有，也没有人会 care 你用什么语言解决问题（除非是特定领域，比如你要搞 android 那你肯定得会 java 和 kotlin），只要你能解决就行，解决不了，几十你会 100 种语言也没用
2. 技能熟练度方面，能写测试框架和工具，如果复杂度到位，那证明你是一个技术还不错的人员，但不一定是个好测开
3. 测开并不是只需要去写代码，好的测开，技术视野首先要比业务测试同学好，更重要的，是得能和业务测试同学一起分析运营业务质量问题，也了解业务

感谢肯定 😙

😙

情况还有点特殊，那我尝试换位思考一下，从开发和开发老板希望从你那里获取什么信息。

1. 需求什么时候能测完，什么时候能上线
2. 需求的 bug 多不多，解 bug 需要花的时间会不会阻碍上线
3. 这次的需求测出来问题很多，有没有办法让下次差不多的需求没那么多问题
4. 上线的需求有很多 bug 反馈过来，以后能不能再也没有这些反馈
5. 除了基本需求测试外，你还有没有什么额外的测试产出

就只能从这些角度去写；3、4、5 其实很抽象，靠你自己去想。1、2 比较明确

1. 在测哪些项目
2. 项目测试进度（不要就一个抽象的进度 xx%；而是 “执行用例数 + 已花费时间 + 剩余用例数”，最后折算出整体进展 xx%，并得出还要多久才能测完）
3. 有什么风险（数据构造？研发不配合？测试环境没 ready？工作量太多？）
4. 是否需要支持（加班？摇人？延期？）

如果手头有一些什么专项，比如自动化，也可以按照类似上面的思路去写，但是要换成一些关键的统计指标，比如计划这个季度覆盖 xx 场景自动化，实现 xx 条用例，实际写了 xx 条。

发现了什么缺陷等等酌情写，如果是零碎的东西写进去没信息量，没人看，如果是通过这个 bug 去表达项目测试困难或者其他实质的问题，那是可以写的。

这个图的箭头方向应该反了，按照表述，数据是从机头指向 EAP，再从 EAP 指向 MES 系统？

没所谓，改改简历也就 10 分钟，给社区同学做点好事

不介意的话可以加我 wx，我免费帮你改改简历，给你点面试建议。之前社区也有几个同学加过我，帮过别人几次了