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

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

除非刻意要求，否则不会

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

学习动力不足我觉得最大的就是生活还算过得去，而且没有更进一步的渴望了。如果有自己很想要的东西，那么你已这个为契机，就会有动力了。一直想着它，慢慢来吧

这个其实就是告诉我们，不能相信研发，研发的话可以参考，但是测试得按自己的节奏来，数据迁移的结果从测试角度，思考，其实很容易就可以分出三种情况，数据迁移完善，数据迁移失败，数据迁移部分成功，然后再考虑怎么判定数据迁移不成功就行了。然后就比较容易发现问题了。
另一个就是接口的问题了，这个功能对应的接口测试不够充分，入参不完整的情况下，接口测试不充分，上线后发现 bug，发现是测试不充分导致的，测试确实要背锅，无可厚非的

功能测试的本质是对业务的理解和自己的看法，可以多看看同事的用例或者 bug，你会惊奇的发现，居然还能这样发现 bug，其次就是测试的范围自己决定，可以参考研发的意见但不能相信研发，该测的都要测..

问题点很多，如果年轻一点我建议你尽早跑路，但是也考虑到你年龄在这块，给自己入职一年之内的适应，如果还不能有比较显著的提升，那就赶紧跳走，因为你这就相当于是泥潭了，只是把你陷死了。