不好意思，才注意到留言。现在是继续在游戏测试行业还是已成功转行啦？

我是 2018 年从游戏测试转到软件测试上的，当时乃至现在无锡的游戏测试岗位还是很少，期间经历过一次跳槽，一次裁员，现在 34 岁了更不管乱动...
2022 年那时候裁员就感觉越往后的工作越难找，2024 年看社区还有一些其他渠道都在说找工作比找媳妇难...

34+ 的测试老兵路过~
2024，共勉

2022 年 3 月经历一波优化后，就蔫了，很少逛社区，很少做总结了
也想着掌握一门外语，尝试去外企碰碰运气，哑巴式英语断断续续学了一个月就放弃了
比较佩服楼主，有毅力，有想法，有行动力。

车载测试我由易到难大概分了三块：智能座舱测试 -- ADAS 实车测试 -- ECU 层面的测试。
智能座舱这块主要侧重于仪表和中控，上手相对容易些；
ADAS 实车测试，前提得有驾照，侧重于传感器方面的测试；
ECU 测试就偏底层了，像 MIL 测试，SIL 测试，HIL 测试等等，这块感觉要求比较高。

书名《质量全面管控 -- 从项目管理到容灾测试》

分享下个人的做法，仅供参考哈~
1.设计用例前，对被测业务流程/业务场景要有一定了解，对需求文档/原型图要做深度剖析，提取被测点；
2.设计用例的工具不限，Xmind 也好，Excel 也罢或是其他用例管理工具，把控好用例颗粒度：可粗可细。比如对于一些通用功能，可以设计一版详细用例便于后期复用；
3.用例我这面分功能用例和系统用例：功能用例就是针对单独的功能点或相关的功能点，系统用例就是完整的业务流程，不同的业务场景。不同的阶段，测试关注的重点不同。
执行用例时发现不足，属于正常现象。个人理解上的偏差或出现考虑不足的情况也会出现，及时做好用例维护更新就行。

1.从测试角度来看，不论是少提文件还是少改配置，执行的最终结果与预期不符，出现一些错误，我们都可以判定为缺陷（Bug）；
2.针对这些 Bug 我们再来分析排查原因，是代码逻辑本身有问题？还是测试环境有问题？上述四点都是引起 Bug 的具体原因；
3.如果你们开发身上有缺陷指标相关的 KPI，那就可以理解为什么会标记为 “外部原因” 了...

最后要说的是，不论出于什么原因，要及时修复，避免日后出现同样的问题就行。如果一再因为开发自身原因导致 Bug 量居高不下，那就要把这类问题单独拿出来说道说道了。

算是间接影响到了吧~
二线城市，日企，疫情原因接不到国内项目，就安排到纯英文项目组（不具备全英文环境办公能力），做了一个月自己顶不住提离职了，最后协商 1 个月补偿金。
服务 3 年的公司，想拿 N+1 不现实，再说也是个人能力不足啊，日过具备较好的英语水平的话，或许还能继续做下去。

首先，测试用例设计能力是测试人员必备的基础能力（不论做功能测试还是做自动化测试或是其他类型的测试）；
其次，想往高级层次的岗位走，那代码编程能力是必不可少的（不论是阅读开发代码还是自己撸代码搞框架都需要编程能力）。
如果是转行做测试，还是循序渐进的来，从基础学起、做起，遇到合适的机会再进阶。