generating-test-cases

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Generating Test Cases

生成测试用例

Turn a feature, change, or fixed bug into a structured, evidence-grounded test-case suite, then render it to whatever destination the user wants. Coverage is derived once from the sources of truth; the output format is a late, swappable step.

The whole skill rests on one discipline you must not skip:

🔒 Iron Law — No test case, no expected value, no test datum without a cited source — and no value left as a category when the test needs an instance. Every row points to where it came from: a doc, source code (
file:line
), git, or the live system. If a value can't be found in a real source, you do not write it — you mark it
TBD (needs confirmation)
and ask. Guessing is a defect, not a shortcut.

Violating the letter of this rule is violating its spirit. Two failure modes break it, not one:

Fabrication — a plausible-but-unsourced value. Worse than blank: it looks verified and isn't.
Under-specification — a value or precondition filled with the spec's class instead of a concrete instance (
```
an email with ≥1 attachment
```
,
```
a valid user
```
,
```
some cargo record
```
). It is "sourced" — you copied the spec — so it slips the source check, carries no hedge word, and can even cite an Evidence cell. But it's untestable. A category is not a value. Resolve it to the real instance (Step 2) or mark
```
TBD (needs confirmation)
```
and ask — never leave the abstraction.

将功能、变更或已修复的bug转化为结构化、基于证据的测试用例套件，再导出至用户指定的目标格式。覆盖范围仅基于可信来源确定；输出格式是可灵活替换的后期步骤。

本技能的核心是一条不可违背的准则：

🔒 铁律 — 所有测试用例、预期值、测试数据必须标注来源；当测试需要具体实例时，不能用类别代替具体值。 每一行都需指向其来源：文档、源代码（
file:line
）、git或实时系统。若无法从真实来源获取某个值，则不得编写该值——需标记为
TBD (需确认)
并询问用户。猜测是缺陷，而非捷径。

违背规则的字面要求即违背其核心精神。 存在两种违规情况：

编造数据 — 看似合理但无来源的数值。比空白更糟：它看起来已验证，但实际并未验证。
规格不足 — 用规格中的类别而非具体实例填充值或前置条件（如
```
带≥1个附件的邮件
```
、
```
有效用户
```
、
```
某货运记录
```
）。它确实“有来源”——你复制了规格内容，因此能通过来源检查，没有提示词，甚至可以在证据单元格中引用来源。但它无法被测试。类别不是具体值。 需将其转化为真实实例（步骤2），或标记为
```
TBD (需确认)
```
并询问用户——绝不能保留抽象表述。

When to invoke

调用时机

"Write test cases / a test plan / QA cases for this feature/PR/change"
After implementation finishes (hand-off from grill-then-plan → build) or a bug is fixed (hand-off from
```
post-mortem
```
→ regression case)
Before filing findings or release sign-off
NOT for verifying one finished task →
```
dual-verifier
```
; NOT for filing tickets →
```
findings-to-ado-backlog
```
/
```
ado-create-work-items
```
(this skill hands off to them)

“为该功能/PR/变更编写测试用例/测试计划/QA用例”
功能实现完成后（从grill-then-plan过渡到build阶段）或bug修复完成后（从
```
post-mortem
```
过渡到回归用例阶段）
提交测试结果或发布签字确认前
请勿用于验证单个已完成任务→请使用
```
dual-verifier
```
；请勿用于提交工单→请使用
```
findings-to-ado-backlog
```
/
```
ado-create-work-items
```
（本技能会将任务移交至这些插件）

Steps

步骤

0. Scope + mode. Testing a change/PR or a whole feature/system? Identify the live system that's involved (runnable app / DB / CRM / API).

1. Gather sources of truth — read-only; save evidence to disk.

docs (spec, ADRs, README) · code (real defaults, behavior, field names)
git — easily skipped, do it explicitly:
- ```
git diff <base>..HEAD
```
  → the real change surface (scope) — change/PR mode
- ```
git log -- <touched paths>
```
  → past fixes in this area → regression cases
- ```
git blame
```
  on risky lines → why it exists → ties a case to a reason
- trailers /
```
#1234
```
  / branch name → Evidence refs
- deep "why does this exist?" → delegate to
```
ticket-trace
```

2. ▶ Pull REAL values from the LIVE system — read-only, never mutate it. Source code gives shape; the live system gives the values that exist nowhere else: actual device/monitor names, real option-set/enum values, true defaults, real schema, whether an error path actually reproduces. Run the app / query the DB·CRM·API and capture the output as Evidence. git = history + intent + change-surface; live = the real values now. This is the step agents skip by default — do not.

