工程开发从规则制定到验收交付的完整流程
版本: 2.0.0 日期: 2026-03-25 适用: 软件工程项目全生命周期 性质: 通用流程框架 + 细致操作指南
目录
1. 流程概览
1.1 完整生命周期流程图
╔═══════════════════════════════════════════════════════════════════════════════════════╗
║ 软件工程项目全生命周期流程 ║
╠═══════════════════════════════════════════════════════════════════════════════════════╣
║ ║
║ ┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓ ║
║ ┃ 第一阶段：规则制定（项目启动） ┃ ║
║ ┃ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┃ ║
║ ┃ │ 需求收集 │───▶│ 需求分析 │───▶│ 规则制定 │───▶│ 规则评审 │───▶│ 规则发布 │ ┃ ║
║ ┃ └─────────┘ └─────────┘ └─────────┘ └─────────┘ └─────────┘ ┃ ║
║ ┃ ┌─────────────────────────────────────────────────────────────────────────┐ ┃ ║
║ ┃ │ 输出：需求规格说明书、开发规则文档、项目计划书、风险清单 │ ┃ ║
║ ┃ └─────────────────────────────────────────────────────────────────────────┘ ┃ ║
║ ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛ ║
║ ↓ ║
║ ┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓ ║
║ ┃ 第二阶段：设计（技术方案） ┃ ║
║ ┃ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┃ ║
║ ┃ │ 架构设计 │───▶│ 接口设计 │───▶│ 数据设计 │───▶│ 安全设计 │───▶│ 设计评审 │ ┃ ║
║ ┃ └─────────┘ └─────────┘ └─────────┘ └─────────┘ └─────────┘ ┃ ║
║ ┃ ┌─────────────────────────────────────────────────────────────────────────┐ ┃ ║
║ ┃ │ 输出：架构设计文档、接口规范、数据库设计、安全方案、技术选型说明 │ ┃ ║
║ ┃ └─────────────────────────────────────────────────────────────────────────┘ ┃ ║
║ ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛ ║
║ ↓ ║
║ ┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓ ║
║ ┃ 第三阶段：开发（编码实现） ┃ ║
║ ┃ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┃ ║
║ ┃ │环境搭建 │───▶│ 编码实现 │───▶│ 单元测试 │───▶│ 代码自审 │───▶│ 提交代码 │ ┃ ║
║ ┃ └─────────┘ └─────────┘ └─────────┘ └─────────┘ └─────────┘ ┃ ║
║ ┃ ┌─────────────────────────────────────────────────────────────────────────┐ ┃ ║
║ ┃ │ 输出：源代码、单元测试、开发文档、技术债务记录 │ ┃ ║
║ ┃ └─────────────────────────────────────────────────────────────────────────┘ ┃ ║
║ ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛ ║
║ ↓ ║
║ ┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓ ║
║ ┃ 第四阶段：测试（质量保证） ┃ ║
║ ┃ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┃ ║
║ ┃ │ 单元测试 │───▶│ 集成测试 │───▶│ 系统测试 │───▶│ 性能测试 │───▶│ 安全测试 │ ┃ ║
║ ┃ └─────────┘ └─────────┘ └─────────┘ └─────────┘ └─────────┘ ┃ ║
║ ┃ ┌─────────────────────────────────────────────────────────────────────────┐ ┃ ║
║ ┃ │ 输出：测试用例、测试报告、缺陷报告、覆盖率报告 │ ┃ ║
║ ┃ └─────────────────────────────────────────────────────────────────────────┘ ┃ ║
║ ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛ ║
║ ↓ ║
║ ┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓ ║
║ ┃ 第五阶段：代码审查（质量把关） ┃ ║
║ ┃ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┃ ║
║ ┃ │ 提交审查 │───▶│ 自动检查 │───▶│ 人工审查 │───▶│ 审查反馈 │───▶│ 审查通过 │ ┃ ║
║ ┃ └─────────┘ └─────────┘ └─────────┘ └─────────┘ └─────────┘ ┃ ║
║ ┃ ┌─────────────────────────────────────────────────────────────────────────┐ ┃ ║
║ ┃ │ 输出：审查记录、改进建议、审查报告 │ ┃ ║
║ ┃ └─────────────────────────────────────────────────────────────────────────┘ ┃ ║
║ ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛ ║
║ ↓ ║
║ ┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓ ║
║ ┃ 第六阶段：集成（系统整合） ┃ ║
║ ┃ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┃ ║
║ ┃ │ 组件集成 │───▶│ 接口联调 │───▶│ 环境部署 │───▶│ 冒烟测试 │───▶│ 集成完成 │ ┃ ║
║ ┃ └─────────┘ └─────────┘ └─────────┘ └─────────┘ └─────────┘ ┃ ║
║ ┃ ┌─────────────────────────────────────────────────────────────────────────┐ ┃ ║
║ ┃ │ 输出：集成报告、环境配置、部署脚本 │ ┃ ║
║ ┃ └─────────────────────────────────────────────────────────────────────────┘ ┃ ║
║ ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛ ║
║ ↓ ║
║ ┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓ ║
║ ┃ 第七阶段：验收（质量确认） ┃ ║
║ ┃ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┃ ║
║ ┃ │ 功能验收 │───▶│ 性能验收 │───▶│ 安全验收 │───▶│ 用户验收 │───▶│ 验收通过 │ ┃ ║
║ ┃ └─────────┘ └─────────┘ └─────────┘ └─────────┘ └─────────┘ ┃ ║
║ ┃ ┌─────────────────────────────────────────────────────────────────────────┐ ┃ ║
║ ┃ │ 输出：验收测试报告、问题清单、验收结论 │ ┃ ║
║ ┃ └─────────────────────────────────────────────────────────────────────────┘ ┃ ║
║ ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛ ║
║ ↓ ║
║ ┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓ ║
║ ┃ 第八阶段：交付（产品发布） ┃ ║
║ ┃ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┃ ║
║ ┃ │ 版本打包 │───▶│ 文档整理 │───▶│ 发布准备 │───▶│ 正式发布 │───▶│ 交付完成 │ ┃ ║
║ ┃ └─────────┘ └─────────┘ └─────────┘ └─────────┘ └─────────┘ ┃ ║
║ ┃ ┌─────────────────────────────────────────────────────────────────────────┐ ┃ ║
║ ┃ │ 输出：发布包、用户文档、运维文档、培训材料 │ ┃ ║
║ ┃ └─────────────────────────────────────────────────────────────────────────┘ ┃ ║
║ ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛ ║
║ ↓ ║
║ ┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓ ║
║ ┃ 第九阶段：运维（持续运营） ┃ ║
║ ┃ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┃ ║
║ ┃ │ 监控告警 │───▶│ 问题处理 │───▶│ 运维优化 │───▶│ 反馈收集 │───▶│ 持续改进 │ ┃ ║
║ ┃ └─────────┘ └─────────┘ └─────────┘ └─────────┘ └─────────┘ ┃ ║
║ ┃ ┌─────────────────────────────────────────────────────────────────────────┐ ┃ ║
║ ┃ │ 输出：监控报告、问题记录、优化方案、需求收集 │ ┃ ║
║ ┃ └─────────────────────────────────────────────────────────────────────────┘ ┃ ║
║ ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛ ║
║ ↓ ║
║ ╔══════════════════╗ ║
║ ║ 迭代反馈循环 ║ ║
║ ╚══════════════════╝ ║
║ ↑ ║
╚═══════════════════════════════════════════════════════════════════════════════════════╝
1.2 各阶段详细说明
┌─────────────────────────────────────────────────────────────────────────────────────┐
│ 阶段时间分配参考 │
├─────────────────────────────────────────────────────────────────────────────────────┤
│ │
│ 规则制定 ████████████ 5-10% │
│ 设计 ███████████████████ 10-15% │
│ 开发 ████████████████████████████████████████████████ 30-40% │
│ 测试 ████████████████████████████████████████ 20-25% │
│ 代码审查 ███████████████████████ 10-15% │
│ 集成验收 ███████████████████ 10-15% │
│ 交付 ████████ 5% │
│ 运维 ∞∞∞∞∞∞∞∞∞∞∞∞∞∞∞∞∞∞∞∞∞∞∞∞∞∞∞∞∞∞∞∞∞∞∞∞∞∞∞ 持续进行 │
│ │
└─────────────────────────────────────────────────────────────────────────────────────┘
1.3 关键里程碑定义
M0: 项目启动
├── 项目立项通过
├── 团队组建完成
└── 开发环境准备
M1: 规则冻结 ────▶ 需求和规则文档定稿，不再变更
├── 需求规格说明书评审通过
├── 开发规则文档发布
└── 项目计划确认
M2: 设计评审通过 ────▶ 技术设计文档通过评审
├── 架构设计文档完成
├── 接口规范确定
├── 数据库设计确认
└── 安全方案通过
M3: Alpha版本 ────▶ 核心功能开发完成，可演示
├── 核心功能实现
├── 基本测试通过
└── 内部演示
M4: Beta版本 ────▶ 功能完整，内部测试完成
├── 所有功能实现
├── 单元测试完成
├── 集成测试通过
└── Bug修复完成
M5: RC版本 ────▶ 修复已知问题，准备发布
├── 已知Bug全部修复
├── 性能优化完成
├── 安全审查通过
└── 发布准备完成
M6: 正式发布 ────▶ 验收通过，正式发布
├── 用户验收通过
├── 发布包构建完成
├── 文档完整
└── 正式对外发布
1.4 角色与职责
┌─────────────────────────────────────────────────────────────────────────────────────┐
│ 项目角色 │
├─────────────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ 项目经理(PM) │ │ 产品经理(PO) │ │ 技术负责人 │ │ 开发工程师 │ │
│ │ │ │ │ │ (TL) │ │ │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ 测试工程师 │ │ 运维工程师 │ │ 安全专员 │ │ UI/UX设计师 │ │
│ │ (QA) │ │ (OPS) │ │ │ │ │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────────────┘
角色职责矩阵:
规则 设计 开发 测试 审查 集成 验收 交付 运维
项目经理 ● ○ ○ ○ ● ● ● ● ○
产品经理 ● ○ ○ ○ ○ ○ ● ○
技术负责人 ● ● ○ ○ ● ● ○ ○ ○
开发工程师 ○ ● ● ○ ○ ● ○ ○
测试工程师 ● ○ ● ● ○
运维工程师 ● ○ ● ●
安全专员 ● ○ ● ● ○
1.5 工作流状态
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ TO DO │────▶│ IN PROGRESS │────▶│ DONE │
│ 待开始 │ │ 进行中 │ │ 已完成 │
└──────────────┘ └──────────────┘ └──────────────┘
▲ │ │
│ ▼ ▼
└──────────────┐ ┌──────────────┐ ┌──────────────┐
│ BLOCKED │ │ REVIEW │
│ 阻塞 │ │ 审查中 │
└──────────────┘ └──────────────┘
2. 阶段一：规则制定
2.1 阶段目标
┌─────────────────────────────────────────────────────────────────────────────────────┐
│ 阶段一目标 │
├─────────────────────────────────────────────────────────────────────────────────────┤
│ ✓ 明确项目需求和范围 │
│ ✓ 制定开发规则和标准 │
│ ✓ 建立团队协作流程 │
│ ✓ 识别项目风险 │
│ ✓ 制定项目计划 │
└─────────────────────────────────────────────────────────────────────────────────────┘
2.2 阶段输入
| 输入物 | 来源 | 说明 | 必需性 |
|---|---|---|---|
| 项目立项书 | 管理层 | 项目背景、目标、预期收益 | 必须 |
| 产品需求文档(PRD) | 产品经理 | 功能需求、用户场景 | 必须 |
| 技术可行性报告 | 技术团队 | 技术方案评估、风险分析 | 必须 |
| 现有系统文档 | 系统分析师 | 如有遗留系统或依赖系统 | 可选 |
| 历史项目总结 | 项目经理 | 经验教训、最佳实践 | 可选 |
| 资源预算 | 财务/人事 | 人力、设备、时间预算 | 必须 |
2.3 详细流程
2.3.1 步骤1：需求收集与分析
┌─────────────────────────────────────────────────────────────────────────────────────┐
│ 需求收集流程 │
├─────────────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ 干系人访谈 │───▶│ 用户调研 │───▶│ 竞品分析 │───▶│ 需求整理 │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │ │ │ │ │
│ ▼ ▼ ▼ ▼ │
│ • 业务负责人 • 问卷调查 • 功能对比 • 功能列表 │
│ • 最终用户 • 用户访谈 • 技术对比 • 非功能需求 │
│ • 技术团队 • 场景分析 • 优劣势分析 • 约束条件 │
│ • 运营团队 │
│ │
└─────────────────────────────────────────────────────────────────────────────────────┘
操作细节：
- 干系人访谈
- 访谈对象：业务负责人、最终用户、技术负责人、运营人员
- 访谈内容：业务痛点、期望功能、使用场景、验收标准
-
访谈输出：访谈记录、需求初稿
-
用户调研
- 调研方法：问卷调查、用户访谈、现场观察、原型测试
- 调研重点：用户习惯、操作场景、痛点问题
-
调研输出：用户画像、用户故事、场景描述
-
竞品分析
- 分析维度：功能对比、技术实现、用户体验、市场定位
- 分析方法：功能矩阵、SWOT分析、优劣势对比
- 分析输出：竞品分析报告、差异化建议
需求分析检查清单：
- [ ] 干系人访谈已完成，访谈记录已整理
- [ ] 用户调研已完成，调研数据已分析
- [ ] 竞品分析已完成，分析报告已输出
- [ ] 功能需求已明确，优先级已划分
- [ ] 非功能需求已定义（性能、安全、可用性等）
- [ ] 约束条件已识别（技术、时间、资源等）
- [ ] 假设条件已列出，后续需验证
- [ ] 需求文档已完成初稿
- [ ] 需求评审会议已安排
2.3.2 步骤2：需求规格编写
需求规格说明书结构：
# 需求规格说明书
## 1. 文档控制
| 版本 | 日期 | 修订内容 | 作者 |
|------|------|----------|------|
| 1.0 | YYYY-MM-DD | 初始版本 | xxx |
## 2. 项目概述
### 2.1 项目背景
- 业务背景
- 项目动因
- 预期收益
### 2.2 项目目标
- 业务目标
- 技术目标
- 用户价值
### 2.3 项目范围
- 功能范围
- 不包含内容
- 后续版本规划
## 3. 用户角色分析
| 角色 | 描述 | 主要需求 | 使用频率 |
|------|------|----------|----------|
| 管理员 | 系统管理员 | ... | 每天 |
## 4. 功能需求
### 4.1 功能清单
| ID | 功能名称 | 优先级 | 复杂度 | 依赖 |
|----|----------|--------|--------|------|
| F001 | 用户登录 | P0 | 低 | 无 |
| F002 | 数据导出 | P1 | 中 | F001 |
### 4.2 功能详细说明
#### F001: 用户登录
**用户故事**: 作为用户，我希望能够登录系统，以便使用系统功能。
**验收标准**:
- Given 用户在登录页面
- When 输入正确的用户名和密码
- Then 成功登录并跳转到首页
- And 显示用户信息
**功能流程**:
1. 用户访问登录页面
2. 输入用户名和密码
3. 系统验证用户信息
4. 验证成功，创建会话
5. 跳转到首页
**界面原型**: [附原型图或线框图]
**异常处理**:
- 用户名或密码错误 → 提示"用户名或密码错误"
- 账号被锁定 → 提示"账号已被锁定，请联系管理员"
- 网络异常 → 提示"网络连接失败，请稍后重试"
## 5. 非功能需求
### 5.1 性能需求
- 系统响应时间 < 3秒 (P95)
- 并发用户数 > 1000
- 数据处理量 > 10万条/分钟
### 5.2 安全需求
- 用户密码加密存储
- 通信数据加密传输
- 操作日志完整记录
- 权限控制精确到按钮级别
### 5.3 可用性需求
- 系统可用性 > 99.5%
- 故障恢复时间 < 1小时
- 数据备份频率：每天一次
### 5.4 兼容性需求
- 支持浏览器：Chrome、Firefox、Safari、Edge
- 支持操作系统：Windows 10+、macOS 12+、Linux
- 支持移动端：iOS 14+、Android 10+
## 6. 数据需求
### 6.1 数据实体
- 用户: 包含属性、关系、约束
- 订单: ...
- 产品: ...
### 6.2 数据量预估
- 用户数据: 预计1年内达到10万条
- 订单数据: 预计1年内达到100万条
## 7. 接口需求
### 7.1 外部接口
- 支付接口: 对接支付宝、微信支付
- 短信接口: 对接阿里云短信
- 物流接口: 对接顺丰、圆通
### 7.2 内部接口
- 前端调用后端API
- 后端调用第三方服务API
## 8. 约束条件
### 8.1 技术约束
- 开发语言: Python 3.12
- 框架: Django 4.2
- 数据库: PostgreSQL 14
- 部署环境: Docker + Kubernetes
### 8.2 业务约束
- 必须符合等保三级要求
- 必须符合数据安全法规定
### 8.3 时间约束
- 项目周期: 6个月
- 上线时间: YYYY-MM-DD
### 8.4 资源约束
- 开发团队: 8人
- 预算: 100万元
- 服务器: 4核8G × 3台
## 9. 假设条件
1. 用户具备基本的计算机操作能力
2. 网络环境稳定
3. 第三方接口可用性 > 99%
4. 后期可根据实际情况调整假设
## 10. 风险识别
| 风险 | 可能性 | 影响 | 应对措施 |
|------|--------|------|----------|
| ... | ... | ... | ... |
## 11. 附录
### 11.1 术语表
| 术语 | 定义 |
|------|------|
| ... | ... |
### 11.2 参考文档
- [相关标准]
- [行业文档]
2.3.3 步骤3：规则制定
开发规则制定流程：
┌─────────────────────────────────────────────────────────────────────────────────────┐
│ 规则制定流程 │
├─────────────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ 编码规范 │───▶│ 开发流程 │───▶│ 协作规则 │───▶│ 质量标准 │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │ │ │ │ │
│ ▼ ▼ ▼ ▼ │
│ • 命名规范 • Git工作流 • 会议制度 • 代码覆盖率 │
│ • 代码格式 • 分支策略 • 沟通工具 • 测试要求 │
│ • 注释规范 • 提交规范 • 文档规范 • 性能指标 │
│ • 类型注解 • 代码审查 • 问题上报 • 安全标准 │
│ │
└─────────────────────────────────────────────────────────────────────────────────────┘
编码规范详细说明：
# 编码规范配置
命名规范:
类名: 大驼峰(PascalCase)
示例: UserManager, OrderService
函数名: 小写+下划线(snake_case)
示例: get_user_info, calculate_total
变量名: 小写+下划线(snake_case)
示例: user_name, total_amount
常量名: 大写+下划线(UPPER_SNAKE_CASE)
示例: MAX_RETRY_COUNT, DEFAULT_TIMEOUT
私有成员: 前缀下划线(_private)
示例: _internal_method, _config_data
文件组织:
导入顺序: 标准库 -> 第三方库 -> 本地模块
import os
import sys
import yaml
import requests
from myproject.utils import helper
文件长度: 建议 < 500行
函数长度: 建议 < 50行
类长度: 建议 < 300行
注释规范:
函数文档: Google风格或NumPy风格
"""
函数简短描述
详细描述（可选）
Args:
param1: 参数1描述
param2: 参数2描述
Returns:
返回值描述
Raises:
Exception: 异常描述
Example:
>>> func(1, 2)
3
"""
行内注释: 简洁明了，解释"为什么"而非"是什么"
# 使用缓存减少数据库查询
块注释: 用于复杂逻辑说明
# 以下算法采用动态规划实现
# 时间复杂度: O(n^2)
# 空间复杂度: O(n)
开发流程规范：
Git工作流:
主分支: main/master
• 只接受经过审查的合并
• 保持稳定可发布状态
开发分支: develop
• 日常开发分支
• 功能完成后合并到主分支
功能分支: feature/功能名
• 从develop分支创建
• 完成后合并回develop
修复分支: fix/问题名
• 从develop分支创建
• 完成后合并回develop和main
发布分支: release/版本号
• 从develop分支创建
• 用于发布准备和版本号更新
提交规范:
格式: <type>(<scope>): <subject>
类型(type):
feat: 新功能
fix: Bug修复
docs: 文档更新
style: 代码格式调整
refactor: 重构
test: 测试相关
chore: 构建/工具链
示例:
feat(auth): 添加用户登录功能
- 实现用户名密码登录
- 添加JWT Token生成
- 添加登录状态检查
Closes #123
代码审查:
触发条件: PR创建时
参与人员: 至少1名审查者
审查内容:
• 功能正确性
• 代码质量
• 测试覆盖
• 文档完整
• 安全问题
通过标准:
• 所有审查意见已处理
• CI检查通过
• 无保留意见
2.3.4 步骤4：风险识别与应对
风险管理流程：
┌─────────────────────────────────────────────────────────────────────────────────────┐
│ 风险管理流程 │
├─────────────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ 风险识别 │───▶│ 风险评估 │───▶│ 风险应对 │───▶│ 风险监控 │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │ │ │ │ │
│ ▼ ▼ ▼ ▼ │
│ • 需求风险 • 发生概率 • 规避 • 定期检查 │
│ • 技术风险 • 影响程度 • 缓解 • 状态更新 │
│ • 资源风险 • 风险等级 • 转移 • 新风险识别 │
│ • 进度风险 • 优先级排序 • 接受 • 应对措施调整 │
│ • 依赖风险 │
│ │
└─────────────────────────────────────────────────────────────────────────────────────┘
风险识别清单：
需求风险:
- 需求不明确或频繁变更
- 用户期望过高
- 业务逻辑复杂
- 多方需求冲突
技术风险:
- 技术选型不当
- 技术难度低估
- 第三方依赖不稳定
- 技术团队能力不足
- 性能目标难以达成
资源风险:
- 人员流动
- 人力不足
- 设备/工具短缺
- 预算不足
进度风险:
- 时间估算不准确
- 任务依赖复杂
- 外部依赖延期
- 需求变更导致返工
质量风险:
- 测试时间不足
- 质量标准不明确
- 技术债务积累
- 上线后问题频发
安全风险:
- 数据泄露
- 系统被攻击
- 权限控制不当
- 合规性问题
沟通风险:
- 需求传递失真
- 团队协作不畅
- 文档不完整
- 信息不同步
风险评估矩阵：
影响程度
高 │ R2 │ R1 │ R1 │
│ 高-高 │ 高-高 │ 高-高 │
─────────┼──────┼──────┼──────
中 │ R3 │ R2 │ R1 │
│ 中-高 │ 中-中 │ 中-高 │
─────────┼──────┼──────┼──────
低 │ R3 │ R2 │ R2 │
│ 低-高 │ 低-中 │ 低-中 │
─────────┼──────┼──────┼──────
│ 低 │ 中 │ 高 │
发生概率
R1: 高风险 - 立即处理
R2: 中风险 - 重点监控
R3: 低风险 - 定期检查
2.3.5 步骤5：项目计划制定
项目计划制定流程：
┌─────────────────────────────────────────────────────────────────────────────────────┐
│ 项目计划制定 │
├─────────────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ 工作分解 │───▶│ 时间估算 │───▶│ 资源分配 │───▶│ 计划评审 │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │ │ │ │ │
│ ▼ ▼ ▼ ▼ │
│ • WBS分解 • 三点估算 • 人员分配 • 计划确认 │
│ • 任务定义 • 缓冲时间 • 设备分配 • 基线确定 │
│ • 依赖关系 • 关键路径 • 预算分配 │ │
│ │
└─────────────────────────────────────────────────────────────────────────────────────┘
WBS分解示例：
项目总目标
├── 1.0 规则制定阶段
│ ├── 1.1 需求收集
│ │ ├── 1.1.1 干系人访谈
│ │ ├── 1.1.2 用户调研
│ │ └── 1.1.3 竞品分析
│ ├── 1.2 需求分析
│ │ ├── 1.2.1 功能分析
│ │ └── 1.2.2 非功能分析
│ ├── 1.3 规则制定
│ └── 1.4 需求评审
├── 2.0 设计阶段
│ ├── 2.1 架构设计
│ │ ├── 2.1.1 系统架构
│ │ ├── 2.1.2 技术选型
│ │ └── 2.1.3 接口设计
│ ├── 2.2 数据设计
│ └── 2.3 安全设计
├── 3.0 开发阶段
│ ├── 3.1 前端开发
│ │ ├── 3.1.1 页面开发
│ │ ├── 3.1.2 组件开发
│ │ └── 3.1.3 状态管理
│ ├── 3.2 后端开发
│ │ ├── 3.2.1 API开发
│ │ ├── 3.2.2 业务逻辑
│ │ └── 3.2.3 数据处理
│ └── 3.3 数据库开发
└── 4.0 测试阶段
├── 4.1 单元测试
├── 4.2 集成测试
└── 4.3 系统测试
2.4 阶段输出
| 输出物 | 说明 | 模板 | 必需性 |
|---|---|---|---|
| 需求规格说明书 | 详细需求文档 | 见附录A | 必须 |
| 技术选型报告 | 技术方案评估 | 见附录B | 必须 |
| 开发规则文档 | 编码规范和流程 | 见附录C | 必须 |
| 项目计划书 | 时间计划和里程碑 | 见附录D | 必须 |
| 风险管理计划 | 风险清单和应对措施 | 见附录E | 必须 |
| 资源需求清单 | 人员、设备、预算 | - | 必须 |
| 干系人沟通计划 | 沟通方式和频率 | - | 推荐 |
2.5 阶段验收标准
## 阶段一验收清单
### 文档完整性
- [ ] 需求规格说明书已完成并评审
- [ ] 技术选型报告已完成
- [ ] 开发规则文档已发布
- [ ] 项目计划书已确认
- [ ] 风险管理计划已制定
### 需求明确性
- [ ] 所有功能需求已明确
- [ ] 所有非功能需求已定义
- [ ] 验收标准已清晰定义
- [ ] 约束条件已全部识别
### 规则可行性
- [ ] 开发规则符合团队实际
- [ ] 技术选型经过充分评估
- [ ] 时间和资源估算合理
- [ ] 风险应对措施可行
### 团队认可
- [ ] 所有团队成员已接受规则培训
- [ ] 规则文档已获得团队认可
- [ ] 项目计划已获得管理层批准
- [ ] 干系人对规则无异议
### 基线建立
- [ ] 需求基线已建立
- [ ] 计划基线已建立
- [ ] 规则基线已建立
- [ ] 后续变更需走变更流程
2.6 阶段常见问题
| 问题 | 原因 | 解决方案 |
|---|---|---|
| 需求不明确 | 干系人沟通不足 | 增加访谈和调研 |
| 规则无法执行 | 脱离实际 | 根据实际情况调整 |
| 风险被忽视 | 没有进行风险分析 | 建立风险识别机制 |
| 计划不合理 | 估算偏差大 | 使用三点估算法 |
| 团队不认可 | 规则制定过程不透明 | 让团队参与制定 |
3. 阶段二：设计阶段
3.1 阶段目标
┌─────────────────────────────────────────────────────────────────────────────────────┐
│ 阶段二目标 │
├─────────────────────────────────────────────────────────────────────────────────────┤
│ ✓ 完成系统架构设计 │
│ ✓ 完成接口设计 │
│ ✓ 完成数据库设计 │
│ ✓ 完成安全设计 │
│ ✓ 通过设计评审 │
└─────────────────────────────────────────────────────────────────────────────────────┘
3.2 阶段输入
| 输入物 | 来源 | 说明 |
|---|---|---|
| 需求规格说明书 | 阶段一输出 | 功能和非功能需求 |
| 技术选型报告 | 阶段一输出 | 技术栈选择 |
| 系统约束条件 | 项目需求 | 技术和业务约束 |
| 参考架构 | 行业最佳实践 | 同类系统架构 |
| 设计规范 | 团队标准 | 设计文档规范 |
3.3 详细流程
3.3.1 步骤1：架构设计
架构设计流程：
┌─────────────────────────────────────────────────────────────────────────────────────┐
│ 架构设计流程 │
├─────────────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ 架构分析 │───▶│ 架构选型 │───▶│ 架构设计 │───▶│ 架构评审 │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │ │ │ │ │
│ ▼ ▼ ▼ ▼ │
│ • 业务分析 • 单体/微服务 • 系统分层 • 架构合理性 │
│ • 功能分解 • 分层架构 • 模块划分 • 扩展性 │
│ • 技术约束 • 事件驱动 • 接口定义 • 性能 │
│ • 非功能需求 • CQRS模式 • 数据流设计 • 安全性 │
│ │
└─────────────────────────────────────────────────────────────────────────────────────┘
架构视图模板：
┌─────────────────────────────────────────────────────────────────────────────────────┐
│ 用户视图 │
├─────────────────────────────────────────────────────────────────────────────────────┤
│ 用户：最终用户、管理员、运维人员 │
│ 场景：用户使用系统、管理员配置系统、运维人员监控系统 │
└─────────────────────────────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────────────────────────────┐
│ 逻辑视图 │
├─────────────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────────────────────────────┐ │
│ │ 应用层 │ │
│ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │
│ │ │ Web应用 │ │ 移动端 │ │ 第三方 │ │ 定时任务 │ │ │
│ │ └─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘ │ │
│ └─────────────────────────────────────────────────────────────────────────────┘ │
│ ↓ │
│ ┌─────────────────────────────────────────────────────────────────────────────┐ │
│ │ 业务层 │ │
│ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │
│ │ │ 用户服务 │ │ 订单服务 │ │ 支付服务 │ │ 通知服务 │ │ │
│ │ └─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘ │ │
│ └─────────────────────────────────────────────────────────────────────────────┘ │
│ ↓ │
│ ┌─────────────────────────────────────────────────────────────────────────────┐ │
│ │ 服务层 │ │
│ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │
│ │ │ 认证服务 │ │ 数据服务 │ │ 文件服务 │ │ 缓存服务 │ │ │
│ │ └─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘ │ │
│ └─────────────────────────────────────────────────────────────────────────────┘ │
│ ↓ │
│ ┌─────────────────────────────────────────────────────────────────────────────┐ │
│ │ 数据层 │ │
│ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │
│ │ │ MySQL │ │ Redis │ │ 文件存储 │ │ 消息队列 │ │ │
│ │ └─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘ │ │
│ └─────────────────────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────────────┘
架构设计文档模板：
# 系统架构设计文档
## 1. 文档信息
- 项目名称:
- 版本:
- 作者:
- 日期:
## 2. 架构概述
### 2.1 架构目标
- 高可用性: 系统可用性 > 99.5%
- 可扩展性: 支持水平扩展
- 可维护性: 模块化设计，易于维护
- 安全性: 符合安全规范
### 2.2 架构原则
- 单一职责: 每个模块只负责一项功能
- 开放封闭: 对扩展开放，对修改封闭
- 依赖倒置: 高层模块不依赖低层模块
- 接口隔离: 客户端不依赖不需要的接口
### 2.3 架构选型
- 单体架构 vs 微服务架构: 选择[单体/微服务]
- 分层架构: 采用[三层/四层/五层]架构
- 通信模式: 同步/异步/消息队列
## 3. 分层设计
### 3.1 应用层
- Web应用: [框架]
- 移动端: [技术]
- 第三方集成: [API]
### 3.2 业务层
- [服务列表]
- [业务流程]
### 3.3 服务层
- [公共服务列表]
- [技术组件]
### 3.4 数据层
- [数据库]
- [缓存]
- [存储]
## 4. 模块设计
### 4.1 模块划分
| 模块 | 职责 | 依赖 |
|------|------|------|
| 用户模块 | 用户管理、认证授权 | 基础模块 |
| 订单模块 | 订单管理、支付 | 用户模块 |
| ...
### 4.2 模块交互
### 5.2 数据同步策略
- 实时同步
- 定时同步
- 事件驱动
## 6. 技术选型
| 类型 | 技术选型 | 说明 |
|------|----------|------|
| 开发语言 | Python 3.12 | 团队熟悉 |
| Web框架 | Django 4.2 | 成熟稳定 |
| 数据库 | PostgreSQL 14 | 开源可靠 |
| 缓存 | Redis 7.0 | 高性能 |
| 消息队列 | RabbitMQ | 可靠消息 |
## 7. 非功能设计
### 7.1 性能设计
- 缓存策略
- 负载均衡
- 数据库优化
### 7.2 安全设计
- 认证授权
- 数据加密
- 安全审计
### 7.3 可用性设计
- 集群部署
- 故障转移
- 备份恢复
## 8. 部署架构
3.3.2 步骤2：接口设计
接口设计流程：
┌─────────────────────────────────────────────────────────────────────────────────────┐
│ 接口设计流程 │
├─────────────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ 接口识别 │───▶│ 接口定义 │───▶│ 接口文档 │───▶│ 接口评审 │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │ │ │ │ │
│ ▼ ▼ ▼ ▼ │
│ • 功能分析 • RESTful设计 • API文档 • 接口合理性 │
│ • 实体提取 • GraphQL设计 • 数据模型 • 易用性 │
│ • 操作识别 • RPC设计 • 示例代码 • 一致性 │
│ • 依赖关系 │
│ │
└─────────────────────────────────────────────────────────────────────────────────────┘
RESTful API设计规范：
# RESTful API设计规范
URL设计:
- 使用名词复数表示资源
- 层级结构不超过3层
- 使用小写字母和连字符
示例:
/api/users # 获取用户列表
/api/users/{id} # 获取单个用户
/api/users/{id}/orders # 获取用户的订单
反例:
/api/getUsers # 不要使用动词
/api/Users # 不要使用大写
/api/user/{id}/order/list # 层级过深
HTTP方法使用:
GET /api/users # 获取资源列表
GET /api/users/{id} # 获取单个资源
POST /api/users # 创建资源
PUT /api/users/{id} # 全量更新资源
PATCH /api/users/{id} # 部分更新资源
DELETE /api/users/{id} # 删除资源
其他操作使用子资源:
POST /api/users/{id}/activate # 激活用户
POST /api/users/{id}/deactivate # 停用用户
查询参数:
分页: ?page=1&size=20
排序: ?sort=createdAt:desc
过滤: ?status=active&type=vip
搜索: ?keyword=test
投影: ?fields=id,name,email
响应格式:
成功响应:
Status: 200 OK
{
"success": true,
"data": {
"id": "123",
"name": "张三"
},
"meta": {
"page": 1,
"size": 20,
"total": 100
}
}
错误响应:
Status: 400 Bad Request
{
"success": false,
"error": "参数验证失败",
"code": "VALIDATION_ERROR",
"details": {
"email": "邮箱格式不正确"
},
"requestId": "req-123456"
}
列表响应:
Status: 200 OK
{
"success": true,
"data": [...],
"meta": {
"page": 1,
"size": 20,
"total": 100
}
}
状态码使用:
200 OK # 请求成功
201 Created # 资源创建成功
204 No Content # 删除成功
400 Bad Request # 请求参数错误
401 Unauthorized # 未认证
403 Forbidden # 无权限
404 Not Found # 资源不存在
409 Conflict # 资源冲突
422 Unprocessable # 参数验证失败
429 Too Many Requests # 请求过多
500 Internal Error # 服务器错误
503 Service Unavailable # 服务不可用
API文档模板：
# API文档：用户管理
## 1. 用户列表
### 1.1 获取用户列表
**接口地址**: `GET /api/users`
**请求参数**:
| 参数 | 类型 | 必填 | 说明 | 示例 |
|------|------|------|------|------|
| page | integer | 否 | 页码，从1开始 | 1 |
| size | integer | 否 | 每页数量，默认20 | 20 |
| keyword | string | 否 | 搜索关键词 | 张三 |
| status | string | 否 | 用户状态 | active |
**请求示例**:
```http
GET /api/users?page=1&size=20&status=active
Authorization: Bearer {token}
响应示例:
{
"success": true,
"data": [
{
"id": "123",
"name": "张三",
"email": "zhangsan@example.com",
"status": "active",
"createdAt": "2024-01-01T00:00:00Z"
}
],
"meta": {
"page": 1,
"size": 20,
"total": 100
}
}
错误响应:
2. 用户详情
2.1 获取用户详情
接口地址: GET /api/users/{id}
路径参数:
| 参数 | 类型 | 必填 | 说明 | 示例 |
|---|---|---|---|---|
| id | string | 是 | 用户ID | 123 |
响应示例:
{
"success": true,
"data": {
"id": "123",
"name": "张三",
"email": "zhangsan@example.com",
"phone": "13800138000",
"avatar": "https://example.com/avatar/123.jpg",
"status": "active",
"createdAt": "2024-01-01T00:00:00Z",
"updatedAt": "2024-01-01T00:00:00Z"
}
}
2.2 更新用户
接口地址: PUT /api/users/{id}
请求体:
响应示例: 同获取用户详情
3. 错误码说明
索引设计原则：
索引设计原则:
选择性原则:
- 在高选择性列上建立索引
- 唯一索引是最好的索引
- 避免在低选择性列(如性别)上建索引
最左前缀原则:
- 联合索引 (a,b,c) 支持: a, ab, abc 查询
- 不支持: b, c, bc 查询
覆盖索引原则:
- 索引包含查询所需的所有字段
- 避免回表查询，提高性能
避免过度索引:
- 索引占用存储空间
- 索影响INSERT/UPDATE性能
- 只在必要的列上建立索引
监控索引使用:
- 定期检查索引使用情况
- 删除未使用的索引
3.3.4 步骤4：安全设计
安全设计流程：
┌─────────────────────────────────────────────────────────────────────────────────────┐
│ 安全设计流程 │
├─────────────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ 威胁分析 │───▶│ 安全方案 │───▶│ 安全实施 │───▶│ 安全评审 │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │ │ │ │ │
│ ▼ ▼ ▼ ▼ │
│ • 资产识别 • 认证授权 • 代码实现 • 安全测试 │
│ • 威胁建模 • 数据加密 • 配置部署 • 渗透测试 │
│ • 风险评估 • 访问控制 • 安全监控 | 安全审计 │
│ • 合规要求 • 安全审计 • 应急响应 │
│ │
└─────────────────────────────────────────────────────────────────────────────────────┘
安全设计清单：
认证授权:
认证方式:
- 用户名密码登录
- 手机验证码登录
- 第三方登录(微信/QQ/GitHub)
- JWT Token认证
密码安全:
- 密码复杂度要求: 至少8位，包含大小写字母、数字
- 密码加密: bcrypt/Argon2加密
- 密码传输: HTTPS加密传输
- 密码重置: 邮箱/手机验证码
会话管理:
- Token有效期: 访问Token 2小时，刷新Token 7天
- 单设备登录: 同一账号只能在一个设备登录
- 异常登录检测: IP异常、设备异常时告警
权限控制:
- RBAC模型: 基于角色的访问控制
- 权限粒度: 控制到菜单、按钮级别
- 权限继承: 角色继承、部门继承
- 数据权限: 行级数据权限控制
数据安全:
传输加密:
- HTTPS: 全站HTTPS
- TLS版本: 1.3以上
- 加密算法: AES-256
存储加密:
- 敏感字段加密: 密码、身份证号、银行卡号
- 加密算法: AES-256
- 密钥管理: 密钥定期轮换
数据脱敏:
- 日志脱敏: 日志中敏感信息脱敏
- 展示脱敏: 前端展示时部分信息用*代替
- 导出脱敏: 数据导出时敏感信息脱敏
备份恢复:
- 数据备份: 每天全量备份，每小时增量备份
- 异地备份: 备份数据异地存储
- 恢复演练: 每季度进行恢复演练
安全防护:
输入验证:
- 白名单验证: 只允许合法字符
- 长度限制: 防止超长输入
- 类型检查: 严格类型检查
- XSS防护: HTML转义
SQL注入防护:
- 参数化查询: 使用参数化查询
- ORM框架: 使用ORM框架
- 输入验证: 严格输入验证
CSRF防护:
- CSRF Token: 表单加入CSRF Token
- SameSite Cookie: Cookie设置SameSite属性
- 验证来源: 验证请求来源
API安全:
- 限流: 每用户每分钟最多100次请求
- 签名验证: 敏感接口使用签名验证
- IP白名单: 管理接口IP白名单
文件安全:
- 文件类型: 只允许指定类型文件
- 文件大小: 限制文件大小
- 文件扫描: 上传文件扫描病毒
- 存储隔离: 上传文件独立存储
安全审计:
审计日志:
- 登录日志: 记录登录时间、IP、设备
- 操作日志: 记录增删改操作
- 异常日志: 记录异常操作
- 日志保留: 审计日志保留6个月
安全监控:
- 异常登录: 异地登录、异常时间登录告警
- 异常操作: 频繁操作、批量操作告警
- 攻击检测: SQL注入、XSS攻击检测
- 性能监控: 系统性能异常告警
3.4 阶段输出
| 输出物 | 说明 | 模板 |
|---|---|---|
| 架构设计文档 | 系统架构、技术选型 | 见上文 |
| 接口设计文档 | API规格、数据格式 | 见上文 |
| 数据库设计文档 | 表结构、索引、关系 | 见上文 |
| 安全设计文档 | 认证授权、安全方案 | 见上文 |
| 原型/POC | 可演示的原型 | 可选 |
3.5 阶段验收标准
## 阶段二验收清单
### 文档完整性
- [ ] 架构设计文档已完成并评审
- [ ] 接口设计文档已完成
- [ ] 数据库设计文档已完成
- [ ] 安全设计文档已完成
### 设计合理性
- [ ] 架构设计满足非功能需求
- [ ] 接口设计符合RESTful规范
- [ ] 数据库设计满足性能要求
- [ ] 安全设计符合合规要求
### 可实施性
- [ ] 技术选型合理可行
- [ ] 开发团队具备相应技能
- [ ] 第三方依赖稳定可靠
- [ ] 有充分的技术储备
### 评审通过
- [ ] 架构评审已通过
- [ ] 接口评审已通过
- [ ] 数据库评审已通过
- [ ] 安全评审已通过
### 风险可控
- [ ] 技术风险已识别
- [ ] 风险应对措施已制定
- [ ] 备选方案已准备
4. 阶段三：开发阶段
4.1 阶段目标
┌─────────────────────────────────────────────────────────────────────────────────────┐
│ 阶段三目标 │
├─────────────────────────────────────────────────────────────────────────────────────┤
│ ✓ 完成编码实现 │
│ ✓ 完成单元测试 │
│ ✓ 代码符合规范 │
│ ✓ 代码自审完成 │
└─────────────────────────────────────────────────────────────────────────────────────┘
4.2 阶段输入
| 输入物 | 来源 | 说明 |
|---|---|---|
| 需求规格说明书 | 阶段一输出 | 功能需求 |
| 设计文档 | 阶段二输出 | 技术设计 |
| 接口文档 | 阶段二输出 | API规格 |
| 数据库设计 | 阶段二输出 | 表结构 |
| 开发规则 | 阶段一输出 | 编码规范 |
4.3 详细流程
4.3.1 步骤1：开发环境搭建
环境搭建流程：
┌─────────────────────────────────────────────────────────────────────────────────────┐
│ 环境搭建流程 │
├─────────────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ 开发工具 │───▶│ 运行环境 │───▶│ 数据库环境 │───▶│ 开发测试 │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │ │ │ │ │
│ ▼ ▼ ▼ ▼ │
│ • IDE配置 • 语言环境 • 数据库安装 • 单元测试框架 │
│ • 代码格式化 • 包管理器 • 数据迁移 • 集成测试框架 │
│ • 代码检查 • 虚拟环境 • 连接配置 • Mock工具 │
│ • Git配置 • Docker使用 │ │ │
│ │
└─────────────────────────────────────────────────────────────────────────────────────┘
开发环境检查清单：
必需工具:
IDE:
- [ ] Visual Studio Code / PyCharm / IntelliJ IDEA
- [ ] 代码格式化插件
- [ ] 代码检查插件
- [ ] Git集成插件
版本控制:
- [ ] Git已安装
- [ ] Git配置完成(user.name, user.email)
- [ ] SSH密钥已配置
语言环境:
- [ ] Python 3.12已安装
- [ ] 虚拟环境已创建
- [ ] 依赖包已安装(requirements.txt)
数据库:
- [ ] PostgreSQL 14已安装
- [ ] 数据库已创建
- [ ] 测试数据已导入
可选工具:
- [ ] Docker
- [ ] Redis
- [ ] RabbitMQ
- [ ] Nginx
测试环境:
- [ ] pytest已安装
- [ ] pytest-cov已安装
- [ ] pytest-mock已安装
- [ ] 测试数据库已配置
4.3.2 步骤2：编码实现
编码流程：
┌─────────────────────────────────────────────────────────────────────────────────────┐
│ 编码实现流程 │
├─────────────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ 理解需求 │───▶│ 编码实现 │───▶│ 代码自审 │───▶│ 提交代码 │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │ │ │ │ │
│ ▼ ▼ ▼ ▼ │
│ • 阅读需求 • 按规范编码 • 检查代码风格 • 遵循提交规范 │
│ • 理解设计 • 类型注解 • 检查命名规范 • 编写提交说明 │
│ • 明确接口 │ 文档字符串 • 检查逻辑错误 │ │
│ • 确认依赖 │
│ │
└─────────────────────────────────────────────────────────────────────────────────────┘
Python编码规范详细说明：
"""
文件文档字符串
模块简短描述
详细描述（可选）
"""
# 1. 标准库导入
import os
import sys
from typing import Dict, List, Optional, Any, Callable
from datetime import datetime
from enum import Enum
# 2. 第三方库导入
import yaml
import requests
from pydantic import BaseModel
# 3. 本地模块导入
from app.core.config import settings
from app.models.user import User
from app.utils.helpers import format_date
# 4. 常量定义
MAX_RETRY_COUNT = 3
DEFAULT_TIMEOUT = 30
API_VERSION = "v1"
# 5. 枚举定义
class Status(Enum):
"""状态枚举"""
ACTIVE = 1
INACTIVE = 2
DELETED = 3
# 6. 异常定义
class UserNotFoundError(Exception):
"""用户未找到异常"""
pass
class ValidationError(Exception):
"""验证异常"""
pass
# 7. 类型定义
class UserCreateRequest(BaseModel):
"""用户创建请求"""
username: str
email: str
password: str
class Config:
schema_extra = {
"example": {
"username": "zhangsan",
"email": "zhangsan@example.com",
"password": "password123"
}
}
# 8. 类定义
class UserService:
"""用户服务类"""
def __init__(self, db_session):
"""初始化
Args:
db_session: 数据库会话
"""
self.db_session = db_session
self.logger = logging.getLogger(__name__)
def get_user(self, user_id: int) -> Optional[User]:
"""获取用户
Args:
user_id: 用户ID
Returns:
用户对象，不存在返回None
Raises:
UserNotFoundException: 用户不存在
"""
user = self.db_session.query(User).filter(User.id == user_id).first()
if not user:
raise UserNotFoundError(f"用户 {user_id} 不存在")
return user
def create_user(self, request: UserCreateRequest) -> User:
"""创建用户
Args:
request: 创建请求
Returns:
创建的用户对象
"""
# 验证用户名是否已存在
if self.db_session.query(User).filter(User.username == request.username).first():
raise ValidationError("用户名已存在")
# 创建用户
user = User(
username=request.username,
email=request.email,
password=self._hash_password(request.password),
status=Status.ACTIVE.value,
created_at=datetime.now()
)
self.db_session.add(user)
self.db_session.commit()
self.db_session.refresh(user)
return user
@staticmethod
def _hash_password(password: str) -> str:
"""哈希密码"""
import bcrypt
return bcrypt.hashpw(password.encode(), bcrypt.gensalt()).decode()
# 9. 函数定义
def format_user(user: User) -> Dict[str, Any]:
"""格式化用户信息
Args:
user: 用户对象
Returns:
格式化的用户信息字典
"""
return {
"id": user.id,
"username": user.username,
"email": user.email,
"status": user.status,
"created_at": user.created_at.isoformat()
}
# 10. 主程序
if __name__ == "__main__":
# 主程序逻辑
pass
常见编码模式：
# 1. 上下文管理器
from contextlib import contextmanager
@contextmanager
def database_session():
"""数据库会话上下文管理器"""
session = create_session()
try:
yield session
session.commit()
except Exception:
session.rollback()
raise
finally:
session.close()
# 使用
with database_session() as session:
user = session.query(User).first()
# 2. 装饰器
from functools import wraps
import time
def log_execution_time(func):
"""记录执行时间装饰器"""
@wraps(func)
def wrapper(*args, **kwargs):
start = time.time()
result = func(*args, **kwargs)
elapsed = time.time() - start
print(f"{func.__name__} 执行时间: {elapsed:.2f}秒")
return result
return wrapper
# 使用
@log_execution_time
def process_data(data):
return data * 2
# 3. 工厂函数
def create_service(service_type: str):
"""创建服务实例工厂函数"""
if service_type == "user":
return UserService()
elif service_type == "order":
return OrderService()
else:
raise ValueError(f"未知的服务类型: {service_type}")
# 4. 策略模式
class PaymentStrategy(ABC):
"""支付策略抽象类"""
@abstractmethod
def pay(self, amount: float) -> bool:
pass
class AlipayStrategy(PaymentStrategy):
"""支付宝支付策略"""
def pay(self, amount: float) -> bool:
# 支付宝支付逻辑
return True
class WeChatPayStrategy(PaymentStrategy):
"""微信支付策略"""
def pay(self, amount: float) -> bool:
# 微信支付逻辑
return True
# 5. 观察者模式
class EventPublisher:
"""事件发布者"""
def __init__(self):
self._subscribers = []
def subscribe(self, callback):
self._subscribers.append(callback)
def publish(self, event):
for callback in self._subscribers:
callback(event)
4.3.3 步骤3：单元测试
TDD开发流程：
┌─────────────────────────────────────────────────────────────────────────────────────┐
│ TDD开发流程 │
├─────────────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ RED │────▶│ GREEN │────▶│ REFACTOR │────▶│ 循环 │ │
│ │ 写测试 │ │ 写代码 │ │ 重构代码 │ │ │ │
│ └─────────┘ └─────────┘ └─────────┘ └─────────┘ │
│ │ │ │ │ │
│ ▼ ▼ ▼ ▼ │
│ • 测试失败 • 测试通过 • 优化代码 • 继续下一功能 │
│ • 明确行为 • 最简实现 • 保持测试通过 │ │
│ │
└─────────────────────────────────────────────────────────────────────────────────────┘
步骤示例:
1. RED: 写测试
def test_add():
assert add(1, 2) == 3
2. 运行测试: 失败（函数未实现）
3. GREEN: 写代码
def add(a, b):
return a + b
4. 运行测试: 通过
5. REFACTOR: 重构（如需要）
def add(a: int, b: int) -> int:
return a + b
6. 运行测试: 仍然通过
单元测试模板：
"""
用户服务单元测试
"""
import pytest
from unittest.mock import Mock, patch
from app.services.user_service import UserService
from app.models.user import User
from app.exceptions import UserNotFoundError, ValidationError
class TestUserService:
"""用户服务测试类"""
@pytest.fixture
def user_service(self, db_session):
"""用户服务fixture"""
return UserService(db_session)
@pytest.fixture
def sample_user(self, db_session):
"""示例用户fixture"""
user = User(
id=1,
username="testuser",
email="test@example.com",
password="hashed_password",
status=1
)
db_session.add(user)
db_session.commit()
return user
def test_get_user_success(self, user_service, sample_user):
"""测试成功获取用户"""
# 执行
result = user_service.get_user(sample_user.id)
# 验证
assert result.id == sample_user.id
assert result.username == "testuser"
def test_get_user_not_found(self, user_service):
"""测试用户不存在"""
# 执行并验证
with pytest.raises(UserNotFoundError):
user_service.get_user(999)
def test_create_user_success(self, user_service):
"""测试成功创建用户"""
# 准备
request = UserCreateRequest(
username="newuser",
email="newuser@example.com",
password="password123"
)
# 执行
result = user_service.create_user(request)
# 验证
assert result.id is not None
assert result.username == "newuser"
def test_create_user_duplicate_username(self, user_service, sample_user):
"""测试创建用户时用户名重复"""
# 准备
request = UserCreateRequest(
username="testuser", # 已存在
email="different@example.com",
password="password123"
)
# 执行并验证
with pytest.raises(ValidationError) as exc_info:
user_service.create_user(request)
assert "用户名已存在" in str(exc_info.value)
@patch('app.services.user_service.UserService._hash_password')
def test_password_hashing(self, mock_hash, user_service):
"""测试密码哈希"""
# 设置mock
mock_hash.return_value = "hashed_password"
# 执行
user_service.create_user(UserCreateRequest(
username="test",
email="test@example.com",
password="password123"
))
# 验证
mock_hash.assert_called_once_with("password123")
4.4 代码自审检查清单
## 代码自审清单
### 功能性
- [ ] 代码实现了需求文档中的所有功能
- [ ] 边界条件已处理（空值、最大值、最小值）
- [ ] 异常情况已处理
- [ ] 业务逻辑正确
### 代码质量
- [ ] 命名清晰准确
- [ ] 逻辑简洁明了
- [ ] 无重复代码
- [ ] 函数长度适中（<50行）
- [ ] 类长度适中（<300行）
- [ ] 嵌套层次合理（<4层）
### 规范性
- [ ] 符合PEP 8规范
- [ ] 有类型注解
- [ ] 有docstring
- [ ] 导入顺序正确
- [ ] 无注释代码
- [ ] 无调试代码（print等）
### 测试
- [ ] 有对应的单元测试
- [ ] 测试覆盖主要逻辑
- [ ] 测试通过
### 安全
- [ ] 无SQL注入风险
- [ ] 无XSS风险
- [ ] 敏感数据已处理
- [ ] 输入已验证
- [ ] 错误信息不泄露敏感信息
### 性能
- [ ] 无明显的性能问题
- [ ] 数据库查询已优化
- [ ] 无不必要的循环
- [ ] 无内存泄漏风险
### 文档
- [ ] 复杂逻辑有注释
- [ ] 公开API有docstring
- [ ] 示例代码准确
4.5 阶段输出
| 输出物 | 说明 |
|---|---|
| 源代码 | 符合规范的代码 |
| 单元测试 | 测试用例代码 |
| 开发文档 | 必要的技术文档 |
| 技术债务记录 | 临时方案和待优化项 |
4.6 阶段验收标准
## 阶段三验收清单
### 功能完整性
- [ ] 所有计划功能已实现
- [ ] 所有接口已开发
- [ ] 数据库已创建
### 代码质量
- [ ] 代码符合规范
- [ ] 代码审查通过率 > 90%
- [ ] 代码复杂度符合要求
- [ ] 无严重技术债务
### 测试覆盖
- [ ] 单元测试覆盖率 > 70%
- [ ] 核心功能覆盖率 > 80%
- [ ] 所有测试通过
### 文档完整性
- [ ] API文档已完成
- [ ] 关键功能有使用说明
- [ ] 技术文档已更新
5. 阶段四：测试阶段
5.1 阶段目标
┌─────────────────────────────────────────────────────────────────────────────────────┐
│ 阶段四目标 │
├─────────────────────────────────────────────────────────────────────────────────────┤
│ ✓ 单元测试完成 │
│ ✓ 集成测试完成 │
│ ✓ 系统测试完成 │
│ ✓ 性能测试完成 │
│ ✓ 安全测试完成 │
└─────────────────────────────────────────────────────────────────────────────────────┘
5.2 阶段输入
| 输入物 | 来源 |
|---|---|
| 源代码 | 阶段三输出 |
| 单元测试 | 阶段三输出 |
| 需求规格 | 阶段一输出 |
| 设计文档 | 阶段二输出 |
5.3 详细流程
5.3.1 测试类型及流程
测试金字塔：
/\
/ \
/ E2E \ 10% - 端到端测试
/--------\
/ \
/ 集成 \ 30% - 集成测试
/--------------\
/ \
/ 单元 \ 60% - 单元测试
/----------------------\
单元测试详细说明：
"""
单元测试示例
"""
import pytest
from app.services.calculator import Calculator
from app.models.order import Order
class TestCalculator:
"""计算器测试类"""
def setup_method(self):
"""每个测试方法前执行"""
self.calculator = Calculator()
def teardown_method(self):
"""每个测试方法后执行"""
del self.calculator
def test_add_positive_numbers(self):
"""测试正数加法"""
# 执行
result = self.calculator.add(1, 2)
# 验证
assert result == 3
assert result > 0
def test_add_negative_numbers(self):
"""测试负数加法"""
result = self.calculator.add(-1, -2)
assert result == -3
def test_divide_by_zero_raises_error(self):
"""测试除以零抛出异常"""
# 执行并验证
with pytest.raises(ZeroDivisionError):
self.calculator.divide(10, 0)
def test_divide_returns_correct_result(self):
"""测试除法返回正确结果"""
result = self.calculator.divide(10, 2)
assert result == 5
@pytest.mark.parametrize("a,b,expected", [
(1, 2, 3),
(0, 0, 0),
(-1, 1, 0),
(100, 200, 300),
])
def test_add_parametrized(self, a, b, expected):
"""参数化加法测试"""
result = self.calculator.add(a, b)
assert result == expected
集成测试详细说明：
"""
集成测试示例
"""
import pytest
from fastapi.testclient import TestClient
from app.main import app
from app.database import get_db
from app.models.user import User
class TestUserAPI:
"""用户API集成测试"""
@pytest.fixture
def client(self):
"""测试客户端"""
return TestClient(app)
@pytest.fixture
def test_user(self, db_session):
"""测试用户"""
user = User(
id=1,
username="testuser",
email="test@example.com"
)
db_session.add(user)
db_session.commit()
return user
def test_get_user_by_id(self, client, test_user):
"""测试通过ID获取用户"""
# 执行
response = client.get(f"/api/users/{test_user.id}")
# 验证
assert response.status_code == 200
data = response.json()
assert data["success"] is True
assert data["data"]["username"] == "testuser"
def test_get_user_not_found(self, client):
"""测试用户不存在"""
# 执行
response = client.get("/api/users/999")
# 验证
assert response.status_code == 404
data = response.json()
assert data["success"] is False
def test_create_user_success(self, client):
"""测试创建用户成功"""
# 执行
response = client.post("/api/users", json={
"username": "newuser",
"email": "newuser@example.com",
"password": "password123"
})
# 验证
assert response.status_code == 201
data = response.json()
assert data["success"] is True
assert data["data"]["username"] == "newuser"
def test_create_user_duplicate_username(self, client):
"""测试创建用户时用户名重复"""
# 先创建一个用户
client.post("/api/users", json={
"username": "testuser",
"email": "test1@example.com",
"password": "password123"
})
# 再创建同用户名的用户
response = client.post("/api/users", json={
"username": "testuser",
"email": "test2@example.com",
"password": "password123"
})
# 验证
assert response.status_code == 409 # Conflict
data = response.json()
assert "用户名已存在" in data["error"]
系统测试详细说明：
"""
系统测试示例
"""
import pytest
from playwright.sync_api import Page, expect
class TestUserWorkflow:
"""用户工作流系统测试"""
def test_complete_user_purchase_flow(self, page: Page):
"""测试完整的用户购买流程"""
# 1. 登录
page.goto("https://example.com/login")
page.fill("input[name='username']", "testuser")
page.fill("input[name='password']", "password123")
page.click("button[type='submit']")
# 验证登录成功
expect(page).to_have_url("https://example.com/dashboard")
# 2. 浏览商品
page.goto("https://example.com/products")
# 验证页面加载
expect(page).to_have_title("商品列表")
# 3. 选择商品
page.click("text=iPhone 15 Pro")
# 验证商品详情页
expect(page).to_have_url("/products/iphone-15-pro")
# 4. 添加到购物车
page.click("button:has-text('加入购物车')")
# 验证添加成功
expect(page.locator(".cart-count")).to_have_text("1")
# 5. 查看购物车
page.click("text=购物车")
# 验证购物车页面
expect(page).to_have_url("/cart")
expect(page.locator(".cart-item")).to_have_count(1)
# 6. 结算
page.click("button:has-text('去结算')")
# 7. 填写收货信息
page.fill("input[name='address']", "北京市朝阳区")
page.fill("input[name='phone']", "13800138000")
# 8. 提交订单
page.click("button:has-text('提交订单')")
# 验证订单提交成功
expect(page).to_have_url("/orders/[0-9]+")
expect(page.locator("text=订单提交成功")).to_be_visible()
5.3.2 测试用例设计方法
等价类划分：
输入：用户年龄
有效等价类：
- 0-17岁（未成年）
- 18-60岁（成年）
- 60岁以上（老年）
无效等价类：
- 负数
- 非数字
- 超大数（如150岁以上）
测试用例：
- 测试16岁（边界值）
- 测试18岁（边界值）
- 测试60岁（边界值）
- 测试61岁（边界值）
- 测试-1岁（无效）
- 测试"abc"（无效）
边界值分析：
输入范围：1-100
边界值：1, 2, 99, 100
测试用例：
- 测试1（最小值）
- 测试2（最小值+1）
- 测试99（最大值-1）
- 测试100（最大值）
- 测试0（小于最小值）
- 测试101（大于最大值）
5.3.3 性能测试
性能测试类型：
负载测试:
目标: 验证系统在预期负载下的性能
方法: 逐步增加用户数，观察响应时间
指标: 响应时间、吞吐量、资源利用率
压力测试:
目标: 找出系统的性能瓶颈和极限
方法: 持续增加负载直到系统崩溃
指标: 最大并发数、崩溃点
峰值测试:
目标: 验证系统在突发高负载下的表现
方法: 模拟突发流量
指标: 系统恢复能力、数据丢失情况
持久性测试:
目标: 验证系统长时间运行的稳定性
方法: 持续运行24小时以上
指标: 内存泄漏、性能下降
性能测试工具：
"""
性能测试示例
"""
import time
import statistics
import pytest
from locust import HttpUser, task, between
class QuickTestUser(HttpUser):
"""快速测试用户"""
wait_time = between(1, 3)
@task
def view_products(self):
self.client.get("/api/products")
@task(3)
def view_product(self):
self.client.get("/api/products/1")
class PerformanceTest:
"""性能测试"""
def test_api_response_time(self):
"""测试API响应时间"""
times = []
for _ in range(100):
start = time.time()
response = self.client.get("/api/users")
end = time.time()
assert response.status_code == 200
times.append(end - start)
# 验证平均响应时间 < 100ms
avg = statistics.mean(times)
p95 = statistics.quantiles(times, n=20)[18] # 95th percentile
assert avg < 0.1, f"平均响应时间 {avg*1000}ms 超过100ms"
assert p95 < 0.2, f"P95响应时间 {p95*1000}ms 超过200ms"
def test_concurrent_users(self):
"""测试并发用户"""
import threading
results = []
errors = []
def worker():
try:
response = self.client.get("/api/users")
results.append(response.status_code)
except Exception as e:
errors.append(str(e))
threads = []
for _ in range(100):
t = threading.Thread(target=worker)
threads.append(t)
t.start()
for t in threads:
t.join()
# 验证99%的请求成功
success_rate = len([r for r in results if r == 200]) / len(results)
assert success_rate > 0.99, f"成功率 {success_rate*100}% 低于99%"
assert len(errors) == 0, f"有{len(errors)}个请求异常"
5.3.4 测试报告模板
# 测试报告
## 测试概述
- 测试时间: YYYY-MM-DD HH:MM
- 测试人员: xxx
- 测试版本: v1.0.0
- 测试环境: staging
## 测试结果汇总
| 测试类型 | 用例数 | 通过 | 失败 | 跳过 | 通过率 |
|----------|--------|------|------|------|--------|
| 单元测试 | 150 | 148 | 2 | 0 | 98.7% |
| 集成测试 | 50 | 48 | 2 | 0 | 96.0% |
| 系统测试 | 20 | 20 | 0 | 0 | 100% |
| 性能测试 | 10 | 9 | 1 | 0 | 90.0% |
| 安全测试 | 15 | 15 | 0 | 0 | 100% |
| **合计** | **245** | **240** | **5** | **0** | **98.0%** |
## 失败用例详情
### 单元测试
| 用例ID | 用例名称 | 失败原因 | 负任人 | 状态 |
|--------|----------|----------|--------|------|
| UT001 | test_skill_timeout | 超时设置不合理 | 张三 | 待修复 |
| UT002 | test_order_calc | 边界条件未处理 | 李四 | 待修复 |
### 集成测试
| 用例ID | 用例名称 | 失败原因 | 责任人 | 状态 |
|--------|----------|----------|--------|------|
| IT001 | test_payment_flow | 第三方接口异常 | 王五 | 待修复 |
| IT002 | test_notification | 通知服务未启动 | 赵六 | 待修复 |
### 性能测试
| 用例ID | 用例名称 | 结果 | 说明 |
|--------|----------|------|------|
| PT001 | test_api_response | 未通过 | P95响应时间220ms超过200ms |
## 覆盖率报告
| 模块 | 行覆盖率 | 分支覆盖率 | 函数覆盖率 |
|------|----------|------------|------------|
| app/services | 85.3% | 78.2% | 92.1% |
| app/api | 82.1% | 75.6% | 88.7% |
| app/models | 90.5% | 85.2% | 95.3% |
| **总计** | **85.0%** | **78.5%** | **91.2%** |
## 问题统计
| 严重程度 | 数量 | 占比 |
|----------|------|------|
| P0-严重 | 0 | 0% |
| P1-高 | 1 | 20% |
| P2-中 | 3 | 60% |
| P3-低 | 1 | 20% |
## 建议与结论
### 建议
1. 修复失败的5个用例
2. 优化API响应时间
3. 增加边界条件测试
### 结论
当前测试通过率98.0%，覆盖率85%，建议修复P1/P2问题后可以发布。
5.4 阶段输出
| 输出物 | 说明 |
|---|---|
| 测试用例 | 所有测试用例 |
| 测试报告 | 测试结果和覆盖率报告 |
| 缺陷报告 | 测试发现的缺陷清单 |
| 测试数据 | 测试用数据 |
5.5 阶段验收标准
## 阶段四验收清单
### 测试完整性
- [ ] 单元测试已完成
- [ ] 集成测试已完成
- [ ] 系统测试已完成
- [ ] 性能测试已完成
- [ ] 安全测试已完成
### 覆盖率要求
- [ ] 代码覆盖率 > 80%
- [ ] 核心功能覆盖率 > 90%
- [ ] 需求覆盖率 100%
### 缺陷处理
- [ ] P0/P1缺陷全部修复
- [ ] P2缺陷修复率 > 80%
- [ ] P3缺陷已记录
### 性能达标
- [ ] 响应时间达标
- [ ] 并发能力达标
- [ ] 资源使用合理
### 安全合规
- [ ] 无严重安全漏洞
- [ ] 符合安全规范
- [ ] 敏感数据保护到位
6. 阶段五：代码审查
6.1 阶段目标
┌─────────────────────────────────────────────────────────────────────────────────────┐
│ 阶段五目标 │
├─────────────────────────────────────────────────────────────────────────────────────┤
│ ✓ 代码审查完成 │
│ ✓ 审查意见已处理 │
│ ✓ 代码质量达标 │
│ ✓ 安全审查通过 │
└─────────────────────────────────────────────────────────────────────────────────────┘
6.2 阶段输入
| 输入物 | 来源 |
|---|---|
| 源代码 | 阶段三输出 |
| 单元测试 | 阶段三输出 |
| 开发规范 | 阶段一输出 |
6.3 详细流程
6.3.1 代码审查流程
┌─────────────────────────────────────────────────────────────────────────────────────┐
│ 代码审查流程 │
├─────────────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ 提交PR │───▶│ 自动检查 │───▶│ 指定审查者│───▶│ 人工审查 │───▶│ 审查完成 │ │
│ └─────────┘ └─────────┘ └─────────┘ └─────────┘ └─────────┘ │
│ │ │ │ │ │ │
│ ▼ ▼ ▼ ▼ ▼ │
│ • 代码提交 • Lint检查 • 分配审查者 • 代码检查 • 审查通过 │
│ • 提交说明 • 格式检查 • 通知审查者 • 提出意见 │ │
│ • 关联Issue • 单元测试 │ • 讨论优化方案 │ │
│ │ 代码覆盖率 │ │ │ │
│ │ 安全扫描 │ │ │ │
│ │
└─────────────────────────────────────────────────────────────────────────────────────┘
6.3.2 审查维度
功能性审查：
"""
功能性审查示例
"""
# ✅ 正确：功能实现正确
def calculate_discount(amount: float, level: int) -> float:
"""计算折扣金额
Args:
amount: 原价
level: 用户等级 (1-5)
Returns:
折扣金额
Raises:
ValueError: 参数无效
"""
if amount <= 0:
raise ValueError("金额必须大于0")
if level < 1 or level > 5:
raise ValueError("等级必须在1-5之间")
discount_rates = {1: 0.0, 2: 0.05, 3: 0.1, 4: 0.15, 5: 0.2}
return amount * discount_rates[level]
# ❌ 错误：功能实现错误
def calculate_discount(amount: float, level: int) -> float:
# BUG: 没有验证amount是否为负数
# BUG: 等级5的折扣率应该是0.2，不是0.25
discount_rates = {1: 0.0, 2: 0.05, 3: 0.1, 4: 0.15, 5: 0.25}
return amount * discount_rates.get(level, 0)
代码质量审查：
# ❌ 糟糕的代码
def d(x): return x*2 if x>0 else x/2
# ✅ 好的代码
def double_if_positive_else_halve(number: float) -> float:
"""如果是正数则翻倍，否则减半"""
return number * 2 if number > 0 else number / 2
安全审查：
# ❌ SQL注入风险
query = f"SELECT * FROM users WHERE name = '{name}'"
cursor.execute(query)
# ✅ 参数化查询
query = "SELECT * FROM users WHERE name = %s"
cursor.execute(query, (name,))
# ❌ 硬编码密钥
API_KEY = "sk-xxxxx"
# ✅ 环境变量
import os
API_KEY = os.getenv("API_KEY")
# ❌ 密码日志
logger.info(f"用户登录: user={username}, password={password}")
# ✅ 不记录敏感信息
logger.info(f"用户登录: user={username}")
性能审查：
# ❌ 低效：N+1查询问题
def get_users_with_orders(user_ids):
users = []
for user_id in user_ids:
user = db.query(f"SELECT * FROM users WHERE id = {user_id}")
orders = db.query(f"SELECT * FROM orders WHERE user_id = {user_id}")
users.append({"user": user, "orders": orders})
return users
# ✅ 高效：批量查询
def get_users_with_orders(user_ids):
users = db.query("SELECT * FROM users WHERE id IN (%s)"
% ','.join(map(str, user_ids))).all()
user_ids_list = [u.id for u in users]
orders = db.query("SELECT * FROM orders WHERE user_id IN (%s)"
% ','.join(map(str, user_ids_list))).all()
# 构建用户-订单映射
orders_by_user = {}
for order in orders:
orders_by_user.setdefault(order.user_id, []).append(order)
# 组装结果
return [
{"user": user, "orders": orders_by_user.get(user.id, [])}
for user in users
]
6.4 审查清单
## 代码审查清单
### 功能性
- [ ] 功能实现符合需求
- [ ] 边界条件处理正确
- [ ] 异常处理完善
- [ ] 业务逻辑正确
### 代码质量
- [ ] 命名清晰准确
- [ ] 逻辑简洁明了
- [ ] 无重复代码
- [ ] 适当抽象
- [ ] 符合DRY原则
### 测试
- [ ] 有单元测试
- [ ] 测试覆盖主要场景
- [ ] 测试通过
- [ ] 有边界测试
### 文档
- [ ] 有docstring
- [ ] 复杂逻辑有注释
- [ ] 公共API有文档
- [ ] 文档与代码一致
### 安全
- [ ] 无安全漏洞
- [ ] 输入验证
- [ ] 敏感数据保护
- [ ] 权限控制正确
### 性能
- [ ] 无明显性能问题
- [ ] 数据库查询优化
- [ ] 无内存泄漏
- [ ] 资源使用合理
### 规范性
- [ ] 符合编码规范
- [ ] 文件结构合理
- [ ] 导入顺序正确
- [ ] 无调试代码
6.5 审查意见模板
## 代码审查意见
### 总体评价
代码整体质量良好，功能实现正确。有几个小问题需要修复。
### 需要修改（必须）
1. **安全**: 第32行存在SQL注入风险
```python
# 当前代码
query = f"SELECT * FROM users WHERE name = '{name}'"
# 建议修改为
query = "SELECT * FROM users WHERE name = %s"
cursor.execute(query, (name,))
```
2. **性能**: 第45-50行循环中重复查询数据库
```python
# 当前代码：N次数据库查询
for user_id in user_ids:
user = db.query(f"SELECT * FROM users WHERE id = {user_id}")
# 建议修改为：批量查询
users = db.query("SELECT * FROM users WHERE id IN (%s)"
% ','.join(map(str, user_ids))).all()
```
### 建议改进（可选）
1. **命名**: 变量`d`名称不够清晰
```python
# 当前
def d(x): return x*2 if x>0 else x/2
# 建议
def double_if_positive_else_halve(number):
return number * 2 if number > 0 else number / 2
```
2. **文档**: 复杂逻辑缺少注释说明
```python
# 建议添加
# 使用折扣率表计算折扣金额
# 折扣率根据用户等级确定：1级无折扣，5级20%折扣
```
### 审查结论
- [ ] 需要修改后再次审查
- [ ] 建议改进已采纳，可以合并
### 审查统计
- 审查文件数: 5
- 审查行数: 350
- 发现问题: 7个
- 严重问题: 2个
- 一般问题: 5个
6.6 阶段输出
| 输出物 | 说明 |
|---|---|
| 审查记录 | 所有审查意见 |
| 修改后的代码 | 开发者修改后的代码 |
| 审查报告 | 审查统计和结论 |
6.7 阶段验收标准
## 阶段五验收清单
### 审查完成
- [ ] 所有PR已审查
- [ ] 审查意见已处理
- [ ] 无保留意见
### 质量达标
- [ ] 代码质量检查通过
- [ ] 安全审查通过
- [ ] 性能审查通过
### 合并条件
- [ ] CI检查全部通过
- [ ] 审查者批准合并
- [ ] 无遗留问题
7. 阶段六：集成阶段
7.1 阶段目标
┌─────────────────────────────────────────────────────────────────────────────────────┐
│ 阶段六目标 │
├─────────────────────────────────────────────────────────────────────────────────────┤
│ ✓ 组件集成完成 │
│ ✓ 接口联调完成 │
│ ✓ 环境部署完成 │
│ ✓ 冒烟测试完成 │
└─────────────────────────────────────────────────────────────────────────────────────┘
7.2 阶段输入
| 输入物 | 来源 |
|---|---|
| 各模块代码 | 阶段三输出 |
| 测试用例 | 阶段四输出 |
| 审查通过代码 | 阶段五输出 |
7.3 详细流程
7.3.1 集成策略
┌─────────────────────────────────────────────────────────────────────────────────────┐
│ 集成策略 │
├─────────────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────────────────────────────────────────────────────────────┐ │
│ │ 大爆炸集成 (不推荐) │ │
│ │ │ │
│ │ 所有模块 ───────────────▶ 一次性集成 ───────────────▶ 系统测试 │ │
│ │ │ │ │ │ │
│ │ ▼ ▼ ▼ │ │
│ │ 问题定位困难 集成问题多 发布延期 │ │
│ └──────────────────────────────────────────────────────────────────────┘ │
│ │
│ ┌──────────────────────────────────────────────────────────────────────┐ │
│ │ 持续集成 (推荐) │ │
│ │ │ │
│ │ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ │ │
│ │ │提交代码 │─▶│自动构建 │─▶│自动测试 │─▶│代码审查 │─▶│集成测试 │ │ │
│ │ └────────┘ └────────┘ └────────┘ └────────┘ └────────┘ │ │
│ │ │ │ │ │ │ │ │
│ │ ▼ ▼ ▼ ▼ ▼ │ │
│ │ 每次提交 构建成功 测试通过 审查通过 集成成功 │ │
│ │ 持续集成 即时反馈 快速定位 代码质量 系统稳定 │ │
│ └──────────────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────────────┘
7.3.2 CI/CD配置
GitHub Actions配置示例：
# .github/workflows/ci.yml
name: CI
on:
push:
branches: [main, develop]
pull_request:
branches: [main, develop]
jobs:
lint:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Set up Python
uses: actions/setup-python@v4
with:
python-version: '3.12'
cache: 'pip'
- name: Install dependencies
run: |
pip install -r requirements.txt
pip install flake8 black mypy
- name: Lint with flake8
run: |
flake8 . --count --select=E9,F63,F7,F401 --show-source --statistics
- name: Check code formatting with black
run: |
black --check .
- name: Type check with mypy
run: |
mypy . --ignore-missing-imports
test:
runs-on: ubuntu-latest
needs: lint
services:
postgres:
image: postgres:14
env:
POSTGRES_PASSWORD: postgres
POSTGRES_DB: test_db
options: >-
--health-cmd pg_isready
--interval 10s
--timeout 5s
--retries 5
steps:
- uses: actions/checkout@v3
- name: Set up Python
uses: actions/setup-python@v4
with:
python-version: '3.12'
cache: 'pip'
- name: Install dependencies
run: |
pip install -r requirements.txt
pip install pytest pytest-cov
- name: Run tests
run: |
pytest tests/ --cov=app --cov-report=xml --cov-report=html --junitxml=junit.xml
- name: Upload coverage to Codecov
uses: codecov/codecov-action@v3
with:
token: ${{ secrets.CODECOV_TOKEN }}
- name: Archive test results
uses: actions/upload-artifact@v3
if: always()
with:
name: test-results
path: |
htmlcov/
junit.xml
security:
runs-on: ubuntu-latest
needs: lint
steps:
- uses: actions/checkout@v3
- name: Run security scan
uses: PyCQA/bandit-action@v1
with:
python-version: '3.x'
- name: Upload security report
uses: actions/upload-artifact@v3
if: always()
with:
name: security-report
path: output/report.html
7.3.3 集成测试环境
Docker Compose配置：
# docker-compose.yml
version: '3.8'
services:
app:
build: .
ports:
- "8000:8000"
environment:
- DATABASE_URL=postgresql://postgres:5432/testdb
- REDIS_URL=redis:6379/0
depends_on:
- postgres
- redis
volumes:
- ./app:/app
postgres:
image: postgres:14
environment:
POSTGRES_DB: testdb
POSTGRES_PASSWORD: postgres
ports:
- "5432:5432"
volumes:
- postgres_data:/var/lib/postgresql/data
redis:
image: redis:7
ports:
- "6379:6379"
volumes:
postgres_data:
7.4 阶段输出
| 输出物 | 说明 |
|---|---|
| 集成报告 | 集成测试结果 |
| 环境配置 | 部署环境配置 |
| 部署脚本 | 自动化部署脚本 |
| 冒烟测试报告 | 冒烟测试结果 |
7.5 阶段验收标准
## 阶段六验收清单
### 集成完成
- [ ] 所有模块已集成
- [ ] 接口联调通过
- [ ] 数据流转正常
### 测试通过
- [ ] 集成测试通过
- [ ] 冒烟测试通过
- [ ] 无P0/P1缺陷
### 环境就绪
- [ ] 测试环境已部署
- [ ] 预发环境已部署
- [ ] 生产环境已准备
8. 阶段七：验收阶段
8.1 阶段目标
┌─────────────────────────────────────────────────────────────────────────────────────┐
│ 阶段七目标 │
├─────────────────────────────────────────────────────────────────────────────────────┤
│ ✓ 功能验收完成 │
│ ✓ 性能验收完成 │
│ ✓ 安全验收完成 │
│ ✓ 用户验收完成 │
└─────────────────────────────────────────────────────────────────────────────────────┘
8.2 详细流程
8.2.1 功能验收
功能验收流程:
验收准备:
- 准备验收环境
- 准备测试数据
- 准备验收用例
执行验收:
- 按验收用例执行
- 记录验收结果
- 收集问题
结果评估:
- 统计验收通过率
- 分析问题原因
- 制定修复计划
问题修复:
- 修复验收发现的问题
- 回归测试
- 重新验收
验收用例模板:
用例ID: TC001
用例名称: 用户登录功能验收
验收步骤:
1. 打开登录页面
2. 输入正确的用户名和密码
3. 点击登录按钮
预期结果:
- 登录成功
- 跳转到首页
- 显示用户信息
实际结果: [待填写]
状态: [通过/失败]
8.2.2 性能验收
性能验收指标:
响应时间:
- 首页加载: < 2秒 (P95)
- API响应: < 100ms (P95)
- 文件上传: < 5秒 (P95)
并发能力:
- 支持并发用户: > 1000
- TPS: > 1000
资源使用:
- CPU使用率: < 70%
- 内存使用: < 4GB
- 数据库连接数: < 100
稳定性:
- 系统可用性: > 99.5%
- 故障恢复时间: < 1小时
性能测试方法:
基准测试:
- 在标准负载下测试
- 记录基准数据
- 与基准数据对比
负载测试:
- 模拟预期负载
- 逐步增加负载
- 记录性能拐点
压力测试:
- 持续增加负载
- 找到系统极限
- 记录崩溃点
8.2.3 安全验收
安全验收清单:
认证授权:
- [ ] 用户名/密码认证正常
- [ ] Token认证正常
- [ ] 权限控制正确
- [ ] 会话超时正常
- [ ] 单点登录正常
输入验证:
[ ] SQL注入测试通过
[ ] XSS攻击测试通过
[ ] CSRF攻击测试通过
[ ] 文件上传验证通过
[ ] 命令注入测试通过
数据安全:
[ ] 敏感数据已加密
[ ] 日志不包含敏感信息
[ ] 备份数据已加密
[ ] 数据传输已加密
安全扫描:
[ ] 依赖漏洞扫描通过
[ ] 代码安全扫描通过
[ ] 网络安全扫描通过
8.2.4 用户验收测试 (UAT)
# UAT测试计划
## 测试环境
- 环境类型: 预发布环境
- 测试数据: 生产数据脱敏副本
- 测试设备: 标准测试设备
## 测试场景
### 场景1: 用户登录
**验收人**: 终端用户
**目标**: 验证用户登录功能
**步骤**:
1. 打开应用登录页面
2. 输入用户名和密码
3. 点击登录按钮
4. 验证登录结果
**验收标准**:
- 能成功登录
- 登录后跳转到正确页面
- 显示正确的用户信息
**结果**: □ 通过 □ 不通过
**备注**:
---
### 场景2: 核心业务流程
**验收人**: 业务代表
**验收标准**:
- 能完成完整业务流程
- 各环节数据正确
- 流程耗时在可接受范围内
8.3 阶段输出
| 输出物 | 说明 |
|---|---|
| 验收测试报告 | 所有验收结果 |
| 问题清单 | 需修复的问题 |
| 验收结论 | 是否通过验收 |
8.4 阶段验收标准
## 阶段七验收清单
### 功能验收
- [ ] 所有核心功能验收通过
- [ ] 边界情况验收通过
- [ ] 异常处理验收通过
### 性能验收
- [ ] 所有性能指标达标
- [ ] 性能测试报告通过
### 安全验收
- [ ] 安全测试全部通过
- [ ] 无严重安全漏洞
- [ ] 符合合规要求
### UAT验收
- [ ] 用户测试场景通过
- [ ] 用户满意度调查合格
- [ ] 用户签字确认
### 缺陷处理
- [ ] P0/P1缺陷全部修复
- [ ] P2缺陷修复率 > 80%
9. 阶段八：交付阶段
9.1 阶段目标
┌─────────────────────────────────────────────────────────────────────────────────────┐
│ 阶段八目标 │
├─────────────────────────────────────────────────────────────────────────────────────┤
│ ✓ 版本打包完成 │
│ ✓ 文档整理完成 │
│ ✓ 发布准备完成 │
│ ✓ 正式发布完成 │
└─────────────────────────────────────────────────────────────────────────────────────┘
9.2 详细流程
9.2.1 版本打包
# 版本打包流程
# 1. 更新版本号
echo "请输入版本号 (如: 1.0.0):"
read VERSION
# 更新__version__.py
sed -i "s/__version__ = .*/__version__ = \"$VERSION\"/" app/__init__.py
# 2. 更新CHANGELOG
cat >> CHANGELOG.md << EOF
## [$VERSION] - $(date +%Y-%m-%d)
### 新增
- 功能1
- 功能2
### 改进
- 改进1
- 改进2
### Bug修复
- 修复1
- 修复2
EOF
# 3. 构建发布包
python setup.py sdist bdist_wheel
# 4. 生成校验和
sha256sum dist/* > dist/checksums.txt
# 5. 签名（如需要）
gpg --detach-sign --local-user $GPG_KEY_ID dist/*
9.2.2 文档整理
文档清单：
必需文档:
- README.md: 项目介绍和快速开始
- CHANGELOG.md: 版本变更记录
- INSTALL.md: 安装指南
- UPGRADE.md: 升级指南
- API.md: API文档
可选文档:
- ARCHITECTURE.md: 架构文档
- DEVELOPMENT.md: 开发指南
- TROUBLESHOOTING.md: 故障排除
- CONTRIBUTING.md: 贡献指南
- LICENSE: 许可证文件
用户文档:
- 用户手册
- 快速入门指南
- 视频教程
- FAQ
9.2.3 发布流程
┌─────────────────────────────────────────────────────────────────────────────────────┐
│ 发布流程 │
├─────────────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ 创建标签 │───▶│ 构建包 │───▶│ 测试验证 │───▶│ 发布到仓库 │───▶│ 发布通知 │ │
│ └─────────┘ └─────────┘ └─────────┘ └─────────┘ └─────────┘ │
│ │ │ │ │ │ │
│ ▼ ▼ ▼ ▼ ▼ │
│ git tag build smoke test GitHub Release 邮件通知 │
│ v1.0.0 wheel/zip install PyPI release 发布文章 │
│ 安装验证 │
│ │
└─────────────────────────────────────────────────────────────────────────────────────┘
发布脚本示例：
#!/bin/bash
set -e
VERSION=$1
echo "=========================================="
echo "开始发布流程 v$VERSION"
echo "=========================================="
# 1. 运行所有测试
echo "步骤1: 运行测试"
pytest tests/ -v --cov=app
if [ $? -ne 0 ]; then
echo "测试失败，发布终止"
exit 1
fi
# 2. 代码检查
echo "步骤2: 代码检查"
flake8 app/
if [ $? -ne 0 ]; then
echo "代码检查失败，发布终止"
exit 1
fi
# 3. 构建包
echo "步骤3: 构建发布包"
python setup.py sdist bdist_wheel
# 4. 检查包
echo "步骤4: 检查包
twine check dist/*
# 5. 发布到GitHub
echo "步骤5: 发布到GitHub"
git tag -a v$VERSION -m "Release v$VERSION"
git push origin v$VERSION
# 6. 发布到PyPI（可选）
read -p "是否发布到PyPI? (y/n) " -n
if [ "$REPLY" = "y" ]; then
echo "步骤6: 发布到PyPI"
twine upload dist/*
fi
echo "=========================================="
echo "发布完成 v$VERSION"
echo "=========================================="
9.3 发布说明模板
# [项目名称] v[版本号] 发布说明
**发布日期**: YYYY-MM-DD
**代号**: [可选版本代号]
---
## 📊 发布概览
本次发布包含 [主要特性] 个新功能，[优化内容] 个优化，以及 [修复数量] 个bug修复。
---
## ✨ 新增功能
- 🎉 **[功能1]**: [简要描述]
- 功能详情
- 使用示例
- 🎉 **[功能2]**: [简要描述]
---
## 🚀 性能优化
- ⚡ [优化1]: 性能提升 [具体指标]
- ⚡ [优化2]: 内存占用减少 [具体指标]
---
## 🐛 Bug修复
- 🐛 **[修复1]**: [问题描述]
- 🐛 **[修复2]**: [问题描述]
---
## 🔧 改进
- 📝 **[改进1]**: [改进内容]
- 🔧 **[改进2]**: [改进内容]
---
## ⚠️ 破坏性变更
- ⚠️ **[变更1]**: [影响说明]
- 迁移指南: [迁移步骤]
---
## 📦 安装升级
### 新安装
```bash
pip install {project-name}=={version}
从旧版本升级
从源码安装
📚 文档更新
- ✅ [更新1]: API文档更新
- ✅ [更新2]: 使用指南更新
- ✅ [更新3]: 架构文档更新
🤝 贡献者
感谢以下贡献者参与本次版本开发: - @contributor1 - @contributor2
📈 下一步计划
💬 反馈与支持
- 问题反馈: GitHub Issues
- 功能建议: GitHub Discussions
- 邮件支持: support@example.com
⏭️ 版本历史
附录B：项目计划模板
附录C：代码审查清单
附录D：测试报告模板
附录E：发布说明模板
附录F：完整阶段检查清单
# 完整阶段检查清单
## 阶段一：规则制定
- [ ] 需求文档已完成
- [ ] 开发规则已发布
- [ ] 项目计划已确认
- [ ] 风险清单已制定
## 阶段二：设计阶段
- [ ] 架构设计已完成
- [ ] 接口设计已完成
- [ ] 数据库设计已完成
- [ ] 安全设计已完成
- [ ] 设计评审已通过
## 阶段三：开发阶段
- [ ] 所有功能已实现
- [ ] 代码符合规范
- [ ] 单元测试已完成
- [ ] 代码自审已完成
- [ ] 代码已提交
## 阶段四：测试阶段
- [ ] 单元测试已通过
- [ ] 集成测试已通过
- [ ] 系统测试已通过
- [ ] 性能测试已通过
- [ ] 安全测试已通过
## 阶段五：代码审查
- [ ] 代码审查已完成
- [ ] 审查意见已处理
- [ ] 审查批准合并
- [ ] CI检查全部通过
## 阶段六：集成阶段
- [ ] 组件集成完成
- [ ] 接口联调通过
- [ ] 环境部署完成
- [ ] 冒烟测试通过
## 阶段七：验收阶段
- [ ] 功能验收通过
- [ ] 性能验收通过
- [ ] 安全验收通过
- [ ] 用户验收通过
- [ ] 验收报告完成
## 阶段八：交付阶段
- [ ] 版本打包完成
- [ ] 文档整理完成
- [ ] 发布准备完成
- [ ] 正式发布完成
- [ ] 用户通知完成
## 阶段九：运维阶段
- [ ] 监控配置完成
- [ ] 告警配置完成
- [ ] 备份策略制定
- [ ] 回滚方案准备
文档版本: 2.0.0 最后更新: 2026-03-25 适用范围: 所有软件工程项目 使用说明: 本文档提供通用框架，项目可根据实际情况剪裁