# 测试方法论演进记录

> 本文档记录绩效模块测试体系从零到七层全覆盖的演进过程，
> 基于 2026-01 至 2026-03 共 14 份测试报告提炼。

---

## 阶段 1：纯集成测试（2026-01）

**做了什么**：基于文档 API 列表编写集成测试，79 个用例覆盖 107 个 API。

**能力边界**：只验证后端 API 是否合规，无法发现前后端集成问题。

**关键数字**：79 → 106 用例（01-15 到 01-16）

**教训**：测试用例全通过不代表系统没问题——集成测试绕过了前端代码，字段名错了根本测不出来。

---

## 阶段 2：集成 + E2E 双线（2026-03-15）

**做了什么**：在集成测试基础上引入 MCP E2E 测试，首次走完 10 个业务流。

**突破**：
- E2E 首次暴露了 6 个集成测试无法发现的 Bug（权限码不匹配、组织隔离缺失、状态转换后缺少自动计算等）
- 首次做 API 契约审计，发现 50+ 处前后端不一致
- 引入 cleanup helper 概念

**能力边界**：E2E 和集成测试之间缺少衔接层，很多问题本可以在更早阶段被拦截。

**关键发现**：权限配置和组织隔离是高频问题源。

---

## 阶段 3：五层方法论（2026-03-16）

**做了什么**：首次引入分层测试体系 L0a/L0b → L1 → L1.5 → L2。

**突破**：
- **契约校验脚本首次产生实际价值**——L0a 在 L1 之前拦截了 2 个 P0 Bug（calibration DTO 字段名不匹配、kpi assignment 缺字段）
- **L1.5 数据质量校验首次上线**——发现 360 模板数据被清理、Test Admin Org 无根部门
- 集成测试新增跨域链路用例（KPI 自评完成 → 360 自动激活）和级联影响用例（删指标 → 撤回已提交 KPI）

**方法论贡献**：
- "静态分析成本低、收益高"被验证——契约脚本在运行测试前就能拦截问题
- 跨域链路和级联影响是集成测试最有价值的覆盖区域

**教训**：9 个契约不匹配被标记为"设计差异不阻断"，但在下一阶段全部修复了——"设计差异"标签容易成为延迟修复的借口。

---

## 阶段 4：六层 → 七层（2026-03-17）

**做了什么**：新增 L0（页面清点）和 L0c（响应快照），形成完整七层体系。

**突破**：
- **L0 页面清点**发现 17 个页面中 2 个孤立（无导航入口），将"必测 API"从模糊的 107 个精确到 73 个
- **L0c 响应快照**实际发请求验证响应结构，52 端点覆盖
- L1 增至 127 测试，API 覆盖率 100%（以 L0 清单为基准）
- L1.5 清理 250 个残留组织

**能力边界**：同一天产出 4 份报告（five-layer/six-layer/full-test/e2e），报告结构和命名缺乏规范。在开发环境跑 E2E 严重受限——缺标准测试账号，多角色流程大面积跳过。

**方法论贡献**：
- L0 页面清点使测试范围有明确边界，避免"盲测"
- 七层递进执行（L0 → L0a/L0b → L0c → L1 → L1.5 → L2 → L3）框架成型
- 之前标为"设计差异"的 9 个契约不匹配在此阶段全部修复

**教训**：环境准备是 E2E 成败的关键，开发环境数据不可控是根本瓶颈。

---

## 阶段 5：环境标准化（2026-03-19）

**做了什么**：独立 Docker 测试环境上线（前端 3010/后端 3011/数据库 35432），经历四轮迭代。

**四轮迭代**：
- v1：锁文件问题阻断
- v2：种子数据丢失
- v3：Docker 方案上线
- v4：schema 复用 + 环境就绪矩阵

