测试用例 Agent 的门禁落地:一条需求缺口,应该挡住哪些用例?
用一个提交申请的合成示例,说明如何关联需求缺口与测试用例、限制依赖范围,并在规则确认后重新校验,避免局部缺口阻塞全部生成或被悄悄写成确定预期。
RESEARCH TOPIC
围绕验证证据、风险规则和回归结果,讨论 Merge / Release 的质量判据。
用一个提交申请的合成示例,说明如何关联需求缺口与测试用例、限制依赖范围,并在规则确认后重新校验,避免局部缺口阻塞全部生成或被悄悄写成确定预期。
测试用例生成被 Gate 卡住,未必都是模型能力问题。区分输入缺口、执行错误与用例质量,分开管理草稿生成和正式交付,并把未知项纳入覆盖报告。
从一次测试用例生成 Agent 的重构出发,讨论为什么 Prompt 无法保证执行流程,以及如何用 Execution Contract、Validator、Trace 和 Drift 检测把 Agent 的过程可靠性变成可验证问题。
Eval 只有进入 CI / Quality Gate 才真正参与交付。本文给出 Baseline、Hard Gate、Regression、Flaky Case、Artifact、Override 与发布准入的工程化设计。
把 Trace、Evidence、Failure Regression、Eval 收束到 Merge / Release Gate,让 Agent 的结果从“能运行”走向“可交付”。
为什么 Prompt 不能替代执行约束?从 Permission、Budget、Timeout、Side Effect、Evidence 到 Recovery,解释 Harness 如何成为 Agent Reliability 的边界。
Agent 最终通过并不代表过程可靠:从执行轨迹、独立证据、失败回归到 Quality Gate,讨论 Agent Reliability 的工程判断。
执行 → 证据 → 评测 → 回归 → 交付