qa-test-planner

QA 测试规划器

这是一项全面的技能，可帮助 QA 自动化工程师制定测试计划、生成手动测试用例、编写自动化 Playwright 测试、创建回归测试套件、使用浏览器自动化验证 UI，并有效记录缺陷。

激活： 只有在明确按名称调用时才会触发此技能（例如 /qa-test-planner、qa-test-planner 或 use the skill qa-test-planner）。

快速开始

创建测试计划：

"Create a test plan for the user authentication feature using the test-plan.md template"

生成测试用例：

"Generate manual test cases for the checkout flow using the test-case.md template"

创建自动化 Playwright 测试：

"Create Playwright automated tests for the login flow using the playwright-test.md template"

使用浏览器验证 UI：

"Navigate to the login page and validate all form elements are visible using Playwright MCP"

构建回归测试套件：

"Build a regression test suite for the payment module using test-case.md templates grouped by priority"

创建缺陷报告：

"Create a bug report for the form validation issue using the bug-report.md template"

快速参考

何时使用此技能

在以下情况下使用此技能：

• 创建或评审测试计划和测试策略
• 根据需求或用户故事生成测试用例
• 编写包含明确复现步骤的缺陷报告
• 根据风险选择构建回归测试套件
• 遵循最佳实践实现 Playwright 自动化
• 记录测试执行和结果
• 开展探索性测试会话
• 使用浏览器自动化验证 UI 元素

前置条件

工作原理

Your Request
    │
    ▼
┌─────────────────────────────────────────────────────┐
│ 1. ANALYZE                                        │
│    • Parse feature/requirement                      │
│    • Identify test types needed (manual/automated)  │
│    • Determine scope and priorities                 │
├─────────────────────────────────────────────────────┤
│ 2. SELECT TEMPLATE                                │
│    • Choose appropriate template from assets/        │
│    • Review template structure and sections         │
│    • Identify placeholders to fill                 │
├─────────────────────────────────────────────────────┤
│ 3. CUSTOMIZE                                      │
│    • Fill in placeholders with project details      │
│    • Add specific test steps and scenarios         │
│    • Apply Playwright best practices               │
├─────────────────────────────────────────────────────┤
│ 4. EXECUTE (with Playwright MCP)                 │
│    • Navigate and interact with browser             │
│    • Capture screenshots and evidence               │
│    • Validate UI elements and behavior              │
├─────────────────────────────────────────────────────┤
│ 5. VALIDATE                                       │
│    • Check completeness                             │
│    • Verify traceability                            │
│    • Ensure actionable steps                        │
└─────────────────────────────────────────────────────┘
    │
    ▼
QA Deliverable Ready

工作流

1) 创建测试计划

1. 使用 templates/test-plan.md 作为起点
2. 确定测试目标、范围、假设和限制
3. 定义测试级别和类型（功能、UI、性能等）
4. 指定环境、测试数据、工具和配置需求
5. 定义准入/退出标准、交付物和报告频率
6. 添加风险矩阵和缓解措施
7. 据此确定测试优先级（基于风险的测试）

模板： templates/test-plan.md

2) 生成测试用例

1. 使用 templates/test-case.md 编写单个测试用例
2. 将需求转换为测试条件（要测试的内容）
3. 选择一种测试设计技术：
   • 针对输入使用等价类划分和边界值
   • 针对规则组合使用决策表
   • 针对生命周期/流程使用状态转换
   • 针对端到端流程使用用例/场景测试
4. 编写原子性强、明确且可追溯的测试用例
5. 添加可观察、可衡量的预期结果
6. 添加优先级和风险标签，以支持基于风险的回归测试
7. 根据稳定性和价值标准标记适合自动化的候选项

模板：

• templates/test-case.md - 单个测试用例

3) 实现自动化测试脚本（Playwright）

1. 使用 templates/playwright-test.md 作为模板
2. 确保测试易于阅读，并与测试用例保持一致
3. 优先使用稳定的定位器（例如 getByTestId），避免脆弱的选择器
4. 避免随意休眠；依靠 Playwright 的自动等待和显式断言
5. 确保测试彼此独立（明确设置前置条件）
6. 在测试标题中使用标签（例如 @smoke、@regression）以便运行测试套件
7. 调试时捕获用于问题分类的工件（屏幕截图/视频/跟踪记录）

模板： templates/playwright-test.md

4) 构建和维护回归测试套件

1. 使用 templates/regression-suite.md 定义测试套件
2. 定义套件层级：冒烟（关键路径）、基本检查（构建验证）、回归（广泛覆盖）、完整（发布）
3. 根据风险 + 频率 + 重要性 + 缺陷历史选择测试
4. 统一标记测试，并记录选择规则
5. 定期审核测试套件：移除过时的覆盖项，增加对已逃逸缺陷的覆盖

模板： 按优先级分组使用单个 test-case.md 模板

5) 创建 Bug 报告

