五类测试怎样落地：把设计、构建、跑批和复核做成工作包

五类测试都写进方案之后，下一步最容易卡住的不是“还缺哪种指标”，而是拿到一条题不知道怎样开始：条件谁确认，参考怎样制作，批量执行收集什么，人工复核从哪里定位，修复之后需要重跑哪些题。

可以把设计、构建、标注、跑批、review、归因与复测作为可验收工作包。每个包有输入、处理规则、产物和完成条件，用同一条用例贯穿，避免把“正在准备数据”写成无法判断完成的状态。

五类范围对应不同判定对象

测试范围	准备的标准数据	主要入口与方法	完成时必须留下什么
权限	六种授权集合、可信账号、策略版本、行外哨兵	API固定认证主体，企微核对真实绑定；正负与撤权对照	实际读取范围、无泄露证据、合法可用性
意图条件	任务标签、规范条件、术语映射、参考时刻、逐轮状态	明确条件、同义词、歧义和改口；分类与槽位检查	漏提、多提、错值、完整匹配及澄清记录
数据准确性	报表筛选台账、同水位参考、反例数据	实际Hermes入口执行，查询契约及结果差分	条件一致性、键和值差异、未知与责任
回答分析交付	原始结果、原子事实、方法规则、文件与接收约定	数字与图表对账、校准Judge、真实文件读取	事实支持、分析依据、附件内容与归属
安全稳定性	A-B合成标记、工具允许清单、故障点和遥测基线	注入、副作用前后对照、消息重投与恢复	禁止事件、幂等、明确终态和资源恢复

五类按主要风险归属统计Case，次级标签用于筛选。不应让一条跨区金额题因为包含三个标签就变成三条样本。人工核验的是不同断言，并不一定需要三个完整执行；若身份或前提改变，才需要形成有版本的独立场景。

把每一类的计划写成七个工作包

工作包	输入	处理操作	输出与完成门
设计	产品规则、现有失败、覆盖缺口	写标准条件、允许与禁止行为、正负对照	任务卡可以由另一人独立执行
构建	批准的指标、权限和数据源	采集参考、冻结快照、准备合成错误	每个预期有独立依据与版本
标注	用户问法与参考条件	逐项核验语义、归一化值、裁定歧义	不能确定的项单独挂起
跑批	冻结题、可信入口、资源与预算	执行并保存每次尝试与实际状态	消息、查询、结果和交付能关联
人工复核	差异报告与独立证据	先关键失败，再看分歧和通过抽样	结论、理由、证据引用完整
归因	已复核差异与阶段记录	区分业务、模型、数据、权限、环境和检查器	根因假设有对应事实支持
复测交付	批准修复与影响映射	重跑原题、邻接反例、合法对照	新trial保留，旧失败不覆盖

工作包之间不是机械传文件。标注发现报表条件含糊，应回到设计或参考构建；跑批发现身份未绑定，应该阻断相应执行，不能把后续错误交给人工逐条猜。复核也可能发现参考或Oracle错误，这时修订的是测试资产，产品不应背下所有失败。

flowchart LR
 A[覆盖缺口与规则] --> B[设计任务及断言]
 B --> C[构建独立参考]
 C --> D[标注与人工核验]
 D --> E[冻结并批量执行]
 E --> F[差异及人工复核]
 F --> G[归因和修复]
 G --> H[原题与影响集复测]
 F --> C

复核回到参考构建的箭头很重要。如果没有这条路径，所有差异只能被归成模型不好或人为接受答案。正确做法是留下争议、引用版本、审批修改，再以新版本重跑，保持历史结论可解释。

Case、trial 与参考答案，先各归各位

Case 是一条用例，包含任务输入、身份条件、数据前提和预期。trial 是该用例的一次完整执行。多轮任务从开始到终态可以算一次 trial，里面再按回合记录 turn。底层模型重试是内部尝试，不应未经约定就膨胀成新的独立用例。

一条题执行三次，意味着一个 Case、三个 trial。每次使用哪个数据集版本、模型、语义资产与权限配置，都要可回查。如果中途修改输入或参考，新的执行应指向新版本，不能让同一个用例标识在历史上代表不同问题而没有说明。

参考答案是独立判断依据，运行基线是某个被测版本的历史输出，两者不能互相替代。新版本与旧版本回答一致，只说明没有观察到差异；旧版本原本可能就错。回归比较同时需要独立参考，才能区分一致地错误与真正保持正确。

预期也不只是最终文字。可以按意图、过程、结果和回答四类组织：意图记录标准条件；过程记录必须发生或禁止发生的关键操作；结果记录业务数据或终态；回答记录数字、单位与交付要求。检查器只核验有证据的可见行为，不要求保存模型私有推理。

用例示意:
  任务: 查询门店A九月净销售额
  条件预期: 指标和时间完整匹配
  过程预期: 授权通过后才允许提交查询
  结果预期: 独立快照中的300元
  回答预期: 明确金额单位并交付给发起主体
