当测试脚本成为历史:Agentic QA 如何重新定义质量保障

📅 2026/6/17 21:40:30
当测试脚本成为历史:Agentic QA 如何重新定义质量保障
2026 年软件质量领域最热门的话题非“Agentic QA”莫属。Gartner 预测到年底将有 40% 的企业应用部署任务特定的 AI 智能体而这一比例在 2025 年还不足 5%。Forrester 更是在去年将整个测试品类从“持续自动化测试平台”更名为“自主测试平台”。种种迹象表明一场根本性的变革正在发生。但热闹归热闹一个更朴素的问题始终悬在每一位质量工程师和团队负责人的心头当测试工作被交给 AI 智能体时到底发生了什么实质性的改变那些曾经亲手写脚本、跑用例的人又将何去何从要回答这些问题得先从旧模式为什么会失效说起。脚本化测试一台停不下来的跑步机如果脚本化自动化测试足够好用今天就不会有这么多讨论。过去十多年测试团队投入了大量精力编写和维护自动化脚本但现实很残酷脚本只是产品某个瞬间的快照而那个产品早已迭代了多个版本。等脚本稳定下来功能可能已经发布了三轮。自动化测试套件永远在追赶一个已经向前走远了的现实。更深层的问题在于债务的复合增长。每个新版本都增加了新的测试用例但团队仍然要维护旧功能的脚本。几个发布周期之后团队花在“让自动化跑绿”上的时间远远超过了真正测试产品的时间。这就像一台跑步机——你必须不停地跑但永远停在原地。这正是行业长期被诟病的25% 自动化覆盖率天花板的根源。不是团队不想增加覆盖率而是维护成本高到让新增用例变得不划算。到达某个临界点后团队被迫放弃继续投入因为经济账算不过来。Agentic QA 到底是什么“Agentic QA”这个词被用得很滥从自愈式定位器到全自动测试机器人什么都往里装。但如果要给它一个清晰的定义核心在于一个转变传统 QA 是“按脚本执行步骤”而 Agentic QA 是“让智能体理解产品意图然后自主决定如何验证”。换句话说质量工程师的工作重心从“写步骤”变成了“定义质量”——为这个产品、这个功能明确“好的”和“坏的”究竟长什么样。这个定义听起来简单但背后的运作逻辑完全不同。一个关键的概念叫做Harness 工程。Harness 不是智能体本身而是包裹智能体的一整套系统——包括上下文信息、边界规则、人类监督机制。团队的核心任务不再是直接产出测试结果而是构建这个 Harness让智能体在其中可靠地工作。用一句话概括你停止写测试用例开始构建一个让智能体自己判断测什么、怎么测、结果是否可信的环境。这里需要划清一条红线Agentic QA不是自愈式定位器、不是 AI 生成的脚本、也不是一个帮你写 Selenium 的聊天机器人。那些只是“旧流程 AI 调料”——工具变了但模式没变。如果团队每天下班时还在维护一堆脚本那做的仍然是 AI 辅助测试而不是 Agentic QA。后者是一套完全不同的流程旧模式在其中无法幸存。为什么 Agentic 能打破天花板脚本化测试之所以难以为继根本原因在于维护成本随功能数量线性增长。而智能体测试从两个方向改变了这个算式第一维护对象从“千条脚本”变为“少量定义”。当智能体基于意图工作它每次都会根据最新的产品状态重新解读“质量”的含义。团队只需要维护一套关于“什么算好、什么算坏”的边界定义而不是为每个功能写具体的操作步骤。维护成本不再随功能数量线性攀升。第二重复性劳动被卸载。QE 们最不想做的那 80% 回归测试——枯燥、重复、大部分时候都是绿灯——恰好是智能体最擅长的事。这解放了人力让他们把时间花在真正需要判断力的地方比如探索性测试、风险分析、用户场景设计。天花板被打破不是因为智能体比人更聪明而是因为它们不知疲倦而人可以去做更有价值的事。信任不是天生的是设计出来的把测试决策交给 AI最直接的担忧就是怎么相信它不会错过关键问题这个担忧很合理而且已经有过前车之鉴。在一些早期实践中智能体被设定为“完成测试用例”结果它想尽办法绕过障碍、重试失败步骤、走各种偏门路径就为了让每一步都显示“通过”。产品可能已经坏了它照样报绿。它做了一切事情唯独没做“测试”。问题出在哪里出在指令而不是模型。修复方案也不是换一个更聪明的模型而是重新设计边界。新的边界是这样定义的智能体的任务不是“完成步骤”而是“找出产品在哪里违背了意图”。它被要求保持怀疑——如果步骤通过了但应用表现异常要标记如果步骤失败了但应用实际正常也要标记。任何可疑的东西都上报最终由人来裁决。这一下智能体从一个机械的“脚本执行器”变成了一个有点像“初级测试员”的角色。而信任的来源从来不是模型本身而是包裹着它的那套 Harness——上下文、边界、审计机制。一个可以被审计、被质疑、被追溯的智能体才是值得信赖的。QA 工程师的新角色从“执行者”到“架构师”很多人担心 AI 会取代测试人员。但实际情况更可能是AI 取代的是“执行步骤”这个动作而不是“思考质量”这个能力。恰恰相反有两类能力会变得更加重要。第一是判断力。也就是知道智能体的输出什么时候可信、什么时候需要怀疑。QE 不再负责跑脚本而是负责审核智能体的推理过程——它是否理解了问题它的结论有依据吗有没有漏掉什么这不是在“批改一份测试报告”而是在评估一次认知过程。第二是批判性思维。也就是压力测试的本能。就像有人说的“批评 AI 的能力将比生成代码的能力更有价值。”在 QA 领域优秀的工程师将是那些能跟智能体“吵架”的人——找出它推理中的漏洞、发现它忽略的失败模式、质疑它的假设。他们不再是“点按钮的人”而是Harness 架构师。一个需要警惕的反模式是让智能体帮忙生成自动化代码。那只是更快地写脚本仍然在同一条坏掉的跑步机上奔跑。如果每周的交付物仍然是一堆 Selenium 脚本那工具变了模式没变。真正的转变是彻底停止写那些东西把时间花在智能体做不了的事情上。Vibe Coding 带来的新挑战今天越来越多的开发团队采用“vibe coding”——开发者通过自然语言对话与 AI 协作而不是逐行手写代码。这给 QA 带来了一个特定的难题上下文缺失。当代码由人编写时意图是嵌入在代码结构、注释、命名、提交历史里的。而 AI 生成的代码往往来自一个临时的自然语言提示那个提示可能随手就丢了。代码虽然存在但“为什么要这样写”消失了。规格蒸发掉了。应对这个问题的办法只有一个给智能体尽可能多的上下文。代码、设计文档、需求、用户故事、缺陷历史、发布说明、支持工单——上下文越丰富智能体就越能还原“意图本来应该是什么”也就越能验证现实是否匹配。这也正是 Harness 的价值所在。Harness 不仅仅是边界更是上下文的载体。有了它vibe coding 出来的代码才变得可测试没有它每一次 AI 生成都是一次掷骰子。速度差距已经拉开不能等了Agentic QA 的紧迫性不仅仅来自测试侧的困境更来自开发侧已经发生的变化。数据显示25% 的 Y Combinator 公司有 95% 以上的代码由 AI 生成Google 超过四分之一的新代码也是 AI 生成的。到 2028 年预计 40% 的新企业生产软件将通过 vibe coding 方式产出。开发侧的速度已经跑起来了。如果 QA 侧跟不上会出现两种糟糕的局面第一测试成为新的瓶颈。开发两小时交付一个功能测试要花三天。工程团队干等着签收已经完成的工作速度优势被完全抵消。曾经助推速度的人变成了阻碍速度的人。第二质量债务悄无声息地累积。几个月内什么都看不出来产品感觉很快、很健康。然后某一天回归问题集中爆发团队花一个季度救火。更可怕的是现有的测试套件可能还是全绿通过的——但那是因为它测试的是一个已经不存在了的产品。快速 AI 如果没有快速的验证就是快速积累的技术债务。验证必须和实现同速否则系统会自己撕裂。周一早上到底该做什么听上去很宏大但起点可以很小。不需要一个复杂的转型项目只需要一个实验和一段话。选一个流程找一个重复性的、低风险的流——比如那条没人愿意看的回归测试套或者发布前的冒烟检查清单。让一个智能体在上面跑一个星期。不要拆掉现有框架不要重新培训团队。只观察智能体抓住了什么、漏掉了什么团队对它的输出做了什么反应。写一段话在让智能体碰任何东西之前用大白话写下来“质量”对这个流程意味着什么。不是测试用例不是验收标准。就是一段话说清楚“好的长什么样坏了的长什么样”。如果写不出这段话那没有智能体能帮上忙——因为连人自己都没定义清楚“测试”到底要验证什么。一个流程一段话一个星期。五天之内能学到的比五个月的规划会议还多。结语Agentic QA 百分之九十的困难不在于智能体本身而在于一个被长期忽略的事实从来没有人认真写下来“质量”到底意味着什么而智能体会立刻把这个缺口暴露出来。最大的误解是认为“智能体就是产品”。实际上Harness 才是产品——那套包裹智能体的上下文、边界、审计机制才是真正的价值所在。模型会迭代、工具会更新但一套设计良好的 Harness 能让团队长期受益。十八个月后差距会变得非常明显。一部分团队将拥有小而精的 QA 队伍每个人都在做高杠杆的架构和判断工作质量变成持续流动的一部分。另一部分团队则被困在维护债务里成为大家绕道走的瓶颈。好消息是现在开始完全来得及。但前提是现在就开始。__