# 开发 ↔ 测试 交接模板

> 场景：开发用 AI 生成代码后，交付给测试时的标准。核心矛盾——AI 写的代码快，但**测试若也由同一个 AI 闭环，会写出"验证错误逻辑"的测试（全绿但全错）**。

## 一、开发交付给测试的清单（DoD）
开发提测前，必须齐备：
- [ ] 代码已过人工审查（`git diff` 逐行过眼，AI 产出不盲合）
- [ ] 自测通过：核心路径 + 边界情况，附自测记录
- [ ] 影响范围说明：本次改动涉及哪些模块 / 接口（有代码图谱的跑 `detect_changes`，没有的用 grep 列调用方）
- [ ] 变更对应的 spec / 需求链接（可测试的行为规格，不只是口头描述）
- [ ] 已知风险与回滚方案

## 二、防偷改测试（关键）
- **铁律：不让同一个 AI（或同一次会话）既写实现又写测试**。AI 会为了让测试通过，写出验证错误逻辑的测试——全绿但实际没测到东西。
- 测试由**独立的人 / 独立的 AI 会话**编写，基于 spec（预期行为）而非基于实现代码。
- 关键场景的测试用 **Hook 强制**（提交前必须跑测试 + 覆盖率门槛），不依赖自觉。

## 三、测试反馈给开发
- 缺陷附**可复现步骤** + 预期 / 实际差异（基于 spec，非"感觉不对"）
- AI 辅助复现：录制操作 → AI 生成复现脚本（见 [autotest](https://gitlab.21tb.com/eln/autotest)，Playwright+Python+Flask UI 自动化）
- 缺陷分类标注是否"AI 生成代码引入"（喂给 [ai-code-ratio](https://gitlab.21tb.com/sa/ai-code-ratio) 做质量度量）

## 四、检查清单
- [ ] 交付物齐全（代码 / 自测 / 影响说明 / spec / 风险）
- [ ] 测试与实现分离编写（防偷改）
- [ ] 关键测试有 Hook 强制
- [ ] 缺陷反馈基于 spec + 可复现

## 五、常见坑
- ❌ 开发让 AI 顺手把测试也写了（全绿但没测到 bug）
- ❌ 提测只给代码，不给影响范围（测试漏测关联模块）
- ❌ 缺陷反馈靠口头"这功能不对"（无法复现、来回扯皮）