3. Canonical schema (format-independent — decide once, before any output choice):

ID · Area · Title · Type(Auto/Manual) · Priority · Auto-test-link · Preconditions · Steps · Test Data · Expected Result · Evidence(required) · Status · Tester · Date · Notes

4. Derive cases — coverage dimensions + two-way traceability. Walk every dimension so none is missed: happy · config/validation · integration · negative/failure/fallback/edge · UI/DPI · packaging.

Order the OUTPUT by the user journey, not by requirement area. Emit the happy-path cases that carry the feature end to end FIRST — one per journey step, in the order a real user hits them (open → enter → preview → commit → confirm → downstream surfaces → API/MCP) — so the suite runs top-to-bottom as one pass and each case's preconditions are the previous case's result. Only AFTER the journey is complete do the edge / negative / detail cases follow, grouped by area. Requirement coverage is a check you run over the finished list, never the outline you write it from: an area-grouped suite has no end-to-end path, so a tester cannot tell whether the feature works at all.
Forward: every requirement / ADR / diff-hunk → ≥1 case. Backward: every case → real Evidence (blank Evidence = not done).
Every fix-commit in the touched area → one regression case.
Mark Auto/Manual, map automated cases to the real test method, assign Priority, flag hard gates (must-pass before sign-off).

5. Make each case executable. Numbered Steps; Expected = a verifiable value from a real source (

2026-06-18_14-03-22_screen.mp4

Total = 500,000 (NOT 0)

), never "works correctly". The same bar applies to Test Data and Preconditions — name the specific instance, not the class: ✗

an email with ≥1 attachment

→ ✓

email "Re: BL-2026-0042" from shipping@acme.com, 1 attachment BL-2026-0042.pdf (PDF, 31 KB)

(the concrete instance pulled live in Step 2). Can't source any of these →

TBD (needs confirmation)

, then ask. And the instance must be in the STATE the case's entry-point requires — a real record in the wrong state (a Draft quote when the button's enable-rule needs Active; a closed ticket when the flow needs open) is as unusable as a fabricated one. Verify the trigger's preconditions (record state, enable/display rules, permissions) live, not just that the record exists. Cite every related entity as a directly-openable, TYPE-QUALIFIED reference — not a bare id. A bare GUID is ambiguous — a contact id and a booking id are byte-identical, so the tester opens the wrong table and reports "data not found". Write the entity SET with the id in a form they can open as-is: Dataverse →

entityset(guid)

(e.g.

quotes(bc5d…)

ctg_cargodetails(ff1d…)

contacts(7271…)

); SQL →

table#pk

; REST → resource path. Do this for EVERY entity the case touches — the record under test AND its related rows (account, contact, parent, schedule, link records). Mark a not-yet-existing seed with a placeholder ref + a create-recipe pointing at a real base ref, never a fabricated id.

6. ▶ ASK the user the destination — before rendering. Do not assume a format.

Output to?  1) Excel (.xlsx)  2) Markdown  3) CSV  4) Tracker (ADO / Jira / GitHub / Notion)
Also: priority scheme? · include Tester/Date columns? · map automated cases to tests?

7. Render via a format adapter (same canonical model → chosen target):

xlsx →
```
scripts/render_xlsx.py
```
(Status dropdown, conditional color, freeze, auto-filter, Cases + Legend + Test Data + Summary sheets)
md → grouped tables + summary · csv → flat rows
tracker → delegate to
```
findings-to-ado-backlog
```
/
```
ado-create-work-items
```
(they own dry-run + safety gate + writeback). Do not re-implement ticket creation here.

8. Self-review gates (all must pass before delivery):

Evidence present on every row; no
```
TBD
```
left unflagged; no "probably/assume/typically" in Steps/Expected/Test Data
Concrete-instance check: every Test Data / Precondition cell names a real instance (actual ID, name, value), not a class. Treat
```
some / any / a valid <noun>
```
and a quantifier used as the datum (
```
≥1
```
,
```
one or more
```
,
```
at least
```
) as smells to resolve — not a literal word-ban; a concrete value that merely contains "a"/"an" is fine.
Coverage: every requirement/ADR/diff-hunk/risk has a case; negative cases present; every P1 has an unambiguous pass/fail
Negative properties: for every rule of the form "X must be refused / omitted / absent / left unchanged", one case asserts the absence, not merely that the happy path still works. A suite that only asserts what the code writes cannot catch code that writes too much — a deleted filter, a widened match, or rows that should have been excluded all pass a presence-only suite.
Every fix-commit in the area has a regression case
Encoding check by codepoint, not by console rendering (avoids false "mojibake")

