名称：qa-test-planner 描述：为QA工程师生成全面的测试计划、手动测试用例、回归测试套件和bug报告。包括与Figma MCP集成以进行设计验证。

QA测试规划器

一个全面的技能，帮助QA工程师创建测试计划、生成手动测试用例、构建回归测试套件、验证设计与Figma的一致性，并有效记录bug。

这个技能的作用

帮助QA工程师：

测试计划创建 - 全面的测试策略和规划
手动测试用例生成 - 详细的逐步测试用例
回归测试套件 - 关键路径和烟雾测试套件
Figma设计验证 - 比较实现与设计（需要Figma MCP）
Bug报告模板 - 清晰、可复现的bug文档
测试覆盖率分析 - 识别测试空白
测试执行跟踪 - 监控测试进度

为什么需要这个技能

没有结构化测试：

测试覆盖不一致
遗漏边缘情况
Bug文档质量差
无回归安全网
设计与实现差距
测试策略不清晰

使用这个技能：

全面的测试覆盖
可重复的测试用例
系统化回归测试
设计与实现验证
专业的bug报告
清晰的测试路线图

核心组件

1. 测试计划生成器

测试范围和目标
测试方法和策略
测试环境需求
进入/退出标准
风险评估
资源分配
时间线和里程碑

2. 手动测试用例生成器

逐步指令
预期与实际结果
前置条件和设置
测试数据需求
优先级和严重性
边缘情况识别

3. 回归测试套件构建器

烟雾测试用例
关键路径测试
集成测试场景
向后兼容性检查
性能回归测试

4. Figma设计验证（使用MCP）

比较UI实现与设计
识别视觉差异
验证间距、颜色、字体
检查组件一致性
标记设计与开发不匹配

5. Bug报告生成器

清晰的复现步骤
环境详情
预期与实际行为
截图和证据
严重性和优先级
相关测试用例

测试用例结构

标准测试用例格式

## TC-001: [测试用例标题]

**优先级：** 高 | 中 | 低
**类型：** 功能 | UI | 集成 | 回归
**状态：** 未运行 | 通过 | 失败 | 阻塞

### 目标
[我们测试什么和为什么]

### 前置条件
- [设置要求1]
- [设置要求2]
- [所需测试数据]

### 测试步骤
1. [执行的操作]
   **预期：** [应该发生什么]

2. [执行的操作]
   **预期：** [应该发生什么]

3. [执行的操作]
   **预期：** [应该发生什么]

### 测试数据
- 输入：[测试数据值]
- 用户：[测试账户详情]
- 配置：[环境设置]

### 后置条件
- [测试后系统状态]
- [所需清理]

### 备注
- [考虑的边缘情况]
- [相关测试用例]
- [已知问题]

测试计划模板

执行摘要

测试的功能/产品
测试目标
关键风险
时间线概览

测试范围

在范围内：

要测试的功能
测试类型（功能、UI、性能等）
平台和环境
用户流程和场景

不在范围内：

不测试的功能（推迟）
已知限制
第三方集成（如适用）

测试策略

测试类型：

手动测试
探索性测试
回归测试
集成测试
用户验收测试
性能测试（如适用）

测试方法：

黑盒测试
正向和负向测试
边界值分析
等价类划分

测试环境

操作系统
浏览器和版本
设备（手机、平板、桌面）
测试数据需求
后端/API环境

进入标准

[ ] 需求文档化
[ ] 设计最终确定
[ ] 测试环境就绪
[ ] 测试数据准备
[ ] 构建部署到测试环境

退出标准

[ ] 所有高优先级测试用例执行
[ ] 90%+测试用例通过率
[ ] 所有关键bug修复
[ ] 无开放高严重性bug
[ ] 回归套件通过
[ ] 利益相关者签署

风险评估

风险	概率	影响	缓解措施
[风险1]	高/中/低	高/中/低	[如何缓解]
[风险2]	高/中/低	高/中/低	[如何缓解]

测试交付物

测试计划文档
测试用例
测试执行报告
Bug报告
测试摘要报告

测试类型和方法

1. 功能测试

什么： 验证功能按规范工作

测试用例：

快乐路径场景
错误处理
输入验证
业务逻辑
数据完整性

示例：

TC: 用户使用有效凭据登录
1. 导航到登录页面
2. 输入有效邮箱和密码
3. 点击“登录”按钮
预期：用户重定向到仪表板，显示欢迎消息

2. UI/视觉测试

什么： 验证视觉外观和布局

测试用例：

布局和对齐
响应式设计
颜色和字体
组件状态（悬停、激活、禁用）
跨浏览器兼容性

使用Figma MCP：

