下午三点，我旁边的张工又打开了B站。

他面前三个显示器，一个在跑自动化脚本，一个在放番剧，还有一个屏幕上，测试用例正一条条自动生成。他只需要偶尔点一下“确认”。

上个月绩效考核，他又是A。

而组里另外两个手工测试的兄弟，加班到晚上十点，bug 单还是被开发打回来一半。

不是张工天赋异禀。他只是把那些别人还在手工硬扛的事，偷偷交给了几个 AI 插件。

这些插件不算秘密，但真正用起来、用对的人，并不多。

目录

一、表面上的“躺平”，暗地里的效率碾压
二、不是测试不行了，是测试的逻辑变了
三、拆解：五个插件到底在替测开做什么
四、一组真实数据的对比，看完你会沉默
五、怎么把这些能力装进自己的流水线
六、最后一个问题

一、表面上的“躺平”，暗地里的效率碾压
2025 年这半年，招聘市场给测试端的信号很撕裂。

一边是 HC 冻结、手工测试岗大幅压缩，大量只会写用例、点点点的人开始慌。另一边，懂 AI 工程化落地的测试开发，薪资反而被抬了上去，很多团队开出 30k 都招不到合适的人。

本质上，不是岗位消失了，是岗位的内涵被重写了。

以前测开的护城河是“我会写自动化框架”“我能搭 CI/CD”。现在大模型出来之后，这些事本身也开始被自动化。能活下来的，是知道“该把 AI 放在流水线的哪个环节”的人。

我见过的那些“偷懒”偷出高绩效的人，都有一个共同点：他们把体力活甩给了插件，把判断力留给了自己。

二、不是测试不行了，是测试的逻辑变了
传统的测试工作流是一条直线：需求评审、写用例、造数据、执行、报 bug、回归。

这条线上，至少有 40% 的工作量是高度重复且规则明确的。

重复意味着可被工程化。规则明确意味着可被模型学会。

五年前我们要花大量时间写脚本去处理这类问题，今天很多插件直接用大模型在语义层面解决了它。表面上看是“工具升级”，实际上是测试活动从过程密集型转向判断密集型。

再直白一点：如果你的工作里全是执行，没有判断，那你本身就是被优化的那个环节。

那些月薪 30k 的测开，心里都清楚这件事。所以他们不是用 AI 来写几个测试用例，而是用 AI 重构了自己的工作流——把“做测试”变成了“设计测试系统”。

下面这五个插件，就是他们重构工作流时用得最多的几个。

三、拆解：五个插件到底在替测开做什么
这里不写软文，不讲“一键搞定”的童话。我们从工程视角看它们到底干了什么、怎么干的、解决了什么问题。

1. 用例生成插件：不是套模板，而是语义映射
   市面上的 AI 用例生成工具，最早那批其实是高级模板填充。你把 PRD 贴进去，它给你拆成前置条件、步骤、预期结果。这有用，但价值有限。

真正被高手用起来的那种插件，多走了一步：语义映射 + 存量召回。

比如你有一个历史用例库，里面几千条用例都已经评审过、有质量标签。插件在生成新需求用例时，不是凭空编，而是先把新需求做向量化，从库里召回语义最接近的历史用例作为 few-shot，再喂给大模型。

这样做的好处：生成的用例风格和团队规范一致，边界值、异常流程不会丢，review 成本低。

这个流程的核心不是模型，而是把团队资产变成生成约束。少了这一步，AI 生成的用例再多，也是废纸。

2. 数据工厂插件：造数据的本质是造约束
   造数据这件事，痛点从来不是“随机生成”，而是“生成的数据必须满足复杂业务约束”。

一个订单系统，用户等级、优惠券类型、库存状态、支付方式之间有隐藏的联动规则。传统方式要写大量工厂脚本，维护成本很高。

现在有些插件直接让大模型去学习这些约束关系。你给它几个真实的表结构、一个业务规则描述，它就能生成符合约束的大批量数据。更进一步的，它会自动构造边界组合和异常链路。

