AI Skills
qa-test-planner

qa-test-planner

热门

为QA工程师生成全面的测试计划、手动测试用例、回归测试套件和错误报告。包含Figma MCP集成，用于设计验证。

2208Star
212Fork
更新于 2026/3/5
获取 Skill源代码

相关 Skills

architecture-patterns3.8万fsharp-testing24万observability-and-instrumentation7.9万
SKILL.md
readonly只读
name
qa-test-planner
description

为QA工程师生成全面的测试计划、手动测试用例、回归测试套件和错误报告。包含Figma MCP集成，用于设计验证。

QA测试计划器

一个为QA工程师设计的综合技能，用于创建测试计划、生成手动测试用例、构建回归测试套件、对照Figma验证设计以及有效记录错误。

激活方式： 此技能仅在明确通过名称调用时触发（例如 /qa-test-planner、qa-test-planner 或 use the skill qa-test-planner）。

快速开始

创建测试计划：

"为用户认证功能创建测试计划"

生成测试用例：

"为结账流程生成手动测试用例"

构建回归套件：

"为支付模块构建回归测试套件"

对照Figma验证：

"将登录页面与[URL]处的Figma设计进行比较"

创建错误报告：

"为表单验证问题创建错误报告"

快速参考

任务 输出内容 耗时
测试计划 策略、范围、时间表、风险 10-15分钟
测试用例 逐步说明、预期结果 每个5-10分钟
回归套件 冒烟测试、关键路径、执行顺序 15-20分钟
Figma验证 设计与实现对比、差异列表 10-15分钟
错误报告 可重现步骤、环境、证据 5分钟

工作原理

您的请求
    │
    ▼
┌─────────────────────────────────────────────────────┐
│ 1. 分析                                              │
│    • 解析功能/需求                                    │
│    • 识别所需的测试类型                                │
│    • 确定范围和优先级                                  │
├─────────────────────────────────────────────────────┤
│ 2. 生成                                              │
│    • 创建结构化的交付物                                │
│    • 应用模板和最佳实践                                │
│    • 包含边界情况和变体                                │
├─────────────────────────────────────────────────────┤
│ 3. 验证                                              │
│    • 检查完整性                                        │
│    • 验证可追溯性                                      │
│    • 确保可操作步骤                                    │
└─────────────────────────────────────────────────────┘
    │
    ▼
QA交付物就绪

命令

交互式脚本

脚本 用途 用法
./scripts/generate_test_cases.sh 交互式创建测试用例 逐步提示
./scripts/create_bug_report.sh 生成错误报告 引导式输入收集

自然语言

请求 输出
"为{功能}创建测试计划" 完整的测试计划文档
"为{功能}生成{N}个测试用例" 带步骤的编号测试用例
"构建冒烟测试套件" 关键路径测试
"与{URL}处的Figma比较" 视觉验证检查清单
"记录错误：{描述}" 结构化的错误报告

核心交付物

1. 测试计划

  • 测试范围和目标
  • 测试方法和策略
  • 环境要求
  • 进入/退出标准
  • 风险评估
  • 时间表和里程碑

2. 手动测试用例

  • 逐步说明
  • 预期结果与实际结果
  • 前置条件和设置
  • 测试数据要求
  • 优先级和严重程度

3. 回归套件

  • 冒烟测试（15-30分钟）
  • 完整回归（2-4小时）
  • 定向回归（30-60分钟）
  • 执行顺序和依赖关系

4. Figma验证

  • 逐组件比较
  • 间距和排版检查
  • 颜色和视觉一致性
  • 交互状态验证

5. 错误报告

  • 清晰的重现步骤
  • 环境详情
  • 证据（截图、日志）
  • 严重程度和优先级

反模式

避免 原因 建议
模糊的测试步骤 无法重现 具体操作 + 预期结果
缺少前置条件 测试意外失败 记录所有设置要求
无测试数据 测试人员受阻 提供样本数据或生成方法
通用的错误标题 难以跟踪 具体："[功能]在[操作]时出现问题"
跳过边界情况 遗漏关键错误 包含边界值、空值等

验证检查清单

测试计划：

  • [ ] 范围明确定义（包含/排除）
  • [ ] 进入/退出标准已指定
  • [ ] 已识别风险并制定缓解措施
  • [ ] 时间表合理