**突破**：
- 从 03-17 E2E 的大面积跳过，到 03-19 的 7 个 P0 流程中 6 个通过——独立环境效果立竿见影
- **环境就绪矩阵**标准化了 6 项前置检查（DB/schema/基础种子/模块种子/后端/前端）
- 首次使用"操作模式分类"（A 填表单/B 角色切换/C 状态推进/D 下拉选择/F 断言验证）量化 E2E 交互覆盖

**方法论贡献**：
- 环境就绪矩阵——任一项失败则阻断测试，避免"环境问题"反复浪费时间
- cleanupAllData 与模块种子的矛盾被识别：全局清理会清模块种子，需每次重新加载

**教训**：种子数据中的人事关系（manager-subordinate）是 E2E 测试的隐性前置条件，缺失时多角色流程直接失败。

---

## 阶段 6：Schema 重构后的回归验证（2026-03-20）

**做了什么**：在 feature/performance-docs-refactor 分支上重新执行七层全覆盖，验证 schema 重构后的系统完整性。

**突破**：
- P0 流程全部 7/7 通过，P1 完成 3/6
- L1 测试代码跟随 schema 重构大幅修改（移除已删除表引用、修正列名、修正状态码），证明测试作为"活文档"的价值

**暴露的问题**：
- 5 个 Bug：KPI 名称输入框 0 宽度、eval-comments 路由 404（重构删除未同步前端）、pending-dependencies 参数校验、团队 KPI 统计初始不准、AuthContext 报错
- schema 重构对测试代码冲击巨大：cleanup helper、辅助函数、断言都需要联动修改

**教训**：重构后前端 API 路径残留是高频问题（eval-comments → results/overall-comment 路由变更未传递到前端）。

---

## 被验证为有效的实践

| 实践 | 验证时间 | 证据 |
|------|---------|------|
| L0 页面清点驱动测试范围 | 03-17 | 发现 2 个孤立页面，精确了"必测 API"范围 |
| L0a/L0b 契约校验前置 | 03-16 | 多次在 L1 之前拦截字段不匹配 |
| L0c 响应快照 | 03-17 | 覆盖 52 端点，补上了"实际响应 vs 前端 interface"的缝隙 |
| L1.5 数据质量校验 | 03-16 | 发现种子数据缺失、模板被清理等隐性问题 |
| 独立测试环境 | 03-19 | 从大面积跳过到全流程通过 |
| 环境就绪矩阵 | 03-19 | 标准化前置检查，v4 起再无环境问题浪费时间 |
| 七层递进阻断 | 03-17+ | "前一层未通过则后一层无意义"多次避免了无效测试 |

## 反复出现最终被固化为规范的问题

| 问题模式 | 出现次数 | 固化位置 |
|---------|---------|---------|
| 前后端契约不一致 | 6+ | CI 门禁 `quality-gates.yml` + `testing-standards.md` §1.8 |
| cleanup helper 遗漏新表 | 4+ | `testing-standards.md` §1.95 + `database-main` SKILL 检查清单 |
| 测试数据/种子数据不完整 | 5+ | `database-architecture.md` 种子数据管理章节 |
| 权限配置不同步 | 4+ | L1 多角色权限矩阵测试 |
| 测试环境不就绪 | 3+ | `testing-standards.md` §1.7 环境就绪矩阵 |

## 仍需改进的方向

1. **L3 人工验收从未执行** — 所有报告的 L3 都是"待执行"
2. **Bug 追踪无闭环** — Bug 在报告中记录，但后续报告不一定回溯确认已修复
3. **自动化脚本缺口** — 环境就绪检查、schema vs cleanup helper 同步检查尚未脚本化

---

## 数字演进

```
用例数:  79 → 106 → 118 → 127 → 131 → 110（schema 重构后精简）
API 覆盖: 模糊 107 → 精确 73（L0 驱动）→ 100%
E2E 流程: 0 → 10 → 6（环境受限）→ 7 P0 → 13（7 P0 + 6 P1）
测试层数: 1 → 2 → 5 → 7
```