先看你需要测什么方面的安全。

通用简单的 web 安全问题（如有安全风险的 web 配置，和一些简单的漏洞），有好多现成工具能拿来扫描，但效果可能不怎么样。比如：https://github.com/greenbone/openvas-scannerhttps://github.com/sqlmapproject/sqlmap，

业务性质的安全漏洞，都是靠经验去挖掘，依赖对业务场景和安全漏洞的理解，这种市面上没有工具，只能靠技能。

9 年 3 跳挺正常，平均 3 年换一家，不会是被诟病的地方。

现在呆的公司，从你的描述看，已经达到了个人各维度的天花板，薪酬空间、管理空间、技术空间都没法再上升，最重要的是公司业务发展也到达天花板，那接下来就不进则退，不突破可能或许会慢性死亡，劣势明显。

新的公司，管理空间没有质变化但至少有量的变化，有熟人关系对自己保护更好，最重要的是有新的技术空间，符合 AI 大趋势，公司还在上升，过去就有机会水涨船高吃到红利。

所以综合对比，当下是不进则退，过去短期有量变长期可能有质变。我认为可以跳。

这个要看业务的，不同的业务不可能拉在一个线上对比。就比如 toB 业务，7% 的逃逸率估计算一般或略差；但是对于 toC 尤其是带开发者开放属性的业务，逃逸率 10%+ 是正常的，因为长尾场景多得数不来。

而且问题逃逸也不一定代表什么，毕竟逃逸风险有高有低，同时，当下的测试资源和业务阶段也是影响逃逸率的重要因素。

故，你要找到同领域同类型（最好还是阶段类似）的业务去对比。

我不是在抖机灵，你可以这么尝试观察情况。
一来你又没体现要找上级反馈工作量超载问题，二来你又要默默吞下所有，最后让大家支招，那就只能这样试试上级的反应。有没有一种可能是，有些活 delay 了也没有影响，当然这只有你自己才能判断。

印象中好像是 hw 第一次说的

在工作刚开始的前两三年，我认为市场不会因为你之前做过什么，而敲死你以后只能做什么，所以我鼓励【尽管去野蛮生长，找到你喜欢的长期方向，不要被你当下从事或者即将从事的工作所束缚】。

新同学经常有类似的疑惑：“完蛋，我天天搞测需求，写自动化用例，同样是 QA，我怎么跟哪些造工具造框架的 QA 比？！！”

我的回答是：

1. 早期更关注你做事情的复杂度，而不是你从事的方向；知识和技能是可以迁移的，写测试用例也是开发，写测试框架也是开发，写 Linux 内核还是开发，只不过不同的事情其复杂度不一样，对领域知识、投入度和思考强度的挑战不一样；
2. 视野不要局限在代码开发，不要认为搞框架搞工具就是厉害。在业务需求里，通过跟不同研发交流，主动去读代码，理解业务，理解架构，其实思考强度一点都不低。如果做到前面说的，我认为已经超越 90% 的测开。我想表达的是，线下交流是极度重要的，你在业务里能接触到形形色色的人要远多于测开，在业务的优势就是交流合作机会很多，要尽量善用。
3. 校招面试一样的道理，不会因为有 “测试框架项目” 就一定更有优势。先扪心自问，你做的 “测试框架” 是不是玩具一个，真的复杂真的能用吗？你真的了解生产环境的测试诉求吗？为什么不去面待遇更高的开发岗位呢？所以，无论是 “测试框架项目”，还是什么其他东西，本质上都是面试敲门砖，简历加分项，只要体现你做的项目的复杂度就好了。所以，简历里有 “测试框架项目”，面试 QA 岗位会有优势是伪命题。

找 bug 不是最难的，如果你有实际项目开发经验，项目越复杂就越有优势（也就是你的 demo 越复杂越好）。
如果我是测试经理，我会优先找技术开发能力更强的，从开发转测试更多是视角和习惯转变，而测试转开发有明确技能门槛是更难的事情。

楼主说【因为是贷款领域 尽量不 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 也不会怪你