开局一张图，经历全靠猜

sorry，文档链接忘记开权限，可以进去链接中自助。

你要的文章是 https://mp.weixin.qq.com/s/EFi1GzHy5qAx9Ixnppoybw

我猜测是 4k~6k 区间，刚毕业的话可能就 2~3k？

哈哈哈哈笑麻，我相信潮汕有的概率要高于湛江，有肯定是有，还要求去到 1w 不仅要能力强估计还得走关系

首先湛江有没有软件测试岗位都不好说 @Rikasai 大佬估计有些了解

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

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

看完 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. 测开并不是只需要去写代码，好的测开，技术视野首先要比业务测试同学好，更重要的，是得能和业务测试同学一起分析运营业务质量问题，也了解业务

感谢肯定 😙

😙