9. Deliver + chain. Report counts (total / auto / manual / P1 / hard-gates) + path. Then: failed/

TBD

cases →

findings-to-ado-backlog

(FILE); summary →

management-talk

(REPORT).

0. 范围与模式。是测试变更/PR还是整个功能/系统？确定涉及的实时系统（可运行的应用/数据库/CRM/API）。

1. 收集可信来源 — 只读；将证据保存至磁盘。

文档（规格、ADR、README）· 代码（真实默认值、行为、字段名）
git — 极易被忽略，需明确执行：
- ```
git diff <base>..HEAD
```
  → 真实变更范围（适用于变更/PR模式）
- ```
git log -- <touched paths>
```
  → 该区域过往的修复记录 → 回归用例
- ```
git blame
```
  标记风险代码行 → 了解代码存在的原因 → 将用例与需求关联
- 尾部信息 /
```
#1234
```
  / 分支名称 → 证据引用
- 深入探究“为何存在此代码？”→ 委托给
```
ticket-trace
```
  处理

2. ▶ 从实时系统提取真实值 — 只读，绝不修改系统。源代码定义结构；实时系统提供其他地方找不到的值：实际设备/显示器名称、真实选项集/枚举值、真实默认值、真实架构、错误路径是否可复现。运行应用/查询数据库·CRM·API并捕获输出作为证据。git = 历史+意图+变更范围；实时系统 = 当前真实值。 这是Agent默认会跳过的步骤——请勿跳过。

3. 标准架构（与格式无关——在选择输出格式前确定一次）：

ID · 领域 · 标题 · 类型(自动/手动) · 优先级 · 自动化测试链接 · 前置条件 · 步骤 · 测试数据 · 预期结果 · 证据(必填) · 状态 · 测试人员 · 日期 · 备注

4. 生成用例 — 覆盖维度+双向可追溯性。覆盖所有维度，无遗漏：正常流程 · 配置/验证 · 集成 · 异常/失败/降级/边缘场景 · UI/DPI · 打包。

按用户旅程排序输出，而非按需求领域。 首先输出贯穿功能全流程的正常路径用例——每个旅程步骤对应一个用例，按真实用户操作顺序排列（打开→输入→预览→提交→确认→下游界面→API/MCP），使测试套件能从上到下一次性执行，且每个用例的前置条件是前一个用例的结果。仅在完成全流程旅程后，再按领域分组输出边缘/异常/细节用例。需求覆盖是对最终列表的检查项，而非编写用例的大纲：按领域分组的套件没有端到端路径，测试人员无法判断功能是否正常运行。
正向追溯：每个需求/ADR/代码差异块 → 至少1个用例。反向追溯：每个用例 → 真实证据（空白证据表示未完成）。
该区域的每个修复提交 → 对应一个回归用例。
标记自动/手动类型，将自动化用例映射到真实测试方法，分配优先级，标记硬性关卡（签字确认前必须通过）。

5. 确保每个用例可执行。步骤需编号；预期结果 = 来自真实来源的可验证值（如

2026-06-18_14-03-22_screen.mp4

、

总计=500,000 (而非0)

），绝不能是“正常工作”。测试数据和前置条件需遵循相同标准——指定具体实例，而非类别： ✗

带≥1个附件的邮件

→ ✓

邮件"Re: BL-2026-0042"来自shipping@acme.com，包含1个附件BL-2026-0042.pdf（PDF格式，31 KB）

（步骤2中从实时系统提取的具体实例）。若无法获取这些信息→标记为

TBD (需确认)

，然后询问用户。实例必须符合用例入口点要求的状态——状态错误的真实记录（如按钮启用规则需要“活跃”状态，但使用了“草稿”报价；流程需要“打开”工单，但使用了“关闭”工单）与编造的数据一样无用。需实时验证触发条件的前置条件（记录状态、启用/显示规则、权限），而非仅确认记录存在。将每个相关实体标注为可直接打开的类型限定引用——而非裸ID。 裸GUID存在歧义——联系人ID和预订ID字节相同，测试人员会打开错误表并报告“数据未找到”。以可直接打开的形式编写实体集与ID：Dataverse →

