我们不仅仅要靠AI设计用例，还要设计出可执行、有价值的用例
1.从测试点到测试用例
测试点是一些值得/需要验证的业务风险或业务结果，而测试用例则是要覆盖这些测试点；
|--------|-----------------------------|
| 不合格写法 | 改进方向 |
| 检查某个按钮 | 某角色完成用户目标后，可观察业务结果符合已确认规则 |
| 检查某个页面 | 在明确前置状态下，关键数据、状态或空态可以被判断 |
| 检查某个入口 | 某角色尝试受限动作时，出现有证据的允许、拦截或授权结果 |
判断测试点是否成立，可以连续问3次：
1.它验证的业务风险是什么？
2.它能追溯到哪条流程或页面事实？
3.它能否写成真实动作与可观察预期？
设计时还要区分确定性和探索性：
|-------|---------------|-------------|----------------|
| 类型 | 来源要求 | 预期写法 | 执行后的处理 |
| 确定性场景 | 已验证页面事实或明确规则 | 客观、可观察的确定结果 | 按证据判断PASS或FAIL |
| 探索性场景 | 推断、候选、问题或受阻风险 | 候选预期和验证路径 | 确认后升级、冲突或受阻时回流 |
探索性并不代表低质量，它只是诚实承认规则尚未得到证据支持。真正的低质量，是把未知包装成确定预期。
用例设计包含2个不同层次：
1.测试点负责回答"哪些风险必须被验证"。
2.测试场景负责回答"在什么角色和前置下，怎样通过一段完整操作验证这些风险"。
先建立测试点，再按用户目标、会话和状态链接把相关检查点组织成场景，可以同时避免覆盖遗漏和碎片化用例。
八维覆盖和依赖闭合
从正向、异常、边界、权限、状态、配置、数据一致性以及网络与加载异常八个维度检查风险。八维不是要求每个功能机械生产八条测试用例，而是要求每个维度都经过核对，并留下覆盖、不适用理由或待确认状态。
测试点保持细粒度，场景则围绕一个可独立执行的用户目标聚合检查点。共享同一角色、会话和状态链的动作通常应组成一条完整旅程，而不是被拆成依赖执行的碎片。
每条场景至少闭合一下内容：
|-------|------------------------|
| 项目 | 合格标准 |
| 来源 | 能回到业务流程、风险或页面事实 |
| 角色与会话 | 身份和初始状态明确，不依赖遗留Cookie |
| 前置与数据 | 由本场景建立，或引用已验证的稳定数据 |
| 操作 | 描述用户动作，不提前绑定脆弱的技术定位 |
| 预期 | 能通过页面、URL、弹窗、状态或数据变化观察 |
| 本轮对象 | 能识别本轮创建或操作的具体业务对象 |
| 清理 | 只处理本轮创建且确认所有权的数据 |
| 追溯 | 测试点能找到场景，场景也能回到来源 |
2.提示词示例：
输入应同时包含本轮业务模型和已验证页面事实，让Agent能够确定规则、候选解释和待确认风险。
请基于业务流程和已验证页面事实设计Web测试，不生成自动化代码。
先按正向、异常、边界、权限、状态、配置、数据一致性以及网络与加载异常核对风险。
测试点负责覆盖与追溯；场景围绕可独立执行的用户目标聚合相关检查点。
每条场景写明来源、角色、前置来源、测试数据、用户动作、可观察预期。
本轮对象的识别方式和清理责任。
没有已验证事实支持的内容只能进入探索性场景，并写明候选预期和验证路径。
最后检查测试点和场景的双向追溯、重复内容和跨场景依赖
SKILL.md示例
name: web-test-03-case-design
description: >
基于已梳理的业务流程基线和已验证页面事实，设计 Web 手工测试：测试点负责覆盖与追溯，
场景围绕可独立执行的用户目标聚合检查点。不生成自动化代码。
当用户说写测试用例、设计用例、出用例、测试设计、场景设计、测试点、把流程变成用例、
按业务流程写用例、给某功能补测试覆盖、列出要测什么时，都应使用本技能。
即使用户没说出「用例」而说「开始测」「把刚才梳理的变成可执行的检查」，也要主动使用，
而不是跳回探索或只给口头建议。
缺少流程基线时先走业务流程梳理（web-test-02-business-flow），不要在本技能里临场编流程；
探索摸底走系统探索（web-test-01-system-explore），不要用本技能去点页面攒事实。
compatibility: >
主要消费上游流程基线（如 web-test-02-business-flow 的 flow-*.md）和探索报告证据；
本阶段不操作页面，无浏览器也可运行。
Web 测试设计（流程基线 → 测试点 → 场景）
探索回答「页面上有什么」，流程梳理回答「按什么顺序发生、在哪里分叉」。本阶段回答「要检查什么、怎样独立执行」。产出是**可追溯的测试点**加上**可独立执行的场景**，不是自动化脚本，也不是另一份流程说明书。
两层拆开是因为它们解决不同的问题。测试点保证覆盖能对上流程基线的取舍；场景保证执行的人（或下一轮）能单独跑完一个用户目标，而不必先读完全部检查清单。混在一起，得到的往往是既不能执行、也无法回答「测了哪条分支」的长剧本。
预期必须能指回已验证事实。没有事实支撑的内容只能进探索性场景，并写明候选预期和验证路径------否则后面失败了分不清是产品错了还是设计猜错了。
本阶段**不生成自动化代码**，不重新探索页面，不重写业务流程。
每次任务先解析
从用户消息与上下文中解析以下参数；缺省时用默认值，**会改变设计边界的项**先简短确认再继续：
| 参数 | 含义 | 缺省策略 |
| ---- | ---------------------------------------- | -------------------------------------------------------- |
| 业务目标 | 要设计哪件事（与流程基线同一条） | 必填；用户未给则从流程基线/上下文取一条并说明 |
| 事实来源 | 流程基线 / 探索报告 / 需求文档 | 优先复用同项目 `flow-*.md`；没有基线则不要临场编流程，先提示走上游 |
| 设计范围 | `accepted`（只收「进入设计」的分支+主线正向）/ `full`（含探索性） | 默认 `full`：正式场景收进入项，待确认项进探索性场景，不进入项只在「未纳入」交代 |
| 输出粒度 | `points`（只测试点）/ `cases`（点+场景） | 默认 `cases` |
| 环境约束 | 能否造数、下单、留脏数据 | 沿用上游允许/禁止清单；禁止构造的检查点不要写成正式场景，降为探索性或未纳入 |
没有流程基线时：不要用「这类系统一般都这样」补流程。用户坚持本轮就出用例，则只基于已验证事实设计，其余全部标探索性，并在范围里写明缺口。
与上游对齐
沿用同一套事实标签，场景里的预期才能和基线、探索报告对得上：
| 字段 | 取值 |
| ------ | ----------------------------------------------------------------- |
| type | `fact` 本轮或上游直接观察 / `inference` 据观察推断未证实 / `question` 证据不足待探明 |
| status | `verified` 可复现 / `candidate` 有线索待补验 / `blocked` 受权限或环境阻塞 / `contradicted` 与已有事实冲突 |
引用上游编号用原号（`S4`、`B2`、`E10`、`Q1`、`R1`）。本轮测试点编号 `TP1`、`TP2`...，场景 `SC1`、`SC2`...。编号是为了让追溯矩阵能一行看完，评审时不用在正文里来回搜。
正式测试点只从这些东西来：
主流程成功路径（正向）
分支清单里 `design_decision: 进入` 的项
`待确认` 的分支不升格为正式 TP，进探索性场景并挂回对应 `Q`。`不进入` 的分支写进「未纳入」，不要删掉------取舍本身也是设计结果。
工作流程
1. 吃进基线
先读流程基线的「业务目标与范围」「取舍小结」「与事实的差距」，不要从主流程第一步重新叙述一遍。确认角色、进入条件、结束判据，以及哪些 B 已决定进入设计。
基线与探索报告冲突时，以 `contradicted` / `Q` 为准，不要悄悄选一边写成预期。
2. 按八类核对覆盖
在写点之前，用下面八类把风险过一遍。这不是再发明一套分类，而是避免只把基线里已写出的 B 抄成 TP、漏掉「进入了但没写成检查」的洞。分支类与流程梳理对齐（`字段` 即边界，`环境` 含配置与网络加载，`操作时序` = 重复操作 + 并发竞态），并额外核主线正向，便于 B → TP 对号：
| # | 类别 | 核对什么 |
| - | ----- | ----------------------------------------- |
| 1 | 正向 | 主线 S1...Sn 走通时，每步可观察的成功响应与状态变化是否都有检查点 |
| 2 | 权限 | 换角色 / 未登录 / 未开通时，拦在哪一步 |
| 3 | 字段 | 必填、格式、精度、上下限、单位、禁用态 |
| 4 | 状态 | 对象合法/非法状态下动作是否被允许 |
| 5 | 数据 | 空态 / 单条 / 多条 / 极值 / 精度 / 排序分页筛选，以及账实是否一致 |
| 6 | 环境 | 语言、时区、币种/交易对、端、主题、模式/杠杆等配置，以及网络与加载时序 |
| 7 | 异常 | 服务端报错、超时、余额或库存不足、规则拦截 |
| 8 | 操作时序 | 连点、刷新重来、回退、多标签；两端同时改同一对象、提交前状态已变 |
某一类在基线里是「进入」但还没有对应 TP，补点。某一类完全没有事实，不要编预期，记到探索性或未纳入，并指回 `Q`。
3. 写测试点
一个测试点只断言一件可观察的事。它负责覆盖与追溯，不负责写成可以照着点的剧本------剧本是场景的事。
能独立失败的观察就拆开（按钮禁用 vs 提示文案可能一个过一个不过）。同一 UI 状态的两个表象可以写在一个点的 `expected` 里，但 `claim` 仍只说一件事。
4. 聚合成场景
场景的单位是**可独立执行的用户目标**（如「用最小数量市价开多并确认持仓」），不是「把所有字段校验塞进一条」。
聚合原则：
同一前置、同一份测试数据、连续操作才能观察到的检查点，放进同一条场景。
会弄脏关键状态、或失败后阻断后续检查的点，单独成场景，避免一条红了后面全没法跑。
每条场景必须能从声明的前置开始，不依赖「上一条场景刚好留下了什么」。共享夹具可以，但要写明，并指定清理责任。
每条场景写清：来源、角色、前置及其来源、测试数据、用户动作、可观察预期、本轮产生对象的识别方式、清理责任。缺这几项，执行时就会在「用谁的号、用什么数、测完仓位谁平」上卡住。
5. 没有事实的，只进探索性场景
`inference` / `question` / `blocked` 不能当正式预期。探索性场景允许跑，但必须同时写：
候选预期（现在猜会怎样，标明是猜）
验证路径（怎样观察才能把它变成 `fact`）
正式场景里不要夹带这类句子。混在一起，报告上的「通过」会把猜测当成已证实规则。
6. 收尾检查
交付前做三件事，漏做会在执行期才爆：
**双向追溯**：每个正式 TP 至少被一条正式场景覆盖；每个正式场景的检查点都能指回 TP。对不上的，不是漏场景就是 TP 写废了。
**去重**：两条场景不要验同一件可观察事实；有意回归同一点时，写明为什么（不同角色、不同数据）。
**跨场景依赖**：若 SC2 必须在 SC1 之后，要么把依赖写成显式夹具，要么合并，要么拆掉。隐式依赖会让「单条失败/换人执行/重跑」全部不可用。
7. 交付
按下文模板写报告，放到本 skill 文件夹，命名 `cases-<业务目标缩写>-<YYYY-MM-DD>.md`，便于和 `flow-*.md`、探索报告对照。同时在对话里给要点摘要（覆盖了哪些进入分支、几条正式场景、几条探索性、未纳入什么），不要只丢文件路径。
记录格式
测试点：
```text
- id: TP<n>
covers: S<n> 或 B<n>（可多项）
category: 正向 | 权限 | 字段 | 状态 | 数据 | 环境 | 异常 | 操作时序
claim: <要验证的一句话>
expected: <可观察预期，文案用原话>
source: <E/F/S/B>
type: fact | inference | question
status: verified | candidate | blocked | contradicted
```
`type` 不是 `fact` 或 `status` 不是 `verified` 的项，不要放进正式场景。
场景：
```text
- id: SC<n>
kind: formal | exploratory
goal: <可独立执行的用户目标>
covers: TP<n>, TP<m>
source: <流程基线文件 / 探索报告>
actor: <角色>
preconditions: <前置状态；每项带来源>
data: <测试数据，具体到值>
steps:
- <用户动作，具体到点了什么/填了什么>
expected:
- <对应动作或终点的可观察结果>
artifacts: <本轮对象：是什么、如何识别（id/文案/位置）>
cleanup: <谁清理、怎么清；不清则写风险>
```
探索性场景在以上字段外再加：
```text
candidate_expected: <候选预期，标明未证实>
verify_path: <怎样观察/复测才能升格为 fact>
blocked_by: <Q 编号或禁止动作，可选>
```
**示例（取自合约下单，说明字段粒度）**
```text
- id: TP4
covers: B2
category: 字段
claim: 数量为 0 时不能提交开仓
expected: 确认按钮 disabled，提示「请输入数量」
source: E10 / B2
type: fact
status: verified
- id: SC2
kind: formal
goal: 用非法数量 0 验证开仓提交被拦
covers: TP4
source: flow-u-futures-open-close-2026-09-06.md
actor: 已登录用户
preconditions: 已在 BTCUSDT 永续交易页，全仓/分仓/10x，合约账户有可用余额（S2）
data: 数量 0
steps:
- 下单区数量填 0，观察「买入/做多」
expected:
- 按钮 disabled，可见提示「请输入数量」；持仓数不变
artifacts: 无新对象
cleanup: 无需清理；不要为了「试试能不能提交」去改数量下真单
```
报告模板
输出用以下结构，章节名不要改------和上游探索报告、流程基线对齐，串起来才能互相引用：
```markdown
测试设计：<业务目标>
范围
业务目标：
角色：
事实来源（流程基线 / 探索报告）：
设计范围 / 输出粒度 / 环境约束：
进入设计的分支：（B 编号）
本轮不测：（B 编号 + 基线原由）
测试点
（TP1...TPn，按八类分组；正式点 status 均为 verified）
场景
（SC 中 kind=formal 的条目，按记录格式）
探索性场景
（kind=exploratory；每条含 candidate_expected 与 verify_path）
追溯矩阵
| TP | 来源 S/B | 覆盖场景 | 类型 |
| -- | ------- | -------- | ---- |
重复与依赖
重复检查点：无 / 列出并说明为何保留
跨场景依赖：无 / 列出夹具与清理责任
未纳入
（不进入的 B、环境不允许构造的点、仍缺事实且本轮不做探索的 Q）
```
常见跑偏
**把测试点写成场景**：测试点没有步骤、数据、清理。出现「打开页面，然后......」就已经越界。
**把场景写成无追溯剧本**：步骤很全但 `covers` 为空，无法回答覆盖了哪条分支。
**猜预期**：读起来像规则的句子，检查 `source` 和 `status`；没有 verified 事实就降到探索性。
**待确认升格**：`design_decision: 待确认` 的 B 不能变成正式 TP。
**隐式依赖**：SC2 假设 SC1 留下了仓位/订单/余额，却没写前置和清理------换人重跑会失败。
**一条场景吞掉全部 TP**：不可独立执行，失败后也无法定位。
**预期不可观察**：「后台应该扣了保证金」但页面没有对应展示，就不是本阶段的预期。
**顺便写自动化 / 顺便去点页面**：那是别的阶段。本技能交付到报告为止。
**重写流程**：主线与分支以基线为准；发现基线有洞，记回 `Q` 或建议补梳理，不要在用例里改流程。
3.内容评审
建议分4轮检查
|-------|---------------------------------|------------------------------|
| 检查轮次 | 动态取样方式 | 需要回答的问题 |
| 来源与覆盖 | 选择一个核心目标、一个高风险分支，再查看八维核对结果 | 需求、风险、测试点之间是否联通；未覆盖和不适用是否有理由 |
| 场景闭包 | 选择一条状态或数据依赖较多的场景 | 角色、会话、数据前置和清理是否能在本场景或显示旅程中闭合 |
| 预期与证据 | 若两类同时存在，各选一条确定性和探索性场景；只有一类时检查原因 | 确定预期是否有来源；未知是否仍以候选预期和验证路径呈现 |
| 粒度与追溯 | 选择步骤高度相似或共享路径的场景 | 是否过度拆分、重复生成；测试点与场景能否双向找到对方 |