Phase 4: 测试 + 迭代

目标：用 AI 建立测试体系，然后基于反馈持续改进产品。

预计时间：1-1.5 小时

前置：Phase 3 的可运行代码

工具：Claude Code（主力）

为什么测试和迭代放在一起

因为它们是一个循环：

开发 → 测试 → 发现问题 → 修复 → 测试
  ↑                                    ↓
  ← ← ← 新需求 ← 用户反馈 ← 上线 ← ←

测试保证”现在没问题”，迭代保证”未来能进化”。AI 在两个环节都能大幅提效。

AI 参与度

环节	你做	AI 做
测试用例设计	补充业务边界场景	生成测试代码
覆盖率分析	判断哪些需要补	分析报告 + 补测试
安全检查	确认修复优先级	扫描 + 报告
需求变更	决定做不做	影响分析
重构	确认方案	分析 + 执行

---

Part A: 测试

4.1 用 AI 生成测试用例

方法论

AI 生成测试的核心技巧：不要说”帮我写测试”，要告诉 AI 测什么、边界在哪、用什么框架。

三种测试，AI 都能生成：

类型	测什么	输入给 AI 的内容	框架
单元测试	单个函数的逻辑	函数代码 + 边界条件	Go testing
集成测试	API 端到端	API 设计 + 数据模型	httptest + testDB
E2E 测试	用户完整操作流程	用户故事	Playwright

实操：单元测试

场景：测试任务状态变更逻辑（只允许特定的状态转换）

请为以下任务状态变更函数写单元测试。

## 函数代码
[粘贴状态变更函数]

## 状态转换规则
- 待办 → 进行中 ✅
- 进行中 → 测试中 ✅
- 测试中 → 已完成 ✅
- 测试中 → 进行中 ✅（打回）
- 已完成 → 待办 ❌（不允许倒退）
- 任意 → 已取消 ✅

## 要求
- 使用 Go 的 table-driven test 格式
- 覆盖所有合法转换（正向）
- 覆盖所有非法转换（反向）
- 覆盖边界情况：空状态、不存在的状态值

实操：集成测试

场景：测试创建任务 API

请为 POST /api/projects/:id/tasks 写集成测试。

## API 行为
- 需要认证（JWT）
- 验证项目存在
- 验证用户是项目成员
- 创建任务并返回

## 测试用例要求
- 正常创建（200）
- 未认证（401）
- 项目不存在（404）
- 非项目成员（403）
- 缺少必填字段（400）
- 分配人不是项目成员（400）

## 技术要求
- 使用 httptest
- 使用测试数据库（不是 mock）
- 每个测试用例前清理数据
- 参考项目中已有的测试结构

实操：E2E 测试

场景：测试完整的看板操作流程

请用 Playwright 写一个 E2E 测试，测试以下用户故事：

## 用户故事
作为项目成员，我想在看板上管理任务。

## 测试步骤
1. 登录系统
2. 进入"测试项目"
3. 在"待办"列创建新任务（标题："完成用户模块"）
4. 验证任务出现在"待办"列
5. 将任务状态改为"进行中"
6. 验证任务出现在"进行中"列
7. 将任务状态改为"已完成"
8. 验证任务出现在"已完成"列

## 技术要求
- 使用 Playwright
- 使用 Page Object 模式
- 包含截图步骤（每次状态变更后截图）

审查要点

AI 生成的测试常见问题：

• 有没有漏掉异常路径？（AI 倾向于只测 happy path）
• 测试之间有没有依赖？（一个测试的数据影响另一个）
• 测试数据是否清理？（避免测试间污染）
• 断言是否足够具体？（assert(resp.StatusCode == 200) 不够，还要检查响应体）

更多测试模式参考 项目实战 - 阶段 7: 测试。

---

4.2 用 AI 分析测试覆盖率

方法论

测试不是写得越多越好，而是要覆盖关键路径。用覆盖率报告找到盲区，让 AI 针对性补测试。

实操

Step 1：生成覆盖率报告

# Go 后端
cd server && go test ./... -coverprofile=coverage.out
go tool cover -func=coverage.out

Step 2：让 AI 分析并补测试

以下是测试覆盖率报告，请分析并补充测试。

[粘贴 coverage.out 输出]

## 要求
1. 找出覆盖率最低的 3 个文件
2. 分析这些文件中未覆盖的代码路径
3. 为最关键的未覆盖路径生成测试用例
4. 关键 = 涉及数据修改或权限校验的代码

产出

• 覆盖率分析报告
• 新增的测试用例

---

4.3 用 AI 做安全检查

方法论

在功能开发完成后、上线前，让 AI 做一次安全扫描。核心是用 OWASP Top 10 作为检查框架。

实操

请对项目管理工具做一次安全审查，按 OWASP Top 10 逐项检查。

## 重点关注
1. SQL 注入：所有数据库查询是否用了参数化？
2. XSS：用户输入（任务标题、描述）在前端渲染时是否转义？
3. 认证：JWT 过期时间合理吗？有没有刷新机制？
4. 权限：非项目成员能不能通过直接调 API 访问数据？
5. CSRF：状态修改接口有 CSRF 防护吗？

## 输出格式
每一项：
- 风险等级（高/中/低）
- 当前状态（安全 ✅ / 有风险 ⚠️ / 存在漏洞 🚨）
- 具体问题描述
- 修复建议（附代码）

审查要点

AI 的安全审查结果需要你判断：