比较实现与Figma设计
验证间距（内边距、外边距）
检查字体大小和粗细
验证颜色值
确保图标准确性

示例：

TC: 主页英雄部分视觉验证
1. 在浏览器中打开主页
2. 与Figma设计[链接]比较
3. 验证：
   - 标题字体：48px，粗体，#1A1A1A
   - CTA按钮：16px内边距，#0066FF背景
   - 图片宽高比：16:9
   - 间距：64px底部外边距
预期：所有视觉元素与Figma完全匹配

3. 回归测试

什么： 确保现有功能仍然工作

何时运行：

每次发布前
bug修复后
新功能后
每周烟雾测试

套件组件：

烟雾测试（关键路径）
完整回归（全面）
目标回归（受影响区域）

示例：

回归套件：用户认证
- 使用有效凭据登录
- 使用无效凭据登录
- 密码重置流程
- 会话超时处理
- 多设备登录
- 社交登录（Google、GitHub）

4. 集成测试

什么： 验证不同组件协同工作

测试用例：

API集成
数据库操作
第三方服务
跨模块交互
组件间数据流

示例：

TC: 结账支付集成
1. 添加商品到购物车
2. 进入结账
3. 输入支付详情（Stripe）
4. 提交支付
预期：
- 通过Stripe API处理支付
- 在数据库中创建订单
- 发送确认邮件
- 更新库存

5. 探索性测试

什么： 无脚本、创造性测试

方法：

基于章程的探索
用户角色模拟
边缘情况发现
可用性评估

会话模板：

探索性测试会话
章程：作为[用户类型]探索[功能]
时间：60分钟
焦点：[探索区域]

发现：
- [发现的bug/问题]
- [UX问题]
- [改进建议]

跟进：
- [要创建的测试用例]
- [要报告的bug]

Figma MCP集成

设计验证工作流

先决条件：

Figma MCP服务器配置
设计文件访问
Figma URL可用

验证过程：

从Figma获取设计规格

“从Figma文件[URL]获取按钮规格”
- 组件：主按钮
- 宽度：120px
- 高度：40px
- 边框半径：8px
- 背景：#0066FF
- 字体：16px，中， #FFFFFF

比较实现

TC: 主按钮视觉验证
1. 在浏览器开发者工具中检查主按钮
2. 与Figma规格比较：
   - 尺寸：120x40px ✓ / ✗
   - 边框半径：8px ✓ / ✗
   - 背景颜色：#0066FF ✓ / ✗
   - 字体：16px中 #FFFFFF ✓ / ✗
3. 记录差异

如果不匹配则创建Bug

BUG: 主按钮颜色与设计不匹配
严重性：中
预期（Figma）：#0066FF
实际（实现）：#0052CC
截图：[附件]
Figma链接：[特定组件]

设计与开发交接清单

使用Figma MCP：

[ ] 从设计检索间距值
[ ] 验证调色板匹配
[ ] 检查字体规格
[ ] 验证组件状态（悬停、激活、禁用）
[ ] 确认断点行为
[ ] 审查图标和资产
[ ] 检查无障碍注释

Bug报告最佳实践

有效Bug报告模板

# BUG-[ID]: [清晰、具体的标题]

**严重性：** 关键 | 高 | 中 | 低
**优先级：** P0 | P1 | P2 | P3
**类型：** 功能 | UI | 性能 | 安全
**状态：** 开放 | 进行中 | 已修复 | 已关闭

## 环境
- **操作系统：** [Windows 11、macOS 14等]
- **浏览器：** [Chrome 120、Firefox 121等]
- **设备：** [桌面、iPhone 15等]
- **构建：** [版本/提交]
- **URL：** [bug发生页面]

## 描述
[对问题的清晰、简洁描述]

## 复现步骤
1. [具体步骤]
2. [具体步骤]
3. [具体步骤]

## 预期行为
[应该发生什么]

## 实际行为
[实际发生什么]

## 视觉证据
- 截图：[附件]
- 视频：[如适用链接]
- 控制台错误：[粘贴错误]
- 网络日志：[如相关]

## 影响
- **用户影响：** [多少用户受影响]
- **频率：** [总是、有时、很少]
- **变通方案：** [如果存在]

## 额外上下文
- 相关：[功能/工单]
- 首次发现：[何时]
- 回归：[是/否 - 如果是，从何时]
- Figma设计：[如果是UI bug则链接]

## 受影响的测试用例
- TC-001：[失败的测试用例]
- TC-045：[相关测试用例]

Bug严重性定义

关键（P0）：

系统崩溃或数据丢失
安全漏洞
完全功能故障
阻塞发布