entityset(guid)

（如

quotes(bc5d…)

ctg_cargodetails(ff1d…)

contacts(7271…)

）；SQL →

table#pk

；REST → 资源路径。用例涉及的每个实体都需这样处理——被测试的记录及其关联行（账户、联系人、父记录、日程、链接记录）。对于尚未存在的种子数据，使用占位符引用+指向真实基础引用的创建步骤，绝不能使用编造的ID。

6. ▶ 询问用户输出目标——在渲染前。请勿假设格式。

导出至？ 1) Excel (.xlsx) 2) Markdown 3) CSV 4) 跟踪系统 (ADO / Jira / GitHub / Notion)
附加选项：优先级方案？· 是否包含测试人员/日期列？· 是否将自动化用例映射到测试方法？

7. 通过格式适配器渲染（同一标准模型→选定目标格式）：

xlsx →
```
scripts/render_xlsx.py
```
（状态下拉菜单、条件格式、冻结窗格、自动筛选，包含用例+图例+测试数据+汇总工作表）
md → 分组表格+汇总 · csv → 扁平化行
跟踪系统 → 委托给
```
findings-to-ado-backlog
```
/
```
ado-create-work-items
```
（这些插件负责试运行、安全关卡和回写）。请勿在此处重新实现工单创建功能。

8. 自我检查关卡（所有项必须通过才能交付）：

每一行均有证据；无未标记的
```
TBD
```
；步骤/预期结果/测试数据中无“可能/假设/通常”等表述
具体实例检查： 每个测试数据/前置条件单元格均指定真实实例（实际ID、名称、值），而非类别。将
```
some / any / a valid <noun>
```
和用作数据的量词（
```
≥1
```
、
```
一个或多个
```
、
```
至少
```
）视为需解决的问题——并非字面禁用；仅包含“a/an”的具体值是可接受的。
覆盖范围：每个需求/ADR/代码差异块/风险均有对应用例；包含异常用例；每个P1用例均有明确的通过/失败标准
异常验证：对于每个形如“X必须被拒绝/忽略/排除/保持不变”的规则，需有一个用例验证缺失状态，而非仅验证正常路径仍可运行。仅验证代码写入内容的套件无法捕获代码写入过多的问题——删除的过滤器、扩大的匹配范围或应排除的行都会在仅验证存在性的套件中通过。
该区域的每个修复提交均有对应回归用例
按代码点检查编码，而非控制台渲染（避免假乱码）

9. 交付与流转。报告统计数据（总数/自动化/手动/P1/硬性关卡）+ 文件路径。然后：失败/

TBD

用例→

findings-to-ado-backlog

（提交）；汇总→

management-talk

（汇报）。

Rationalization table

合理化对照表

Excuse	Reality
"This value is probably ~X"	"Probably" = a guess. Read it / run it / query it.
"It's obvious from general behavior"	General ≠ this system. Cite this system's source.
"No time to run the live app — use a sample value"	A guessed sample = a test you can't trust. Pull the real value or mark TBD + ask.
"Docs are old, I'll infer from the function name"	Docs vs code → code/live wins. Read the real thing.
"The task said decide the format myself"	Decide structure yourself; the destination is the user's call — ask (Step 6).
"git is overkill for tests"	git diff scopes the change; git log finds the regressions you'd otherwise miss.
"The spec literally says 'an email with ≥1 attachment' — so it's sourced"	The spec gives the class; a test needs an instance. Pull the real email live (Step 2) or mark TBD. A category is not a value.
"I gave the GUID, that's concrete"	A bare id is ambiguous across entities — a contact id reads as a booking id. Cite it type-qualified: `entityset(guid)` / `table#pk` / resource path.

借口	实际情况
“该值可能约为X”	“可能”=猜测。读取/运行/查询真实值。
“从通用行为可明显看出”	通用≠当前系统。引用当前系统的来源。
“没时间运行实时应用——使用示例值”	猜测的示例值=不可信的测试。提取真实值或标记为TBD并询问用户。
“文档过时，我将从函数名推断”	文档vs代码→代码/实时系统优先。查看真实内容。
“任务要求我自行决定格式”	你可自行决定结构；输出目标由用户决定——询问用户（步骤6）。
“git用于测试过于冗余”	git diff确定变更范围；git log发现你可能遗漏的回归场景。
“规格明确写着‘带≥1个附件的邮件’——所以有来源”	规格给出类别；测试需要实例。从实时系统提取真实邮件（步骤2）或标记为TBD。类别不是具体值。
“我提供了GUID，这是具体值”	裸ID在不同实体间存在歧义——联系人ID会被误认为预订ID。标注类型限定的引用： `entityset(guid)` / `table#pk` / 资源路径。

