Testing Agent Harness与测试平台-AiDD研发数字峰会2026-深圳站

论坛主席：李华伟

阿里巴巴研发效能负责人，长期深耕服务端测试平台与研发效能领域，主导建设了文娱集团服务端全流程保障平台，有效支撑优酷+大麦服务端全部核心应用高质量交付，并通过将传统基础能力进行系统性的 Harness 化改造，以 CLI/Skill/Agent三种形态接入服务端AI Native研发流程，构建了"AI 写代码、AI保质量"的端到端闭环。曾多次受邀在国内技术大会上演讲并获评年度明星讲师，在服务端研发效能与智能测试领域具有广泛的行业影响力。

阿里巴巴研发效能技术专家

Testing Agent Harness与测试平台

本论坛聚焦测试智能体的工程平台建设，研究如何通过Harness把测试任务标准化、模块化、平台化，支撑多场景协同落地。论坛将讨论自动调度、资产复用、链路编排、效能评估、工具集成、持续治理等主题，强调平台如何承接测试智能化的规模扩展需求。听众将理解如何搭建可复用、可运营、可演进的智能测试平台。

从人工卡点到自主收敛——需求驱动的智能测试流水线

李前国

荣耀终端测试架构师

内容简介：

端侧 App 的智能测试大多停在「AI 帮我写脚本」。我们基于 Claude Code 构建了一条需求驱动的端侧测试流水线：输入需求编号与 APK 版本，经需求分析、用例生成、脚本生成、执行、覆盖率度量五个域，以需求维度代码覆盖率 ≥85% 为收敛目标自主循环。
架构上是 7 个 Skill 组成的联邦：编排层 + 5 个领域子 Skill + mock 造数旁路，每个域出口设质量卡点——人工卡点管方向，自动卡点管质量（语法/收集/smoke 三件套、失败三分类、覆盖率判据），跨域状态用单一 state.json 支撑断点续跑。
关键设计有三：一是卡点分级，人工只出现在方向判断处，且循环补用例时豁免人工卡点并记录审计链；二是失败分类闸门，环境类失败才允许自动重试，断言类失败直接报 Bug，防止自愈机制吞掉缺陷；三是证据化完成判定，用覆盖率提升 ≥5% 才允许继续循环的硬判据，证明补充用例与覆盖增长的真实对应。
落地效果：多个需求全流程闭环，页面直达采用页面树查询 + 深链方案实测可达率 94.6%，覆盖率刷新链路典型延迟 5-10 分钟。适合正在搭建 Agent 测试流水线的工程团队。

演讲提纲：
1.为什么「AI 写脚本」不够 8min 单 Agent 跑 10 步闭环的跨阶段复利事故；从 Demo 到流水线的三个断层（方向、质量、收敛）；本议题核心主张：AI 写脚本只是起点，自主收敛才是终点
2.架构与全流程走查 12min 7-Skill 联邦拓扑（编排层只调度不分析、state.json 断点续跑、gated/auto 双模式）；用一个真实需求从输入到覆盖率达标的完整回放串起架构：五卡点状态演进、每域产物落盘
3.卡点分级：哪里留人、哪里全自动 10min 五卡点分级表（人工×1 / 半自动×1 / 全自动×3）；循环回跳免人工卡点 + loop_added_cases 审计；「自动卡点任何模式不可跳过」的边界
4.失败分类闸门与 mock 造数旁路 10min 三分类决策表（环境→重试 / 脚本→修脚本 / 缺陷→报单，防自愈吞 Bug）；响应满足性三维判定（分支可达/字段非空/异常可触发）→ 轻路径（本地响应规则字段级替换）优先、重路径（整链路配桩回放）兜底；为什么改环境与改用例必须严格区分
5.覆盖率收敛循环与证据化完成判定 10min 采集→云侧计算→循环控制（85%/60%/3轮/+5%/停滞2轮终止）；三层证据链（静态命名链/动态审计链/闭环收敛验证）；如实讲缺口：逐用例↔逐方法正向归因不存在；结尾迁移建议：哪些可迁移、哪些强绑定端侧
Q&A 5min