高（P1）：

主要功能不工作
重大用户影响
无变通方案
发布前应修复

中（P2）：

功能部分工作
变通方案可用
轻微用户不便
可在下个版本修复

低（P3）：

外观问题
罕见边缘情况
最小影响
有则修复更好

测试覆盖率分析

覆盖指标

功能覆盖：

总功能：25
已测试：23
未测试：2
覆盖率：92%

需求覆盖：

总需求：150
有测试用例：142
无测试用例：8
覆盖率：95%

风险覆盖：

高风险区域：12
已测试：12
中风险：35
已测试：30

覆盖矩阵

功能	需求	测试用例	状态	空白
登录	8	12	✓ 完成	无
结账	15	10	⚠ 部分	支付错误
仪表板	12	15	✓ 完成	无

回归测试套件结构

烟雾测试套件（15-30分钟）

运行： 每次测试周期前、每日构建

关键路径：

用户登录/登出
核心用户流程（如创建订单）
导航和路由
API健康检查
数据库连接性

示例：

SMOKE-001: 关键用户流程
1. 作为标准用户登录
2. 导航到主要功能
3. 执行主要操作
4. 验证成功消息
5. 登出
预期：所有步骤完成无错误

完整回归套件（2-4小时）

运行： 每周、发布前

覆盖：

所有功能测试用例
集成场景
UI验证
跨浏览器检查
数据完整性测试

目标回归（30-60分钟）

运行： bug修复后、功能更新后

覆盖：

受影响功能区域
相关组件
集成点
先前失败的测试

测试执行跟踪

测试运行模板

# 测试运行：[发布版本]

**日期：** 2024-01-15
**构建：** v2.5.0-rc1
**测试员：** [姓名]
**环境：** 暂存

## 摘要
- 总测试用例：150
- 已执行：145
- 通过：130
- 失败：10
- 阻塞：5
- 未运行：5
- 通过率：90%

## 按优先级测试用例

| 优先级 | 总数 | 通过 | 失败 | 阻塞 |
|----------|-------|------|------|---------|
| P0（关键） | 25 | 23 | 2 | 0 |
| P1（高） | 50 | 45 | 3 | 2 |
| P2（中） | 50 | 45 | 3 | 2 |
| P3（低） | 25 | 17 | 2 | 1 |

## 失败

### 关键失败
- TC-045: 支付处理失败
  - Bug：BUG-234
  - 状态：开放

### 高优先级失败
- TC-089: 邮件通知未发送
  - Bug：BUG-235
  - 状态：进行中

## 阻塞测试
- TC-112: 仪表板小部件（API端点关闭）
- TC-113: 导出功能（依赖未部署）

## 风险
- 2个关键bug阻塞发布
- 支付集成需要关注
- 邮件服务间歇性

## 下一步
- 在BUG-234修复后重测
- 完成剩余5个测试用例
- 签署前运行完整回归

使用这个技能

生成测试计划

./scripts/generate_test_plan.sh

创建全面测试计划的交互式工作流。

生成手动测试用例

./scripts/generate_test_cases.sh

为功能创建逐步指令的手动测试用例。

构建回归套件

./scripts/build_regression_suite.sh

创建烟雾和回归测试套件。

使用Figma验证设计

配置Figma MCP后：

“比较登录页面实现与Figma设计[URL]，并为视觉验证生成测试用例”

创建Bug报告

./scripts/create_bug_report.sh

生成包含所有必要详情的结构化bug报告。

访问模板

references/test_case_templates.md - 各种测试用例格式
references/bug_report_templates.md - Bug文档模板
references/regression_testing.md - 回归测试指南
references/figma_validation.md - 使用Figma MCP的设计验证

QA流程工作流

1. 规划阶段

[ ] 审查需求和设计
[ ] 创建测试计划
[ ] 识别测试场景
[ ] 估算努力和时间线
[ ] 设置测试环境

2. 测试设计阶段

[ ] 编写测试用例
[ ] 与团队审查测试用例
[ ] 准备测试数据
[ ] 构建回归套件
[ ] 获取Figma设计访问

3. 测试执行阶段

[ ] 执行测试用例
[ ] 记录带清晰复现步骤的bug
[ ] 验证与Figma设计的一致性（UI测试）
[ ] 跟踪测试进度
[ ] 沟通阻塞

4. 报告阶段

[ ] 编译测试结果
[ ] 分析覆盖
[ ] 记录风险
[ ] 提供通过/不通过建议
[ ] 归档测试工件

最佳实践

测试用例编写

做：

✅ 具体且无歧义
✅ 每个步骤包含预期结果
✅ 每个测试用例测试一件事
✅ 使用一致的命名约定
✅ 保持测试用例可维护

