spec-test-usecase

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Spec 测试用例（V2：Usecase）

Spec Test Cases (V2: Usecase)

把

requirements/solution.md

requirements/prd.md

中的验收口径（AC）转成 可执行、可判定、可追溯、可机器提取 的手工测试用例结构。

权威口径：

design/aisdlc_spec_verification.md

Convert the acceptance criteria (AC) in

requirements/solution.md

requirements/prd.md

into an executable, determinable, traceable, machine-extractable manual test case structure.

Authoritative specification:

design/aisdlc_spec_verification.md

硬门禁（必须遵守）

Hard Access Control (Must Comply)

先定位再读写：必须先运行
```
spec-context
```
得到并回显
```
FEATURE_DIR=...
```
；失败即停止，禁止猜路径。

必读项目级 memory：

project/memory/product.md

、

project/memory/tech.md

、

project/memory/glossary.md

；读不到必须写

CONTEXT GAP

。

需求级最小输入：

{FEATURE_DIR}/requirements/solution.md

或

{FEATURE_DIR}/requirements/prd.md

至少其一必须存在；否则停止并写

CONTEXT GAP

。

强制结构化：每条用例必须满足“编号/类型/步骤+断言点/追溯/套件”最小结构，不允许用自由散文代替。
禁止越权路由：完成后只输出
```
ROUTER_SUMMARY
```
，下一步由
```
using-aisdlc
```
决策。

Locate path first before reading/writing: You must first run
```
spec-context
```
to get and echo
```
FEATURE_DIR=...
```
; stop immediately if it fails, guessing paths is prohibited.

Must read project-level memory:

project/memory/product.md

project/memory/tech.md

project/memory/glossary.md

; write

CONTEXT GAP

if any of them cannot be read.

Minimum requirement-level input: At least one of
```
{FEATURE_DIR}/requirements/solution.md
```
or
```
{FEATURE_DIR}/requirements/prd.md
```
must exist; otherwise stop and write
```
CONTEXT GAP
```
.
Mandatory structuring: Each test case must meet the minimum structure of "ID/type/steps + assertion points/traceability/suite", free prose is not allowed as a replacement.
Unauthorized routing prohibited: Only output
```
ROUTER_SUMMARY
```
after completion, the next step is decided by
```
using-aisdlc
```
.

红旗清单（出现任一条就停止）

Red Flag Checklist (Stop if Any Item Occurs)

没有回显
```
FEATURE_DIR=...
```
就开始编写用例
想用“覆盖登录/覆盖支付”这种描述代替
```
TC-*
```
可执行步骤
想把“预期结果”写成主观判断（如“看起来正常”）而不是可观测断言点
想用
```
TBD/待补
```
代替 AC 追溯链接

Start writing test cases without echoing
```
FEATURE_DIR=...
```
Try to use descriptions like "cover login/cover payment" to replace
```
TC-*
```
executable steps
Try to write "expected results" as subjective judgments (such as "looks normal") instead of observable assertion points
Try to use
```
TBD/to be supplemented
```
to replace AC traceability links

唯一做法（PowerShell）

The Only Operation Method (PowerShell)

1) 获取

FEATURE_DIR

1) Get

FEATURE_DIR

powershell

. ".\skills\spec-context\scripts\spec-common.ps1"
$context = Get-SpecContext
$FEATURE_DIR = $context.FEATURE_DIR
Write-Host "FEATURE_DIR=$FEATURE_DIR"

powershell

. ".\skills\spec-context\scripts\spec-common.ps1"
$context = Get-SpecContext
$FEATURE_DIR = $context.FEATURE_DIR
Write-Host "FEATURE_DIR=$FEATURE_DIR"

2) 目标输出路径

2) Target Output Path

powershell

$out = Join-Path $FEATURE_DIR "verification/usecase.md"
Write-Host "OUTPUT=$out"

powershell

$out = Join-Path $FEATURE_DIR "verification/usecase.md"
Write-Host "OUTPUT=$out"

