楼主说【因为是贷款领域 尽量不 mock】，不应该是【因为是贷款领域 尽量要 mock】

支持 2 楼。

1. 部署专门的自动化环境，在这个环境里搞不影响线上数据。
2. 拆解链路一点点看，最后金钱支出在哪个环节发生，就让流程去到哪个环节之前中断或拦截下来。

核心问题还是不能因为测试，导致是实际资金转移。

想想，要是你跑一次自动化，公司欠别人几百个 w，或者每次都让外部公司出人手工帮你回滚测试数据，都不用说的没办法推进。

测试思维，看书本只是让你意识到有这回事，而思维本身的历练还是要靠具体的项目，最后转换为所接触业务领域、业务形态、复杂度的 “多或少”，“高或低” 的问题。

首先，测试思维，它是一个模式化的框框，在这个框框里有固定的几个东西占位置。如功能、性能、稳定性、安全、兼容，再靠自己的经验（还是来自前面说的三个要素）去补充。经验越多，见过的奇怪问题越多，就越能举一反三，当你看到这个功能，立马会产生 “警惕性”。或者一句话，测试思维迭代需要真正的阅读量。

其次，好的测试思维，离不开对业务技术实现的理解和熟练度。如果不知道业务功能大体的实现逻辑（不需要一字一句地理解，很多时候只要猜对就行，基本也很容易猜对），涉及的上下游，用到的技术组件，也做不好边界场景的补充。

最后，对于刚工作的同学，我的建议是：

1. 测试思维有固定的模式，可以按照上述几个固定方向去穷尽业务场景；
2. 业务场景穷尽过程，要关注 “用户实际视角” 和 “技术实现视角” 两个，前者需要对业务功能有好的理解和用户使用想象力，后者需要有代码能力支撑来猜测技术实现；
3. 多找一些不同业务领域（如电商、游戏、社交...），不同业务形态（移动端、web、agent 客户端、服务端接口），不同复杂度的项目去自己尝试设计测试用例，磨练手感和思维敏捷度；

那你也试试活没干完 886 节奏，看看对进度有没有影响，大家什么反应，先别感动了自己。

【如何判断是工具本身局限性还是自己操作错误】这个经验为主吧，但一般工具清楚说明了它支持 xx 功能，然后你怎么用都无效基本就是自己的使用不当问题。

如果工具没说明，你使用有问题，以前是上外网搜搜看看其他人或者老外有没有解法，现在就直接问 AI 好了。AI 在信息搜索上是无敌的。

试试 AI 做 UI 自动化测试咯：https://ui-tarsai.com/

jmeter 也是我毕业前两年接触到的第二个压测工具，当时跑在 windows 上，有 UI 界面，只要理解几个关键的参数就能直接开始用，后面单机压力不够看了，还能换成命令行使用搞成多机。整体很适合作为性能测试接触的第一个 GUI 工作。

但是随着业务场景越来越复杂，jmeter 这些老派工具就跟不上了，一方面是 java 本身的性能极限不够高（线程模型、堆大小上限等编程语言方面的约束引入的天花板）；另一方面从命令行工具角度评价，市面上其他工具用起来感觉都很像，无非就是参数设置稍有差异；

进阶的接口性能测试，就不再是拿二进制工具单接口发压这么简单，开始关注多接口关联的场景性压测，此时可能演变为写代码调用库来更灵活地发压；

接口性能测试在大公司的终极形态，必然是平台化，此时你就脱离性能测试工具本身，不会再关注你用的是 jmeter 还是 gatling 还是 wrk 还是啥，平台会帮你解决压测机器调度、多机发压等问题，你只要告诉压测平台你要压多少 qps，压多长时间，qps 变化策略和一些动态构造的数据就行，还会额外出现压测环境、压测集群等跟公司研发体系配套的问题，人就会聚焦在 “性能测试方案” 上，返璞归真。

1. 测试周期短，测试时间少：有没有办法让研发分批提测，不要让研发全部搞完后一次性全怼过来。这里还涉及研发如何拆分需求的依赖关系，也不是说着这么轻巧；
2. 线上逃逸的接收程度：多和研发沟通变更，没有变更的地方，不回归在线上出问题可不可以接受？以这个原则去删减回归工作，可能有立竿见影的效果。和各方沟通，大胆接受线上出小问题，不然就接受一直这么累，或者跑路；
3. 低级工作下放：什么都要你一个人干，你累死；实习生永远只能点点点，别人也没积极性越干越不想干。一些只有你知道的，但也不依赖经验和判断力的业务知识沉淀成文档，一次过内部培训把大家教会，就再也不用被垃圾事情浪费时间；
4. 能力培养：在这样的环境和强度上，根本不存在能力提升一说，测试是一直是 “原地踏步 -> 人员流失 -> 放低要求紧急补充人员 -> 原地踏步” 循环，得发掘重点培养对象，建立人才梯队，做更多的工作下放；
5. 自动化：这种频繁迭代的短中期项目，我不建议自动化，最多就做一些简单的核心接口自动化，但如果解决不了人效问题那就去幻想自动化能有什么用；
6. 别全都要：有些工作是不是可以不做，或者简单做？比如各种报告是不是能简化，一些基本质量让研发保障（showcase 打回，如果测试有足够话语权）等……

