# 用例可执行性标准（Executability）

> "看似专业但不可执行"是当前最大质量问题。本标准是**框架级硬标准**，所有产出用例的 Skill（`test-case-writing`、`test-case-review`、`bug-analysis` 的回归用例建议）统一遵守。
>
> 本标准同时是评测的一票否决指标：不可执行的用例，覆盖再全也计零分。

## 1. 失败模式——AI 为什么会生成不可执行的用例

| # | 失败模式 | 典型表现 |
|---|---------|---------|
| 1 | 凭空想象系统 | 没见过真实页面 / 接口，凭 PRD 与通用经验虚构入口、字段、文案 |
| 2 | 写给评审者而非执行者 | 追求覆盖矩阵漂亮，不关心执行者下一步能不能操作 |
| 3 | 前置不可得 | 默认环境 / 账号 / 数据随手就有，不交代从哪获得 |
| 4 | 判定不可操作 | 预期结果写"功能正常"这类模糊判定；异步行为无判定时限 |
| 5 | 断言超出验证强度 | 两个样本就断言"全局唯一"；UI 操作就断言数据库约束 |

## 2. 八条硬标准

1. **代码优先**——有代码必读代码，以实现为行为基线，杜绝凭文档想象（失败模式 1 的根治手段）
2. **执行模型判定**——有 UI 独立执行 / 无 UI 转"测试-开发协作清单"，开工先判定
3. **具体数据**——操作步骤嵌真实编号 / 字段值，禁止占位符（`{xxx}`、`<xxx>`、`某某`）
4. **页面可达性**——每个入口写清从哪里到达；未知 → 澄清 + TODO
5. **判定时限**——异步行为必须写"多久不发生即判失败"
6. **断言范围 ≤ 验证强度**——用例名称与实际能证明的范围一致
7. **前置可得性**——环境 / 账号未知时列"TODO：向谁索取"，不省略
8. **零上下文新人复述**——定稿自检：没读过需求、没人讲解的人只拿这份文件能开工

## 3. 定稿自检清单（逐条执行）

以"零上下文新人"（没读过需求文档、没人讲解、只拿到这份文件）为标准：

- [ ] 随机抽 3 条用例复述：验证什么、从打开什么系统开始怎么操作、怎么算通过——任何一步卡住（不认识某个词 / 不知道页面在哪 / 不知道怎么造前置状态 / 不知道等多久算失败）→ 修复正文或补导读区，而不是降低标准
- [ ] 导读四件套齐全：功能简介+角色表 / 环境与账号表（未知列 TODO 指明找谁）/ 术语表 / 图例
- [ ] 正文零代码内部：无 `文件:行`、SDK 符号、错误码常量、函数名（代码证据隔离在附录）
- [ ] 操作步骤嵌具体数据，无占位符
- [ ] 每个被测入口首次出现时写明到达路径
- [ ] 含异步预期的用例逐条有判定时限
- [ ] 用例名称断言不超出步骤实际验证强度
- [ ] 每条用例可独立执行（有 UI）或可整包交开发协作执行（无 UI）

## 4. 违反即不可执行的红线（Eval 判分依据）

以下任一命中，该条用例在 Eval 中判为不可执行：

1. 操作步骤或预期结果包含占位符（`{xxx}`、`<xxx>`、"某数据"）
2. 第一步操作指向不存在的入口（虚构页面 / 未说明到达路径且无 TODO）
3. 预期结果为"功能正常 / 正常显示"等无判定信息的表述
4. 异步预期无判定时限
5. 前置条件不可获得且无 TODO 指引（需要不存在的账号 / 数据却未说明来源）
6. 用例名称断言超出步骤能证明的范围

## 5. 引用方式

各 SKILL.md 的用例产出 / 审查 / 定稿步骤标注"此时执行本文件全部检查项"，相对路径 `../core/executability.md`。

第二个消费场景是**执行型 skill 的转换闸门**：`automated-e2e-testing`、`api-testing` 把存量用例转为自动化脚本前，对待转用例逐条过第 4 节红线——不可执行的用例直接翻译成脚本只会产出"幻觉自动化"（脚本能跑，测的不是真实系统行为）；命中红线的用例先补齐再转，补不了的明确暂缓进遗留清单，不静默硬转。