用例结构（强制，自动化友好）

Test Case Structure (Mandatory, Automation Friendly)

每条用例必须包含：

稳定编号：
```
TC-<DOMAIN>-<NNN>
```
（例：
```
TC-AUTH-001
```
）。编号发布后不随意改动。
优先级：P0 / P1 / P2
类型：UI / API / 集成 / 回归（可按需扩展，但必须可枚举）
标签：影响面/模块/风险（数组形式）
追溯：至少链接到 1 条 AC（来自
```
solution/prd
```
）
套件：至少标注
```
smoke
```
/
```
regression
```
（如有
```
targeted
```
也可标注）
前置条件：可准备、可执行（含账号/权限/开关/环境）
测试数据：给出示例值或生成方式（禁止“自行准备”）
步骤：逐步编号；每步必须包含预期结果（可观测断言点）
后置条件/清理：会污染数据时必须写清楚

Each test case must include:

Stable ID:
```
TC-<DOMAIN>-<NNN>
```
(example:
```
TC-AUTH-001
```
). Do not change the ID randomly after release.
Priority: P0 / P1 / P2
Type: UI / API / Integration / Regression (can be extended as needed, but must be enumerable)
Tags: Impact scope/module/risk (in array format)
Traceability: Link to at least 1 AC (from
```
solution/prd
```
)
Suite: Mark at least
```
smoke
```
/
```
regression
```
(you can also mark
```
targeted
```
if applicable)
Preconditions: Preparable and executable (including account/permission/switch/environment)
Test data: Provide sample values or generation methods ("prepare by yourself" is prohibited)
Steps: Numbered step by step; each step must include expected results (observable assertion points)
Post conditions/Cleanup: Must be clearly written when data will be polluted

最小模板（单条用例）

Minimum Template (Single Test Case)

markdown

undefined

markdown

undefined

TC-XXX-001: [标题]

TC-XXX-001: [Title]

优先级： P0 | P1 | P2 类型： UI | API | 集成 | 回归 标签： [tag1, tag2] 追溯： AC-001（

requirements/prd.md#...

或

requirements/solution.md#...

） 套件： smoke, regression

requirements/prd.md#...

requirements/solution.md#...

) Suite: smoke, regression

目标

Objective

[一句话说明验证什么]

[One sentence stating what to verify]

前置条件

Preconditions

测试数据

Test Data

测试步骤

Test Steps

... 预期： ...
... 预期： ...

... Expected: ...
... Expected: ...

后置条件/清理

Post conditions/Cleanup

---

---

DoD 自检（V2-DoD）

DoD Self-Check (V2-DoD)

P0/P1 用例均“可执行”：前置条件与数据不缺失
每一步都有“预期结果”（可观测、可判定）
AC 覆盖关系明确（至少能回答“哪些 AC 被哪些用例覆盖”）
用例结构满足后续自动化生成的最小信息要求（编号/类型/步骤/断言点）

All P0/P1 test cases are "executable": preconditions and data are not missing
Each step has "expected results" (observable, determinable)
AC coverage relationship is clear (at least can answer "which AC are covered by which test cases")
Test case structure meets the minimum information requirements for subsequent automated generation (ID/type/steps/assertion points)

完成后输出与自动路由（必须执行）

Output and Automatic Routing After Completion (Must Be Executed)

usecase.md

落盘后，必须完成以下动作（按顺序，不可省略）：

输出 ROUTER_SUMMARY（YAML 形态，供 Router 决策）：

yaml

ROUTER_SUMMARY:
  stage: V2
  artifacts:
    - "{FEATURE_DIR}/verification/usecase.md"
  needs_human_review: false
  blocked: false
  block_reason: ""
  notes: "软检查点：测试用例已生成/更新；Router 可继续自动推进到 V3（spec-test-suites）或 V4（spec-test-execute）"

