# 外包测试与修复任务书（2026-02-22 批次）

> 生效日期：2026-02-22
> 执行周期：4 周（稳态迭代）
> 适用团队：外包测试与开发团队、内部验收团队
> 环境边界：仅开发环境 + 脱敏测试数据（禁止生产权限）

---

## 1. 背景与目标

上一轮外包修复已通过基础审查，但系统仍需持续做潜在问题扫描、防复发回归和修复闭环。

本任务书目标：

1. 建立可持续的“发现问题 -> 修复 -> 回归 -> 验收”流程。
2. 用强门禁拦截逻辑回归与脏数据崩溃类问题。
3. 把外包交付标准固化为可检查、可追责、可复盘的文档化流程。

---

## 2. 范围与边界

### 2.1 本轮范围

1. 逻辑正确性：`Policy / Regime / Signal / Audit / Backtest`
2. 健壮性：空值、非法值、类型错误、边界条件
3. 联动一致性：模板、路由、API 调用契约
4. 防复发：guardrail 回归集维护与扩展
5. 文档交付：缺陷单、修复说明、回归报告、周报

### 2.2 明确不在范围

1. 生产环境排障与生产数据直连分析
2. 未经批准的架构重构和大规模重命名
3. 与本轮缺陷无关的功能开发

---

## 3. 角色与职责

### 3.1 外包团队职责

1. 主动测试发现问题并登记缺陷单。
2. 提交修复代码，补齐对应测试。
3. 执行模块回归与关键回归集。
4. 提交每周进展与风险清单。

### 3.2 内部团队职责

1. 缺陷优先级裁决（P0/P1/P2）。
2. 抽检外包提交质量。
3. 按门禁规则决定是否放行。
4. 维护最终验收结论与批次复盘。

---

## 4. 四周执行节奏

### Week 1：基线盘点与建账

1. 跑通关键回归与 guardrail。
2. 形成本批次缺陷台账（含优先级和归属模块）。
3. 输出《Week1 缺陷基线报告》。

### Week 2：高优先级修复

1. 优先完成 P0/P1 修复。
2. 每个修复必须配套测试与回归证据。
3. 输出《Week2 修复与回归报告》。

### Week 3：跨模块联调

1. 聚焦跨模块调用链路（页面 -> API -> 用例 -> 仓储）。
2. 处理复发问题和联动类缺陷。
3. 输出《Week3 联调回归报告》。

### Week 4：收口与验收

1. 清零 P0，压降 P1。
2. 完成全量验收回归与交付归档。
3. 输出《批次验收报告》。

---

## 5. 任务包拆分（并行执行）

### 任务包 A：逻辑正确性回归

1. 覆盖关键业务分支与失败分支。
2. 重点检查配置生效、状态流转、结果一致性。

### 任务包 B：健壮性与脏数据

1. 对外部输入统一做安全解析。
2. 必测 `None`、`""`、`"N/A"`、非法类型。

### 任务包 C：页面/路由/API 一致性

1. 页面调用路径与后端 URL 名称一致。
2. API 字段结构和前端解析一致。

### 任务包 D：Guardrail 防复发

1. 不允许移除既有 guardrail。
2. 新发现高风险问题必须补对应 guardrail 用例。

### 任务包 E：文档与交付物

1. 每单必须有“问题-修复-验证”闭环记录。
2. 每周固定提交周报和风险清单。

---

## 6. 强门禁规则（不满足即驳回）

1. `python manage.py check` 必须通过。
2. 关键回归集必须通过。
3. Guardrail 回归集必须通过。
4. 涉及模板/路由/API 的改动必须附对照表。
5. 涉及解析或计算逻辑的改动必须附脏数据/边界值测试。

---

## 7. 单缺陷 DoD（Definition of Done）

每个缺陷单必须同时满足：

1. 缺陷描述完整：复现步骤、期望、实际、影响范围、优先级。
2. 修复提交合规：单目标提交，不混入无关改动。
3. 测试完整：新增或更新测试并通过。
4. 回归完整：提供本模块 + 关键集的执行结果。
5. 风险可控：写明回滚方案和残余风险。

---

## 8. 提交与分支规范

1. 分支命名：`outsource/<module>/<ticket-id>-<short-desc>`
2. 提交类型分离：`bugfix`、`refactor`、`docs`、`migration` 不混合。
3. Commit 消息模板：`<type>: <问题> | <修复点> | <验证命令>`
4. PR 描述必须包含：
   - 问题根因
   - 修复方案
   - 验证命令与结果摘要
   - 影响范围与回滚方案

---

## 9. 验收与评分机制

### 9.1 批次放行条件

1. P0 必须全部关闭。
2. 强门禁全绿。
3. 文档和证据齐全。

### 9.2 质量评分（周度）

1. 回归通过率（目标 100%）
2. 缺陷复发率（越低越好）
3. 提交合规率（单目标提交比例）
4. 交付完整率（模板与证据齐全比例）

---

## 10. 升级与阻塞处理

1. P0：当日升级，24 小时内提交临时止血方案，72 小时内提交正式修复。
2. 阻塞项分类：
   - 环境阻塞
   - 数据阻塞
   - 需求定义阻塞
3. 所有阻塞项必须单独建单，不得口头挂起。

---

## 11. 本批次必跑命令

```bash
python manage.py check
```

```bash
pytest -q tests/guardrails/test_logic_guardrails.py tests/integration/policy/test_policy_integration.py tests/unit/policy/test_fetch_rss_use_case.py tests/unit/regime/test_config_threshold_regression.py
```

说明：

1. 外包可在各模块补充回归命令，但不得替代上述必跑命令。
2. 任一必跑命令失败，该批次不可申请放行。

---

## 12. 附录模板

### 12.1 缺陷单模板

```markdown
标题：
模块：
优先级：P0/P1/P2
环境：dev/test

复现步骤：
1.
2.
3.

期望结果：
实际结果：
影响范围：
根因分析：
修复方案：
验证命令：
验证结果：
残余风险：
```

### 12.2 PR 检查清单模板

```markdown
- [ ] 单目标提交（未混入无关改动）
- [ ] 已补充/更新测试
- [ ] `python manage.py check` 通过
- [ ] 必跑回归命令通过
- [ ] 已附影响范围和回滚方案
```

### 12.3 周报模板

```markdown
周次：
新增缺陷数：
关闭缺陷数：
P0/P1 状态：
主要修复项：
回归结果摘要：
复发问题：
阻塞项与升级状态：
下周计划：
```

---

## 13. 关联规则文档

1. [工程护栏与评审规矩](../../development/engineering-guardrails.md)
2. [外包团队工作指南](../../development/outsourcing-work-guidelines.md)
3. [系统逻辑问题审查报告](../../development/logic-issues-review.md)
4. [外包测试与修复批次审查报告（2026-02-20）](../../testing/archive/outsourcing-test-fix-review-2026-02-20.md)