运行记录:
  用例编号: 示例C01
  执行编号: 示例T01
  参考版本: 示例R1
  数据版本: 示例S1

示意中的三百元为合成值，真实落地需要连接独立参考。字段名称只为解释职责，不能直接当作某个框架已支持这些自动断言的证明。适配时应复用框架既有用例协议，把领域核验规则留在项目评测包中，确有共性缺口再扩共享能力。

数据集先按用途分区，再冻结

至少区分开发调试、校准和验收用途。调试题可反复帮助优化提示与工具；校准题用于验证检查器和评分规则；验收题保留相对独立性，避免每次失败后马上把原题加入提示。不同用途混在一起，分数会越来越接近训练熟悉度。

分区要按同源语义分组，而非随手打乱行号。来自同一份报表条件的十种改写，应作为一组分配；同一多轮模板更换门店名，也可能高度相似。若它们跨分区，系统可能已经见过测试结构，验收结果应说明这种局限。

每条参考记录保留来源、采集时间、语义版本、数据水位和审阅状态。争议题暂不进入确定性结论，修订时保留变更原因。模型生成的问法和初标结果属于候选，人工确认后才具备基准价值，不能把自动生成数量直接报成已验证覆盖。

冻结前由有权人员审阅候选范围、关键断言和脱敏情况。人工批准应是真实动作，不能由 Agent 自动填身份或代替确认。冻结后产生版本摘要，执行清单绑定该版本。新增题、修改标准条件或调整关键预期，都需要形成新版本与审阅记录。

资产	主要作用	变更时要做什么
业务参考	定义哪些结果正确	核验口径与水位，保留版本
候选用例	组织任务与断言	人工审阅并补覆盖缺口
校准反例	证明检查器能发现错误	修改规则后重跑
冻结基准	稳定版本比较	变更后重新审阅
运行清单	描述这次测了什么	每批独立保存
失败归因	推动修复和回归	关联旧记录，不覆盖历史

执行前，先判断这批结果是否可比

运行清单需要记录目标版本、入口、模型与参数、语义与权限版本、数据快照、数据集摘要、检查器和 Judge 版本、并发、超时与预算。它们不是装饰信息：其中任一变化，都可能影响成功率、延迟或成本。

真实目标、隔离环境与参考未就绪时，先做协议验证是合理的，但结论只能写本地协议通过。模拟工具返回三百元，不能证明真实数仓、企业身份和渠道交付正确。报告应标注证据层级，避免把不同环境的绿灯拼成一个真实业务结论。

重复执行要控制变量。三次 trial 若跨了三个数据水位，不能直接归因模型随机性；两版本并发能力不同，也不能拿未说明条件的平均时延做公平比较。最好固定快照、相同输入与预算，并将运行顺序随机化或交错安排，减少时间和环境偏差。

失败重跑需要规则。修复后的执行可以作为新记录，不能删除首次失败；环境瞬断允许补跑，也要保留原终态和补跑原因。测试人员反复点到成功再只统计最后一次，会系统性抬高稳定性表现。

覆盖矩阵怎样进入自动检查

字段、角色、时间与异常可以无限组合，不能把笛卡尔积全部展开。先由业务和风险确定必需单元，再检查当前用例是否真正覆盖。没有独立预期的候选不算已覆盖；仅写了标签但没有对应断言，也不能自动认领。

通用任务包示意如下，不是现有框架Case格式。真实映射可以使用scenario_types、scenario_families及领域条件字段，但标签与检查器需要明确绑定。

工作包: 数据准确性基础对账
必要单元:
  - 指标净额与有效状态
  - 时间右端点
  - 一对多重复关联
  - 合法空集
产物:
  - 已批准条件和参考版本
  - 逐项独立断言
  - Oracle正负校准结果
  - 逐次执行差异与人工裁定
完成门: 必要单元有证据，无未决关键事实

按评测逻辑整理的教学实现，非业务项目源码。它按稳定用例编号去重，只接受有真值且有明确断言的覆盖声明，不把trial数或标签数量当作业务覆盖。

def coverage(required, cases):
    seen, covered = set(), set()
    for case in cases:
        if case["id"] in seen:
            raise ValueError("duplicate case id")
        seen.add(case["id"])
        if case["reference_ready"] and case["checks_ready"]:
            covered.update(set(case["cells"]) & set(required))
    return {"covered": covered, "missing": set(required) - covered}

required = {"date_end", "join_duplicate", "empty_result"}
cases = [{"id": "c1", "cells": ["date_end"], "reference_ready": True, "checks_ready": True},
         {"id": "c2", "cells": ["join_duplicate"], "reference_ready": True, "checks_ready": False}]