测试用例：

  • [ ] 每个步骤都有预期结果
  • [ ] 前置条件已记录
  • [ ] 测试数据可用
  • [ ] 已分配优先级

错误报告：

  • [ ] 可重现的步骤
  • [ ] 环境已记录
  • [ ] 截图/证据已附加
  • [ ] 严重程度/优先级已设置

参考资料

<details>
<summary><strong>深入探讨：测试用例结构</strong></summary>

标准测试用例格式

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

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

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

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

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

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

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

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

### 后置条件
- [测试后的系统状态]
- [需要清理的内容]

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

测试类型

类型 重点 示例
功能 业务逻辑 使用有效凭据登录
UI/视觉 外观、布局 按钮与Figma设计匹配
集成 组件交互 API向前端返回数据
回归 现有功能 以前的功能仍然有效
性能 速度、负载处理 页面在3秒内加载
安全 漏洞 防止SQL注入

</details>

<details>
<summary><strong>深入探讨：测试计划模板</strong></summary>

测试计划结构

# 测试计划：[功能/发布名称]

## 执行摘要
- 正在测试的功能/产品
- 测试目标
- 关键风险
- 时间表概览

## 测试范围

**包含范围：**
- 要测试的功能
- 测试类型（功能、UI、性能）
- 平台和环境
- 用户流程和场景

**排除范围：**
- 不测试的功能
- 已知限制
- 第三方集成（如适用）

## 测试策略

**测试类型：**
- 手动测试
- 探索性测试
- 回归测试
- 集成测试
- 用户验收测试

**测试方法：**
- 黑盒测试
- 正向和负向测试
- 边界值分析
- 等价类划分

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

## 进入标准
- [ ] 需求已记录
- [ ] 设计已定稿
- [ ] 测试环境就绪
- [ ] 测试数据已准备
- [ ] 构建已部署

## 退出标准
- [ ] 所有高优先级测试用例已执行
- [ ] 90%以上测试用例通过率
- [ ] 所有关键错误已修复
- [ ] 无未解决的高严重性错误
- [ ] 回归套件已通过

## 风险评估

| 风险 | 概率 | 影响 | 缓解措施 |
|------|-------------|--------|------------|
| [风险1] | 高/中/低 | 高/中/低 | [缓解措施] |

## 测试交付物
- 测试计划文档
- 测试用例
- 测试执行报告
- 错误报告
- 测试总结报告

</details>

<details>
<summary><strong>深入探讨：错误报告</strong></summary>

错误报告模板

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

**严重程度：** 致命 | 高 | 中 | 低
**优先级：** P0 | P1 | P2 | P3
**类型：** 功能 | UI | 性能 | 安全
**状态：** 打开 | 处理中 | 已修复 | 已关闭

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

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

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

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

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

## 视觉证据
- 截图：[已附加]
- 视频：[链接（如适用）]
- 控制台错误：[粘贴错误]

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

## 附加上下文
- 相关：[功能/工单]
- 回归：[是/否]
- Figma设计：[如果是UI错误的链接]

严重程度定义

级别 标准 示例
致命 (P0) 系统崩溃、数据丢失、安全 支付失败、登录中断
高 (P1) 主要功能损坏，无变通方案 搜索无法工作
中 (P2) 功能部分损坏，有变通方案 筛选缺少一个选项
低 (P3) 外观问题，罕见边界情况 拼写错误、轻微对齐

</details>

<details>
<summary><strong>深入探讨：Figma MCP集成</strong></summary>

设计验证工作流

前提条件：

  • Figma MCP服务器已配置
  • 可访问Figma设计文件
  • 组件/页面的Figma URL

流程：

  1. 从Figma获取设计规格
"从Figma文件[URL]获取按钮规格"

响应包括：
- 尺寸（宽度、高度）
- 颜色（背景、文本、边框）
- 排版（字体、大小、粗细）
- 间距（内边距、外边距）
- 边框半径
- 状态（默认、悬停、激活、禁用）
  1. 比较实现
TC: 主按钮视觉验证
1. 在浏览器开发者工具中检查主按钮
2. 与Figma规格比较：
   - 尺寸：120x40px
   - 边框半径：8px
   - 背景颜色：#0066FF
   - 字体：16px Medium #FFFFFF