• 10 人内部工具，某些风险可以接受（如 CSRF 对内部工具威胁较低）
• 但 SQL 注入和权限校验必须修复，无论规模大小
• 先修高风险，低风险的放到后续迭代

更多安全模式参考 项目实战 - 阶段 6: 安全加固 和 代码审查清单。

---

Part B: 迭代

4.4 用 AI 做需求变更分析

方法论

产品上线后，需求变更是常态。关键不是”做不做”，而是”做了会影响什么”。让 AI 帮你做影响分析，你再决策。

实操

场景：老板说”加个甘特图”。

老板要在项目管理工具中加一个甘特图功能。请做影响分析。

## 当前系统
- 数据模型：[粘贴当前 schema 或让 AI 读项目文件]
- 已有功能：项目 CRUD、任务 CRUD、看板视图、成员管理

## 请分析
1. 数据模型需要改吗？（任务需要新增哪些字段？）
2. 需要新增哪些 API？
3. 前端需要新增/修改哪些页面？
4. 有没有破坏性变更？（改了现有接口的返回格式？）
5. 预估工作量（小/中/大）
6. 建议的实施方案（分几步做？先做什么？）

审查要点

• AI 是否低估了工作量？（甘特图的时间轴交互比看起来复杂得多）
• 是否有更简单的替代方案？（也许一个时间线视图就够了）
• 破坏性变更是否可以避免？（新增字段比修改字段安全）

产出

一份 影响分析报告 + 实施方案。

---

4.5 用 AI 做重构

方法论

代码随着功能增加会变乱——这是正常的。重构的时机是：你感觉”加新功能越来越费劲”。

核心原则：先分析再动手，小步重构，每步验证。

实操

Step 1：让 AI 分析代码结构

请分析项目管理工具的代码结构，找出需要重构的地方。

## 关注点
1. 重复代码：有没有多个地方写了相似的逻辑？
2. 函数过长：有没有超过 50 行的函数？
3. 职责不清：有没有一个文件做了太多事？
4. 错误处理：是否统一？有没有漏掉错误检查？

## 输出
- 问题清单（按严重程度排序）
- 每个问题的重构建议
- 建议的重构顺序（先改哪个影响最小、收益最大？）

Step 2：分步执行

选择最重要的 1-2 个重构点，让 AI 分步执行：

请执行重构方案 #1：提取通用的分页查询逻辑。

## 要求
- 不改变任何 API 的输入输出行为
- 重构完成后所有现有测试必须通过
- 每一步改完告诉我需要验证什么

审查要点

• 重构前后行为一致（测试全过）
• 没有引入新 Bug
• 代码确实变简单了（不是换了一种复杂方式）

---

4.6 用 AI 做性能优化

方法论

性能优化的顺序：量化 → 定位 → 优化 → 验证。不要凭感觉优化。

实操

Step 1：量化

# 测量 API 响应时间
curl -w "\n%{time_total}s\n" http://localhost:8080/api/projects/1/tasks

# 或者用 hey 做压测（10 人工具不需要高并发，但可以发现慢查询）
hey -n 100 -c 5 http://localhost:8080/api/projects/1/tasks

Step 2：让 AI 分析

以下 API 响应较慢（平均 800ms，期望 < 200ms）。

API：GET /api/projects/1/tasks（获取项目下所有任务 + 分配人信息）

请分析可能的原因：
1. 检查 SQL 查询（是否有 N+1 问题？）
2. 检查是否缺少索引
3. 检查是否做了不必要的数据加载

[粘贴相关 handler 代码]

Step 3：验证优化效果

# 优化后再次测量
curl -w "\n%{time_total}s\n" http://localhost:8080/api/projects/1/tasks

---

全链路回顾

走完 4 个 Phase，你用 AI 完成了一个项目的完整开发流程：

Phase 1              Phase 2           Phase 3            Phase 4
一句话需求      →    设计文档      →   可运行的代码    →  有测试保障的产品
                                                          ↓
                                                     用户反馈
                                                          ↓
                                                     Phase 4.4-4.6
                                                     需求变更/重构/优化
                                                          ↓
                                                     回到 Phase 1（新功能）

阶段	你的核心工作	AI 的核心工作	关键产出
需求分析	回答关键问题、做决策	发散需求、结构化分析	需求文档
设计	审核模型和 API	生成 Schema、架构图、原型	设计文档
开发	验证功能、判断方案	写代码、调试、审查	可运行的代码
测试	补充业务场景、确认修复	生成测试、分析覆盖率	测试套件
迭代	决定方向、确认方案	影响分析、重构、优化	改进后的产品

常见陷阱

陷阱	症状	对策
只测 happy path	AI 生成的测试全是正常场景	Prompt 中明确要求测异常路径
过度优化	10 人工具花 2 天优化到 10ms	先定性能目标，达标就停
重构改太多	一次重构改了 20 个文件	小步重构，每步不超过 3 个文件
跳过影响分析	新需求直接开始写代码	先跑 4.4，5 分钟省 5 小时
安全检查只做一次	上线前查一次就不管了	每次加新功能后再查一次认证和权限

Mini Exercise

基于 Phase 3 实现的代码，完成以下任务：

1. ✅ 为任务状态变更写单元测试（4.1）
2. ✅ 为创建任务 API 写集成测试（4.1）
3. ✅ 跑覆盖率报告，让 AI 补测试到 60%+（4.2）
4. ✅ 做一次安全检查，修复高风险项（4.3）
5. ✅ 模拟一个需求变更（如”加截止日期提醒”），走影响分析流程（4.4）