实际上，这是在用模型去逼近一个隐式的约束求解器。

3. 脚本自愈插件：让自动化活得更久
   UI 自动化最让人头疼的问题：页面改了个 class，脚本就挂了。

传统做法是靠显式等待、智能定位策略去扛，本质上还是人提前定义好容错规则。

现在有些插件做的是“意图定位”。脚本不是记录 xpath，而是记录“找到那个写着‘提交’的按钮”。执行时，插件实时分析 DOM 树和视觉信息，基于语义重新定位元素。

这个变化很小，但影响巨大：维护脚本的时间可以下降 60% 以上。

UI 自动化的未来，不是让脚本更健壮，而是让脚本不再依赖脆弱的定位器。

4. 性能根因分析插件：把专家直觉工程化
   线上出性能问题，经典的排查路径：看监控、翻日志、查慢 SQL、分析调用链。这个过程高度依赖个人经验，一个资深的老哥可能凭直觉就知道是哪个服务出了问题。

现在有些插件在干的事，就是把这种直觉工程化。它们接入 Metrics、Trace、Log 数据后，用大模型去关联多模态信号，自动给出根因推断和止损建议。

核心在于，它不是替代你的判断，而是把需要跨多个系统核对的信息，在一分钟内替你完成了。

5. 缺陷智能分类与去重插件
   大一点的测试团队，一天收几百个 issue，其中三成可能是重复的，或者分类是错的。

这类插件做的事看起来简单：自动识别重复 bug、自动分配模块和优先级。但实质上，它把 bug 管理从“信息流转”变成了“信息治理”。

这些插件，有个共同特征
你仔细看这五个插件，会发现它们没有一个是“替代测试人员”的。

它们替代的，是测试人员过去被迫要做的那些机械劳动：搬数据、翻日志、修脚本、填模板。

AI 不是来替代测试的，是来替代那些只会执行用例的测试的。

四、一组真实数据的对比，看完你会沉默
说个我看到的案例。

某项目中台团队，原本三个人专职写测试用例，两个星期才能覆盖一次大版本的核心流程。引入用例生成插件和数据工厂后，同样三个人，同样的周期，覆盖范围扩大了 3 倍，还把异常场景用例补了进来。

更有意思的数字是：他们花在用例 review 上的时间反而变多了。

因为 AI 把制造的时间省下来之后，人终于有精力去做真正的质量分析了。这不是摸鱼，这是把时间花在了更有杠杆率的事上。

你加班两小时只能多跑 30 条用例，别人用 AI 十分钟跑完，剩下时间在研究哪些用例才值得跑。

五、怎么把这些能力装进自己的流水线
插件的原理不复杂，但落地一定会碰到现实问题。

第一个问题是信任。你敢不敢让 AI 生成的用例直接上线？答案肯定是不敢。所以必须是“生成 + 人工确认”的闭环。上面流程图最后那条反馈线，才是关键。每一次 review 修正的结果，都要回流到 prompt 或知识库里，不然模型不会有进步。

第二个问题是标准。你们的用例规范、缺陷分级标准，是不是能被结构化描述？如果这些规范还停留在“老员工脑子里的经验”，那用 AI 插件就是灾难。你得先把知识工程化。

第三个问题是时机。我不建议一上来就全面铺开。选一个痛点最明确的环节，比如数据造数或者脚本维护，把这个场景跑透，跑出数据，再扩面。务实的工程判断比追逐新工具重要得多。

六、最后一个问题
写这些，不是想推销什么课或者工具。只是我看到太多测试同行，还在用 2019 年的方式拼命，以为努力就能解决问题。

现实是，你执行的效率再高，也高不过一个能并行生成几千条用例、24 小时不休息的模型。

所以，最后只留一个问题，值得你花时间想一想：

你现在的测试工作里，到底有哪些环节，其实是在“按规则执行”，而不是在做“质量判断”？把这些环节列出来，然后去找对应的工具。

本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。