不做：

❌ 假设知识
❌ 使测试用例过长
❌ 跳过前置条件
❌ 忘记边缘情况
❌ 预期结果模糊

Bug报告

做：

✅ 提供清晰复现步骤
✅ 包含截图/视频
✅ 指定确切环境详情
✅ 描述对用户的影响
✅ 链接到Figma用于UI bug

不做：

❌ 无复现步骤报告
❌ 使用模糊描述
❌ 跳过环境详情
❌ 忘记分配优先级
❌ 重复现有bug

回归测试

做：

✅ 尽可能自动化重复测试
✅ 定期维护回归套件
✅ 优先处理关键路径
✅ 频繁运行烟雾测试
✅ 每次发布后更新套件

不做：

❌ 发布前跳过回归
❌ 让套件过时
❌ 每次测试所有内容
❌ 忽略失败的回归测试

Figma MCP设置

配置

安装Figma MCP服务器：

# 遵循Figma MCP安装说明
# 使用Figma API令牌配置
# 设置文件访问权限

在测试规划中使用：

“分析Figma设计文件[URL]，为以下生成视觉验证测试用例：
- 颜色方案合规性
- 字体规格
- 组件间距
- 响应式断点
- 交互状态”

示例查询：

“从Figma设计[URL]获取按钮规格”
“比较导航菜单实现与Figma设计”
“从Figma提取仪表板布局的间距值”
“列出Figma设计系统中使用的所有颜色标记”

测试用例示例

示例1：登录流程

## TC-LOGIN-001: 有效用户登录

**优先级：** P0（关键）
**类型：** 功能
**预估时间：** 2分钟

### 目标
验证用户可以使用有效凭据成功登录

### 前置条件
- 用户账户存在（test@example.com / Test123!）
- 用户尚未登录
- 浏览器cookie已清除

### 测试步骤
1. 导航到 https://app.example.com/login
   **预期：** 登录页面显示邮箱和密码字段

2. 输入邮箱：test@example.com
   **预期：** 邮箱字段接受输入

3. 输入密码：Test123!
   **预期：** 密码字段显示掩码字符

4. 点击“登录”按钮
   **预期：**
   - 显示加载指示器
   - 用户重定向到 /dashboard
   - 显示欢迎消息：“欢迎回来，测试用户”
   - 头像/个人资料图像显示在头部

### 后置条件
- 用户会话创建
- 认证令牌存储
- 分析事件记录

### 视觉验证（使用Figma）
- 比较仪表板布局与Figma设计[链接]
- 验证欢迎消息字体：24px，中，#1A1A1A
- 检查头像大小：40x40px，边框半径50%

### 考虑的边缘情况
- TC-LOGIN-002: 无效密码
- TC-LOGIN-003: 不存在的邮箱
- TC-LOGIN-004: SQL注入尝试
- TC-LOGIN-005: 非常长的密码

示例2：响应式设计验证

## TC-UI-045: 移动导航菜单

**优先级：** P1（高）
**类型：** UI/响应式
**设备：** 移动（iPhone、Android）

### 目标
验证导航菜单在移动设备上正确工作

### 前置条件
- 从移动设备或响应式模式访问
- 视口宽度：375px（iPhone SE）到428px（iPhone Pro Max）

### 测试步骤
1. 在移动设备上打开主页
   **预期：** 汉堡菜单图标可见（右上角）

2. 点击汉堡图标
   **预期：**
   - 菜单从右侧滑入
   - 覆盖层出现在内容上
   - 关闭（X）按钮可见

3. 点击菜单项
   **预期：** 导航到部分，菜单关闭

4. 与Figma移动设计[链接]比较
   **预期：**
   - 菜单宽度：280px
   - 滑动动画：300ms缓出
   - 覆盖层不透明度：0.5，颜色 #000000
   - 字体大小：16px，行高24px

### 要测试的断点
- 375px（iPhone SE）
- 390px（iPhone 14）
- 428px（iPhone 14 Pro Max）
- 360px（Galaxy S21）

摘要

这个QA测试规划器技能提供：

结构化测试规划 - 全面的测试策略
手动测试用例生成 - 详细、可重复的测试
回归测试 - 防止破坏性变更
Figma验证 - 设计与实现验证
Bug文档 - 清晰、可操作的报告
覆盖分析 - 识别测试空白

记住： 质量是每个人的责任，但QA确保它被系统化验证。

“测试显示bug的存在，而不是它们的缺失。” - Edsger Dijkstra

“质量不是一次行为，而是一种习惯。” - 亚里士多德