如果要用户体验好，肯定得和目标系统耦合在一起，不一定是什么前端，可能就直接是后端把 ai 整合在一起调用了。

【这整个搭建过程复杂吗？一个人再通过 AI 大概多久能完成呢？】这个问题太 case by case 了，没法回答

写简历要点其实不是极繁，而是极简（前面很多网友都是一样的反馈 “太长看不下去”）。
如果不得不凑字数，也要凑些有价值的能聊清楚的内容，不然就自己给面试的时候挖坑了。

不是的，在某个 AI 聊天框上的问答模式显然没法满足，体验割裂的同时也没有上下文一说。都是通过 api_key 调模型接口的。然后固定好提示词，以及一些业务资产的输入。

是的是的，一看就是有真实践的哥们。

确实除了业务知识库，业务的一切资产也是尽量精简一些喂给 AI，包括业务代码、业务配置、业务文档等。

这里面比较蛋疼的是，往往很多东西都跟公司内部平台绑定，很多概念性的东旭需要让 AI 先知道；另外发展快的业务用起来确实极差，目前相对更适合迭代成熟，需求偏向在原有功能上改的类型（而不是起全新功能的需求）

测试分析和测试用例做绝对没错，但是很需要足够的知识库和上下文，不能让 AI 太发散，范围要约束好（第一个坑就是上来就让 AI 对通用需求提供通用用例，应该是具体某方向的需求提供某些具体维度用例）。我们内部也有实践，虽然也是效果很差，但我判断是提示语设定的 AI 工作目标太发散 & 业务知识库匮乏的原因。这些短板慢慢补上去之后，肯定会越来越好。

再给一些建议，改完之后的版本，在简历中还是处于 “写得差” 的段位。

1. 专业技能就只体现技能，不要把工作数据收益混在里头（如第 6 点），显得很没逻辑
2. 第 1、2、3、4、5、8 这些点实话说，基本都是通识基础要求，单独写出来也没什么实质性内容，建议直接合并为一到两个点。比如我问，你白盒测试有什么技巧，或者就直接问你 Spring 框架的一些工程实现，能答得上来吗？

问题 & 建议

1. 开篇的专业技能非常震撼，极度啰嗦凑字数，有效信息极少 —— 写得长不是加分项，是减分项；同类项合并，每一个点控制在一行或一行出头，点控制在 10 个之内，最好 5 个内。【为什么是 10 个/5 个，为什么是一行，就是格式舒服与信息量的权衡，无科学依据】
2. 项目细节，也是极致体现 “极繁” 论述的风格 —— 显而易见大家懂的都懂的东西就不用写，写出来反而是凑字数嫌疑，显得没料。如【从 0 到 1 建设自动化测试体系并接入 CI 门禁：接口自动化覆盖元数据/发布/权限/数据元等……】，修改打样：

从 0 到 1 建设自动化与 CI 门禁：接口自动化 300+ 用例覆盖 xx% 核心功能，UI 自动化 30+ 用例覆盖 xx 核心链路；CI 接入自动化，回归周期 5 天->3 天，回归人力 10 人日->7 人日。

其他的，如此类推，是有技巧的。

1. 关键收益数据要通过格式凸显，不要和冗长的文字糅杂在一起，别人很难找
2. 太业务的细节，留到面试再聊，往简历上堆叠是总结能力欠缺或没料的表现
3. 行业通识的东西，就不要复杂化，大家都理解，别把面试官当傻子
4. 内容量不是关键，第一要义是让别人看简历觉得很舒服，一下子抓到要点，可以给你打上你想要的标签
5. 最后，无论是什么级别的人，简历最好控制在 2 页内（特殊 case 另说）

我们组的思路是在研发自测大背景下，帮助研发自测得更快更好。

1. 对于已有的用例，从不同类型的风险视角，评估哪些用例要留下，哪些可以去掉
2. 结合现有的各种自动化、监控报警、专项兜底，第 1 步中留下的用例，是不是还能进一步删减
3. 最后剩下的少量用例，是否除了执行本身外，还需要关联去建设自动化、监控报警、专项兜底等，给出执行和建设引导

上面是用例评估的，结合用例生成，自测留痕、bug 验证，就都闭环在一个质量平台下了，最后结论是 QA 自己把自己干掉

https://testerhome.com/topics/43564

非常的广告

身边的环境正在这样变化，仅供参考：

1. 产运：AI 重塑业务
2. 研发：AI 提效编码开发、Code Review、监控报警（主要还是编码开发）
3. 测试：AI 提效测试文本/自动化用例生成、质量风险评估、用例执行，并大量人员开始转型大模型评测

蚂蚁招聘，简历投到个人 qq 邮箱？建议贴企业邮箱

公司质量高层求变，核心逻辑还是降本，反正已经陆陆续续有人头顶上的剑掉下来了

我在的公司基本全民 AI，产品研发测试都是在 AI，其实绝大部分人就是拿着锤子找钉子，无论什么方向都尝试用 AI “重塑”，这个思路是没问题的。

但正因为这个思路是很普遍，所以越是容易想到的想法就越多人挤，AI 的出现让很多问题似乎变得不再复杂了，但复杂度并没有消失，多数时候是从工程复杂度转化为给 AI 多维输入的复杂度。

同时一个错误的方向是，很多人想着靠 AI 一把梭把问题全解决了，但 AI 幻觉永远存在，AI 不会懂它没学过的东西，外部一定要尽量把可以确定的东西做成确定性，不要每次都让 AI 玄幻解决。

回到 AI 生成用例这个方向，可能是作为 QA “拿着锤子找钉子” 的前三个冒出来的想法，就类比研发第一个想到 “ AI 能不能根据需求文档直接生成需求所有代码” 一样，太广太泛，以至于第一眼让人以为很容易做而放松警惕（的确撸一个原型可以说毫无难度），实际上是非常难做的。

为啥难做？大家想到的是喂给 AI 需求文档，技术文档，进阶一些地再喂研发需求代码实现，但本质上，AI 不知道你的测试环境（有什么工具、用什么平台）、用例规范、功能历史上下文、业务特性……本质上就是 context 不够，所以【AI 生成用例】我个人感觉步子太大有点扯蛋。

但从始至终，基座模型还是会越发强大，下限越来越高，哪一天 AI 确实能一步到位生成用例了，咱们就失业了。

那也还是很多方向，但是有没有效果现在还无法评价。

如果我们锁死质量这一个狭隘的领域，你就去回忆一个需求从线下到线上都需要做什么质量活动呗。那用例设计、测试 case 编写只是线下最前置的一环，你要是把视角往后挪就能把思路打开。比如风险评估、自动化、监控兜底等。

需求风险评估方向，需求跟版/上线时风险是否可控，就可以从功能、性能、稳定性、安全、兼容、业务特性下手；随便举个例子，比如 app 启动主链路的代码有没有变更，会不会直接导致 app 启动时长变长，这就是很明确很单点的落地。
自动化方向，大模型把现有用例自动翻译为自动化，大模型生成自动化，大模型修复自动化，这些都是很容易想到的。

诸如此类吧

除非有什么特殊要求，不然首选第一种；接口自动化用例需要有原子性，每个 case 只测一个东西，保持简单

AI 不是最擅长代码吗？那就 AI 来写测试平台，什么最基础的 CICD、造数、抓包、用例管理都能用 AI 做

下班回家，业余多学点技术，用免费 AI 搭建一些项目原型。

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

通用简单的 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 越复杂越好）。
如果我是测试经理，我会优先找技术开发能力更强的，从开发转测试更多是视角和习惯转变，而测试转开发有明确技能门槛是更难的事情。