Red flags — STOP and go find the source

危险信号——立即停止并查找来源

"probably / expected / typically / normally / assume / should be" in Steps, Expected, or Test Data
A value or precondition stated as a class, not an instance —
```
a / an / some / any / a valid <noun>
```
, or a quantifier standing in for data (
```
≥1
```
,
```
one or more
```
,
```
at least
```
). You can't run a test from a category.
A concrete instance whose state doesn't satisfy the action's entry-point (enable rule / status / permission) — a real GUID in the wrong record state is still an unusable test datum.
A related entity cited as a bare id with no entity type/set — the tester can't tell which table to open (a contact id read as a booking id). Cite it type-qualified:
```
entityset(guid)
```
/
```
table#pk
```
/ resource path.
An Expected Result with no Evidence cell filled
Cases ordered by requirement area / subsystem with no end-to-end happy path a tester can run top-to-bottom first
Picked a format without asking the user
Wrote device names / defaults / enum values without running or querying the live system

步骤、预期结果或测试数据中出现“可能/预期/通常/正常/假设/应该”等表述
值或前置条件以类别而非实例表述——
```
a / an / some / any / a valid <noun>
```
，或用量词代替数据（
```
≥1
```
、
```
一个或多个
```
、
```
至少
```
）。你无法基于类别运行测试。
具体实例的状态不满足操作的入口条件（启用规则/状态/权限）——状态错误的真实GUID仍是无用的测试数据。
相关实体以无实体类型/集合的裸ID引用——测试人员无法确定打开哪个表（联系人ID被误认为预订ID）。标注类型限定的引用：
```
entityset(guid)
```
/
```
table#pk
```
/ 资源路径。
预期结果对应的证据单元格为空
用例按需求领域/子系统排序，无测试人员可从上到下执行的端到端正常路径
未询问用户就选择了格式
未运行或查询实时系统就编写了设备名称/默认值/枚举值

Common mistakes

常见错误

Happy-path-only → Step 4's dimensions + backward-trace from git regressions force the failure cases.
Vague "works correctly" → Step 5 demands an exact verifiable value.
Area-grouped outline → Step 4's dimension list reads as buckets and pulls toward grouping by requirement; the ORDER is the journey, the dimensions are the coverage check.
Assuming xlsx → Step 6 asks first; the canonical model (Steps 1–5) is format-blind so re-rendering to a second format is free.
Re-implementing ADO/Jira creation → delegate to the backlog plugins.
Skipping the live system → the single most common gap; the real values live there.
Category instead of instance → copying the spec's abstraction (
```
a valid X
```
,
```
≥1 Y
```
) into Test Data. It's "sourced" but untestable; resolve to a concrete instance from Step 2, or mark TBD + ask.

仅覆盖正常路径 → 步骤4的维度+从git回归记录反向追溯强制要求覆盖失败场景。
模糊的“正常工作”表述 → 步骤5要求明确的可验证值。
按领域分组的大纲 → 步骤4的维度列表看似分类依据，容易导致按需求分组；需按用户旅程排序，维度仅作为覆盖检查项。
默认选择xlsx格式 → 步骤6先询问用户；标准模型（步骤1–5）与格式无关，因此可免费重新渲染为第二种格式。
重新实现ADO/Jira创建功能 → 委托给待办事项插件。
跳过实时系统 → 最常见的漏洞；真实值仅存在于实时系统中。
用类别代替实例 → 将规格中的抽象表述（
```
有效X
```
、
```
≥1个Y
```
）复制到测试数据中。它“有来源”但无法测试；需转化为步骤2中的具体实例，或标记为TBD并询问用户。

Chain position

流转位置

Sits on the WORK → FILE hinge. In:

grill-then-plan

→build,

post-mortem

→regression case, alongside

dual-verifier

scrutinize

. Out:

findings-to-ado-backlog

ado-create-work-items

(FILE),

management-talk

(REPORT).

位于工作→提交的衔接处。输入：

grill-then-plan

→build、

post-mortem

→回归用例，与

dual-verifier

scrutinize

并行。输出：

findings-to-ado-backlog

ado-create-work-items

（提交）、

management-talk

（汇报）。