result = coverage(required, cases)
assert result["covered"] == {"date_end"}
assert result["missing"] == {"join_duplicate", "empty_result"}
ready = cases[1] | {"checks_ready": True}
assert "join_duplicate" in coverage(required, [cases[0], ready])["covered"]
try:
    coverage(required, [cases[0], cases[0]])
except ValueError:
    pass
else:
    raise AssertionError("duplicate case was counted twice")
print("缺断言不计覆盖，重复编号不能重复计数")

实际覆盖检查还需核验cells来自哪份需求与断言映射，不能任由候选生成器自报覆盖。某个时间端点只在组件层被测，也应与真实Agent层区别标记。覆盖率分母是已批准必要单元，不是临时把所有标签相加。

跑批和review，怎样交接才不会重复找资料

每条差异记录并排展示用户问题、标准条件、实际条件、参考版本、原始结果和最终回答。权限题增加策略与查询审计，交付题增加文件内容和实际接收对象，安全题增加前后状态。复核人员点开的是一个有上下文的任务，而不是一张孤立红色截图。

可以设置先处理严重事件，再处理不可判定和模型评分分歧，最后抽样通过项。通过抽样不是多余工作，它验证检查器有没有漏报。复核状态应区分待取证、待业务裁定、确认产品错误、确认测试错误和已完成复测，不要只有一个已处理勾选框。

归因写成可验证假设。例如“时间错了”应指向标准区间与实际参数，“数据晚到”应指向水位差异，“回答改数字”应指向原始结果和产物差值。没有这类证据时保留待确认，不能用一段模型生成的解释代替根因。

复测从影响映射选题。修改指标口径，就包含正常、状态、时间、关联与文件检查；修改身份，就包含合法、拒绝、撤权、缓存和真实渠道。原题通过后仍需要邻接反例，防止只针对一个固定问法修补。

五类指标怎样进入工作包

指标不是报告结束时临时补上的百分比。设计包先确定适用范围，构建包准备独立依据，执行包记录真实分母，复核包处理未知。下面列的是领域指标设计，不是框架读到字段后自动计算的承诺。

范围	主要指标与含义	计数要求	未知怎样处理
权限	越权事件率、合法成功率、误拒与有效拒绝	trial为单位，确认泄露即使最终超时仍计事件	缺审计不能填无读取，证据覆盖另列
意图	Accuracy、类别Macro-F1、条件Precision/Recall/F1及ExactMatch	任务分类与条件事实使用不同分母	无法直接观察B1时标明间接证据
准确性	执行结果正确率EX、结果行PRF、关键金额正确率	同范围、水位、单位下与独立参考对账	数据不齐或参考争议暂停业务裁决
回答交付	事实支持率、无据断言率、关键事实整题通过、实际交付成功	断言、整题和产物分别计数	无法确认支持依据的事实单列
安全稳定性	攻击成功率ASR、隔离违规、幂等违规、恢复成功率	攻击trial、重复消息组和故障场景不能共用分母	遥测缺失、查询状态未知不得记安全通过

Precision表示提取或预测内容中正确的比例，Recall表示应当识别内容中被找出的比例，F1综合两者。Macro-F1先逐类别算F1再平均，防止高频汇总题淹没少数澄清题；ExactMatch要求标准条件全部匹配。Oracle指独立判定规则，GT指经审核参考，rubric是Judge评分标准。LLM-as-Judge属于辅助语义评分，不能覆盖金额或权限的确定性失败。

工作包完成率也需明确口径。十条候选中八条已采集参考、七条已完成人审，不代表有八条可发布基准。分别报告参考就绪、审核完成与可执行覆盖；同源改写生成十种表达仍只增加问法，不增加十组独立业务条件。批量发送成功只完成执行操作，差异复核与争议关闭没有发生时，整个测试包仍未完成。

用一条任务检查七个包是否真的接通

选择“门店A九月净销售额”作为贯穿样本。设计包写明金额指标、完整月份和授权范围；构建包取得对应报表参考及水位；标注包确认口语改写未变成订单数；执行包发送问题且不附标准金额；复核包将实际条件、结果与参考并排；归因包依据差异定位；复测包保留新的运行及原始失败。

随后主动制造一次错误：把展示单位改为万元。数值查询本身应保持通过，回答或产物事实检查应失败。如果整题只有一个模糊红灯，工程师仍要从头查起；如果指标全部通过，说明断言漏了单位。工作包的完成门应要求这种故意错误能够定位，而非仅要求文件已经生成。

再制造一次参考争议，例如报表采用另一退款口径。正确处理是挂起数值裁决、修订参考版本，并保留原差异，不要求开发修改Agent去迎合错误答案。这种返回上游的分支必须进入流程，否则人工review会被迫把所有问题都压成通过或不通过。

经验感想

按工作包交接测试资产和证据：设计能执行，参考可复查，分母可追溯，失败可复测。用这些完成门组织工作，比只列场景名称更能发现实际缺项。

推荐标签

#智能问数 #Agent评测 #测试工程 #技术设计