只要一个密码泄露，一堆 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，我免费帮你改改简历，给你点面试建议。之前社区也有几个同学加过我，帮过别人几次了

不是想学什么，而是看你需要什么再去学，得功利一些

进中厂可能会对你的外包经历有歧视，小公司可能反倒觉得这段经历是个亮点，所以这个思路我觉得没问题

钉钉这个业务虽然一般，但是如果你成长得快，多扛一些业务，呆两年多跳旗下小公司是可以的（比如我记得广州有个阿里旗下互娱的小公司），但是你说要跳到优酷做正式员工可能还是有些难度