听众收益：
正在或计划用 AI Agent 搭建测试流水线的测试开发/测试平台工程师；关心「AI 测试结果可不可信」的质量负责人。
一张卡点分级决策表（拿走即用）：五个质量门禁哪些必须留人工、哪些可全自动、循环回跳时哪些可豁免——以及豁免时的审计方案；避开「全自动 = 全去掉人工卡点」的坑，方向性错误只有人工能拦
一套失败分类闸门规则：环境/脚本/产品缺陷三分类如何决定「重试 vs 修脚本 vs 报 Bug」；避开最危险的坑——AI 流水线把真 Bug 当环境噪声自愈吞掉
一组覆盖率收敛控制参数（可直接抄）：目标 85% / 底线 60% / 上限 3 轮 / 每轮提升 ≥5% / 停滞 2 轮终止；以及「提升 ≥5% 才允许继续循环」这个硬判据为什么是防自欺的关键
一次完整的踩坑复盘：单 Agent 跑 10 步闭环为什么会跨阶段复利出错、错误到执行期才暴露的返工代价、联邦化拆分后错误如何被隔离在域内——省掉你自己踩一遍的时间

测试架构师与研发效能架构师，10+年开发与测试经验，在端云协同测试与AI测试领域有丰富记录。长期深耕互联网业务交付一线，持续探索规模化快速交付下质量与效率的工程化平衡，现专注以AI 驱动的测试范式的演进。

从出报告到拦交付：自建 AI 内容质量门禁实践

包蕾

网龙网络 AI Native Engineer

内容简介：

AI 生成内容的评测体系业界已建了不少，但产出大多是一份报告：跑完出分、人看一眼，产物照常交付。我们把评测接进了在线交付路径——内容生成 Agent 每产出一份内容都先过质量门禁：确定性规则做硬拦截，LLM 判官做软评分；判不通过就定位问题、自动修复，复检通过才交付。
真正的难点不在判得准不准，而在四个在线约束：结论必须在用户等得起的时间内返回；评测器不可用时必须放行，门禁会悄悄失效；误拦比漏放代价更高；判词描述失真，可能造成人工复核误判。本次分享 Agent 评测如何从”出报告”走到“拦交付”。

演讲提纲：
1. 评测报告为什么挡不住问题
离线评测与在线门禁是两套问题：后者必须在放行前、每一次都按时给出结论
拦不住的红线比没有红线更糟——它让人以为已经拦住了
2. 门禁怎么搭：从只记录到真拦截
分工判据：能给出可复核证据的才做硬拦截，其余交给 LLM 判官软评分
渐进上线：仅记录 → 灰度 → 真拦，先量出"如果真拦会拦多少"
拦下要有出口：定位 → 自动修复 → 复检 → 交付
3. 时延：在线窗口废掉了三种常规做法
多判官投票、重复采样、人工抽检都会成倍拉长时延
先定可接受的超窗率，再从实测长尾反推等待窗口
4. 另外三个坑
会自己消失的门禁：放行必须单独留痕，否则失效与正常通过无法区分
误拦代价不对称：给不出结论不等于有问题，应判"存疑"而非拦截
判词描述失真：问题判对了，复核时却被当成误判放过
5. 让门禁本身可信
尺子要有版本号：判据和判官模型一变，分数漂移可追溯
评测器自己也要被测，指标靠数据做减法

听众收益：
1. 一条可落地的在线质量门禁路径：规则硬拦截 + LLM 判官软评分，拦下即定位、修复、复检再交付。
2. 在线门禁特有的四个坑及应对：时延预算、门禁静默失效、误拦代价、判词失真。
3. 一套让门禁本身可信的做法：判据与判官模型版本化、评测器自测，以及用数据给指标做减法。

网龙网络 AI Native Engineer，深耕测试与质量保障领域 13 年。近年负责公司 AI Testing 技术探索与落地，搭建 TestCortex 智能测试平台，打通 AI 生成测试用例、AI 接口测试、AI UI 测试等核心场景。当前聚焦 AI Agent 产品评测体系建设，主导离线评测与在线评测双轨机制，同时探索评测体系的自进化。2025 年带队获得首届微软 AI 开发者挑战赛冠军。

让系统承接复杂业务测试：Harness Test 从手工验证到全流程自主交付

梁倩倩

天猫测试开发专家

内容简介：

本演讲以超长链路基于规则驱动的复杂结算场景为例，分享复杂长链路的Harness Test实践：不是AI单点提效，而是构建"需求理解→用例生成→真实执行→自动校验"的完整验证闭环。AI与工程分工明确：大模型负责PRD理解、规则结构化与候选数据推导；工程系统承接数据构造、单据状态推进、异步轮询与字段级比对判定，保证结果确定性。落地后同等规模测试从人工约2天缩短到小时级，沉淀的不是脚本而是可复用的执行与判定系统能力。演讲并给出"是否值得脱手"五要素判断：规则清晰、场景可枚举、预期可计算、执行可编排、结果可结构化校验。

