test-strategy

テスト戦略（test-strategy）

「この機能をどうテストすべきか」に答え、リスクを2つの領域におけるテスト範囲と深度に落とし込みます。戦略は「要件 → リスク分析 → 戦略 → テスト設計 → テストケース」の流れに位置し、戦略を飛ばして直接テストケースを書くことは、このフレームワークが明確に避けるべきとしている行為です。

• 入力：要件モデル（需求模型.md。ない場合は、要件ソースをインラインで簡易調査）、コードリポジトリ、システムアーキテクチャ、過去のバグ
• 出力（ファイルに保存）：{プロジェクト}/测试策略.md（Risk Map + 2領域の scope + depth_budget）。handoff / blocked / 外部実行器の軸がある場合は、さらに {プロジェクト}/专项移交_{轴}_{日期}.yaml を生成します
• 境界：具体的なテストケースは書きません（→ test-case-writing）。ユーザーに代わって決定しません（自動化の提案、予算の裁定はいずれも確認待ち ⏸）。対象範囲はシステムレベルのブラックボックス（UI / API / 手動 / 専門的な引き継ぎ）に限ります。ユニットテスト／統合テストは開発側の責任です。本戦略のリスク評価と「カバー済み」の結論は、いずれもその層に既存の保証があることを前提とします（前提が未検証の場合はテストレポートに記載し、「システムレベルのテストがすべて合格 = 品質が保証されている」という誤解を防ぎます）。

使用する場合

• 「この機能をどうテストすべきか」——範囲／種類／深度／優先度の戦略的な判断と理由が必要な場合
• リスクを特定して評価（Risk Map）し、テストケースの優先度や回帰のアンカーを決める根拠とする場合
• テストの種類（性能／セキュリティ／信頼性／互換性など）について、何をどこまでテストし、何を明確にテストしないかを決め、記録する場合
• 自動化計画の提案と長期的な回帰戦略を策定する場合

使用しない場合

• 要件全体のエンドツーエンドテスト → qa のオーケストレーション
• 要件を体系的にモデル化する必要がある場合 → requirement-analysis
• すでに戦略があり、直接テストケースを書く場合 → test-case-writing
• コード変更後に回帰範囲を判断する場合 → regression-testing（この skill の regression_plan は長期的な回帰戦略であり、特定の diff の範囲選択ではありません）

テスト戦略 Schema（出力構造）

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, depth: standard, rationale: "存量功能回归基线" }
  type_scope:                  # 类型域：十轴全轴必答，每轴单行 flow 风格（校验器按行解析）
    performance:        { decision: include, depth: full,     signals: ["PRD-4.2 SLA", "order_service.go:88"], risk_refs: [R3], executor: k6, execution_status: blocked, todo: "向运维索取独立压测环境", handoff_ref: "专项移交_性能_{日期}.yaml" }
    security_business:  { decision: include, depth: standard, signals: ["多角色", "内部信号:permission≥standard"] }
    reliability:        { decision: include, depth: standard, signals: ["retry: pay_service.go:41"] }
    concurrency:        { decision: include, depth: standard, signals: ["库存扣减", "S级复核: check-then-write 命中 cart_service.go:41"] }
    compatibility:      { decision: include, depth: light,    signals: ["有前端"] }
    accessibility:      { decision: include, depth: light,    signals: ["有前端"] }
    visual:             { decision: include, depth: light,    signals: ["有前端"] }
    i18n:               { decision: exclude,  rationale: "需求信号（海外/多语言/RTL）未命中；无代码仓库", scanned: ["需求信号(G)"] }
    migration:          { decision: include, depth: standard, signals: ["migrations/2026-08-x.sql"] }
    contract_integration: { decision: include, depth: standard, signals: ["外部风控依赖"] }
  depth_budget:                # full ≤3（两域合并计）；被裁 Critical 轴走预算裁决
    full_axes: [functional, permission, performance]
    ranking_rationale: "R3(资损 Critical) > R2(越权 High) > ..."
  automation_plan:            # 哪些用例自动化、用什么框架（提案，⏸ 等用户确认）
  regression_plan:            # 回归策略（锚点用例、回归节奏）
  risk_map_ref:               # 指向 Risk Map（本文档内嵌，每条风险含证据）

フィールドの定義：signals は要件のセクション／ファイル:行／マトリクス内部のシグナルを参照します。scanned は exclude の G+S の二重リストです（各項目の末尾に (G)/(S) を付けます）。executor は省略時に agent とみなします。agent 以外（k6 / locust など）の場合は handoff_ref が必須です。execution_status は ready / blocked / done のいずれかです。exclude の軸では省略します。深度は次の3値のみです。full（全項目を網羅）／standard（主要フロー + 重要な異常ケース）／light（サンプリング + スモークテスト）。「テストしない」は深度ではなく範囲の判断です。機能領域では include: false（rationale を記載）、種類領域では decision: exclude または handoff とし、いずれも理由を記載する必要があります（バリデーターは depth にそれ以外の値がある場合、拒否します）。