1. 以 templates/bug-report.md 为起点
2. 确保能够稳定复现，并简化为最少步骤
3. 记录变化情况（频率）和影响范围
4. 记录环境详情（构建版本／应用版本、操作系统、浏览器／设备、账户／角色）
5. 描述预期行为与实际行为
6. 说明影响，并统一设置严重性和优先级
7. 附上证据（屏幕截图、控制台日志、网络跟踪记录、Playwright 跟踪记录）
8. 跟踪生命周期：分诊记录、负责人、修复版本、验证步骤

模板： templates/bug-report.md

安全指南

凭据处理

绝不要在测试用例或代码中嵌入真实凭据。 请改用占位符：

测试数据最佳实践：

• 使用通过 API 或管理面板配置的测试账户
• 将凭据存储在环境变量中
• 使用 Faker.js 或类似工具生成测试数据
• 绝不要将真实凭据提交到版本控制系统

URL 导航安全

使用 Playwright MCP 验证外部／不可信 URL 时：

1. 导航前确认 URL 属于受信任的域名
2. 避免执行来自不可信来源的任意 JavaScript
3. 测试第三方应用时使用沙盒环境
4. 未经验证，切勿导航到不可信用户输入提供的 URL

输入清理

所有用户输入都应：

• 验证是否符合预期格式
• 在用于生成代码时进行转义
• 绝不要直接传递给 eval() 或 shell 执行

反模式

验证清单

测试计划：

• 明确定义范围（包含／不包含）
• 明确指定进入／退出标准
• 识别风险并制定缓解措施
• 时间安排切实可行

测试用例：

• 每个步骤都有预期结果
• 记录前置条件
• 测试数据使用占位符（不硬编码凭据）
• 指定优先级

自动化测试：

• 使用基于角色的定位器
• 实现 Web 优先断言
• 应用页面对象模型
• 使用 test.step() 分组以提高可读性
• 处理错误并截取屏幕截图
• 从环境变量加载凭据

Bug 报告：

• 提供可复现的步骤
• 记录环境信息
• 附上屏幕截图／证据
• 设置严重性／优先级

模板

可用模板

模板用法

所有模板都位于 templates/ 中。使用方法如下：

1. 将模板复制到项目目录
2. 填写占位符（以 [brackets] 或 ${VARIABLE} 标记）
3. 根据具体需求自定义章节
4. 视情况删除或添加章节
5. 保存并进行版本控制，完成文档

参考资料

• references/test_case_templates.md - 所有测试类型的标准格式
• references/bug_report_templates.md - 文档模板
• references/regression_testing.md - 测试套件的构建与执行
• references/playwright_automation.md - 浏览器自动化与测试生成

示例

"Create a test case for user login with valid credentials using the test-case.md template"

"Create a bug report for a login form validation issue using the bug-report.md template"

"Create Playwright tests for the login flow using the playwright-test.md template"

最佳实践（避免上述反模式）

编写测试用例

• 描述具体且明确；为每个步骤注明预期结果
• 每个用例只测试一件事；记录所有前提条件和测试数据
• 纳入边界情况和边界值；使用一致的命名方式

报告错误

• 提供精简、准确的重现步骤；注明环境详情
• 附上截图或视频，并描述对用户和业务的影响
• 设置严重程度和优先级；使用清晰、具体的标题以避免重复报告

回归测试

• 将重复测试自动化；优先覆盖关键路径
• 经常运行冒烟测试；定期审查并精简测试套件
• 使用一致的标签；绝不忽略失败的回归测试

安全

• 使用环境变量存储凭据；绝不提交机密信息
• 导航前验证 URL；报告可疑内容
• 绝不执行来自用户输入的任意 JavaScript

质量门禁（自检）

• 测试计划包含范围、方法、风险、环境、进入／退出标准、交付物和指标
• 测试用例可追溯、原子化、确定性强，并包含明确的判定依据和数据
• 自动化易于维护（稳定的定位器、尽量减少不稳定测试、测试相互独立、断言清晰）
• 回归测试基于风险、带有标签，并经过筛选，且有明确的增删规则
• 错误报告可复现、可执行，并包含证据、环境和影响

故障排除

常见借口

常见的捷径和“差不多就行”的借口会降低测试质量——以下是每种说法背后的实际情况。

“测试显示的是缺陷的存在，而非缺陷的不存在。”——Edsger Dijkstra

“品质不是一时之举，而是一种习惯。”——Aristotle

验证

完成此技能的工作流后，请确认：

• 已创建测试策略文档 — 涵盖范围、方法、资源、时间安排和风险
• 已定义测试级别 — 定义单元、集成、E2E 和验收级别及其标准
• 已记录进入/退出标准 — 明确测试开始和结束的条件
• 已按风险确定优先级 — 根据影响 x 可能性对测试进行优先级排序
• 已列出环境要求 — 硬件、软件、数据和网络要求
• 已定义缺陷管理流程 — 说明如何报告、跟踪和解决 Bug
• 已获利益相关方签字确认 — 测试计划已由相关利益相关方审查并批准