立即执行
using-aisdlc
：将上述
```
ROUTER_SUMMARY
```
作为路由输入传递给 using-aisdlc，由 Router 判定下一步并自动推进（无需等待用户说「继续」）。
- 若 Router 判定可自动续跑：在同一轮对话内继续执行下一步 worker skill（如 V3、V4 等）
- 若 Router 触发硬中断：停下并输出阻断原因、需要的输入、候选下一步
对话输出：在调用 using-aisdlc 前，可简短说明「本阶段产物已落盘，正在调用 using-aisdlc 路由下一步。」

name: spec-test-usecase description: Use when 需要在 sdlc-dev 的 Spec Pack 中生成/更新 verification 阶段 V2 测试用例（verification/usecase.md），并且必须保证用例结构可执行、每步有预期且可追溯 AC。

After

usecase.md

is saved to disk, must complete the following actions (in order, cannot be omitted):

Output ROUTER_SUMMARY (in YAML format, for Router decision making):

yaml

ROUTER_SUMMARY:
  stage: V2
  artifacts:
    - "{FEATURE_DIR}/verification/usecase.md"
  needs_human_review: false
  blocked: false
  block_reason: ""
  notes: "Soft checkpoint: Test cases have been generated/updated; Router can continue to automatically advance to V3 (spec-test-suites) or V4 (spec-test-execute)"

Execute
using-aisdlc
immediately: Pass the above
```
ROUTER_SUMMARY
```
as routing input to using-aisdlc, the Router will decide the next step and advance automatically (no need to wait for the user to say "continue").
- If the Router determines that automatic continuous running is possible: Continue to execute the next worker skill in the same round of conversation (such as V3, V4, etc.)
- If the Router triggers a hard interrupt: Stop and output the blocking reason, required input, and candidate next steps
Conversation output: Before calling using-aisdlc, you can briefly state "The product of this phase has been saved to disk, calling using-aisdlc to route the next step."

name: spec-test-usecase description: Use when you need to generate or update V2 test cases (verification/usecase.md) for the verification phase in the Spec Pack of sdlc-dev, and must ensure the test case structure is executable, each step has expected results, and AC is traceable.

Spec 测试用例（V2：verification/usecase.md）

Spec Test Cases (V2: verification/usecase.md)

概览

Overview

本技能是 verification 阶段 worker skill，只负责：

门禁校验（先定位
```
{FEATURE_DIR}
```
，再读必要输入）
生成/更新
```
{FEATURE_DIR}/verification/usecase.md
```
按 V2-DoD 自检（可执行 + 可追溯 + 自动化友好结构）
输出
```
ROUTER_SUMMARY
```
后回到
```
using-aisdlc
```

This skill is a verification phase worker skill, only responsible for:

Access control verification (first locate
```
{FEATURE_DIR}
```
, then read necessary inputs)
Generate/update
```
{FEATURE_DIR}/verification/usecase.md
```
Self-check according to V2-DoD (executable + traceable + automation friendly structure)
Output
```
ROUTER_SUMMARY
```
and return to
```
using-aisdlc
```

硬门禁（不得绕过）

Hard Access Control (Cannot Be Bypassed)

1) 先定位 FEATURE_DIR（禁止猜路径）

1) Locate FEATURE_DIR first (guessing paths is prohibited)

powershell

. ".\skills\spec-context\scripts\spec-common.ps1"
$context = Get-SpecContext
$FEATURE_DIR = $context.FEATURE_DIR
Write-Host "FEATURE_DIR=$FEATURE_DIR"

失败即停止。

powershell

. ".\skills\spec-context\scripts\spec-common.ps1"
$context = Get-SpecContext
$FEATURE_DIR = $context.FEATURE_DIR
Write-Host "FEATURE_DIR=$FEATURE_DIR"

Stop immediately if it fails.

2) 必读项目级 Memory（缺失写 CONTEXT GAP）

2) Must read project-level Memory (write CONTEXT GAP if missing)

```
.aisdlc/project/memory/product.md
```
```
.aisdlc/project/memory/tech.md
```
```
.aisdlc/project/memory/glossary.md
```

任一缺失：在

usecase.md

