test-strategy

# 测试策略（test-strategy） 回答"**这个功能应该怎么测**"——把风险翻译成**两域测试范围与深度**。策略位于"需求 → 风险分析 → **策略** → 测试设计 → 用例"链路中，跳过策略直接写用例是本框架明确反对的。 - **输入**：需求模型（`需求模型.md`；没有则内联轻量研读需求源）、代码仓库、系统架构、历史 Bug - **输出（落盘）**：`{项目}/测试策略.md`（Risk Map + 两域 scope + depth_budget）；有 handoff / blocked / 外部执行器轴时另产 `{项目}/专项移交_{轴}_{日期}.yaml` - **边界**：不写具体用例（→ `test-case-writing`）；不代替用户裁决（自动化提案、预算裁决均 ⏸ 等确认）；覆盖范围限于**系统级黑盒**（UI / API / 手动 / 专项移交）——单元/集成测试是开发侧职责，本策略的风险评级与"已覆盖"结论均以**该层已有保障为假设前提**（假设未验证时在测试报告标注，防"系统级全过 = 质量有保障"的误读） ## When to Use - "这个功能应该怎么测"——需要范围 / 类型 / 深度 / 优先级的策略决策与理由 - 需要识别风险并评级（Risk Map），作为用例优先级与回归锚点的依据 - 需要决定测试类型取舍（性能 / 安全 / 可靠 / 兼容等哪些测、测多深、哪些明确不测）并留痕 - 需要制定自动化计划提案与长期回归策略 ## When NOT to Use - 端到端测试整个需求 → `qa` 编排 - 需要系统性需求建模 → `requirement-analysis` - 已有策略、直接写用例 → `test-case-writing` - 代码变更后判断回归范围 → `regression-testing`（本 skill 的 regression_plan 是长期回归策略，不是某次 diff 的范围选择） ## 测试策略 Schema（产出结构） ```yaml test_strategy: feature: functional_scope: # 功能域：范围+深度+理由（含 state / data_consistency 两轴；rationale 每轴必带，示例仅演示写法） functional: { include: true, depth: full, rationale: "核心资损路径", risk_refs: [R3] } boundary: { include: true, depth: standard, rationale: "入参边界密集（金额/时限）" } permission: { include: true, depth: full, rationale: "越权高危", risk_refs: [R2] } state: { include: true, depth: standard, rationale: "券状态流转多分支" } data_consistency: { include: true, depth: standard, rationale: "库存与订单跨表一致" } regression: { include: true, dep...