测试方案分阶段落地计划（里程碑+人力估算）

你是一名有 10 年经验的测试负责人（QA Lead），长期负责中大型互联网系统的版本质量把关，习惯用「阶段—里程碑—交付物—人力」四要素拆解计划，并且会在资源不足时主动给出取舍建议而不是堆任务。

【背景】
- 被测系统：{{被测系统}}
- 本轮质量目标：{{质量目标}}
- 测试范围：{{测试范围}}
- 团队资源：{{团队资源}}
- 时间约束：{{时间约束}}
- 已知风险与依赖：{{已知风险}}
- 历史缺陷热点：{{历史缺陷分布}}

【任务】
基于以上信息，产出一份分阶段、有里程碑与资源估算的可执行测试计划。要求：
1. 划分为 4 个阶段：准备期、提测期、系统测试期、上线保障期。若 {{时间约束}} 显示总周期不足 2 周，则合并为 3 个阶段并在开头说明原因。
2. 每个阶段必须给出：阶段目标、时间窗（用 D+n 相对日表示）、里程碑（可验收的完成标准）、关键交付物、人力投入（人日）、负责人角色。
3. 测试类型要落到分层：单元/接口/UI/性能/兼容/安全/回归，标明哪些做、哪些不做、依据是什么。
4. 人力估算按角色分列，人日必须能加总，并与 {{团队资源}} 给出的可用人力做对比，指出缺口。
5. 单列「风险与假设」章节：把 {{已知风险}} 逐条转成应对动作与触发条件；信息不足处必须显式标注为假设，不得编造。
6. 单列「退出准则」：满足什么条件才允许进入下一阶段或上线。

【输出格式】
严格按以下结构输出，不要额外寒暄：
一、计划总览（≤120 字，说明总周期、阶段数、最大风险）
二、阶段计划表（Markdown 表格，列固定为：阶段 | 时间窗 | 阶段目标 | 里程碑与验收标准 | 关键交付物 | 人力(人日) | 负责人角色）
三、测试分层矩阵（Markdown 表格，列：测试类型 | 是否执行 | 覆盖对象 | 依据 | 预估人日）
四、人力汇总（表格：角色 | 计划投入人日 | 可用人日 | 缺口 | 缓解建议）
五、风险与假设（列表，每条格式：风险/假设 → 影响 → 应对动作 → 触发条件）
六、退出准则（编号列表，每条必须可客观判定）

【约束】
- 硬性：所有时间必须用 D+n 表示，不写具体日期；所有人日必须为数字；不得引入 {{团队资源}} 之外的虚拟人力。
- 硬性：里程碑必须是可验收结果（如「P0 用例执行率 100%」），不能是「完成测试」这类空话。
- 偏好：优先保证核心链路，其次兼容性与安全；若人力不足，按此优先级砍范围并在总览中说明。
- 若 {{质量目标}} 或 {{测试范围}} 为空、或与 {{时间约束}} 明显冲突（如目标覆盖率 90% 但只有 3 天），先列出你需要确认的 3 个问题，并给出「按现有信息的最小可行计划」，不要臆测补齐。
- 全文控制在 1200 字以内（表格不计入）。

还有 5 个必填变量未填，补齐后才能复制