结合 1 楼 2 楼的方法，最后甩给产品和 UI 走查，做兜底

一方面的体面的拒绝，另一方面，协作能力强和对业务深度思考，可能是跨部门人员的协作以及深层业务逻辑的关联了。举个例子就是，一个项目，可能存在多个需求方，比如功能上的，风控上的，后台中台，数据分析等多部门都对公司产品有一定的需求，如何协作，深层业务逻辑的关联，举例，功能上的改动，风控上的改动等会关联影响到其他部门的需求么，会影响功能么？就举个例子哈，仅供参考

回老家，拿个事业编。找点关系，把编制坑位先给占了，然后花点时间考过笔试就行了。

分功能层级，核心功能和主要功能以及次级功能，然后根据业务划分测试范围，减少不必要的测试量。同时搭建自动化流程，减少重复性测试。有权限的话，，看开发提交记录，回归起来也会更具体一些。但不完全，因为核心功能该看还是得看，这里还是得自动化比较好

多做，多总结，多思考，多实践

出了二楼说的两种之外，第三种就是家里那边的国企或者事业单位，还是有计算机岗位的需求的，家里有点关系的话，可以考虑进编。虽然工资肯定跟大城市没得比，但是事少离家近。也算是一种出路

国企的话，其实就是走领导层向上发展了。简单来说，就是趁着还年轻，在国企里多往上爬一下，爬到个主管或者副总级别就很不错了，剩下的就是分清楚工作和生活，多照顾照顾家庭，工作不出错，顺顺利利到退休就行了。

不太建议，培训班教的与实际工作中脱节的比较多，大多数困难还是实战的时候才能了解，一个花架子，还是得实践经验。就拿自己手上的项目做一下性能测试实践会很合适

建议检查一下链接是否是通的。