去年底和几个测试同行吃饭，聊到一个很直接的话题：AI时代，测试工程师还能活多久？
三个人的回答完全不一样。一个说“测试要被团灭了”，一个说“反而更值钱了”，还有一个沉默了十几秒，说“我不知道”。
这不是段子。这是2026年每天都在发生的真实对话。
一边是“一人公司”浪潮里，创业者对着三个窗口——写需求的AI、写代码的AI、跑测试的AI——三个月从零做到上线，全程没有出现“测试工程师”这个职位。另一边是行业报告显示，2026年AI能覆盖六成左右的常规测试任务。信通院的数据更直接：全球70%的企业测试用例已由AI生成。
但真正让人后背发凉的，不是“AI能生成测试用例”。
而是AI开始自己“探索”了。
目录
一、手工“点点点”正在失效——不是被替代，是被绕过
二、探索性测试的本质变化——从“人的直觉”到“模型的世界模型”
三、AI怎么“探索”一个应用——三层架构拆解
四、一个真实对比——同样一个应用，人和AI各自发现了什么
五、工程落地启示——你现在就该做的三件事
六、一个留给你的问题
一、手工“点点点”正在失效——不是被替代，是被绕过
先讲清楚一件事：AI做自动化测试不是新闻。2023年就有。
但2025年到2026年发生了一个质变。之前AI在测试里干的是“辅助”的活——生成用例模板、帮忙写脚本、分析日志。2026年，AI从“辅助”走向了“主导”。
什么叫主导？不是帮你想测试点，是它自己去测。
Thoughtworks在2025年的技术雷达里提到，AI驱动的UI测试主要集中于探索性测试。到了2026年，主流的UI测试框架Playwright和Selenium都已经引入了各自的MCP服务器，让AI Agent可以直接驱动浏览器做探索。
npm上出现了breakit这样的工具——一个命令行工具，驱动真实浏览器遍历你的应用，发现UX问题、功能bug、流程混乱、控制台报错和安全信号，然后给你可复现的操作步骤和证据。还有explorbot，描述写得特别直接：“像一个最执着的QA工程师那样点击、填表、找bug”。
不是脚本化的回归测试。是探索。
脚本化测试验证的是你“已经想到”的路径。探索性测试找的是你“没想到”的。
AI现在在干后面这件事。
二、探索性测试的本质变化——从“人的直觉”到“模型的世界模型”
要理解这件事的严重性，得先搞清楚探索性测试到底是什么。
传统的探索性测试，核心是“边学边测”。测试人员没有预设脚本，一边探索应用一边发现缺陷。这依赖两样东西：测试人员的经验和直觉，以及“人”对这个世界的基本理解——比如一个登录框，正常人会怎么用？会输什么？会怎么绕过去？
AI现在能做到同样的事，但路径完全不同。
它不靠“经验”，靠的是大语言模型对“世界”的理解。一个训练充分的模型，看过几亿个网页、几千万个应用界面、无数种用户交互模式。它知道一个表单应该怎么填、一个按钮点了之后应该发生什么、一个流程走不通的时候用户会怎么反应。
本质是：它不是在“执行测试用例”，它是在“模拟一个合理的人会怎么用这个软件”。
2026年ACL Findings上发表的GUITester论文把这个逻辑拆得很清楚。多模态大模型在导航上已经很强了，但之前一直卡在两个问题上：一是“目标导向掩蔽”——模型太专注于完成任务，反而忽略了中途发现的异常；二是“执行偏差归因”——系统出了bug，模型会误以为是自己的操作错了。
GUITester的解法是把“导航”和“验证”解耦。一个模块负责探索和操作，另一个模块专门负责判断“刚才发生的事情是不是问题”。F1-score达到了48.90%，远超基线模型的33.35%。
核心洞察：AI做探索性测试，不是一个模型干所有事，是多角色分工。
三、AI怎么“探索”一个应用——三层架构拆解
工程上，目前主流的AI探索性测试工具基本遵循同一个架构模式。拿explorbot举例，它的工作流是这样的：
第一层：Research（研究）。给AI一个URL和一个目标，它先把页面切成不同的功能区域，索引每一个可交互元素。不需要源代码，不需要文档，纯靠视觉和DOM理解。
第二层：Plan（规划）。基于对页面的理解，AI自己起草测试场景——正常的、好奇的、边缘的，三种风格同时进行。
第三层：Execute（执行）+ Verify（验证）。驱动真实浏览器一步步操作，过程中实时适应应用的变化。每发现一个问题，就做根因聚类、截图、录屏，然后把通过的流程保存成可执行的测试脚本。
注意几个关键设计决策：
策略是确定性的，战术是AI驱动的。什么意思？整个工作流（研究→规划→测试）是固定的、可预测的。但具体“怎么点这个按钮”“弹窗出来了怎么办”“操作失败了怎么恢复”，这些是AI实时决策的。
便宜的模型干活，聪明的模型做决策。实际执行点击和读取的Agent用便宜的模型跑，决策层只读短操作日志，用聪明模型也不贵。一个完整会话的成本是“美分级别”。
每次运行都会学习。同一个页面跑得越多，决策越快越准。这已经超越了“自动化”，进入了“自主进化”的范畴。
breakit的设计思路类似，但它更强调“角色扮演”——不同的探索策略本质上是不同的LLM驱动的Agent，每个有自己明确的目标、风险等级和关注点。比如有的是专门“虐待”表单输入的，有的是模拟低技术素养用户的，有的是在移动端视口下操作的。
这些不是随机乱点。每一个策略都在追求自己的目标，在覆盖完关注区域或用完操作预算后停下来。
四、一个真实对比——同样一个应用，人和AI各自发现了什么
说个我去年亲眼看到的对比。
一个中等复杂的SaaS产品，有个多步骤的表单流程——大概7步，每步有验证、有条件分支、有文件上传。团队手工做了一轮探索性测试，一个资深QA花了两天，发现了大概20个问题。主要是边界值、文案错误、个别流程卡死。
然后用一个AI探索测试工具跑了同样的流程，4小时，发现了47个问题。
数量不是重点。重点是类型。
手工测试发现的问题集中在“预设路径”上——测试人员按照自己对产品的理解，走了主要路径和少量分支。AI发现的问题里，有相当一部分是“正常人不会这么走，但某个真实用户可能真的会这么走”的路径。
比如：在第三步上传了一个超大文件、第四步退回第二步修改、再回到第四步时状态错乱。比如：用极慢的网络完成前两步、然后突然加速、缓存状态和服务器状态不一致。比如：在移动端和桌面端之间来回切换设备、浏览器状态残留触发的异常。
手工测试不是想不到这些场景。是时间不够，精力不够，覆盖不了。
AI可以24小时不停地跑。它不累，不烦，不会因为“这个路径太绕了”就跳过。
这就是差距的本质：人受限于注意力和体力，AI受限于算力和token预算。而算力在降价，token在变便宜。
五、工程落地启示——你现在就该做的三件事
说几个实际的判断。
第一，别跟AI拼“覆盖”。
手工测试的核心价值从来不是“覆盖了多少路径”。是“判断什么值得测”。AI可以一天跑几万条路径，但它不知道哪条路径对应的业务风险最大。这一点目前没有改变，短期内也不会改变。
测试人员的角色正在从“执行者”变成“策略设计者”。你不需要再花大量时间手动执行测试，但你需要花更多时间定义：AI应该重点探索哪些区域？哪些发现是真正严重的？哪些可以忽略？
第二，把AI探索测试当成“新增层”，不是“替代层”。
单元测试测函数，端到端测试测固定路径，探索性测试测“没想到的”。这三层目前是互补关系，不是替代关系。
AI探索测试不会取代你的回归测试套件——它覆盖的是回归测试覆盖不到的东西。它也不会取代手工探索性测试——它更像一个“先遣队”，先跑一轮把明显问题筛出来，然后测试人员把精力集中在确认、深挖和判断上。
第三，现在就开始积累“测试知识库”。
AI探索测试工具的效果，严重依赖你对它的“调教”。explorbot允许你通过纯文本的领域提示来引导它。你告诉它“这个应用的支付流程特别重要”“这个模块历史上出过三次数据一致性问题”“这几个页面不要乱点因为会触发真实邮件”，AI的探索效率会完全不同。
未来的核心竞争力，不是你会用哪个测试平台，而是你如何定义AI的输入和校准AI的输出。换句话说：你不需要会训练模型，但必须会“教”模型怎么测你的产品。
六、一个留给你的问题
AI探索测试已经在改变这个行业了。
它不是“会不会来”的问题，是“已经来了，你团队用上没有”的问题。
但有一个更深的问题，我到现在没有找到确定的答案：
当AI可以自主探索、自主发现、自主生成测试脚本的时候，测试工程师的“判断力”——判断什么值得测、什么算问题、什么可以放行——这个能力，AI什么时候能学会？
或者说：你现在的测试流程里，有没有一个环节是AI暂时替代不了的？那个环节是什么？
本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。
