القائمة
修改/重构/Bug 修复后避免老问题复发时使用。适用于版本回归、修复后回归、重构验证。融合 Impact Analysis、Test Suite Pruning、Smoke/Sanity/Full 三层套件。
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/zhaoxuya520/AI-Fullstack-Delivery-Workflow --skill regression-testingيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
设计 API 认证鉴权和权限矩阵时使用。适用于多角色系统、租户隔离、字段级权限。优先使用 OAuth 2.0 / JWT + RBAC + 资源归属检查。
设计具体 API 端点时使用。适用于资源建模后的下一步、列端点清单、HTTP 方法和状态码选择。优先使用 RFC 7231 HTTP 语义 + GitHub REST 命名规范。
设计 API 错误码和错误结构时使用。适用于错误响应规范、调用方错误处理、调试可观测。优先使用 RFC 7807 Problem Details + 业务错误码 + 调用方处理建议。
استنادا إلى تصنيف SOC المهني
عرض SKILL.md
| name | regression-testing |
| description | 修改/重构/Bug 修复后避免老问题复发时使用。适用于版本回归、修复后回归、重构验证。融合 Impact Analysis、Test Suite Pruning、Smoke/Sanity/Full 三层套件。 |
参考来源：ISTQB Foundation、Google《Software Engineering at Google》Test Selection、Microsoft Test Impact Analysis。
1. 不重复发生的 Bug 才是好回归
每个修复的 Bug 必须有回归用例
2. 回归不是全跑
要做影响分析，按变更范围选择套件
3. 三层套件结构
Smoke / Sanity / Full（详见下文）
4. 套件要剪枝
失败率 < 5% 才稳定
半年没失败的可能要删（或归档）
5. 自动化是回归的归宿
手工回归不可持续
┌─────────────────────────────────────┐
│ Smoke（5 分钟） │
│ - CI 每次必跑 │
│ - 核心路径"能用"验证 │
│ - 失败 = 阻塞合并 │
└─────────────────────────────────────┘
┌─────────────────────────────────────┐
│ Sanity（30 分钟） │
│ - 发布前 / 每日定时跑 │
│ - 主要功能正确性验证 │
│ - 失败 = 阻塞发布 │
└─────────────────────────────────────┘
┌─────────────────────────────────────┐
│ Full（1~3 小时） │
│ - 重大版本 / 重构后跑 │
│ - 全量回归 │
│ - 失败 = 评估影响后决策 │
└─────────────────────────────────────┘
1. 变更内容是什么？
- 新增功能
- 修改逻辑
- 修复 Bug
- 重构（行为应不变）
- 依赖升级
2. 变更影响哪些代码？
- 直接修改的模块
- 调用方（谁用了它）
- 被调用方（它用了谁）
- 共享代码（utils、middleware）
3. 变更影响哪些功能？
- 直接相关的用户流程
- 间接相关（共享数据 / 状态 / 配置）
4. 选择回归套件
- Smoke：必跑
- Sanity：相关模块
- Full：跨模块大改 / 重构
| 变更类型 | 推荐回归 |
|---|---|
| Bug 修复（单点） | Smoke + 该 Bug 历史用例 |
| 功能修改（单模块） | Smoke + Sanity（该模块） |
| 跨模块功能 | Smoke + Sanity（涉及模块） |
| 共享代码变更（utils） | Smoke + Sanity（所有模块） |
| 重构（行为不变） | Full |
| 数据库迁移 | Full + 数据完整性专项 |
| 依赖升级（major） | Full |
| 配置变更 | 受影响场景 + Smoke |
Bug 修复后必做：
1. 写一条复现用例（最小复现路径）
2. 写一条边界用例（防类似变体）
3. 加入 Sanity 套件
4. 标注：源自 Bug-XXX
5. 6 个月内不删除
示例：
Bug-789：退款金额可输入负数
→ 回归用例 1：输入 -100，预期返回 INVALID_AMOUNT，金额无变化
→ 回归用例 2：输入 0，预期返回 INVALID_AMOUNT
→ 回归用例 3：输入超过订单金额的正数，预期返回 EXCEED_LIMIT
→ 回归用例 4：边界：等于订单金额（应该成功）
| 时机 | 动作 |
|---|---|
| 失败率 > 5% | 修复或隔离 Flaky 用例 |
| 6 个月未失败 | 审视，可能要删 |
| 模块下线 | 删除相关用例 |
| 业务变更 | 同步更新 |
| 用例执行 > 5 分钟 | 拆分或优化 |
1. 收集变更说明
- 修改了什么 / 为什么 / 影响范围
↓
2. 影响分析
- 用变更范围决定回归层级
↓
3. 选择套件
- Smoke / Sanity / Full
↓
4. 添加新用例（如有 Bug 修复）
- 历史 Bug 转回归用例
↓
5. 执行（优先自动化）
- 失败 → bug-reporting
↓
6. 失败分析
- 真 Bug：开发修
- Flaky：隔离 / 修复
- 测试代码问题：修测试
↓
7. 报告
- 通过率 / 失败用例 / 是否阻塞
↓
8. 套件维护
- 加新用例 / 删旧用例 / 修 Flaky
高优先（必自动化）：
- Smoke 套件 100%
- Sanity 套件 80%+
- 历史 Bug 回归用例
中优先（可自动化）：
- Full 套件中稳定部分
- API 契约测试
低优先（保留手工）：
- UI 视觉回归
- 兼容性（多浏览器 / 设备）
- 探索式
症状：用例时通过时失败，无规律
排查顺序：
1. 时序：异步等待不够
2. 数据：上一个用例污染
3. 状态：缓存 / 会话残留
4. 环境：网络 / 第三方抖动
5. 并发：多线程 / 多用户冲突
6. 时间：依赖具体日期 / 时区
处理：
- 立即隔离（标 @flaky 跳过 CI）
- 1 周内修复或删除
- 不要"多重试几次让它过"
□ 三层套件清晰（Smoke/Sanity/Full）
□ Smoke < 5 min，Sanity < 30 min
□ 历史 Bug 100% 转回归用例
□ 失败率 < 5%
□ Flaky 用例已隔离或修复
□ 影响分析驱动套件选择
□ 重构后跑 Full
□ 6 个月未失败的用例已审视
□ 自动化优先级合理
templates/regression-suite-template.md — 三层套件 + 影响分析 + 历史 Bug 跟踪 + 套件健康自检上游：
test-case-design → 提供用例
bug-reporting → 历史 Bug
risk-based-testing → 高风险点入回归
下游：
自动化测试工作流 → 实现自动化套件
quality-gate → 回归通过率作为门禁
test-report → 回归结果纳入报告