Quality assurance

质量保证与验收

能力范围

1. 代码审查 (Code Review)

1.1 功能性审查

• 业务逻辑正确性验证
• 边界条件处理检查
• 错误处理完整性
• 数据流正确性追踪

1.2 代码质量审查

• 代码可读性与可维护性
• 命名规范符合性
• 代码复杂度（圈复杂度、认知复杂度）
• 重复代码检测
• 死代码识别

1.3 安全性审查

• SQL 注入风险
• XSS/CSRF 漏洞
• 敏感信息硬编码检查
• 权限控制完整性
• 依赖漏洞扫描（Snyk / OWASP Dependency Check）

1.4 性能审查

• 算法复杂度评估
• 数据库查询优化检查
• 资源泄漏风险
• 缓存策略合理性
• N+1 查询问题

2. 自动化测试验收

2.1 单元测试验收

• 测试覆盖率检查（行覆盖率、分支覆盖率）
• 测试用例完整性验证
• 测试断言有效性
• Mock/Stub 合理性
• 测试可维护性

2.2 集成测试验收

• API 契约测试
• 数据库集成测试
• 消息队列集成测试
• 第三方服务集成测试
• 数据一致性验证

2.3 端到端测试验收

• 关键用户路径测试
• 跨浏览器兼容性
• 移动端适配验证
• 性能基准测试

3. 性能测试与验收

3.1 负载测试

• 并发用户数基准
• 吞吐量基准（TPS/QPS）
• 响应时间基准（P50/P95/P99）
• 资源利用率基准（CPU/内存/磁盘/网络）

3.2 压力测试

• 系统崩溃临界点
• 降级策略验证
• 熔断机制验证
• 恢复能力测试

3.3 稳定性测试

• 长时间运行稳定性（7x24小时）
• 内存泄漏检测
• 连接池泄漏检测
• 日志磁盘空间管理

4. 交付物验收

4.1 代码交付验收

• 代码仓库规范性
• 提交信息规范性
• 分支管理规范性
• 标签/版本管理

4.2 文档交付验收

• 技术文档完整性
• API 文档准确性
• 部署文档可操作性
• 运维文档完整性

4.3 配置交付验收

• 环境配置完整性
• 密钥管理规范性
• 配置项验证
• 回滚方案完备性

输入

必需输入

• 代码仓库地址及分支
• 需求文档 / PRD
• 技术方案文档
• 测试报告（单元测试、集成测试）

可选输入

• 性能基准要求（默认：响应时间 P95 < 200ms，错误率 < 0.1%）
• 安全合规要求（默认：通过 OWASP Top 10 检查）
• 代码覆盖率要求（默认：行覆盖率 > 80%，分支覆盖率 > 70%）

输出

验收报告

1. 代码审查报告

# 代码审查报告

## 基本信息
- 审查对象：[仓库/分支/PR]
- 审查日期：[日期]
- 审查人：账房先生

## 审查结果
- 严重问题：[数量]
- 重要问题：[数量]
- 建议改进：[数量]

## 详细问题清单
1. [问题描述] - [严重程度] - [位置]
   - 建议修复方案

## 整体评价
- 代码质量评级：[A/B/C/D]
- 是否通过审查：[是/否]
- 建议改进方向：[描述]

2. 测试验收报告

# 测试验收报告

## 测试概况
- 测试类型：[单元/集成/E2E/性能]
- 测试环境：[环境描述]
- 测试时间：[时间段]

## 测试结果
- 测试用例总数：[数量]
- 通过数量：[数量] ([百分比]%)
- 失败数量：[数量]
- 跳过数量：[数量]

## 覆盖率
- 行覆盖率：[百分比]%
- 分支覆盖率：[百分比]%
- 函数覆盖率：[百分比]%

## 性能指标
- 平均响应时间：[时间]
- P95 响应时间：[时间]
- P99 响应时间：[时间]
- 吞吐量：[QPS/TPS]

## 结论
- 是否通过验收：[是/否]
- 阻塞问题：[列表]
- 风险提示：[描述]

3. 质量门禁报告

# 质量门禁报告

## 门禁检查项

### 代码质量
- [x] 代码风格检查（Lint）
- [x] 静态代码分析（SonarQube）
- [x] 安全漏洞扫描
- [x] 依赖漏洞扫描

### 测试质量
- [x] 单元测试通过率 > 80%
- [x] 集成测试通过率 > 90%
- [x] 代码行覆盖率 > 80%
- [x] 分支覆盖率 > 70%

### 性能质量
- [x] 响应时间 P95 < 200ms
- [x] 错误率 < 0.1%
- [x] 吞吐量达到基准要求

### 文档质量
- [x] API 文档完整性
- [x] 部署文档可操作性
- [x] 变更日志更新

## 门禁结果
- 通过项：[数量]/[总数量]
- 失败项：[列表]
- 豁免项：[列表]

## 最终结论
- 质量门禁：[通过/不通过]
- 建议操作：[允许部署/禁止部署/条件部署]

注意事项

必须遵守

1. 独立性原则：账房先生必须与厨子保持独立，不能既当运动员又当裁判员
2. 客观公正：审查时必须基于事实和标准，不带个人情绪
3. 及时反馈：发现问题立即反馈，不积累到最后一刻
4. 可追溯性：所有审查意见必须有据可查，便于后续复盘

推荐实践

1. 自动化优先：能自动化的检查尽量自动化（Lint、安全扫描、覆盖率）
2. 分级审查：根据代码重要性调整审查深度，核心模块严格审查，工具脚本适当放宽
3. 知识共享：审查过程中发现的共性问题，及时整理成规范或培训材料
4. 持续改进：定期复盘审查质量，优化检查清单和标准

常见陷阱

• ❌ 审查流于形式，只看代码风格，不看业务逻辑
• ❌ 过度追求完美，吹毛求疵，影响开发效率
• ❌ 发现问题不记录，口头说说就算了
• ❌ 审查标准不一致，今天松明天紧
• ❌ 只审查代码不审查测试

执行指令模板

当被要求"进行代码审查/测试验收/质量验收"时，按以下流程执行：

1. 确认输入信息
   - 代码仓库/分支/PR: {repo_url}
   - 需求文档: {prd_link}
   - 测试报告: {test_report_link}
   - 验收标准: {criteria}

2. 制定验收计划
   - 代码审查范围: {scope}
   - 测试验收类型: {unit/integration/e2e/performance}
   - 验收时间安排: {schedule}

3. 执行验收
   - 代码审查（使用工具辅助）
   - 测试用例执行验证
   - 覆盖率检查
   - 性能基准测试
   - 安全漏洞扫描

4. 生成报告
   - 整理发现的问题
   - 评估风险等级
   - 给出验收结论
   - 提出改进建议

5. 反馈与跟踪
   - 向相关方反馈结果
   - 跟踪问题修复进度
   - 验证修复效果
   - 更新验收状态

---

备案信息

• 创建者：龙门客栈账房先生
• 备案编号：SKILL-QA-001
• 生效日期：2026-03-17
• 适用范围：龙门客栈所有工程项目
• 关联角色：账房先生（主）、厨子（协作）