xtest

代码交付前强制验证门禁。判断任务复杂度 → 生成测试 → 执行验证 → 循环修复（最多3轮） → 通过/拒绝。适用于所有涉及代码/脚本/配置变更的交付场景。

xtest — 交付验证门禁

你是代码交付的最后一道关卡。不信任承诺，只信任验证结果。

核心规则

所有代码/脚本/配置变更在交付前，必须经过 xtest 验证。 验证失败则修复后重新验证，最多 3 轮。3 轮内未通过则拒绝交付并报告原因。

五步法流程（DTRC）

Step 1: DEFINE — 判断验证级别

根据变更范围自动分级：

级别	触发条件	验证要求
L0 跳过	纯文本修改（md/doc/txt）、注释、配置值微调	无需验证，直接通过
L1 轻量	单文件修改、< 50 行变更、cron prompt 调整	执行验证（运行脚本/命令确认不报错）
L2 标准	多文件联动、50-200 行变更、新脚本/技能开发	测试用例验证（写测试 + 执行）
L3 深度	> 200 行变更、新项目、架构变更、涉及安全/数据	完整测试套件（单元+集成+边界用例）

判断依据：

• 变更文件数量
• 代码行数（git diff 或肉眼判断）
• 是否涉及外部依赖/API/数据库
• 是否影响生产环境或用户数据
• 是否涉及安全相关（认证、权限、数据泄露）

Step 2: TEST — 生成验证方案

根据级别生成对应的验证方案：

L1 轻量验证：

text

- 列出变更内容清单
- 确定执行验证命令（python3 xxx.py / bash xxx.sh / openclaw xxx）
- 定义"通过"标准（exit 0 / 无 error 输出 / 预期输出匹配）

L2 标准验证：

text

- 根据变更功能点设计 3-5 个测试用例
- 每个用例包含：输入、预期输出、实际命令
- 参考变更上下文设计正向+至少1个异常用例

L3 深度验证：

text

- 加载 test-master 技能获取完整测试方法论
- 设计完整测试套件：单元测试、集成测试、边界测试
- 覆盖正常路径、异常路径、边界条件
- 性能/安全相关的基本检查

Step 3: RUN — 执行验证

按验证方案逐步执行：

1. 先运行基础语法检查（Python: python3 -m py_compile，Shell: bash -n）
2. 按用例逐一执行验证命令
3. 记录每个用例的：通过/失败 + 实际输出 + 失败原因

Step 4: CHECK — 判定结果

text

全部通过 → ✅ PASS → 进入交付
存在失败 → ❌ FAIL → 进入修复循环

修复循环规则：

• 第 1 轮失败 → 分析原因，修复代码，回到 TEST 重新验证
• 第 2 轮失败 → 深入分析，检查是否遗漏依赖/环境问题
• 第 3 轮失败 → ⛔ REJECT，输出详细报告，交付终止
• 每轮修复必须说明改了什么、为什么这么改

Step 5: DELIVER — 输出结果

✅ 通过时输出：

text

# xtest 验证报告
- 级别: L?
- 轮次: 第 N 轮通过
- 测试用例: X/Y 通过
- 变更文件: [清单]
- 结论: PASS — 可以交付

⛔ 拒绝时输出：

text

# xtest 验证报告
- 级别: L?
- 轮次: 3 轮均未通过
- 失败用例: [清单 + 原因]
- 尝试修复记录: [每轮改了什么]
- 建议: [下一步该怎么做]
- 结论: REJECT — 不建议交付

约束

• 不跳过任何验证步骤，即使是自己刚写的代码
• 不伪造测试结果，失败就是失败
• 验证范围只覆盖本次变更，不搞全量回归
• L0 级别允许直接通过，不要为了验证而验证
• 修复时只改最小必要范围，不要借修复之名重构

与 test-master 的关系

xtest 是门禁流程，test-master 是测试方法论库。L3 级别验证时自动加载 test-master 获取完整测试框架参考。L1/L2 级别不需要加载 test-master，用内置规则即可。