本手册指导「基于测试用例执行 → 采集 → 判定 → 产出报告」这一阶段的流程与工具搭建。 组织形态：以确定性脚本/引擎为主，LLM 为辅助，二者边界见第 4 节。 输入：第一部分交付的声明式测试用例（符合《测试用例契约》）。 边界声明：本部分不设计用例、不判断「该测什么」。它只忠实执行契约中的用例并产出可信报告。
把第一部分产出的用例，通过自动化 harness 可重复地执行，采集结果、确定性地判定通过与否，并输出分维度、可回归的报告。
设计目标优先级：
- 可信——判定结果准确，不假绿不假红。
- 可重复——同一用例任意时刻跑结果一致（flaky 除外，且 flaky 本身要被暴露）。
- 可回归——每次 GitCode 发版能自动重跑，标出回归。
- 自动化——人工只看报告和分诊结论，不手工点。
关键资产：独立测试实例，可随意破坏/重置——这是「可重复」的物理前提，破坏性用例跑完即重置。
harness 的唯一合法输入是可执行 YAML 用例——即第一部分由文本用例（source of truth）依据 GitCode 规范编译出的派生物。字段以第一部分手册 §7.3《可执行用例契约》为准，此处复述关键结构以对齐。注意：GitCode 规范变更时，第一部分会重新编译 YAML，harness 消费新版本即可，无需改动执行逻辑。
id, dimension, priority, title, intent_ref
setup: { repo_fixture, secrets, variables, branch_protection }
workflow: <被测 workflow 内联定义>
trigger: { event, as, params }
fault_injection: { at, action, params, recovery_expectation } | null
assertions: [ { type: positive|negative|nonfunctional, target, ... } ]
teardown: { reset: fixture|full_instance|none }输入校验是第一道闸门：harness 启动时先用 schema 校验器逐条校验，不合规的用例直接拒收并回报第一部分，绝不「尽力执行」残缺用例——这是保证边界干净的纪律。
数据流：用例加载 → 触发适配 → 被测实例执行(可注入故障) → 采集 → 断言判定 → 落库 → 报告，破坏性用例执行后触发环境重置回到起点。
下列组件全部为确定性脚本/服务（LLM 不介入，见第 4 节）：
| 组件 | 职责 | 关键点 |
|---|---|---|
| 用例加载器 | 读取用例、schema 校验、按优先级/依赖排序 | 不合规即拒收 |
| 触发 + 身份适配器 | 把 trigger 意图翻译成对 GitCode 实例的 git + API 操作 |
隔离 GitCode 与 GitHub 的 API 差异；支持 maintainer / untrusted_contributor 两种身份 |
| 执行引擎 | 布置 setup、提交 workflow、驱动触发、等待完成 | 超时控制、并发调度 |
| 故障注入器 | 在 fault_injection.at 时机执行破坏动作 |
依赖对底层实例的操作权限 |
| 结果采集器 | 抓取 run 状态、job/step 结果、全量日志、产物、时间戳、副作用 | 日志需可全文扫描（负向断言用） |
| 断言引擎 | 按三类断言确定性判定 pass/fail | 见 §3.1 |
| 环境管理器 | 按 teardown.reset 级别隔离与重置，IaC 驱动 |
见第 5 节 |
| 报告器 | 聚合结果、生成分维度报告、回归 diff、flaky 标记 | 见第 6 节 |
positive：比对状态/产物/退出码是否符合预期。negative（安全命脉）：验证「不应发生」——全文扫描日志确认密钥未泄露、检查 fork 身份未获得 secret、确认无越权副作用。nonfunctional：校验时序（启动/完成耗时阈值）、并发隔离（N 个并发互不干扰）、错误信息包含可定位上下文。
铁律：pass/fail 的最终裁决只由断言引擎（确定性）做出。唯一例外是显式标注 eval: llm_assisted 的易用性可理解性判据，其 LLM 评分作为参考信号，仍需落到一个可复核的确定性阈值上，不由 LLM 直接判 fail。
LLM 在本阶段是辅助，不进入执行与判定主链路。明确划分如下：
| 环节 | 由谁做 | 说明 |
|---|---|---|
| 用例加载、校验 | 脚本 | 确定性 |
| 触发、身份切换 | 脚本 | 确定性 |
| 故障注入 | 脚本 | 确定性 |
| 结果采集 | 脚本 | 确定性 |
| pass/fail 判定 | 脚本（断言引擎） | 绝不交给 LLM |
| 环境重置 | 脚本 / IaC | 确定性 |
| 报告聚合、回归 diff、flaky 标记 | 脚本 | 确定性 |
| 失败根因初判 | LLM 辅助 | 读失败日志，分类「产品 bug / 用例问题 / 环境问题」，供人分诊，不改判定结果 |
| 失败衍生用例 | LLM 辅助 | 由已发现缺陷举一反三生成变体，回流第一部分评审，不自行入执行集 |
| 易用性可理解性评判 | LLM 辅助 | 扮演「从 GitHub 迁移的新手」评估错误信息/文档，产出参考评分 |
一句话原则：凡是需要「可信、可复现、可追责」的结论（尤其 pass/fail），由确定性脚本负责；凡是「加速人类判断」的非裁决性工作，交给 LLM。LLM 的产物永远是建议或信号，不是判定。
状态污染是自动化测试最大的隐性 bug 源，默认隔离：
| 用例类型 | 隔离/重置级别 (teardown.reset) |
理由 |
|---|---|---|
| 功能 / 兼容性 | fixture：per-test 临时仓库，跑完删 |
仓库便宜，隔离干净 |
| 破坏性稳定性 / 安全 | full_instance：per-suite 或 per-run 全量重置 |
可能污染 runner、耗尽资源、动系统状态 |
- 用 IaC（Terraform/Ansible 等）管理实例，harness 可编程触发 reset，不依赖人工重装。
- 越晚补越痛：环境重置看似脏活，却是「可重复」承诺的兑现前提，建议在打通最小闭环时就一并实现。
报告不是终点，是回归的起点。三项必备机制：
每次 run 落一条结构化记录：每条用例的 id / dimension / priority / result / duration / log_fingerprint / assertion_details。结构化是回归 diff 与趋势分析的前提。
报告顶层给分维度通过率（如：完备性 92% / 稳定性 85% / 安全性 78% / 易用性 90%），对照第一部分的质量门禁逐维度判断能否上线，而不是一个混合总通过率。P0 失败单独高亮为 blocker。
每次 run 与基线（或上一次）对比，自动标出「上版本绿、本版本红」的用例——这是上线后持续盯 GitCode 新版本的回归网。
对（尤其稳定性维度的）用例重复跑 N 次，时绿时红者标记为 flaky。二义性必须暴露：要么是 GitCode 真不稳定（即稳定性缺陷），要么是用例不可靠——两者都需处置，不能被偶发失败淹没。
把整套 harness 挂到 GitCode 每次发版的流水线上，从「一次性验收」升级为「常驻回归网」。每次新版本自动重跑全量用例、出分维度报告、标回归——这是这个功能长期质量的持续保障。
不要一次把 harness 做满，先打通最小闭环再堆维度：
- 最小闭环：用例加载 + 触发适配器 + 最简
positive断言 + 落库，拿 3~5 条纯功能用例把「声明→触发→采集→判定→落库」跑通。 - 补隔离：尽早实现环境管理（fixture + full_instance 两级重置）。
- 加维度：依次接入
negative断言（安全）、故障注入（稳定性）、nonfunctional采集。 - 接 LLM 辅助：失败根因初判 → 易用性评判 → 失败衍生用例。
- CI 化：挂到 GitCode 发版，形成回归闭环。
- 能对不合规用例正确拒收并回报第一部分。
- 支持 maintainer / untrusted_contributor 两种触发身份。
- 三类断言均可确定性判定；pass/fail 不经 LLM。
- 破坏性用例执行后按声明级别自动重置，无跨用例污染。
- 报告含分维度通过率、回归 diff、flaky 标记。
- LLM 辅助产出均为建议/信号，不参与判定裁决。
- 整套可在 GitCode 发版流水线中自动触发。