当我们谈论AI 测试时很多讨论停留在让大模型写几条用例的层面。但当你真正把大模型塞进一个又一个传统测试平台——从需求评审、手工用例、接口测试、UI 自动化、数据构造到精准测试——会发现一件事大模型不是给平台加了个智能按钮而是逼你重新划分平台里确定性逻辑与生成式逻辑的边界。与其问大模型能帮测试做什么不如问平台中哪些环节本质上是开放域理解与生成任务哪些环节必须保持可复现、可验证、可追溯。前者大胆交给模型后者继续由代码兜底。这就是我重写了一系列测试平台后认为最合适的做法。一、先看清本质传统平台的痛点和大模型的能力恰好咬合传统测试平台解决了资产沉淀、调度执行、报告展示的问题但长期存在几个老大难第一瓶颈在输入侧。用例靠人写、数据靠人造、元素定位靠人维护——平台把执行和报告做的再花哨也解决不了前端的无米之炊。第二维护成本随业务线性膨胀。UI 自动化里一个按钮换了位置脚本就挂一片接口加了字段造数逻辑就得改。平台越用越重越重越没人敢动。第三结论靠翻译。海量执行结果最后还是要人去看堆栈、判失效、写总结、提建议平台只负责跑不负责懂。大模型带来的能力恰好打在这三点上自然语言理解、代码与文档生成、失败的归因与自愈、结果的归纳与决策建议。所以AI 重构测试不是伪需求——但关键在于怎么放。二、核心原则把平台拆成骨架和大脑而不是整体智能化新手最容易犯的错误是试图让一个大模型端到端搞定一切输入一个需求期望它直接吐出通过/不通过的结论。这样做的结果通常是不可控、不可复现、不可信最后团队不敢用。我在重写平台时始终遵循一条原则确定性的事情交给工作流Workflow开放性的事情交给大模型LLM大模型只做决策建议执行与校验留给代码。具体来说一个平台可以拆成两部分骨架部分Workflow——流程编排、调度执行、数据持久化、版本管理、报告渲染、权限控制。这些必须是确定的、稳定的、可复现的用传统代码写死。大脑部分LLM——理解需求、生成用例、分析代码调用链后的推荐、失败堆栈的归因、测试报告的自然语言总结。这些是开放域任务适合模型干但产出必须经过规则校验或人工确认环节。也就是说大模型在平台里的角色定位是**初级测试工程师 顾问而非裁判**。它可以提议平台来把关它可以写错但平台不能让错误溜出去。三、六大典型场景大模型在测试平台里的正确嵌入方式接下来逐个场景拆解。这些场景覆盖了测试全流程每个场景我都会讲清楚模型做什么、代码做什么、人在哪里介入。场景一需求工程——从文档输入到缺陷前置发现传统做法是人工读需求文档、提取测试点。大模型在这里的价值不是简单总结摘要而是进行系统化的缺陷检测识别需求中的歧义、矛盾、遗漏、不可测描述以及缺失的非功能需求性能、安全、兼容。正确的嵌入方式是让模型输出结构化结果JSON 形式的问题清单每条带类型、位置、风险等级、建议提问平台再渲染成可确认列表。产品经理或测试负责人逐条确认后问题进入下一环节。这里人是必须介入的因为需求的最终解释权在人模型只负责把潜在问题提前摊开。一个实战细节不要让模型笼统地找问题而要给它检查清单checklist按歧义性、一致性、完整性、可测试性、非功能维度逐项扫描并结合项目历史的缺陷类型做 few-shot 示例召回质量会明显提高。场景二用例生成——最值回票价、也最容易被低估的场景用例生成是大模型应用最成熟、ROI 最明显的场景但做法有高下之分。关键认知用例生成本质上是理解 粒度控制 等价类/边界值方法论不是造句。所以不能把需求文档直接丢给模型让它自由发挥而要设计两阶段先抽取功能点/测试点树待确认确认后再基于每个功能点按等价类、边界值、场景法、错误推测法展开成用例。平台侧要做好三件事一是中间结果可确认。功能点树先给人调整增删改合并再进入生成这一步决定了用例的覆盖率上限。二是第二模型评审。生成的用例不要直接落库让另一个独立提示词甚至另一个模型从完整性、冗余度、可执行性、数据与预期是否明确四个维度评审过滤看起来完整但没法执行的水用例。三是资产反哺。历史优质用例应进入检索池生成时以相似模块的老用例做参考RAG让模型贴合团队的写作颗粒度和业务术语而不是每次从零开始。这样生成的用例可以直接导出为 XMind、XML 或同步到管理平台真正进入工程流程而不是停在对话框里。场景三接口测试——AI 负责理解和推荐引擎负责执行传统接口自动化平台已经很成熟大模型的增量价值集中在三个地方一是基于代码变更推导该测哪些接口。结合 Git diff 和调用链分析Java 用静态分析、Python 用 AST定位变更影响到的 Controller/API自动圈定回归范围而不是全量盲跑或靠人猜。二是智能造数。接口测试最大的隐性成本是准备满足约束必填、类型、外键依赖、业务规则的请求数据。让大模型根据接口定义和依赖关系生成造数计划再由确定性脚本代码链路工具执行落库既智能又可靠。注意顺序——模型出方案代码做执行和校验不要让模型直接连库写数据。三是结果断言与归因。失败响应交给模型判断是业务失败、数据问题、环境问题还是真正的缺陷并给出初步定位建议。执行引擎本身HttpRunner 等完全不需要智能化它的价值就是稳定、确定、可复现。这是典型的骨架不动、大脑嵌入。场景四UI 自动化——大模型真正解决维护贵的痛点UI 自动化的死敌一直是元素定位失效和脚本维护。大模型加上视觉/可访问性快照accessibility snapshot后出现了一种更鲁棒的模式不再强依赖固定选择器而是用自然语言描述目标由模型在当前页面快照中理解并定位元素再执行操作。落地时建议采用快照旧方式循环打开页面 → 获取结构化快照而非裸截图token 成本低且信息全→ 模型决策下一步动作 → 执行 → 重新快照验证。每一步都校验而不是让模型一次性写完整段操作流程。另一个高价值能力是失败自愈当定位失败时把旧定位符、当前页面快照、DOM 片段一起交给模型让它推断新定位并修复脚本修复后重试验证。这把维护成本随变更线性增长变成了大部分常见变更自动消化。但要守住两条底线自愈不能无限循环要设重试上限和人工兜底自愈修改的定位符要留痕方便回溯避免模型悄悄改对了但没人知道为什么。场景五智能数据构造——被低估的隐形金矿前面接口场景提到了造数这里单独强调因为数据准备往往占用测试团队大量时间却最不被看见。大模型在这个场景的正确用法不是直接生成随机数据而是先做依赖与约束分析输出可执行的造数计划要构造一个已完成的大额订单需要先建用户、建商品带库存和类目约束、建收货地址、下单、支付、履约——这是一棵依赖树。模型负责根据业务规则推导这棵树和每一步的数据代码负责按拓扑顺序执行、处理外键、校验结果。再往前一步可以建立数据血缘记录每条构造数据的来源和关联关系测完后按血缘反向智能清理避免脏数据堆积。对外还可以封装成开放 API兼容 OpenAPI 风格让其他平台和脚本按需点单式造数。这个场景的启示是越脏越累、越依赖业务理解的活越是大模型的好战场但生成与执行必须分层。场景六精准测试与报告智能——让平台从会跑变成会说精准测试的核心是双向追溯代码变更 ↔ 用例 ↔ 覆盖率。大模型在这里扮演推荐器和解说员基于调用链和覆盖率数据模型推荐本次变更最该跑的用例子集并解释推荐理由哪些方法被改动、关联哪些接口、历史上哪些用例曾在此处发现缺陷。人可以采纳或调整。这种可解释的推荐比黑盒置信度分数更容易建立信任。报告侧则是把执行结果、失败堆栈、日志、历史趋势交给模型生成结构化的日报/专题分析本次回归结论、新增失败及归因、疑似缺陷、风险与建议。更进一步还可以让 Agent 持续采集技术情报社区热点、高危漏洞、工具更新并自动归类服务于测试决策。需要警惕的是报告可以让模型写但结论的数字通过率、覆盖率必须来自真实执行数据严禁模型生成或臆测否则报告就失去了公信力。四、推荐的技术架构一套可以复用的分层模式重写这些平台后我沉淀出一个几乎可以复用的分层架构接入层提供 Web UI 和开放 API。一个重要经验是把核心能力同时做成纯 HTTP 服务这样平台之间可以互相调用——比如用例生成能力可以同时服务手工用例平台、接口平台和 UI 平台避免每个平台各接一遍大模型。**编排层工作流引擎**负责把任务拆成确定的步骤和状态机待生成 → 待确认 → 已生成 → 待评审 → 已落库 → 已执行。每个节点明确这步是模型干还是代码干、是否需要人工确认。长任务采用异步任务 回调 心跳轮询天然支持后续把执行节点分布式部署。能力层沉淀可复用的 AI 能力统一的大模型网关兼容 OpenAI 接口规范便于切换不同模型供应商、提示词模板管理、结构化输出校验、RAG 检索、token 与成本统计。执行层是确定性的接口执行引擎、浏览器/设备驱动、静态分析与脚本工具。大模型不进执行链路只在决策点被调用。存储层除了业务库建议单独管理知识资产需求文档切片、历史优质用例、缺陷库、元素定位库、造数模板——这些是 RAG 和 few-shot 的弹药也是团队越用越准的关键。技术栈上FastAPI Vue3 MySQL 是被反复验证高效的组合大模型通过兼容 OpenAI 协议的网关接入国内可用 ARK 等平台关键是用协议解耦别把业务绑死在某一家模型上。五、落地路径建议别一上来就追求无人值守如果团队想动手我的建议是按价值确定性 × 实现难度排优先级分三步走第一步做副驾驶先拿下用例生成和报告总结。这两个场景容错高产出本来就要人看、见效快、对现有流程侵入小最容易让团队建立信心。第二步做分析推荐切入影响面分析、精准测试推荐、智能造数计划。这类场景需要对接代码和数据工程复杂度高一些但价值更深开始改变测什么、怎么造的决策方式。第三步才碰自动执行与自愈如 UI 失败自愈、Agent 自主执行。这类场景风险最高必须在前面的校验、留痕、人工兜底机制成熟后再做而且要始终保留一键退回纯人工的开关。整个过程中人确认节点不是过渡方案而是长期架构的一部分。不要把目标设成去掉人而要设成把人从重复劳动里解放出来聚焦在判断和决策上。六、踩过的坑这几条请直接抄走最后是几条用真实项目换来的教训第一结构化输出必须校验绝不轻信模型会守规矩。要求 JSON 输出就要做 schema 校验校验失败自动重试并回灌错误信息关键字段缺失宁可重生成也不能带病入库。第二提示词和配置要外部化管理。不要把提示词硬编码在业务代码里。不同模块、不同场景往往需要不同模型有的重推理、有的重性价比做成可配置项调优时不必改代码、不必重新发版。第三环境配置如 .env 加载要用绝对可靠的路径。配置加载失败时要有明确报错或回退策略否则大模型网关地址、密钥读不到平台会静默变傻排查极费时间。第四新增功能坚持增量接入独立文件不要整体覆盖现有入口。很多平台改造事故是加 AI 模块时把成熟的主流程文件整个重写覆盖了。先读现有代码、只做增量新能力放独立模块。第五为不确定性留好兜底模型超时、限流、返回异常时平台要能降级重试、换模型、转人工队列不能因为大模型抖动让整个测试流程停摆。第六沙箱/内网环境往往无法访问外部模型与依赖。设计时就要考虑离线开发、mock 验证、e2e 测试与真实环境的切换交付前务必先在目标环境跑通端到端测试。写在最后大模型对测试平台的重构本质上不是一次功能升级而是一次职责重新分工把开放域的理解、生成、归因、推荐交给大模型把确定性的编排、执行、校验、追溯留给代码把最终的判断和决策留给人。谁能把这条边界划得越清楚谁的 AI 测试平台就越可用、越可信、越能真正落地。而那些端到端全自动、黑盒、无确认的炫技方案往往死在第一次生产事故里。测试这个行业不会因为大模型消失但会用大模型的测试团队正在替代不会用的团队。希望这些从十几个平台里磨出来的经验能帮你少走几段弯路。如果觉得有启发欢迎转发给身边做测试平台和质量工程的朋友。也欢迎在留言区聊聊你们团队的 AI 测试现在走到哪一步了
当我们谈论AI 测试时很多讨论停留在让大模型写几条用例的层面。但当你真正把大模型塞进一个又一个传统测试平台——从需求评审、手工用例、接口测试、UI 自动化、数据构造到精准测试——会发现一件事大模型不是给平台加了个智能按钮而是逼你重新划分平台里确定性逻辑与生成式逻辑的边界。与其问大模型能帮测试做什么不如问平台中哪些环节本质上是开放域理解与生成任务哪些环节必须保持可复现、可验证、可追溯。前者大胆交给模型后者继续由代码兜底。这就是我重写了一系列测试平台后认为最合适的做法。一、先看清本质传统平台的痛点和大模型的能力恰好咬合传统测试平台解决了资产沉淀、调度执行、报告展示的问题但长期存在几个老大难第一瓶颈在输入侧。用例靠人写、数据靠人造、元素定位靠人维护——平台把执行和报告做的再花哨也解决不了前端的无米之炊。第二维护成本随业务线性膨胀。UI 自动化里一个按钮换了位置脚本就挂一片接口加了字段造数逻辑就得改。平台越用越重越重越没人敢动。第三结论靠翻译。海量执行结果最后还是要人去看堆栈、判失效、写总结、提建议平台只负责跑不负责懂。大模型带来的能力恰好打在这三点上自然语言理解、代码与文档生成、失败的归因与自愈、结果的归纳与决策建议。所以AI 重构测试不是伪需求——但关键在于怎么放。二、核心原则把平台拆成骨架和大脑而不是整体智能化新手最容易犯的错误是试图让一个大模型端到端搞定一切输入一个需求期望它直接吐出通过/不通过的结论。这样做的结果通常是不可控、不可复现、不可信最后团队不敢用。我在重写平台时始终遵循一条原则确定性的事情交给工作流Workflow开放性的事情交给大模型LLM大模型只做决策建议执行与校验留给代码。具体来说一个平台可以拆成两部分骨架部分Workflow——流程编排、调度执行、数据持久化、版本管理、报告渲染、权限控制。这些必须是确定的、稳定的、可复现的用传统代码写死。大脑部分LLM——理解需求、生成用例、分析代码调用链后的推荐、失败堆栈的归因、测试报告的自然语言总结。这些是开放域任务适合模型干但产出必须经过规则校验或人工确认环节。也就是说大模型在平台里的角色定位是**初级测试工程师 顾问而非裁判**。它可以提议平台来把关它可以写错但平台不能让错误溜出去。三、六大典型场景大模型在测试平台里的正确嵌入方式接下来逐个场景拆解。这些场景覆盖了测试全流程每个场景我都会讲清楚模型做什么、代码做什么、人在哪里介入。场景一需求工程——从文档输入到缺陷前置发现传统做法是人工读需求文档、提取测试点。大模型在这里的价值不是简单总结摘要而是进行系统化的缺陷检测识别需求中的歧义、矛盾、遗漏、不可测描述以及缺失的非功能需求性能、安全、兼容。正确的嵌入方式是让模型输出结构化结果JSON 形式的问题清单每条带类型、位置、风险等级、建议提问平台再渲染成可确认列表。产品经理或测试负责人逐条确认后问题进入下一环节。这里人是必须介入的因为需求的最终解释权在人模型只负责把潜在问题提前摊开。一个实战细节不要让模型笼统地找问题而要给它检查清单checklist按歧义性、一致性、完整性、可测试性、非功能维度逐项扫描并结合项目历史的缺陷类型做 few-shot 示例召回质量会明显提高。场景二用例生成——最值回票价、也最容易被低估的场景用例生成是大模型应用最成熟、ROI 最明显的场景但做法有高下之分。关键认知用例生成本质上是理解 粒度控制 等价类/边界值方法论不是造句。所以不能把需求文档直接丢给模型让它自由发挥而要设计两阶段先抽取功能点/测试点树待确认确认后再基于每个功能点按等价类、边界值、场景法、错误推测法展开成用例。平台侧要做好三件事一是中间结果可确认。功能点树先给人调整增删改合并再进入生成这一步决定了用例的覆盖率上限。二是第二模型评审。生成的用例不要直接落库让另一个独立提示词甚至另一个模型从完整性、冗余度、可执行性、数据与预期是否明确四个维度评审过滤看起来完整但没法执行的水用例。三是资产反哺。历史优质用例应进入检索池生成时以相似模块的老用例做参考RAG让模型贴合团队的写作颗粒度和业务术语而不是每次从零开始。这样生成的用例可以直接导出为 XMind、XML 或同步到管理平台真正进入工程流程而不是停在对话框里。场景三接口测试——AI 负责理解和推荐引擎负责执行传统接口自动化平台已经很成熟大模型的增量价值集中在三个地方一是基于代码变更推导该测哪些接口。结合 Git diff 和调用链分析Java 用静态分析、Python 用 AST定位变更影响到的 Controller/API自动圈定回归范围而不是全量盲跑或靠人猜。二是智能造数。接口测试最大的隐性成本是准备满足约束必填、类型、外键依赖、业务规则的请求数据。让大模型根据接口定义和依赖关系生成造数计划再由确定性脚本代码链路工具执行落库既智能又可靠。注意顺序——模型出方案代码做执行和校验不要让模型直接连库写数据。三是结果断言与归因。失败响应交给模型判断是业务失败、数据问题、环境问题还是真正的缺陷并给出初步定位建议。执行引擎本身HttpRunner 等完全不需要智能化它的价值就是稳定、确定、可复现。这是典型的骨架不动、大脑嵌入。场景四UI 自动化——大模型真正解决维护贵的痛点UI 自动化的死敌一直是元素定位失效和脚本维护。大模型加上视觉/可访问性快照accessibility snapshot后出现了一种更鲁棒的模式不再强依赖固定选择器而是用自然语言描述目标由模型在当前页面快照中理解并定位元素再执行操作。落地时建议采用快照旧方式循环打开页面 → 获取结构化快照而非裸截图token 成本低且信息全→ 模型决策下一步动作 → 执行 → 重新快照验证。每一步都校验而不是让模型一次性写完整段操作流程。另一个高价值能力是失败自愈当定位失败时把旧定位符、当前页面快照、DOM 片段一起交给模型让它推断新定位并修复脚本修复后重试验证。这把维护成本随变更线性增长变成了大部分常见变更自动消化。但要守住两条底线自愈不能无限循环要设重试上限和人工兜底自愈修改的定位符要留痕方便回溯避免模型悄悄改对了但没人知道为什么。场景五智能数据构造——被低估的隐形金矿前面接口场景提到了造数这里单独强调因为数据准备往往占用测试团队大量时间却最不被看见。大模型在这个场景的正确用法不是直接生成随机数据而是先做依赖与约束分析输出可执行的造数计划要构造一个已完成的大额订单需要先建用户、建商品带库存和类目约束、建收货地址、下单、支付、履约——这是一棵依赖树。模型负责根据业务规则推导这棵树和每一步的数据代码负责按拓扑顺序执行、处理外键、校验结果。再往前一步可以建立数据血缘记录每条构造数据的来源和关联关系测完后按血缘反向智能清理避免脏数据堆积。对外还可以封装成开放 API兼容 OpenAPI 风格让其他平台和脚本按需点单式造数。这个场景的启示是越脏越累、越依赖业务理解的活越是大模型的好战场但生成与执行必须分层。场景六精准测试与报告智能——让平台从会跑变成会说精准测试的核心是双向追溯代码变更 ↔ 用例 ↔ 覆盖率。大模型在这里扮演推荐器和解说员基于调用链和覆盖率数据模型推荐本次变更最该跑的用例子集并解释推荐理由哪些方法被改动、关联哪些接口、历史上哪些用例曾在此处发现缺陷。人可以采纳或调整。这种可解释的推荐比黑盒置信度分数更容易建立信任。报告侧则是把执行结果、失败堆栈、日志、历史趋势交给模型生成结构化的日报/专题分析本次回归结论、新增失败及归因、疑似缺陷、风险与建议。更进一步还可以让 Agent 持续采集技术情报社区热点、高危漏洞、工具更新并自动归类服务于测试决策。需要警惕的是报告可以让模型写但结论的数字通过率、覆盖率必须来自真实执行数据严禁模型生成或臆测否则报告就失去了公信力。四、推荐的技术架构一套可以复用的分层模式重写这些平台后我沉淀出一个几乎可以复用的分层架构接入层提供 Web UI 和开放 API。一个重要经验是把核心能力同时做成纯 HTTP 服务这样平台之间可以互相调用——比如用例生成能力可以同时服务手工用例平台、接口平台和 UI 平台避免每个平台各接一遍大模型。**编排层工作流引擎**负责把任务拆成确定的步骤和状态机待生成 → 待确认 → 已生成 → 待评审 → 已落库 → 已执行。每个节点明确这步是模型干还是代码干、是否需要人工确认。长任务采用异步任务 回调 心跳轮询天然支持后续把执行节点分布式部署。能力层沉淀可复用的 AI 能力统一的大模型网关兼容 OpenAI 接口规范便于切换不同模型供应商、提示词模板管理、结构化输出校验、RAG 检索、token 与成本统计。执行层是确定性的接口执行引擎、浏览器/设备驱动、静态分析与脚本工具。大模型不进执行链路只在决策点被调用。存储层除了业务库建议单独管理知识资产需求文档切片、历史优质用例、缺陷库、元素定位库、造数模板——这些是 RAG 和 few-shot 的弹药也是团队越用越准的关键。技术栈上FastAPI Vue3 MySQL 是被反复验证高效的组合大模型通过兼容 OpenAI 协议的网关接入国内可用 ARK 等平台关键是用协议解耦别把业务绑死在某一家模型上。五、落地路径建议别一上来就追求无人值守如果团队想动手我的建议是按价值确定性 × 实现难度排优先级分三步走第一步做副驾驶先拿下用例生成和报告总结。这两个场景容错高产出本来就要人看、见效快、对现有流程侵入小最容易让团队建立信心。第二步做分析推荐切入影响面分析、精准测试推荐、智能造数计划。这类场景需要对接代码和数据工程复杂度高一些但价值更深开始改变测什么、怎么造的决策方式。第三步才碰自动执行与自愈如 UI 失败自愈、Agent 自主执行。这类场景风险最高必须在前面的校验、留痕、人工兜底机制成熟后再做而且要始终保留一键退回纯人工的开关。整个过程中人确认节点不是过渡方案而是长期架构的一部分。不要把目标设成去掉人而要设成把人从重复劳动里解放出来聚焦在判断和决策上。六、踩过的坑这几条请直接抄走最后是几条用真实项目换来的教训第一结构化输出必须校验绝不轻信模型会守规矩。要求 JSON 输出就要做 schema 校验校验失败自动重试并回灌错误信息关键字段缺失宁可重生成也不能带病入库。第二提示词和配置要外部化管理。不要把提示词硬编码在业务代码里。不同模块、不同场景往往需要不同模型有的重推理、有的重性价比做成可配置项调优时不必改代码、不必重新发版。第三环境配置如 .env 加载要用绝对可靠的路径。配置加载失败时要有明确报错或回退策略否则大模型网关地址、密钥读不到平台会静默变傻排查极费时间。第四新增功能坚持增量接入独立文件不要整体覆盖现有入口。很多平台改造事故是加 AI 模块时把成熟的主流程文件整个重写覆盖了。先读现有代码、只做增量新能力放独立模块。第五为不确定性留好兜底模型超时、限流、返回异常时平台要能降级重试、换模型、转人工队列不能因为大模型抖动让整个测试流程停摆。第六沙箱/内网环境往往无法访问外部模型与依赖。设计时就要考虑离线开发、mock 验证、e2e 测试与真实环境的切换交付前务必先在目标环境跑通端到端测试。写在最后大模型对测试平台的重构本质上不是一次功能升级而是一次职责重新分工把开放域的理解、生成、归因、推荐交给大模型把确定性的编排、执行、校验、追溯留给代码把最终的判断和决策留给人。谁能把这条边界划得越清楚谁的 AI 测试平台就越可用、越可信、越能真正落地。而那些端到端全自动、黑盒、无确认的炫技方案往往死在第一次生产事故里。测试这个行业不会因为大模型消失但会用大模型的测试团队正在替代不会用的团队。希望这些从十几个平台里磨出来的经验能帮你少走几段弯路。如果觉得有启发欢迎转发给身边做测试平台和质量工程的朋友。也欢迎在留言区聊聊你们团队的 AI 测试现在走到哪一步了
