Install
openclaw skills install defect-prevention-expert缺陷预防专家
缺陷预防方法论专家，覆盖逆向操作、依赖踏空、同屏并发、新旧交替、状态迁移、因果判定六类场景。 适用于需求设计、研发设计、需求评审、设计评审、测试用例评审、代码评审全阶段。 帮助团队在早期识别潜在缺陷，降低修复成本，提升软件质量。 Use when: - 需求设计/评审阶段，需要识别潜在缺陷和风险点 - 研发设计/评审阶段，需要评估架构健壮性 - 测试用例评审阶段，需要系统化设计测试场景 - 代码评审阶段，需要发现代码逻辑缺陷 - Keywords: "缺陷预防", "评审", "风险识别", "测试策略", "质量提升", "逆向操作", "依赖踏空", "并发冲突", "新旧兼容", "状态迁移", "因果图" Output: 根据评审类型输出对应的分析报告（需求风险清单/设计缺陷报告/代码审查意见/测试场景补充建议等） Not for: 具体的代码修复（用 bug-fixing），性能优化（用 performance-optimization），纯代码重构（用 refactoring）
缺陷预防专家 v3.1
核心承诺：在软件交付全生命周期中系统性识别缺陷，根据评审类型动态适配分析流程，将问题消灭在萌芽阶段。
工作流概览（分支路由结构）
Phase 0: 评审类型识别与分支路由
│
├─ 识别评审类型（7 种）
├─ 根据类型路由到对应的工作流（Stage 1-7）
└─ 输出：评审计划
│
├─→ Stage 1: 需求设计阶段工作流
├─→ Stage 2: 研发设计阶段工作流
├─→ Stage 3: 需求评审阶段工作流
├─→ Stage 4: 设计评审阶段工作流
├─→ Stage 5: 编码实现阶段工作流
├─→ Stage 6: 测试用例评审阶段工作流
└─→ Stage 7: 代码评审阶段工作流
│
Phase 8: 知识沉淀（通用）
│
├─ 更新缺陷模式库
├─ 更新检查清单
└─ 输出：知识更新记录
何时使用
触发条件：
- 需求设计阶段：识别需求漏洞和边界场景
- 研发设计阶段：设计健壮的架构和边界处理逻辑
- 需求评审阶段：识别潜在风险点
- 设计评审阶段：审查技术方案和架构设计
- 编码实现阶段：实现并发控制、版本兼容、依赖检查
- 测试用例评审阶段：设计系统化测试场景
- 代码评审阶段：发现代码逻辑缺陷和安全漏洞
关键词触发：
- "评审" + "需求/设计/代码/测试用例"
- "缺陷预防"、"风险识别"
- "逆向操作"、"依赖踏空"、"并发冲突"、"新旧兼容"
- "测试策略"、"质量提升"
不适用场景
| 场景 | 应使用的 Skill |
|---|---|
| 具体 Bug 修复 | bug-fixing |
| 性能瓶颈优化 | performance-optimization |
| 纯代码重构 | refactoring |
| 生成测试用例代码 | test-generator |
| 架构设计从零开始 | system-design |
铁律（执行时 NEVER 违反）
┌──────────────────────────────────────────────────────────────────────────┐
│ Rule 1: 必须先明确评审类型，再路由到对应工作流，不可混用流程 │
│ │
│ Rule 2: 必须覆盖六大方法论（逆向/依赖/并发/兼容/状态/因果），按阶段侧重应用 │
│ │
│ Rule 3: 每个发现必须标注严重程度（P0-P3）和优先级 │
│ │
│ Rule 4: 不能只提问题不给建议，每个风险至少附带一条改进措施 │
│ │
│ Rule 5: 必须区分"设计意图"和"实现风险"，避免混淆 │
│ │
│ Rule 6: 输出必须使用该评审类型对应的报告模板，不可通用化 │
│ │
│ Rule 7: 新发现的缺陷模式必须更新到知识库，不能遗漏 │
│ │
│ Rule 8: 评审后必须跟踪待办事项的完成情况，不能评审完就结束 │
└──────────────────────────────────────────────────────────────────────────┘
Phase 0: 评审类型识别与分支路由
目标：明确评审类型，路由到对应的工作流
0.1 评审类型识别矩阵
| 评审类型 | 输入文档 | 分析重点 | 输出格式 | 路由至 |
|---|---|---|---|---|
| 需求设计 | 无（从零开始） | 需求完整性、边界场景、异常流程 | 需求风险清单 | Stage 1 |
| 研发设计 | 需求文档 | 架构合理性、数据一致性、扩展性 | 设计缺陷报告 | Stage 2 |
| 需求评审 | 需求文档/PRD | 需求漏洞、边界场景、异常流程 | 需求评审报告 | Stage 3 |
| 设计评审 | 设计文档/架构图 | 技术方案、架构设计、可行性 | 设计评审报告 | Stage 4 |
| 编码实现 | 设计文档/接口定义 | 并发控制、版本兼容、依赖检查 | 编码检查清单 | Stage 5 |
| 测试用例评审 | 测试用例文档 | 覆盖度、边界条件、异常场景 | 测试场景补充建议 | Stage 6 |
| 代码评审 | 代码/API 文档 | 逻辑正确性、并发安全、代码质量 | 代码审查意见 | Stage 7 |
0.2 路由决策流程
用户请求
│
├─ 是否从零开始设计需求？ → Stage 1: 需求设计阶段
├─ 是否有需求文档，需要设计技术方案？ → Stage 2: 研发设计阶段
├─ 是否有需求文档，需要评审？ → Stage 3: 需求评审阶段
├─ 是否有设计文档，需要评审？ → Stage 4: 设计评审阶段
├─ 是否有设计文档，需要编码实现指导？ → Stage 5: 编码实现阶段
├─ 是否有测试用例，需要评审？ → Stage 6: 测试用例评审阶段
└─ 是否有代码，需要评审？ → Stage 7: 代码评审阶段
0.3 范围确认清单
- 评审类型已识别（Stage 1-7）
- 输入文档已提供（或明确从零开始）
- 重点关注领域已识别（逆向/依赖/并发/兼容/状态/因果）
- 输出格式已确定（对应该阶段的模板）
0.4 输出：评审计划
## 评审计划
- **评审类型**: [Stage 1-7 之一]
- **输入文档**: [文档列表或"无（从零开始）"]
- **分析重点**: [该阶段的重点关注领域]
- **输出格式**: [对应该阶段的报告模板]
Stage 1: 需求设计阶段工作流
适用场景：从零开始设计需求，需要识别潜在缺陷和边界场景
1.1 输入要求
- 业务背景描述
- 目标用户和核心功能
- 关键业务流程（主流程）
1.2 分析重点
| 方法论 | 应用重点 | 典型问题 |
|---|---|---|
| 逆向操作 | 同一用户在同一界面，一系列连续顺序操作后改变前置操作 | 改变前置操作后，后续联动是否正确处理？（如：添加商品A→添加商品B→选择优惠券→修改商品A数量→总价是否重算？） |
| 依赖踏空 | 业务数据/事务变更或消失（强依赖/弱依赖） | 业务数据删除/变更后，系统如何处理？（如：商品下架/改价、优惠券过期、部门删除） |
| 并发冲突 | 多端/多用户操作场景 | 多端同时操作同一资源，冲突如何解决？ |
| 新旧兼容 | 是否有历史数据或旧系统 | 新版本如何兼容旧数据？升级策略是什么？ |
| 状态迁移 | 系统状态流转是否合法、是否有非法跳转 | 订单能否从“已取消”直接跳到“已发货”？审批流能否跳过“主管审批”？ |
| 因果判定 | 多个条件组合导致的不同结果是否覆盖完全 | “满100元且新用户且非特价商品”才可用优惠券，各种组合是否都测试到了？ |
1.3 分析流程
- 梳理业务流程：主流程 → 分支流程 → 异常流程
- 识别关键数据依赖：数据实体、关联关系、级联规则
- 应用六大方法论：逐项分析逆向/依赖/并发/兼容/状态/因果场景
- 生成风险清单：按 P0-P3 分级，附改进建议
1.4 检查清单
### 逆向操作场景
- [ ] 用户操作路径是否覆盖正向和逆向流程？
- [ ] 修改前置操作后，后续操作是否正确处理？
- [ ] 级联依赖关系是否完整定义？（如省市区联动）
- [ ] 状态回退场景是否有明确的处理规则？
### 依赖踏空场景
- [ ] 是否识别了所有强依赖关系？
- [ ] 依赖数据删除/变更后的处理策略是否明确？
- [ ] 历史数据的保护机制是否定义？
- [ ] 降级方案是否可行且用户体验可接受？
### 并发操作场景
- [ ] 是否涉及多端操作？冲突解决机制是否定义？
- [ ] 是否涉及多用户协作？数据一致性方案是否明确？
- [ ] 实时同步的频率和延迟要求是否合理？
### 新旧兼容场景
- [ ] 是否有历史数据或旧系统共存？
- [ ] 版本升级策略是否明确（停服 vs 不停服）？
- [ ] 数据迁移方案是否评估？
- [ ] 回滚方案是否可行？
### 状态迁移场景
- [ ] 是否定义了完整的状态流转图？
- [ ] 是否存在非法状态跳转的可能？
- [ ] 状态回退是否有明确规则？
- [ ] 终态（如已完成/已取消）是否允许变更？
### 因果判定场景
- [ ] 是否识别了所有影响结果的条件？
- [ ] 多个条件组合的情况是否覆盖完全？
- [ ] 是否有判定表或决策树梳理业务规则？
- [ ] 条件优先级和冲突处理是否明确？
1.5 输出模板：需求风险清单
## 需求风险清单 — [项目名称]
### 业务场景概述
- **核心功能**: [一句话描述]
- **目标用户**: [用户群体]
- **关键流程**: [主流程描述]
### 风险清单（按严重程度排序）
| 编号 | 风险类型 | 严重程度 | 描述 | 影响范围 | 建议措施 |
|------|---------|---------|------|---------|---------|
| R001 | 依赖踏空 | P1 | ... | ... | ... |
### 建议补充的需求点
1. [补充点1]
2. [补充点2]
### 待确认事项
- [ ] [事项1] — [负责人]
- [ ] [事项2] — [负责人]
Stage 2: 研发设计阶段工作流
适用场景：已有需求文档，需要设计技术方案，评估架构健壮性
2.1 输入要求
- 需求文档/PRD
- 业务流程描述
- 性能/安全/扩展性要求（如有）
2.2 分析重点
| 方法论 | 应用重点 | 典型问题 |
|---|---|---|
| 逆向操作 | 状态机设计、事务回滚，前置操作改变后后续逻辑是否正确 | 改变前置操作后，数据一致性如何保证？（如：订单创建→库存扣减→支付发起→修改订单商品→库存和支付是否重新计算？） |
| 依赖踏空 | 业务数据/事务依赖，依赖变更或消失 | 业务数据删除/变更后，系统如何处理？（如：商品下架/改价、优惠券过期、部门删除） |
| 并发冲突 | 分布式锁、乐观锁、最终一致性 | 多实例并发写入，如何避免冲突？ |
| 新旧兼容 | 数据迁移、API 版本管理 | 新旧数据共存的适配层如何设计？ |
| 状态迁移 | 状态机设计、状态校验、非法跳转防护 | 状态流转是否用状态机控制？是否存在绕过状态校验的接口？ |
| 因果判定 | 复杂业务规则的条件组合覆盖 | 折扣计算规则涉及多个条件，是否用判定表梳理了所有组合？ |
2.3 分析流程
- 梳理技术架构：分层架构、服务拆分、数据流向
- 识别技术风险点：并发控制、事务边界、依赖管理
- 应用六大方法论：从技术角度分析逆向/依赖/并发/兼容/状态/因果
- 生成设计缺陷报告：附改进建议和架构优化方案
2.4 检查清单
### 架构设计
- [ ] 是否采用合理的分层架构？
- [ ] 服务拆分边界是否清晰？
- [ ] 数据流向和调用链路是否完整？
- [ ] 是否考虑了水平扩展能力？
### 数据一致性
- [ ] 并发控制的实现方案？（乐观锁、悲观锁、分布式锁）
- [ ] 事务边界是否合理？
- [ ] 分布式事务的处理方案？
- [ ] 最终一致性的补偿机制？
### 依赖管理
- [ ] 依赖关系的校验机制？
- [ ] 循环依赖是否避免？
- [ ] 依赖变更的兼容性处理？
- [ ] 依赖消失的降级策略？
### 版本兼容
- [ ] 数据结构变更的兼容方案？
- [ ] API版本管理策略？
- [ ] 新旧数据共存的适配层设计？
- [ ] 废弃字段/接口的清理计划？
### 状态管理
- [ ] 状态流转是否用状态机控制？
- [ ] 状态校验逻辑是否集中管理？
- [ ] 是否存在绕过状态校验的接口？
- [ ] 状态变更是否记录审计日志？
### 业务规则
- [ ] 复杂规则是否用判定表梳理？
- [ ] 条件组合是否覆盖完全？
- [ ] 规则冲突时的优先级是否明确？
- [ ] 规则变更是否影响现有数据？
### 性能设计
- [ ] 数据库索引设计是否合理？
- [ ] 缓存策略是否定义？（缓存什么、何时失效）
- [ ] 大数据量的分页方案？
- [ ] 慢查询的预防机制？
### 安全设计
- [ ] 权限控制粒度是否足够？
- [ ] 敏感数据是否加密存储？
- [ ] SQL注入、XSS等常见漏洞的防护？
- [ ] 接口防重放、防刷机制？
2.5 输出模板：设计缺陷报告
## 设计缺陷报告 — [项目名称]
### 技术架构概述
- **架构模式**: [分层架构/微服务/事件驱动等]
- **技术栈**: [主要技术选型]
- **数据流向**: [关键数据流转描述]
### 设计缺陷清单（按严重程度排序）
| 编号 | 缺陷类型 | 严重程度 | 描述 | 影响范围 | 改进建议 |
|------|---------|---------|------|---------|---------|
| D001 | 并发安全 | P1 | ... | ... | ... |
### 架构优化建议
1. [建议1]
2. [建议2]
### 待决策事项
- [ ] [事项1] — [负责人]
- [ ] [事项2] — [负责人]
Stage 3: 需求评审阶段工作流
适用场景：已有需求文档，需要评审需求完整性和潜在风险
3.1 输入要求
- 需求文档/PRD
- 用户故事或用例
- 业务流程图（如有）
3.2 分析重点
| 方法论 | 应用重点 | 典型问题 |
|---|---|---|
| 逆向操作 | 需求中的操作路径是否完整，同一用户连续顺序操作后改变前置操作 | 改变前置操作后，需求是否覆盖？（如：选择省→选择市→选择区→修改市→区是否清空并重新加载？） |
| 依赖踏空 | 需求中的依赖关系是否明确，依赖数据/服务变更 | 依赖数据变更后的处理是否定义？（如：商品下架、优惠券过期、部门删除后人员归属） |
| 并发冲突 | 需求是否考虑多端/多用户场景 | 并发操作的冲突解决是否定义？ |
| 新旧兼容 | 需求是否考虑历史数据 | 新旧系统共存的策略是否明确？ |
| 状态迁移 | 需求是否定义完整状态流转 | 订单状态流转是否定义完整？是否有非法跳转的可能？ |
| 因果判定 | 需求中的业务规则是否用判定表梳理 | 满减、折扣、优惠券叠加规则，各种条件组合是否都定义清楚了？ |
3.3 分析流程
- 阅读需求文档：理解业务目标和核心功能
- 识别需求漏洞：边界场景、异常流程、缺失定义
- 应用六大方法论：从需求角度分析逆向/依赖/并发/兼容/状态/因果
- 生成需求评审报告：附改进建议和待确认事项
3.4 检查清单
### 需求完整性
- [ ] 边界条件是否明确？（空值、最大值、最小值）
- [ ] 异常场景是否定义？（网络异常、数据异常）
- [ ] 性能要求是否量化？（响应时间、并发量）
- [ ] 安全要求是否考虑？（权限、敏感数据）
### 逆向操作场景
- [ ] 是否考虑了用户修改前置操作后的系统行为？
- [ ] 级联依赖关系是否完整定义？
- [ ] 状态回退场景是否有明确的处理规则？
### 依赖踏空场景
- [ ] 是否识别了所有强依赖关系？
- [ ] 依赖数据删除/变更后的处理策略是否明确？
- [ ] 降级方案是否可行且用户体验可接受？
### 并发操作场景
- [ ] 多端操作同一资源的冲突解决机制是否定义？
- [ ] 多用户并发修改的数据一致性方案是否明确？
### 新旧交替场景
- [ ] 版本升级策略是否明确？
- [ ] 历史数据的兼容性访问方案是否定义？
### 状态迁移场景
- [ ] 是否定义了完整的状态流转图？
- [ ] 是否存在非法状态跳转的可能？
- [ ] 状态回退/撤销是否有明确规则？
### 因果判定场景
- [ ] 复杂业务规则是否梳理了所有条件组合？
- [ ] 规则冲突时的优先级是否明确？
- [ ] 是否遗漏了某些条件组合？
3.5 输出模板：需求评审报告
## 需求评审报告 — [项目名称]
### 评审信息
- **评审日期**: YYYY-MM-DD
- **评审人员**: [参与人员]
- **需求文档**: [文档名称/链接]
### 发现的需求漏洞（按严重程度排序）
| 编号 | 漏洞类型 | 严重程度 | 描述 | 建议措施 |
|------|---------|---------|------|---------|
| G001 | 边界场景缺失 | P1 | ... | ... |
### 建议补充的需求点
1. [补充点1]
2. [补充点2]
### 待确认事项
- [ ] [事项1] — [负责人]
- [ ] [事项2] — [负责人]
### 评审结论
- [ ] 通过
- [ ] 有条件通过（需补充后二次评审）
- [ ] 不通过
Stage 4: 设计评审阶段工作流
适用场景：已有设计文档，需要评审技术方案和架构设计
4.1 输入要求
- 设计文档
- 架构图
- 接口定义
- 数据库设计（如有）
4.2 分析重点
| 方法论 | 应用重点 | 典型问题 |
|---|---|---|
| 逆向操作 | 状态机、事务回滚设计，前置操作改变后后续逻辑是否正确 | 改变前置操作后，数据一致性如何保证？（如：订单创建→库存扣减→修改订单→库存是否重新调整？） |
| 依赖踏空 | 业务数据/事务依赖，依赖变更或消失 | 业务数据删除/变更后，系统如何处理？（如：商品下架、优惠券过期、部门删除） |
| 并发冲突 | 分布式锁、乐观锁、缓存一致性 | 多实例并发写入，如何避免冲突？ |
| 新旧兼容 | 数据迁移、API 版本管理 | 新旧数据共存的适配层如何设计？ |
| 状态迁移 | 状态机设计、状态流转合法性校验 | 是否用状态机模式控制流转？是否存在越权状态变更的接口？ |
| 因果判定 | 复杂业务规则的条件组合设计 | 计费/折扣规则涉及多条件，是否用判定表确保覆盖完整？ |
4.3 分析流程
- 阅读设计文档：理解技术架构和关键设计决策
- 识别设计缺陷：架构不合理、数据一致性风险、扩展性不足
- 应用六大方法论：从设计角度分析逆向/依赖/并发/兼容/状态/因果
- 生成设计评审报告：附改进建议和架构优化方案
4.4 检查清单
### 架构设计
- [ ] 是否采用合理的分层架构？
- [ ] 服务拆分边界是否清晰？
- [ ] 数据流向和调用链路是否完整？
### 数据一致性
- [ ] 并发控制的实现方案？
- [ ] 事务边界是否合理？
- [ ] 最终一致性的补偿机制？
### 依赖管理
- [ ] 依赖关系的校验机制？
- [ ] 依赖消失的降级策略？
### 版本兼容
- [ ] 数据结构变更的兼容方案？
- [ ] API版本管理策略？
### 状态管理
- [ ] 状态机设计是否合理？
- [ ] 状态校验逻辑是否集中？
- [ ] 非法状态跳转是否有防护？
### 业务规则
- [ ] 复杂规则是否用判定表梳理？
- [ ] 条件组合覆盖是否完整？
- [ ] 规则冲突时的优先级是否定义？
### 性能设计
- [ ] 数据库索引设计是否合理？
- [ ] 缓存策略是否定义？
### 安全设计
- [ ] 权限控制粒度是否足够？
- [ ] 敏感数据是否加密存储？
4.5 输出模板：设计评审报告
## 设计评审报告 — [项目名称]
### 评审信息
- **评审日期**: YYYY-MM-DD
- **评审人员**: [参与人员]
- **设计文档**: [文档名称/链接]
### 发现的设计缺陷（按严重程度排序）
| 编号 | 缺陷类型 | 严重程度 | 描述 | 影响范围 | 改进建议 |
|------|---------|---------|------|---------|---------|
| D001 | 架构设计 | P1 | ... | ... | ... |
### 架构优化建议
1. [建议1]
2. [建议2]
### 待决策事项
- [ ] [事项1] — [负责人]
- [ ] [事项2] — [负责人]
### 评审结论
- [ ] 通过
- [ ] 有条件通过（需修改后二次评审）
- [ ] 不通过
Stage 5: 编码实现阶段工作流
适用场景：已有设计文档，需要编码实现，检查并发控制、版本兼容、依赖处理
5.1 输入要求
- 设计文档
- 接口定义
- 数据库设计
- 技术栈要求
5.2 分析重点
| 方法论 | 应用重点 | 典型问题 |
|---|---|---|
| 逆向操作 | 状态机实现、事务回滚，前置操作改变后后续逻辑是否正确 | 改变前置操作后，后续逻辑是否正确处理？（如：选择商品→选择规格→选择配送→修改规格→配送方式是否重新校验？） |
| 依赖踏空 | 业务数据/事务依赖，依赖数据不存在时 | 业务数据不存在时，是否有容错处理？（如：商品下架、优惠券过期） |
| 并发冲突 | 乐观锁、分布式锁、缓存更新 | 共享资源访问是否线程安全？ |
| 新旧兼容 | 字段兼容、API 版本 | 新旧数据共存时，适配层是否实现？ |
| 状态迁移 | 状态机实现、状态校验代码 | 状态变更是否有统一的状态机控制？是否存在绕过校验的直接 UPDATE？ |
| 因果判定 | 复杂条件判断的代码实现 | 多重 if-else 嵌套是否可简化？是否遗漏了某些条件分支？ |
5.3 分析流程
- 理解设计意图：明确架构设计和关键决策
- 识别编码风险点：并发安全、依赖处理、版本兼容
- 应用六大方法论：从编码角度分析逆向/依赖/并发/兼容/状态/因果
- 生成编码检查清单：附实现建议和注意事项
5.4 检查清单
### 逆向操作处理
- [ ] 前置操作改变后，后续操作是否正确处理？
- [ ] 级联依赖关系的联动更新是否正确？
- [ ] 状态回退后的数据一致性是否保证？
### 依赖踏空处理
- [ ] 依赖数据不存在时是否有异常处理？
- [ ] 依赖关系变更时是否有校验逻辑？
- [ ] 是否有适当的用户提示？
### 并发安全
- [ ] 共享资源的访问是否线程安全？
- [ ] 数据库操作是否有并发控制？
- [ ] 缓存更新是否有竞争条件？
### 新旧兼容
- [ ] 数据结构变更的兼容处理是否实现？
- [ ] API版本管理是否实现？
- [ ] 新旧数据共存的适配层是否实现？
### 状态迁移处理
- [ ] 状态变更是否集中管理？
- [ ] 非法状态跳转是否有拦截？
- [ ] 状态回退逻辑是否正确实现？
### 因果判定处理
- [ ] 复杂条件判断是否有遗漏的分支？
- [ ] if-else 嵌套是否过深？
- [ ] 是否可使用策略模式或表驱动简化？
### 代码质量
- [ ] 函数长度是否合理？（建议<50行）
- [ ] 圈复杂度是否过高？（建议<10）
- [ ] 是否有重复代码？
- [ ] 命名是否清晰易懂？
### 性能优化
- [ ] 是否有N+1查询问题？
- [ ] 循环中是否有数据库查询？
- [ ] 是否有内存泄漏风险？
### 安全风险
- [ ] 是否有SQL注入风险？
- [ ] 是否有XSS漏洞？
- [ ] 权限校验是否完整？
5.5 输出模板：编码检查清单
## 编码检查清单 — [项目名称/模块]
### 实现要点
- **核心功能**: [一句话描述]
- **技术栈**: [主要技术选型]
- **关键接口**: [接口列表]
### 检查项执行结果
| 检查项 | 状态 | 备注 |
|--------|------|------|
| 逆向操作处理 | [通过/需改进] | ... |
| 依赖踏空处理 | [通过/需改进] | ... |
| 并发安全 | [通过/需改进] | ... |
| 新旧兼容 | [通过/需改进] | ... |
### 实现建议
1. [建议1]
2. [建议2]
### 注意事项
- [注意1]
- [注意2]
Stage 6: 测试用例评审阶段工作流
适用场景：已有测试用例文档，需要评审测试覆盖度和系统化场景设计
6.1 输入要求
- 测试用例文档
- 测试计划
- 需求文档/设计文档（参考）
6.2 分析重点
| 方法论 | 应用重点 | 典型问题 |
|---|---|---|
| 逆向操作 | 测试用例是否覆盖同一用户连续顺序操作后改变前置操作的场景 | 是否有改变前置操作的测试用例？（如：添加商品A→添加商品B→选择优惠券→修改商品A数量→验证总价和优惠券重算） |
| 依赖踏空 | 业务数据/事务消失场景的测试用例 | 是否有业务数据删除的测试用例？（如：商品下架、优惠券过期、部门删除） |
| 并发冲突 | 测试用例是否覆盖并发场景 | 是否有多端/多用户并发的测试用例？ |
| 新旧兼容 | 测试用例是否覆盖兼容性场景 | 是否有新旧数据共存的测试用例？ |
| 状态迁移 | 状态流转路径的测试覆盖 | 是否测试了所有合法状态跳转？是否测试了非法跳转的拦截？ |
| 因果判定 | 条件组合场景的测试覆盖 | 多条件组合的业务规则，测试用例是否覆盖了所有有效和无效组合？ |
6.3 分析流程
- 阅读测试用例：理解测试覆盖范围
- 识别覆盖盲区：边界条件、异常场景、并发场景
- 应用六大方法论：从测试角度分析逆向/依赖/并发/兼容/状态/因果
- 生成测试场景补充建议：附新增测试用例建议
6.4 检查清单
### 测试覆盖度
- [ ] 是否覆盖所有核心功能路径？
- [ ] 边界条件测试是否完整？
- [ ] 异常场景测试是否充分？
### 缺陷预防场景
- [ ] 逆向操作场景测试用例？
- [ ] 依赖踏空场景测试用例？
- [ ] 同屏并发场景测试用例？
- [ ] 新旧数据兼容测试用例？
- [ ] 状态流转路径测试用例？
- [ ] 条件组合场景测试用例？
### 测试数据
- [ ] 测试数据是否覆盖各种边界值？
- [ ] 是否有足够的异常数据？
- [ ] 是否考虑了数据量对性能的影响？
### 测试环境
- [ ] 测试环境是否与生产环境一致？
- [ ] 多端测试设备是否准备齐全？
- [ ] 并发测试的压力工具是否准备？
### 验收标准
- [ ] 通过标准是否明确？
- [ ] 性能指标是否量化？
- [ ] 缺陷严重程度的分级标准？
6.5 输出模板：测试场景补充建议
## 测试场景补充建议 — [项目名称]
### 评审信息
- **评审日期**: YYYY-MM-DD
- **评审人员**: [参与人员]
- **测试用例文档**: [文档名称/链接]
### 发现的覆盖盲区（按严重程度排序）
| 编号 | 盲区类型 | 严重程度 | 描述 | 建议补充的测试场景 |
|------|---------|---------|------|------------------|
| T001 | 并发场景缺失 | P1 | ... | ... |
### 建议补充的测试用例
1. [用例1]
2. [用例2]
### 测试数据建议
- [建议1]
- [建议2]
### 评审结论
- [ ] 通过
- [ ] 有条件通过（需补充后二次评审）
- [ ] 不通过
Stage 7: 代码评审阶段工作流
适用场景：已有代码，需要评审逻辑正确性、并发安全、代码质量
7.1 输入要求
- 代码文件
- API 文档
- 设计文档（参考）
7.2 分析重点
| 方法论 | 应用重点 | 典型问题 |
|---|---|---|
| 逆向操作 | 前置操作改变后，同一用户后续逻辑是否正确 | 级联依赖的联动更新是否正确？（如：填写订单→选择地址→选择发票→修改地址→发票信息是否重新计算？） |
| 依赖踏空 | 业务数据/事务不存在时，是否有容错 | 业务数据/事务变更时是否有校验？（如：商品下架、优惠券过期） |
| 并发冲突 | 共享资源访问是否线程安全 | 数据库操作是否有并发控制？ |
| 新旧兼容 | 新旧数据共存时，适配层是否实现 | 字段兼容、API 版本是否处理？ |
| 状态迁移 | 状态机实现、状态校验逻辑 | 状态变更是否集中管理？非法跳转是否拦截？ |
| 因果判定 | 复杂条件判断、多重分支覆盖 | if-else 嵌套是否遗漏分支？条件组合是否覆盖完全？ |
7.3 分析流程
- 阅读代码：理解业务逻辑和实现方式
- 识别代码缺陷：逻辑错误、并发风险、安全漏洞
- 应用六大方法论：从代码角度分析逆向/依赖/并发/兼容/状态/因果
- 生成代码审查意见：附改进建议和代码优化方案
7.4 检查清单
### 功能正确性
- [ ] 业务逻辑是否正确实现？
- [ ] 边界条件是否正确处理？
- [ ] 异常场景是否有容错处理？
### 逆向操作处理
- [ ] 前置操作改变后，后续操作是否正确处理？
- [ ] 级联依赖关系的联动更新是否正确？
- [ ] 状态回退后的数据一致性是否保证？
### 依赖踏空处理
- [ ] 依赖数据不存在时是否有异常处理？
- [ ] 依赖关系变更时是否有校验逻辑？
- [ ] 是否有适当的用户提示？
### 状态迁移处理
- [ ] 状态变更是否有统一的状态机控制？
- [ ] 非法状态跳转是否有拦截逻辑？
- [ ] 状态回退逻辑是否正确实现？
### 因果判定处理
- [ ] 多重条件判断是否有遗漏的分支？
- [ ] if-else 嵌套是否过深？是否可用策略模式简化？
- [ ] 条件组合的覆盖是否完整？
### 并发安全
- [ ] 共享资源的访问是否线程安全？
- [ ] 数据库操作是否有并发控制？
- [ ] 缓存更新是否有竞争条件？
### 代码质量
- [ ] 函数长度是否合理？（建议<50行）
- [ ] 圈复杂度是否过高？（建议<10）
- [ ] 是否有重复代码？
- [ ] 命名是否清晰易懂？
### 性能优化
- [ ] 是否有N+1查询问题？
- [ ] 循环中是否有数据库查询？
- [ ] 是否有内存泄漏风险？
### 安全风险
- [ ] 是否有SQL注入风险？
- [ ] 是否有XSS漏洞？
- [ ] 敏感信息是否泄露？
- [ ] 权限校验是否完整？
7.5 输出模板：代码审查意见
## 代码审查意见 — [项目名称/模块]
### 评审信息
- **评审日期**: YYYY-MM-DD
- **评审人员**: [参与人员]
- **代码文件**: [文件列表]
### 发现的代码缺陷（按严重程度排序）
| 编号 | 缺陷类型 | 严重程度 | 文件:行号 | 描述 | 改进建议 |
|------|---------|---------|-----------|------|---------|
| C001 | 并发安全 | P1 | file.py:123 | ... | ... |
### 代码优化建议
1. [建议1]
2. [建议2]
### 代码质量评估
- **可读性**: [高/中/低]
- **可维护性**: [高/中/低]
- **性能**: [高/中/低]
- **安全性**: [高/中/低]
### 评审结论
- [ ] 通过
- [ ] 有条件通过（需修改后二次评审）
- [ ] 不通过
Phase 8: 知识沉淀（通用）
目标：将评审中发现的新模式更新到知识库，持续积累
8.1 更新检查清单
- 将新发现的缺陷场景补充到
checklists/review-checklist.md - 定期评审和更新检查清单的完备性
8.2 更新示例场景
- 将典型案例补充到
examples.md - 记录具体的测试步骤和验证方法
8.3 更新知识库文件
| 文件 | 更新时机 | 内容 |
|---|---|---|
checklists/review-checklist.md | 发现新的检查项 | 补充新的检查点 |
examples.md | 发现新的典型场景 | 补充新的示例 |
templates/test-case-template.md | 发现新的测试方法 | 补充新的测试策略 |
8.4 输出：知识更新记录
## 知识更新记录
- **更新日期**: YYYY-MM-DD
- **评审项目**: [项目名称]
- **评审类型**: [Stage 1-7]
- **新增检查项**: [描述]
- **新增示例**: [描述]
- **更新文件**: [文件路径]
Anti-Patterns（禁止行为）
| 禁止行为 | 正确做法 |
|---|---|
| 混用不同阶段的流程和模板 | 根据评审类型路由到对应工作流 |
| 泛泛而谈"代码质量不好" | 指出具体文件/函数/行号和具体问题 |
| 只提问题不给建议 | 每个问题至少附带一条改进建议 |
| 跳过检查清单 | 按清单逐项检查，记录结果 |
| 评审后不跟进 | 明确待办事项、责任人、截止时间 |
| 用完整流程处理明显的小问题 | 快速记录，简化流程 |
| 忽略历史遗留问题 | 评估影响范围，制定渐进式改进计划 |
| 跳过知识沉淀 | 每次评审后更新知识库 |
| 混淆设计意图和实现风险 | 先确认设计意图，再评估实现风险 |
Skill 协作
| 触发条件 | 转交至 |
|---|---|
| 发现具体 Bug 需要修复 | bug-fixing |
| 需要生成测试用例代码 | test-generator |
| 需要架构设计评审 | system-design |
| 需要代码重构 | refactoring |
| 需要绘制流程图/架构图 | diagram-generator |
参考文件
| 文件 | 用途 |
|---|---|
| checklists/review-checklist.md | 评审检查清单（需求/设计/测试/代码） |
| examples.md | 典型场景示例 |
| templates/test-case-template.md | 测试用例模板 |
| templates/concept-clarification.md | 六大方法论概念澄清与区分 |
技能进化
更新此 Skill 的时机：
- 评审过程中发现检查清单覆盖不足
- 出现新的典型缺陷场景
- 团队反馈评审流程可以优化
更新原则：
- 优先更新具体章节，而非添加新规则
- 保持工作流的简洁性，避免过度官僚化
- 更新后验证与其他 Skill 的协作关系是否仍然清晰