中显式写

CONTEXT GAP

（并说明对用例口径的影响）。

```
.aisdlc/project/memory/product.md
```
```
.aisdlc/project/memory/tech.md
```
```
.aisdlc/project/memory/glossary.md
```

If any is missing: Explicitly write

CONTEXT GAP

usecase.md

(and explain the impact on test case specifications).

3) AC 来源至少其一存在

3) At least one AC source exists

必须读取其一作为验收口径来源：

```
{FEATURE_DIR}/requirements/solution.md
```
或
```
{FEATURE_DIR}/requirements/prd.md
```

两者都不存在：停止并回到

using-aisdlc

。

Must read one of them as the acceptance criteria source:

```
{FEATURE_DIR}/requirements/solution.md
```
or
```
{FEATURE_DIR}/requirements/prd.md
```

If neither exists: Stop and return to

using-aisdlc

4) 测试计划建议作为约束输入

4) Test plan is recommended as constraint input

若

{FEATURE_DIR}/verification/test-plan.md

已存在：应读取以约束范围/环境/优先级口径；若不存在：在

usecase.md

写明

CONTEXT GAP

并把缺口放入风险/阻断项（不得用

TBD

悬空）。

{FEATURE_DIR}/verification/test-plan.md

already exists: Read it to constrain scope/environment/priority specifications; if it does not exist: Write

CONTEXT GAP

usecase.md

and put the gap into risk/blocking items (do not leave it hanging with

TBD

输出（落盘）

Output (Save to Disk)

```
{FEATURE_DIR}/verification/usecase.md
```

```
{FEATURE_DIR}/verification/usecase.md
```

usecase.md

结构要求（强制）

usecase.md

Structure Requirements (Mandatory)

编号规范

ID Specification

稳定编号：
```
TC-<DOMAIN>-<NNN>
```
（例如
```
TC-AUTH-001
```
）
编号发布协作后不随意改动
禁止自创
```
UC-001
```
、
```
CASE-1
```
等编号体系

Stable ID:
```
TC-<DOMAIN>-<NNN>
```
(for example
```
TC-AUTH-001
```
)
Do not change the ID randomly after release and collaboration
Self-created ID systems such as
```
UC-001
```
,
```
CASE-1
```
are prohibited

单条用例最小模板（必须字段齐全）

Minimum Template for Single Test Case (Required Fields Must Be Complete)

markdown

undefined

markdown

undefined

TC-XXX-001: [标题]

TC-XXX-001: [Title]

优先级： P0 | P1 | P2 类型： UI | API | 集成 | 回归 标签： [tag1, tag2] 追溯： AC-001（

requirements/solution.md#...

或

requirements/prd.md#...

） 套件： smoke, regression

requirements/solution.md#...

requirements/prd.md#...

) Suite: smoke, regression

目标

Objective

[一句话说明验证什么]

[One sentence stating what to verify]

前置条件

Preconditions

测试数据

Test Data

测试步骤

Test Steps

... 预期： ...（可观测、可判定）
... 预期： ...

... Expected: ... (observable, determinable)
... Expected: ...

后置条件/清理

Post conditions/Cleanup

undefined

undefined

“可观测预期”的最低标准

Minimum Standard for "Observable Expectations"

预期必须指向可判定信号，例如（择一即可，越具体越好）：

UI 文案/控件状态/跳转路径
HTTP 状态码/响应体字段
数据记录是否创建/更新（含关键字段）
日志关键字/审计事件

禁止用“成功/正常/符合预期”之类不可判定措辞。

Expectations must point to determinable signals, for example (choose one, the more specific the better):

UI copy/control state/jump path
HTTP status code/response body fields
Whether data records are created/updated (including key fields)
Log keywords/audit events

Undeterminable wording such as "success/normal/meets expectations" is prohibited.

V2-DoD 自检

V2-DoD Self-Check

P0/P1 用例可执行（前置条件与数据不缺失）
每步都有可观测预期结果（可判定 pass/fail）
AC 覆盖关系可回答（哪些 AC 被哪些用例覆盖）
用例编号稳定、结构可供后续自动化生成