形式上の厳格な制約（弱いモデルによる形式の揺れを防ぐため）：type_scope の各軸は、必ず flow 形式で1行に記述してください。たとえば performance: { decision: include, depth: standard, signals: ["..."] } のようにします。1つの軸を decision / depth / signals の複数行からなるブロック形式に分割することは禁止です（バリデーターは行単位で解析するため、ブロック形式は検証失敗となり、その軸は未決定として扱われます）。書く前に、直前の行の形式をそのまままねてください。根拠：弱いモデルでの実測では、サンプルのほぼ半数でブロック形式への逸脱が発生し、解析に失敗しました。判断内容自体に問題はなく、純粋な形式上の損失です。

ワークフロー

1. 入力の調査

• 要件モデルを読みます（なければ、元の要件ソースを読んで簡易調査します）。コードがある場合は、リポジトリのパス／ブランチ／diff を確認し、実装形態（UI の有無、インターフェース面、データフロー）を把握します。
• 過去のバグ（同じ機能領域／同じモジュール）を収集します。過去の欠陥密度は、Likelihood の推定に使う情報であり、R3 の格上げ／格下げを判断するトリガーです。

2. リスクの特定と評価（この時点で ../core/risk-model.md を読み込みます）

• 次元ごとにリスクを調査します。機能領域の次元（権限／データ整合性／境界／状態遷移／資金損失——5つの次元とステップ3の scope 6軸との対応は ../core/risk-model.md の dimension 注釈を参照）+ 種類領域の軸名（並行性／信頼性／セキュリティ／性能／互換性／移行／契約——マトリクスの軸と共通）
• 各リスク（R1、R2…）をモデルに従って評価します。Impact × Likelihood（各1～5）→ Critical/High/Medium/Low。各リスクには必ず根拠を記載してください。根拠のないリスク評価は無効です。
• 手法の選択については ../core/testing-principles.md 第2節を参照します（機能特性に応じて設計手法を選び、機能領域の各軸の深度を決める理由とします）。

3. 機能領域の範囲を決定

各軸について include / depth / rationale を決定します（functional / boundary / permission / state / data_consistency / regression）。

• リスクレベルからテストケース優先度へのマッピングは ../core/risk-model.md 第3節に従います（Critical には必ず P0 があり、回帰アンカーにもなる……）。逸脱する場合は理由を明記します。
• テストしない場合も理由を記載してください。「なぜテストしないのか」は「なぜテストするのか」と同じくらい重要です。
• permission を高い深度（≥standard）でテストすることは、軸2のビジネスセキュリティを内部的に対象に含めるシグナルでもあります（判断はマトリクス第2節を参照）。

4. 種類領域の全軸スキャン（この時点で ../core/test-type-matrix.md の該当セクションをグループ単位で読み込みます）

軸グループごとに進めます（A 資金と正確性 → B 依存関係と変更 → C フロントエンド体験。各グループでは、そのグループの軸に関するマトリクスのセクションだけを読み込み、ファイル全体は読み込みません）。

1. G レベルのスキャン（コードリポジトリがある場合、作業開始時に3グループ共通で1回実行）：python3 ../core/scripts/scan_signals.py <仓库路径> → 各軸の G レベルシグナル + 事前入力表
2. 軸ごとに判断（選択肢を限定し、事前入力表を修正。空欄から作成しない）：要件シグナル → G レベルの照合 → S レベルの項目をすべて再確認（マトリクスの各軸で〔S〕が付いた項目をコードで個別に確認）→ decision → depth
3. 形式だけの追認を防止：exclude は事前入力されません。exclude を選ぶ場合は S レベルの再確認を完了し、G+S の二重リストを scanned に記載してください。「スクリプトで検出されなかった」ことだけでは exclude の理由になりません。
4. グループ内の完了確認：グループ内のすべての軸を決定してから次のグループに進みます。10軸すべての決定が完了したら、ステップ5に進みます。

コードリポジトリがない場合：G/S レベルの確認を省略し、要件シグナルのみで判断します。exclude の rationale に「コードリポジトリなし」と記載してください（バリデーターはこれを根拠に S レベルの要件を免除します）。

5. 深度の調整と予算の優先順位付け（この時点でマトリクス第13節の R1–R6 を実行します）

