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

我是 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 不现实，再说也是个人能力不足啊，日过具备较好的英语水平的话，或许还能继续做下去。

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

3 月底换工作时下载了 Boss 直聘、智联招聘、51job、猎聘、拉勾直聘、脉脉。
Boss 直聘基本上都是已读不回，招聘单位不付费使用的话，每天联系候选人数量有限制。目前大部分都是外包主动联系，用人单位几乎不主动联系；
智联招聘，活跃度一般，心仪的岗位不是很多，好在部分 HR 能够互动下；
51job 和智联招聘感觉差不多；
猎聘感觉都是高端岗位，外企岗位多些；
拉勾直聘我所在地区招聘岗位不是很多；
脉脉中一些脉友内推，相对少走了些弯路。
最主要还是人脉，朋友推荐的机会稳定、靠谱些。

看过书上一句话关于做管理还是做技术的分析：做技术有余力，有心得，就可以去做管理，去进一步推行自己的心得；反过来，当管理有余力，就应该再去做技术。

我们都想着减重，你却想着增重...
不过每次看大佬回帖都那么认真负责，手动点赞。

新的一年，相信你也会找到自己的目标的，加油。

新的一年，加油~

嗯，有道理。

测试类别的只有中级，软件评测师。高级的话没有测试相关的，一般高级考信息系统项目管理师。

有时间的话，翻翻纸质书，写写字做做笔记，更真实些。

谢谢，新的一年一起加油

在我 2014 年进入游戏测试行业之后，和大猫交流是最多的，也是我觉得游戏测试能做到这么极致和深入为数不多的人。
一些解决问题思路和管理层面的想法，的确深受启发。
期待后十年的文章。

真励志。

沙龙也不是说随便就能搞起来的，得有发起人、组织者、场地、话题等等。
只要有一个发起负责人，联系下社区应该还是能够很快落地的。

测试用例只是把需求抄一遍的测试人员，是合格的测试吗？
测试用例的本质是什么？设计测试用例的目的是什么？如果仅是简单扩充下需求，那为什么前期不把需求写完善， 测试直接对照着去做呢？
这是个问题....

一般在大版本更新时才会出具测试报告（比如从 V1.0 升级到 V2.0 这种必须要有对应的测试报告，从 V1.0.0 升级到 V1.1.0，这种最好也要提供测试报告，像 V1.0.0 升级到 V1.0.1 就没必要了）。
测试报告应该是在发版前邮件发送项目经理，产品经理，开发经理及相关责任人，告知测试结果及已知风险，证明版本内容已经过测试验证，符合发布上线标准。说句难听点的，就是发布上线后出现问题，测试要担负一定责任。
测试发版后有必要的话，需要做测试分析总结，针对当前版本的测试密度、缺陷密度做数据统计，查漏补缺，为后续测试工作做提升改善。

我还想从无锡去南京...