3. 记录差异
  1. 如果不匹配则创建错误
BUG: 主按钮颜色与设计不匹配
严重程度：中
预期（Figma）：#0066FF
实际（实现）：#0052CC
截图：[已附加]
Figma链接：[具体组件]

要验证的内容

元素 检查内容 工具
颜色 精确的十六进制值 浏览器取色器
间距 内边距/外边距像素 DevTools计算样式
排版 字体、大小、粗细 DevTools字体面板
布局 宽度、高度、位置 DevTools盒模型
状态 悬停、激活、聚焦 手动交互
响应式 断点行为 DevTools设备模式

示例查询

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

</details>

<details>
<summary><strong>深入探讨：回归测试</strong></summary>

套件结构

套件类型 时长 频率 覆盖范围
冒烟 15-30分钟 每日 仅关键路径
定向 30-60分钟 每次变更 受影响区域
完整 2-4小时 每周/发布 全面
健全 10-15分钟 热修复后 快速验证

构建回归套件

步骤1：识别关键路径

  • 用户离不开什么？
  • 什么产生收入？
  • 什么处理敏感数据？
  • 什么最常用？

步骤2：对测试用例排序

优先级 描述 必须运行
P0 业务关键、安全 始终
P1 主要功能、常见流程 每周+
P2 次要功能、边界情况 发布时

步骤3：执行顺序

  1. 先冒烟——如果失败，停止并修复构建
  2. 接下来P0测试——必须通过才能继续
  3. 然后P1，再P2——跟踪所有失败
  4. 探索性测试——发现意外问题

通过/失败标准

通过：

  • 所有P0测试通过
  • 90%以上P1测试通过
  • 无关键错误未解决

失败（阻止发布）：

  • 任何P0测试失败
  • 发现关键错误
  • 安全漏洞
  • 数据丢失场景

有条件：

  • P1失败但有变通方案
  • 已知问题已记录
  • 修复计划已就位

</details>

<details>
<summary><strong>深入探讨：测试执行跟踪</strong></summary>

测试运行报告模板

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

**日期：** 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-234
  - 状态：打开

## 阻塞的测试
- TC-112：仪表板小部件（API端点宕机）

## 风险
- 2个关键错误阻止发布
- 支付集成需要关注

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

覆盖跟踪

## 覆盖矩阵

| 功能 | 需求 | 测试用例 | 状态 | 缺口 |
|---------|--------------|------------|--------|------|
| 登录 | 8 | 12 | 完成 | 无 |
| 结账 | 15 | 10 | 部分 | 支付错误 |
| 仪表板 | 12 | 15 | 完成 | 无 |

</details>

<details>
<summary><strong>QA流程工作流</strong></summary>

阶段1：计划

  • [ ] 审查需求和设计
  • [ ] 创建测试计划
  • [ ] 识别测试场景
  • [ ] 估算工作量和时间表
  • [ ] 设置测试环境

阶段2：测试设计

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

阶段3：执行

  • [ ] 执行测试用例
  • [ ] 用清晰步骤记录错误
  • [ ] 对照Figma验证（UI测试）
  • [ ] 跟踪测试进度
  • [ ] 沟通阻塞项

阶段4：报告

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

</details>

<details>
<summary><strong>最佳实践</strong></summary>

测试用例编写

应该做：

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

不应该做：

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

错误报告

应该做：

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

不应该做：

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

回归测试

应该做：

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

不应该做：

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

</details>

示例

<details>
<summary><strong>示例：登录流程测试用例</strong></summary>

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

**优先级：** P0（致命）
**类型：** 功能
**预计时间：** 2分钟

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

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

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

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

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

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

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

### 需要考虑的边界情况
- TC-LOGIN-002：无效密码
- TC-LOGIN-003：不存在的邮箱
- TC-LOGIN-004：SQL注入尝试
- TC-LOGIN-005：超长密码

</details>

<details>
<summary><strong>示例：响应式设计测试用例</strong></summary>

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

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

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

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

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

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

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

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

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

</details>

“测试只能证明存在错误，不能证明没有错误。”——Edsger Dijkstra

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