6.3 KiB
6.3 KiB
| title | description | sidebar | ||
|---|---|---|---|---|
| 测试选项 | 比较内置 QA 智能体（Quinn）与测试架构师（TEA）模块的测试自动化。 |
|
BMad 提供两条测试路径：用于快速生成测试的内置 QA 智能体，以及用于企业级测试策略的可安装测试架构师模块。
应该使用哪一个？
| 因素 | Quinn（内置 QA） | TEA 模块 |
|---|---|---|
| 最适合 | 中小型项目、快速覆盖 | 大型项目、受监管或复杂领域 |
| 设置 | 无需安装——包含在 BMM 中 | 通过 npx bmad-method install 单独安装 |
| 方法 | 快速生成测试，稍后迭代 | 先规划，再生成并保持可追溯性 |
| 测试类型 | API 和 E2E 测试 | API、E2E、ATDD、NFR 等 |
| 策略 | 快乐路径 + 关键边界情况 | 基于风险的优先级排序（P0-P3） |
| 工作流数量 | 1（Automate） | 9（设计、ATDD、自动化、审查、可追溯性等） |
:::tip[从 Quinn 开始] 大多数项目应从 Quinn 开始。如果后续需要测试策略、质量门控或需求可追溯性，可并行安装 TEA。 :::
内置 QA 智能体（Quinn）
Quinn 是 BMM（敏捷套件）模块中的内置 QA 智能体。它使用项目现有的测试框架快速生成可运行的测试——无需配置或额外安装。
触发方式： QA 或 bmad-bmm-qa-automate
Quinn 的功能
Quinn 运行单个工作流（Automate），包含五个步骤：
- 检测测试框架——扫描
package.json和现有测试文件以识别框架（Jest、Vitest、Playwright、Cypress 或任何标准运行器）。如果不存在，则分析项目技术栈并推荐一个。 - 识别功能——询问要测试的内容或自动发现代码库中的功能。
- 生成 API 测试——覆盖状态码、响应结构、快乐路径和 1-2 个错误情况。
- 生成 E2E 测试——使用语义定位器和可见结果断言覆盖用户工作流。
- 运行并验证——执行生成的测试并立即修复失败。
Quinn 会生成测试摘要，保存到项目的实现产物文件夹中。
测试模式
生成的测试遵循"简单且可维护"的理念：
- 仅使用标准框架 API——不使用外部工具或自定义抽象
- UI 测试使用语义定位器（角色、标签、文本而非 CSS 选择器）
- 独立测试，无顺序依赖
- 无硬编码等待或休眠
- 清晰的描述，可作为功能文档阅读
:::note[范围]
Quinn 仅生成测试。如需代码审查和故事验证，请改用代码审查工作流（CR）。
:::
何时使用 Quinn
- 为新功能或现有功能快速实现测试覆盖
- 无需高级设置的初学者友好型测试自动化
- 任何开发者都能阅读和维护的标准测试模式
- 不需要全面测试策略的中小型项目
测试架构师（TEA）模块
TEA 是一个独立模块，提供专家智能体（Murat）和九个结构化工作流，用于企业级测试。它超越了测试生成，涵盖测试策略、基于风险的规划、质量门控和需求可追溯性。
- 文档： TEA 模块文档
- 安装：
npx bmad-method install并选择 TEA 模块 - npm：
bmad-method-test-architecture-enterprise
TEA 提供的功能
| Workflow | Purpose |
|---|---|
| Test Design | 创建与需求关联的全面测试策略 |
| ATDD | 基于干系人标准的验收测试驱动开发 |
| Automate | 使用高级模式和工具生成测试 |
| Test Review | 根据策略验证测试质量和覆盖范围 |
| Traceability | 将测试映射回需求，用于审计和合规 |
| NFR Assessment | 评估非功能性需求（性能、安全性） |
| CI Setup | 在持续集成管道中配置测试执行 |
| Framework Scaffolding | 设置测试基础设施和项目结构 |
| Release Gate | 基于数据做出发布/不发布决策 |
TEA 还支持 P0-P3 基于风险的优先级排序，以及与 Playwright Utils 和 MCP 工具的可选集成。
何时使用 TEA
- 需要需求可追溯性或合规文档的项目
- 需要在多个功能间进行基于风险的测试优先级排序的团队
- 发布前具有正式质量门控的企业环境
- 在编写测试前必须规划测试策略的复杂领域
- 已超出 Quinn 单一工作流方法的项目
测试如何融入工作流
Quinn 的 Automate 工作流出现在 BMad 方法工作流图的第 4 阶段（实现）。典型序列：
- 使用开发工作流（
DS）实现一个故事 - 使用 Quinn（
QA）或 TEA 的 Automate 工作流生成测试 - 使用代码审查（
CR）验证实现
Quinn 直接从源代码工作，无需加载规划文档（PRD、架构）。TEA 工作流可以与上游规划产物集成以实现可追溯性。
有关测试在整体流程中的位置，请参阅工作流图。
术语说明
- QA (Quality Assurance)：质量保证。确保产品或服务满足质量要求的过程。
- E2E (End-to-End)：端到端。测试整个系统从开始到结束的完整流程。
- ATDD (Acceptance Test-Driven Development)：验收测试驱动开发。在编码前先编写验收测试的开发方法。
- NFR (Non-Functional Requirement)：非功能性需求。描述系统如何运行而非做什么的需求，如性能、安全性等。
- P0-P3：优先级级别。P0 为最高优先级，P3 为最低优先级，用于基于风险的测试排序。
- Happy path：快乐路径。测试系统在理想条件下的正常工作流程。
- Semantic locators：语义定位器。使用有意义的元素属性（如角色、标签、文本）而非 CSS 选择器来定位 UI 元素。
- Quality gates：质量门控。在开发流程中设置的检查点，用于确保质量标准。
- Requirements traceability：需求可追溯性。能够追踪需求从设计到测试再到实现的完整链路。
- agent：智能体。在人工智能与编程文档中，指具备自主决策或执行能力的单元。
- CI (Continuous Integration)：持续集成。频繁地将代码集成到主干，并自动运行测试的实践。
- MCP (Model Context Protocol)：模型上下文协议。用于在 AI 模型与外部工具之间通信的协议。