• リスクの格上げ／格下げは R1–R6 に従います（リスクによる格上げ／複数の情報源のシグナル／過去の欠陥／シグナルなしの場合の格下げ／コストの上限／予算の制約）。
• R6 > R1：full（2領域合算）> 3 の場合は、リスク順に絞り込みます。絞り込み対象になった Critical の軸については、⏸ 予算裁定チェックポイントを設けます。優先順位と絞り込みの影響を提示し、ユーザーは予算を拡張できます（予算を拡張する場合は、depth_budget に budget_review: {approved_by: 用户} を記録します）。headless の場合（pipeline-integration の取り決め1、第4条）：budget_review: {headless 未决: 保守裁剪, 依据: …} と正確に記録してください。ユーザーが承認したと記載してはいけません。人手による確認後、元の行に approved_by: 用户 を追記します。
• depth と execution_status は分けて扱います：環境／データ／ツールが不足している場合、depth は下げず、blocked + todo（誰に何を依頼するか）を記録します。「実行できない」を「テスト不要」と取り違えてはいけません。

6. 自動化計画の提案（⏸ 提案のみ。裁定しません）

• テストケースの特性に応じて提案します。UI の主要フローがある場合 → Playwright（automated-e2e-testing）。インターフェースレベルの検証／冪等性／並行性 → API スクリプト（api-testing）。スクリプト型の軸の実行物（性能／ビジュアル、アクセシビリティの axe スキャンタスク）→ 専用スクリプト／スキャンタスク。探索的テスト／一度限りのテスト → 手動。
• automation_plan は提案です。推奨リスト + フレームワーク + 自動化しない項目のリストと理由を提示し、ユーザーの確認を受けます（qa パイプラインでは実行戦略チェックポイントとなります）。確認前に実行系の skill を開始してはいけません。

7. 回帰戦略

• Critical/High リスクと P0 テストケースから、回帰アンカー（毎回必ず実行するもの）を指定します。
• regression_plan：アンカーセット + 変更の種類に応じた拡張ルール（インターフェースの変更 → インターフェーステストケースをすべて実行、UI の変更 → 主要フローの E2E……）

8. 落盘与交付

1. 写 {项目}/测试策略.md（Schema 结构 + Risk Map 内嵌；type_scope 每轴单行 flow 风格 + 足够性声明：逐轴档位动作清单与完成状态；开头一段范围假设声明：本策略限于系统级黑盒，单元/集成测试为开发侧职责，结论以此为前提）
2. handoff 轴 / include+外部执行器 / blocked 轴 → 生成 {项目}/专项移交_{轴}_{日期}.yaml 移交包（目标、场景参数、阈值/验收口径）。文件名中的 {轴} 用以下轴中文短名（与矩阵轴一一对应；轴 1 全名"性能效率"文件名取"性能"）：性能 / 业务安全 / 可靠性 / 并发一致性 / 兼容性 / 无障碍 / 视觉一致性 / 国际化 / 迁移与升级 / 契约与集成，如 专项移交_性能_20260901.yaml——执行侧（api-testing 等）按中文名 glob 消费，用英文轴 id 会断链
3. 校验后交付：python3 ../core/scripts/validate_schema.py {项目}/测试策略.md（V1–V5；有代码仓库时叠加 --repo-root {仓库根} 抽查各轴 signals 指涉真实性），错误清零再交付。注意：include 且挂 Critical 风险的轴若最终维持 full 以下档位，校验器要求该轴名出现在 budget_review 文本中——降档裁量必须留一行依据，不许无声消失
4. 交付索引给下游（test-case-writing）：策略路径 + include 轴清单（用例型轴的 type/标签要求见矩阵第 12 节）+ 优先级映射要求

Common Mistakes

错误	后果	正确做法
风险评级无证据（拍脑袋 High）	评级不可复核，策略失去推导链	每条风险挂 evidence（../core/risk-model.md）
类型轴静默缺失（漏轴）	类型盲区被藏成"没想过"，无从挑战	十轴必答（V1），exclude 也要留痕
include 无信号 / exclude 无理由	过测 / 漏测	signals 挂证据；rationale + scanned 双清单（V2/V3）
脚本无命中直接 exclude	脚本盲区被制度化为漏测	S 级复核后才可 exclude（G+S 双确认）
full 满天飞	资源稀释在长尾，无重点	full ≤3 + 挂风险编号（V4）；冲突时 R6>R1 + 预算裁决
环境缺位记成 exclude	"做不了"冒充"不用测"	depth/execution 分离，blocked + todo（R5/V5）
scope 只写布尔开关	"测多深"丢失，执行时各自理解	范围 + 深度 + 理由三件套
把用例写进策略	越界（那是 test-case-writing 的产出）	策略到"范围/深度/优先级要求"为止
automation_plan 直接执行不等确认	剥夺用户执行策略裁决权	提案 → ⏸ 用户确认 → 才启动执行
风险等级沿用 P0/P1 命名	与用例优先级同名歧义	风险用 Critical/High/Medium/Low（../core/risk-model.md）