القائمة
发现缺陷需要记录时使用。适用于功能测试、回归测试、探索式测试发现的所有缺陷。融合 Cem Kaner 缺陷报告、ISTQB 缺陷生命周期、严重度优先级矩阵。
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/zhaoxuya520/AI-Fullstack-Delivery-Workflow --skill bug-reportingيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
设计 API 认证鉴权和权限矩阵时使用。适用于多角色系统、租户隔离、字段级权限。优先使用 OAuth 2.0 / JWT + RBAC + 资源归属检查。
设计具体 API 端点时使用。适用于资源建模后的下一步、列端点清单、HTTP 方法和状态码选择。优先使用 RFC 7231 HTTP 语义 + GitHub REST 命名规范。
设计 API 错误码和错误结构时使用。适用于错误响应规范、调用方错误处理、调试可观测。优先使用 RFC 7807 Problem Details + 业务错误码 + 调用方处理建议。
استنادا إلى تصنيف SOC المهني
عرض SKILL.md
| name | bug-reporting |
| description | 发现缺陷需要记录时使用。适用于功能测试、回归测试、探索式测试发现的所有缺陷。融合 Cem Kaner 缺陷报告、ISTQB 缺陷生命周期、严重度优先级矩阵。 |
参考来源：Cem Kaner《Lessons Learned in Software Testing》、Google Bug Tracking Best Practices、ISTQB Foundation。
1. Bug 报告是给开发看的
开发能 5 分钟内复现 = 好报告
2. 标题 = 模块 + 现象 + 关键条件
"登录失败" 是垃圾标题
3. 最小复现路径
去掉无关步骤，留必要的
4. 预期 vs 实际明确
不能让开发猜你想要什么
5. 严重度 × 优先级 分开
严重度 = 影响大小（QA 判）
优先级 = 修复紧迫度（PM 判）
6. 复现率必须说
"偶发" / "100% 复现" 信息量天差地别
| 坏标题 | 好标题 |
|---|---|
| 登录失败 | [登录] 输入超过 64 字符的邮箱时返回 500 而非 400 |
| 提交按钮没用 | [订单创建] 网络慢时（>3s）连续点击导致重复创建 |
| 显示错误 | [订单列表] 时区切换后 created_at 显示错误（晚 8 小时） |
| 性能问题 | [搜索] 关键词包含特殊字符 % 时响应时间从 200ms 增至 30s |
原则：删一步还能复现，就再删
❌ 长流程：
1. 注册账号
2. 登录
3. 充值 100
4. 浏览商品
5. 加入购物车
6. 结算
7. 支付
8. 退款 → 出问题
✅ 最小：
前置：已存在状态=paid 的订单 ORD-123
1. POST /orders/ORD-123/refund {"amount": -100}
2. 观察响应
1. 标题（含模块 + 现象 + 条件）
2. 环境（版本 / 浏览器 / 设备 / 数据库）
3. 账号（角色 / 租户 / 测试账号）
4. 前置条件（最小数据准备）
5. 复现步骤（编号清晰）
6. 预期结果
7. 实际结果
8. 截图 / 录屏 / 日志 / trace_id
9. 严重度 + 优先级
10. 复现率（100% / 50% / 偶发）
11. 影响范围（用户 / 功能 / 环境）
12. 是否需要立即缓解
| 等级 | 含义 | 示例 |
|---|---|---|
| S0 致命 | 数据丢失 / 资金损失 / 全用户阻塞 / 安全漏洞 | 重复扣款 / 数据被覆盖 / SQL 注入 |
| S1 严重 | 核心功能不可用 / 部分用户阻塞 | 登录失败 / 支付失败 |
| S2 一般 | 功能不完整 / 有 workaround | 部分字段不显示 / 排序错 |
| S3 轻微 | UI / 文案 / 边缘场景 | 文案错字 / 像素偏移 |
| 等级 | 含义 | 修复时间 |
|---|---|---|
| P0 | 阻塞上线 | 立即 |
| P1 | 本版本必修 | 本迭代 |
| P2 | 下版本修 | 下迭代 |
| P3 | 排期看 | 何时都行 |
注意：S 和 P 不必相同。例如：S3 文案错但出现在落地页 → P0 立即修。
New（新建）
↓
Assigned（分配）
↓
In Progress（修复中）
↓
Fixed（已修复）
↓
Verified（QA 验证通过）
↓
Closed（关闭）
或：
↓
Reopened（验证失败，重新打开）
↓
（回到 In Progress）
或：
↓
Wont Fix / Duplicate / Cannot Reproduce
QA 操作：New / Verified / Closed / Reopened
Dev 操作：Assigned / In Progress / Fixed / Wont Fix
PM 操作：调整优先级 / Wont Fix 决策 / 关闭
1. 发现现象
- 当前操作 / 数据 / 环境
↓
2. 尝试最小复现
- 删步骤直到不能复现
↓
3. 收集证据
- 截图 / 录屏 / 日志 / trace_id / cURL
↓
4. 评估影响
- 严重度 / 复现率 / 影响范围
↓
5. 写报告
- 标题 + 复现 + 预期 + 实际 + 证据
↓
6. 标定优先级
- 与 PM 沟通
↓
7. 紧急的报告先短信 / 群里说
- S0 / P0 不能只靠 ticket
↓
8. 修复后验证
- 原路径 + 边界 + 回归套件
↓
9. 转化为回归用例
- 见 regression-testing
↓
10. 沉淀经验
- 同类问题的根因 → field-journal
1. 收集所有可能的状态
- 时间 / 数据 / 用户 / 环境 / 时序
2. 增加日志
- 与开发协作加 debug 日志
3. 监控触发条件
- 用户上报 / 客诉 / 监控告警
4. 不立即关 "Cannot Reproduce"
- 标 "Pending Reproduction" 跟踪 1 周
5. 实在再现不了
- 关闭 + field-journal 记录现象 + 触发条件假设
按模块：哪个模块 Bug 最多 → 重点测
按严重度：S0/S1 占比 → 上线就绪度
按发现阶段：单元 / 集成 / E2E / 探索 / 生产
→ 越晚发现，成本越高
按根因类别：
- 需求不清
- 设计缺陷
- 编码错误
- 配置问题
- 数据问题
- 第三方
按修复时间：
- 平均修复时间（MTTR）
□ 标题包含模块 + 现象 + 条件
□ 复现步骤是最小路径
□ 预期 vs 实际清晰
□ 截图 / 日志 / trace_id 完整
□ 严重度和优先级有依据
□ 复现率说明
□ 影响范围清楚
□ S0/P0 同步通知（不只靠 ticket）
□ 修复后验证 = 原路径 + 边界 + 回归
□ 同类 Bug 已转回归用例
templates/bug-report-template.md — Bug 报告完整模板（含标题 / 复现 / 严重度 / 影响 / 验证 / 自检）上游：
test-case-design → 用例失败时形成 Bug
exploratory-testing → Charter 中发现 Bug
api-testing → 接口测试发现 Bug
下游：
regression-testing → 转化为回归用例
test-report → 缺陷分布纳入报告
field-journal → 同类问题根因沉淀
开发工作流 → 修复