Harness Test 从手工验证到全流程自主交付

议题提交

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

2026.12.04 · 深圳湾万丽酒店

演讲嘉宾：梁倩倩 · 天猫测试开发专家

时长 60分钟

所属论坛：Testing Agent Harness与测试平台

梁倩倩

天猫测试开发专家

内容简介：

本演讲以超长链路基于规则驱动的复杂结算场景为例，分享复杂长链路的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在测试全链路中的实践，并在规则驱动、长链路场景的全流程自主交付验证闭环落地，致力于让测试从人工验证走向可复用、可校验的系统化能力。