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

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

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

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

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

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

除非刻意要求，否则不会

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

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

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

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

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

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

其实相对来说，我解读了部分的形象，如果言语冒犯之处，我先道歉。其实楼主就相对来说没有很亮眼，中规中矩，没出过大毛病，但是很优秀算不上，不知道是自我介绍的谦虚还是什么，但是初中级后端，前端勉强能做，这不合适在面试的时候说，其实有一个困境，就是什么都会一点，也还可以，但是不突出不够优秀。嗯，首先简历上或者面试上，请记住，要足够的自信，这个是很大的待改善点，然后第二点，35 岁的瓶颈，你跳到大厂之后，面临这个瓶颈你该怎么让自己不可替代，你的竞争力是什么呢？毕竟快 35 了吧，该考虑的后续发展真的要考虑清楚。

我觉得楼主可能更倾向于技术栈的提升吧。我还没到楼主这种情况，不过从我个人而言，我后面有所余力的话，会去关注人工智能吧，算法优化，机械学习，深度学习等等。

看起来挺有意思的，没想到居然是半年前的帖子了，一种意外发现宝藏的感觉

可能是个不太合适的建议，可以考虑考虑那种业务很复杂的公司，这种公司非常吃测试人员的经验，然后业务上比较庞大比较复杂的话，这个项目多数是需求较为稳定的迭代中的了，那么工作时间和排期都比较稳定，加班会较少。懂一点代码，挺好的，可以从底层代码去理解业务.

前面说的都很充分了，就事论事就行。如果想有更亮眼的表现，可以提出对应的问题的解决方案，比如你觉得你觉得 bug 很多，是不是提测质量过差导致的，方案的话，可以考虑需不需要提高提测标准，要求研发自测更完善之类的。不得罪人的最直接的办法就是，让别人觉得你只是在正常工作，并没有刻意针对就行。

你这也只是提出问题啊，建议再写个续集，说说改怎么样才能存到钱

其实按照这个理论还得测试这个监督测试脆弱度的系统是否可信，有点无限套娃了，不可置否。成本，规模，各方面都不一定试用。

建议你可以研究一下招聘平台上一些职位的招聘要求，然后技术栈上写一些你确实会的，一些高热度词，比如，自动化，接口，MySQL 等等（只是举例哈），因为之前招人的时候，hr 问我要怎么样的人，我就会说，要会自动化，要会点性能，代码 java 或 Python 至少会一项，...在我这一系列的条件下，不满足条件的就会直接筛选掉了，所以，其实你的简历第一步要给 hr 看的。你得先过 hr 那关。

自动化不适用于快速迭代的项目其实这个大家应该都是公认的吧，特别是需求不明确的项目初期，UI 自动化的成本巨大，我都不太理解这个时候就进行 UI 自动化的目的是什么。我倒是建议前期约束研发交付的时候交付文档规范，以及产品改动需求的每次争议都留存好，相信我，你不会愿意，中途产品质疑测试为什么没发现实现的功能与需求不符合（这个改动是产品要求的但是产品不记得了！）。总之，做好所有的记录。其次标题确实太过了，不要和开发做朋友这个太标题党了。