也可以回老家县城的事业单位或者国企继续当开发吧。我老家电厂也有 it 部门，有点技术，又有点关系，也差不多能混进去。

发现 A 佬，拜读一下佬的文章，把历史帖贴出来太贴心啦

我补充一点吧，大家都聊的是技术，但是实际上，业务倾向也是存在的。现在技术层高到不可替代的还是很少的，大多数的工作其实可替代性很强，通俗的说，大家来来回回干的都差不多，这个时候，其实业务方面会有一定的影响，比如我这个岗位其实就挺在意是否有 sdk 数据埋点的经验。楼主的在简历的项目上可以一定程度的体现业务倾向。举个例子，如果你有丰富的金融行业或者银行项目经验，那么金融行业的互联网公司就会更倾向于录用你。当然，这都是我个人的观点，仅供参考

只能说国内 AI 潜力巨大了，未来可期

外包的水平稂莠不齐，加上频繁更换人员，很难说，产品的质量能有所保证，基本上是越来越差的恶性循环。如果想要在行业较为长久的发展，也不能一直做外包，还得是去自研润。

招聘也是有周期的，第一周的面试基本都不行。客观来说，也得领导确定好公司的发展趋势，能有多少个坑位，然后，开始招人，会一直持续一段时间，等一季度中下旬的时候才开始招人比较多，也就是 3 月中下旬的时候。Q1 绩效考核这个时候人力资源就会冲绩效了，那时候面试会多的多

一、无法复现，就先记录下来，方便后续追溯。
二、你梳理一下自己的测试用例，确认是否用例覆盖完全
三、查看 bug 的时间节点是否有其他人的异常操作，可能是其他人在做了什么，只是你正好在那个节点被影响到了。bug 的根源不在于你那。

心态放平就好，没必要考虑太多。焦虑的内耗自己，不如今朝有酒今朝醉。未来的事未来再说呗

其实每个公司有每个公司的情况，考虑现实的情况，每个人的建议对楼主不一定有用，不如从根本上去考虑一些问题。比如，先考虑自身方面，流程和测试效率上能否调整改善，能不能使用某些工具，简化你的测试工作等等，再比如，交接的内容，比如开发，你可以让开发怎么样去提升双方的效率，一定是要共赢的，这样开发才会觉得你这样才算是优化，才会配合，不然根本推不下去的。开发自测，测试左移，流程简化...等等，结合业务和项目组的实际情况来考虑改善吧

阿里系从语雀到阿里云到滴滴，吃瓜不断。确实是降本增笑了

想拿大礼包找借口其实很简单吧，随便找个看得不爽的点，从领导的工作能力到性格缺陷，到生理缺陷，只要你想吵架，自然能找出一大堆的跟领导吵架的借口，就是别太厉害，把领导骂走了，你留下了。

看公司愿不愿意给赔偿以及在公司呆了多久吧，摆烂摸鱼放开一些，然后准备的差不多了，就看情况借题发挥，给几个领导吵一吵架，马上领导就给你安排裁员大礼包。拿钱走人就是了

作为菜鸡的我表示，长见识了。

实话实说，如果没有一点业务经验的话，就很难向下兼容，也很难带领团队，举个例子，你带个测试团队，团队成员有遇到问题，你业务一点都不懂，是不是不太好。特别是很多公司的测开岗位其实兼着干点工的活的，到时候换工作都不好找。所以建议还是学点业务的。

除非刻意要求，否则不会

你这个应该是业务上的逻辑问题，可能是计算逻辑的问题，也可能是边界值没处理好导致的。

客观而言，不建议主动裸辞找工作，先找下家吧

有没有一种可能 jmeter 其实不只是支持单接口。也可以支持二进制文件上传。目前你说的情况应该都可以用 jmeter 实现，当然小概率你的公司技术和业务过于复杂 jmeter 不适用，不排除这个可能性，具体的话你多搜一下吧，这个不算很复杂。

文件上传的压测的话，用 jmeter 的话，从压测角度就是高并发了，查看 tps 的极限和响应时间了。从业务上来说，就是文件的大小和格式了。然后可以设计场景来实现了具体的压测情况，比如，5 分钟内，有 10w 用户上传文件，文件大小是 1M。这个就是简单的负载场景了，总之根据需求设计场景，来简单压测一下呗。不过要考虑 jmeter 的性能极限吧。太精准的压测，jmeter 不太适合了。

作为补充的测试手段的话，挺好的。在某些场景上的作用很大。

嗯，其实两个问题我觉得有部分因素是经验不足吧，接口的取值跟其他系统相关的这部分其实是非常容易出问题的，数据格式不对，参数缺失 ，参数命名不同，需要参数映射等等，这块如果你不知道改动的话，情有可原，知道的话，这是个很明显的测试点，有变动跟之前不一样的地方，理论上应该都要检验一下吧。
至于第二个问题，逻辑上是减一的话，那 0-1，这个其实也是很常见的校验点。不过研发的这个实现逻辑上确实是让人意外，过于简单粗暴了，这个有点看个人经验了。这个慢慢积累吧