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

通用简单的 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 节奏，看看对进度有没有影响，大家什么反应，先别感动了自己。