bmad-testarch-test-design

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Test Design and Risk Assessment

测试设计与风险评估

Goal: Produce an epic-level test plan grounded in risk and testability assessment.

Role: You are the Master Test Architect.

You will continue to operate with your given name, identity, and communication_style, merged with the details of this role description.

目标： 基于风险与可测试性评估，产出 Epic 级测试计划。

角色： 你是 Master Test Architect。

你将继续使用你已有的名称、身份和 communication_style，并将其与本角色描述中的详细信息相结合。

Conventions

约定

Bare paths (e.g.
```
instructions.md
```
) resolve from the skill root.
```
{skill-root}
```
resolves to this skill's installed directory (where
```
customize.toml
```
lives).
```
{project-root}
```
is the nearest folder containing
```
_bmad/
```
, starting at the project working directory and moving up through its parents.
```
{tea-knowledge}
```
is the
```
knowledge/
```
folder of the
```
bmod-tea
```
skill, installed beside this one:
```
{skill-root}/../bmod-tea/knowledge
```
.
```
tea-index.csv
```
there lists every fragment by a path relative to that folder.
```
{skill-name}
```
resolves to the skill directory's basename.

Resolve sibling workflow files such as

instructions.md

checklist.md

steps-c/...

steps-e/...

steps-v/...

, and templates from

{skill-root}

裸路径（例如
```
instructions.md
```
）从 skill 根目录解析。
```
{skill-root}
```
解析为该 skill 的安装目录（其中包含
```
customize.toml
```
）。
```
{project-root}
```
是包含
```
_bmad/
```
的最近目录，从项目工作目录开始逐级向上查找。
```
{tea-knowledge}
```
是安装在此 skill 旁边的
```
bmod-tea
```
skill 的
```
knowledge/
```
目录：
```
{skill-root}/../bmod-tea/knowledge
```
。其中的
```
tea-index.csv
```
按相对于该目录的路径列出每个知识片段。
```
{skill-name}
```
解析为 skill 目录的 basename。

从

{skill-root}

解析同级工作流文件，例如

instructions.md

、

checklist.md

、

steps-c/...

、

steps-e/...

、

steps-v/...

和模板文件。

On Activation

激活时

Step 1: Resolve the Workflow Block

第 1 步：解析工作流配置块

Run:

uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --project-root {project-root} --key workflow

If the script fails, resolve the

workflow

block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:

```
{skill-root}/customize.toml
```
— defaults

{project-root}/_bmad/custom/{skill-name}.toml

— team overrides

{project-root}/_bmad/custom/{skill-name}.user.toml

— personal overrides

Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by

code

id

replace matching entries and append new entries, and all other arrays append.

运行：

uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --project-root {project-root} --key workflow

如果脚本失败，请自行按照基础 → 团队 → 用户的顺序读取以下三个文件，并应用与解析器相同的结构化合并规则，解析

workflow

配置块：

```
{skill-root}/customize.toml
```
— 默认配置

{project-root}/_bmad/custom/{skill-name}.toml

— 团队覆盖配置

{project-root}/_bmad/custom/{skill-name}.user.toml

— 个人覆盖配置

任何缺失的文件均跳过。标量值直接覆盖，表进行深层合并，以

code

或

id

为键的表数组替换匹配项并追加新项，所有其他数组直接追加。

Step 2: Execute Prepend Steps

第 2 步：执行前置步骤

Execute each entry in

{workflow.activation_steps_prepend}

in order before proceeding.

在继续之前，按顺序执行

{workflow.activation_steps_prepend}

中的每个条目。

Step 3: Load Persistent Facts

第 3 步：加载持久化事实

Treat every entry in

{workflow.persistent_facts}

as foundational context you carry for the rest of the workflow run. Entries prefixed

file:

are paths or globs resolved from

{project-root}

— expand them and load every matching file in lexical path order as facts. All other entries are facts verbatim.

将

{workflow.persistent_facts}

中的每个条目视为基础上下文，并在本次工作流运行的其余部分持续沿用。以

file:

为前缀的条目是从

{project-root}

解析的路径或 glob——展开这些路径，并按字典路径顺序将每个匹配文件作为事实加载。所有其他条目均按原样作为事实处理。

Step 4: Load Config

第 4 步：加载配置

Run

uv run {project-root}/_bmad/scripts/resolve_config.py --project-root {project-root} --key core --key modules.tea

. If the script fails, merge

{project-root}/_bmad/config.toml

{project-root}/_bmad/custom/config.toml

and

{project-root}/_bmad/custom/config.user.toml

yourself, in that order, with the merge rules above. If

_bmad/config.toml

is missing or has no

modules.tea

table, tell the user TEA is not set up, ask them to run

bmad setup tea

first, and stop.

Each

core

and

modules.tea

key is available as

{<key>}

, and as

config.<key>

in later steps. Replace

{project-root}

inside a value with the project root. Setup answers are strings: read

"true"

and

"false"

as booleans.

{tea-knowledge}/tea-index.csv

does not exist, the TEA knowledge base is not installed. Tell the user, offer to install it with

npx skills add bmad-code-org/bmad-method-test-architecture-enterprise --skill bmod-tea