1. AI 是真的能提效，对个人对老板都有收益，不要对 AI 有偏见，不要抗拒 AI 落地，要理解且拥抱，可以选择不做先锋布道者，但聪明人至少都做跟进者（有条件最好再理解一下 AI 底层进步迭代的逻辑，看论文看别人分析都好）
2. AI 在质量领域的落地实践，正被大厂迅速开发。可能再过一年半，AI 在质量中能玩的地方基本都走了个遍，那会就沉淀出和传统质量一样的质量框架/套路，大家就照着干就完了
3. 各行各业垂类领域的 AI 实践，肯定靠这个行业内的人去想，即使是传统质量也是一样，行内人是第一批知道痛点的，你可以骂你老板傻逼，但是不应该放弃思考（当然不思考也不代表什么）

能帮助好别人就好

1. 先从学习大纲入手 —— 搜索引擎搜索 + 多 AI 问学习大纲，最后自己把答案整合一下
2. 有了大纲后，明确学习先后顺序，大概画出初级、进阶路线（可以让 AI 帮忙划分）—— 基础概念优先学习，质量方向优先学习（如大模型评测，更接近测试思维，会更容易学进去），理出部分有互相依赖的概念一起学
3. 然后就是一个个学，看资料、找视频、学案例 —— 对于非严肃的学习来说，这个程度的知识储备就差不多了，如果要严肃地说，那就得看一些体系化的书籍了

那要看性能测试的人跟不跟业务，如果他们是一波独立于业务之外专职搞性能的人，不了解业务，你让他们评估也实在是为难别人（当然你可以对外沟通时给他们甩锅，看你自己怎么想）。

从我的角度看，业务最后出问题还是自己受损，你能评估到也是你的 goodcase，如果自己有能力评估还是要尽量参与。

改代码就让研发评估是否需要回归功能，但多数对自己没自信的研发为了保险起见更倾向让测试做冗余回归，这时测试人员能不能 review 研发的改动，评估改动影响大不大，要不要回归，回归多和少，就显得很重要了。

别把自己 pua 到抑郁了

先自查评审是不是复读机大会

我的评审，研发参与感都挺强，我会一直和研发互动，过重点抛问题讲测试思路，一些很常规 case 其实不需要研发 review

真实又真诚

1. 现在的岗位与你预期不符的具体是什么？是学不到新东西带来的焦虑？还是行业方向不对？还是薪资或其他问题？
2. 你能做出的改变可能是哪些？内部向上申请更多的机会？找厉害的同事学习？换一份工作？

上面的问题你想清楚，然后咨询一下 AI 估计就有思路了。

你说的这个可以归类到其他前面两种情况

在大厂里无非 3 种选择：

1. 迎合职场规则，去做对自己晋升加薪最有利的事情，不论好坏
2. 但行好事，去做自己认可价值的事情，但不一定是利益最大化
3. 老板怎么说你就怎么做，没成绩至少有苦劳，做不到结果时因为你按老板说的完全执行了 ta 也不会怪你

如果去产品位置，能得到更多的资源和空间（如人脉资源、晋升加薪空间、能力成长空间），为什么不去呢？
如果只是听上头大老板一言堂说做什么就做什么，完全没有自己的空间，也没有更资深的产品能一起协作（让别人带带），那就没必要去了。

现在的本科，北上广深杭一类的互联网大厂，校招入职就 20+k

也不能这样算，本身这个 1 里面就有水分，有潜在干到 130% 的潜力，我个人感觉只是用大模型为幌子先来榨干这一块水分（卷大家）

有自学能力和动力，苟着多学点准备好就面试走。
没自学能力和动力，就尽快离职，换个让你更有动力的工作环境。

感觉问这个问题，大概率是第二种情况，多呆一天都是浪费时间，除非生活所迫。

建议趁机看看能不能在这里转研发

有了 AI 后，无论研发还是测试，相同能力下，同一个人单位时间能完成的事情变得更多，说不卷那是假的。

同意，其实很多知识并不难，不是说懂不懂，而是知道不知道 或 了解不了解 的问题而已，只要基础没问题，脑子灵活愿意学习，有上进心，就这些东西每天都接触，一两个月都基本能掌握到独立完成的程度