演讲提纲：
1. 背景：规则驱动的复杂业务测试，为什么长期只能靠人扛
1.1 以长链路结算场景为例：规则多、组合多、公式复杂、链路长、结果异步，测试重点不是接口返回值，而是真实业务链路中能否正确识别、计费与结算；
1.2 一条case的"重"：背后挂着从规则理解、数据构造、预期手工验算、单据推进到结果比对的完整验证链路，每一段都依赖人工判断与衔接。
2. 问题拆解：三重"重"在哪里
2.1 用例设计重：难的不是列场景，而是把规则约束翻译成一组可执行、可命中、可验证的正式输入（字段组合、边界值、默认值、优先级）
2.2 预期验算重：预期结果受元数据类型、计费模式、生效节点、命中条件、优先级等多因素影响，必须先"算出来"；
2.3 结果校验重：多数自动化只做到"脚本跑完"，预期人算、结果人核、结论人判。
3. 解法：Harness Test 三步闭环
3.1 case生成：AI理解PRD，识别元数据类型、计费模式、计费节点，把非结构化规则转成结构化约束并推导候选数据组合；
3.2 执行系统：主/子执行流编排，长链路数据构造、单据创建与状态推进、结算链路触发、异步轮询、实际结果获取与标准化；
3.3 自动校验：围绕命中规则编码、规则取值、计费金额等关键字段做字段级比对（真实字段现场出示），产出字段级、可解释、可追溯的判定依据，让系统给出最终结论；
3.4 现场演示（5–8分钟）：实操/播放一条真实需求从case生成、执行到自动校验的全过程，现场看系统自己给出判定结论。
4. AI 与工程化的分工边界
4.1 不All in AI：结算是对确定性要求极高的场景；
4.2 大模型负责输入理解与候选推导（理解PRD、识别规则、补齐边界/默认值/冲突覆盖）；工程系统负责执行、判定与最终校验（模板分配、数据结构化落地、预期计算、编排、状态推进、对比判定、报告输出）。
5. 带来的变化：不只是更快
5.1 效率：同等规模需求从人工约2天到小时级；
5.2 成本结构：测试投入不再与case数量线性绑定；
5.3 沉淀的是系统能力而非脚本：模板体系、预期结果计算器、执行系统、判定系统；
5.4 测试重心迁移：从"需求跟随型劳动"转向"基础设施型建设"。
6. 判断模型与展望：什么样的测试值得脱手
6.1 五要素判断：规则是否清晰、场景是否可枚举、预期结果是否可计算、执行是否可编排、实际结果是否可结构化校验；
6.2 不适合照搬的特征：规则频繁变化、场景高度开放、预期依赖专家经验、链路不稳定、结果难结构化、数据依赖外部环境；
6.3 泛化路径：五要素判断模型即复制的出口——任何满足五要素的场景都可按同一闭环承接，现场用该模型对两个典型候选场景（如分账、稽核规则类）做脱手评估演示，正面回答"换个业务还成立吗"；
6.4 展望：harness+react 多场景的AI自动探索，让模式具备更大拓展性。

听众收益：
1. 获得一套"AI+工程"混合驱动、把复杂业务测试真正"承接"下来的完整闭环方法（用例生成→真实执行→自动校验），可直接借鉴到计费、结算、分账等规则驱动场景；
2. 明确大模型与工程系统的能力边界分工，理解高确定性业务中为何不能All in AI、确定性应由工程系统保证，避免落地踩坑；
3. 拿到一个可操作的"是否值得脱手"五要素判断模型（规则清晰、场景可枚举、预期可计算、执行可编排、结果可结构化校验），帮助团队评估自身哪些测试适合做成工程化闭环。

从事软件测试10余年，长期深耕软件测试流程优化与AI赋能测试实践。近年聚焦复杂业务测试的工程化承接，主导多场景、多类型业务质量保障，不断探索AI在测试全链路中的实践，并在规则驱动、长链路场景的全流程自主交付验证闭环落地，致力于让测试从人工验证走向可复用、可校验的系统化能力。

AiDD峰会

K+峰会

联系我们