P0/P1 test cases are executable (preconditions and data are not missing)
Each step has observable expected results (can determine pass/fail)
AC coverage relationship is answerable (which AC are covered by which test cases)
Test case IDs are stable, and the structure is available for subsequent automated generation

反模式（必须避免）

Anti-patterns (Must Be Avoided)

反模式	为什么不行	正确做法
用 `TBD/待确认` 占位步骤或数据	用例不可执行	缺失进入风险/阻断项并说明影响
每步没有预期结果	无法判定通过/失败	每步写可观测断言点
只写“覆盖很多面”的标题	不可执行	标题之外必须补全前置/数据/步骤/预期

Anti-pattern	Why it is not allowed	Correct practice
Use `TBD/to be confirmed` to occupy steps or data	Test cases are not executable	Put missing items into risk/blocking items and explain the impact
No expected results for each step	Cannot determine pass/fail	Write observable assertion points for each step
Only write titles that "cover many aspects"	Not executable	Must complete preconditions/data/step/expectations besides the title

红旗 STOP

Red Flag STOP

未回显
```
FEATURE_DIR=...
```
就开始写
```
usecase.md
```
用例编号体系偏离
```
TC-<DOMAIN>-<NNN>
```
步骤预期出现“成功/正常/符合预期”这类不可判定措辞

Start writing
```
usecase.md
```
without echoing
```
FEATURE_DIR=...
```
Test case ID system deviates from
```
TC-<DOMAIN>-<NNN>
```
Undeterminable wording such as "success/normal/meets expectations" appears in step expectations

完成后输出与自动路由（必须执行）

Output and Automatic Routing After Completion (Must Be Executed)

usecase.md

落盘后，必须完成以下动作（按顺序，不可省略）：

输出 ROUTER_SUMMARY（YAML 形态，供 Router 决策）：

yaml

ROUTER_SUMMARY:
  stage: V2
  artifacts:
    - "{FEATURE_DIR}/verification/usecase.md"
  needs_human_review: false
  blocked: false
  block_reason: ""
  notes: "软检查点：测试用例已生成/更新；Router 可继续自动推进到 V3（spec-test-suites）或 V4（spec-test-execute）"

立即执行
using-aisdlc
：将上述
```
ROUTER_SUMMARY
```
作为路由输入传递给 using-aisdlc，由 Router 判定下一步并自动推进（无需等待用户说「继续」）。
- 若 Router 判定可自动续跑：在同一轮对话内继续执行下一步 worker skill（如 V3、V4 等）
- 若 Router 触发硬中断：停下并输出阻断原因、需要的输入、候选下一步
对话输出：在调用 using-aisdlc 前，可简短说明「本阶段产物已落盘，正在调用 using-aisdlc 路由下一步。」

After

usecase.md

is saved to disk, must complete the following actions (in order, cannot be omitted):

Output ROUTER_SUMMARY (in YAML format, for Router decision making):

yaml

ROUTER_SUMMARY:
  stage: V2
  artifacts:
    - "{FEATURE_DIR}/verification/usecase.md"
  needs_human_review: false
  blocked: false
  block_reason: ""
  notes: "Soft checkpoint: Test cases have been generated/updated; Router can continue to automatically advance to V3 (spec-test-suites) or V4 (spec-test-execute)"

Execute
using-aisdlc
immediately: Pass the above
```
ROUTER_SUMMARY
```
as routing input to using-aisdlc, the Router will decide the next step and advance automatically (no need to wait for the user to say "continue").
- If the Router determines that automatic continuous running is possible: Continue to execute the next worker skill in the same round of conversation (such as V3, V4, etc.)
- If the Router triggers a hard interrupt: Stop and output the blocking reason, required input, and candidate next steps
Conversation output: Before calling using-aisdlc, you can briefly state "The product of this phase has been saved to disk, calling using-aisdlc to route the next step."