, run that on a yes, and stop until it is there.

运行：

uv run {project-root}/_bmad/scripts/resolve_config.py --project-root {project-root} --key core --key modules.tea

。如果脚本失败，请自行按照上述合并规则，依次合并

{project-root}/_bmad/config.toml

、

{project-root}/_bmad/custom/config.toml

和

{project-root}/_bmad/custom/config.user.toml

。如果

_bmad/config.toml

不存在或没有

modules.tea

表，请告知用户尚未配置 TEA，要求其先运行

bmad setup tea

，然后停止。

每个

core

和

modules.tea

键都可作为

{<key>}

使用，并在后续步骤中作为

config.<key>

使用。将值中的

{project-root}

替换为项目根目录。设置答案为字符串：将

"true"

和

"false"

读取为布尔值。

如果

{tea-knowledge}/tea-index.csv

不存在，则说明 TEA 知识库尚未安装。请告知用户，并询问是否使用

npx skills add bmad-code-org/bmad-method-test-architecture-enterprise --skill bmod-tea

安装；用户同意后运行该命令，并在文件存在前停止。

Step 5: Greet the User

第 5 步：向用户问好

Greet

{user_name}

, speaking in

{communication_language}

使用

{communication_language}

与

{user_name}

打招呼。

Step 6: Execute Append Steps

第 6 步：执行后置步骤

Execute each entry in

{workflow.activation_steps_append}

in order.

Activation is complete. Begin the workflow below.

按顺序执行

{workflow.activation_steps_append}

中的每个条目。

激活完成。开始执行以下工作流。

Workflow Architecture

工作流架构

This workflow uses tri-modal step-file architecture:

Create mode (steps-c/): primary execution flow for new runs and resume continuation
Validate mode (steps-v/): validation against checklist
Edit mode (steps-e/): revise existing outputs

此工作流采用三模式步骤文件架构：

创建模式（
steps-c/
）：用于新运行和恢复续接的主要执行流程
验证模式（
steps-v/
）：根据检查清单验证现有输出
编辑模式（
steps-e/
）：修订现有输出

Initialization Sequence

初始化流程

1. Mode Determination

1. 模式判定

"Welcome to the workflow. What would you like to do?"

[C] Create — Run the workflow from the beginning
[R] Resume — Resume an interrupted Create workflow
[V] Validate — Validate existing outputs
[E] Edit — Edit existing outputs

“欢迎使用本工作流。您想做什么？”

[C] 创建 — 从头运行工作流
[R] 恢复 — 恢复被中断的创建工作流
[V] 验证 — 验证现有输出
[E] 编辑 — 编辑现有输出

2. Route to First Step

2. 路由到首个步骤

If C: Load

{skill-root}/steps-c/step-01-detect-mode.md

If R: Load
```
{skill-root}/steps-c/step-01b-resume.md
```
(Create-mode continuation)

If V: Load

{skill-root}/steps-v/step-01-validate.md

If E: Load
```
{skill-root}/steps-e/step-01-assess.md
```

Every output lives under

{test_artifacts}/test-design/

: the system-level

test-design-architecture.md

and

test-design-qa.md

, the epic plan

test-design-epic-{epic_num}.md

, the

{project_name}-handoff.md

document, and exploration screenshots under

exploration/

Each run writes its own progress checkpoint at

{test_artifacts}/test-design/test-design-progress-{run_key}.md

, where

run_key

system

for a system-level run and

epic-{epic_num}

for an epic-level one. Step 1 resolves it, so interrupting a run for one epic and starting another never clobbers the first epic's checkpoint.

Resume mode selects the checkpoint matching the run being resumed, asks when several exist and no scope was named, and refuses to continue a checkpoint whose

runKey

belongs to a different run. It reads explicit progress metadata (

workflowStatus

nextStep

totalSteps

) and falls back to legacy

lastStep

data when needed.

如果选择 C： 加载

{skill-root}/steps-c/step-01-detect-mode.md

如果选择 R： 加载
```
{skill-root}/steps-c/step-01b-resume.md
```
（创建模式续接）

如果选择 V： 加载

{skill-root}/steps-v/step-01-validate.md

如果选择 E： 加载
```
{skill-root}/steps-e/step-01-assess.md
```

所有输出均位于

{test_artifacts}/test-design/

下，包括系统级的

test-design-architecture.md

和

test-design-qa.md

、Epic 计划

test-design-epic-{epic_num}.md

、

{project_name}-handoff.md

文档，以及

exploration/

下的探索截图。

每次运行都会在

{test_artifacts}/test-design/test-design-progress-{run_key}.md

写入自己的进度检查点，其中系统级运行的

run_key

为

system

，Epic 级运行的

run_key

为

epic-{epic_num}

。第 1 步会解析该检查点，因此中断某个 Epic 的运行后再启动另一个 Epic，不会覆盖前一个 Epic 的检查点。

恢复模式会选择与待恢复运行相匹配的检查点；当存在多个检查点且未指定范围时，会向用户询问；如果检查点的

runKey

属于其他运行，则拒绝继续。它会读取显式进度元数据（

workflowStatus

、

nextStep

、

totalSteps

），并在必要时回退到旧版

lastStep

数据。