regression-testing

回帰テスト（regression-testing）

コード変更 → 回帰が必要なテストを自動判定します。

• 入力：Code Diff（git diff <base>...<head>）、Bug 修正の説明、要件変更の説明、既存のテストケース（markmap + 测试用例.schema.yaml）、（任意）要件モデル
• 出力（ファイルに保存）：{项目}/回归清单_{日期}.md——必須回帰（P0）／推奨回帰（P1）／任意回帰（P2）の3段階に分け、各項目に根拠を示します。档名では P 系の記号をそのまま使用しますが、分類ルールは影響の直接性によるもので、テストケース自体の優先度とは別の基準です：変更に直接関連 → 必須回帰、同一モジュールへの間接的な影響 → 推奨回帰。[P2] のテストケースでも、code_refs が変更に直接関連する場合は「必須回帰」に分類します（パイプラインでの段階的な実行は本分類に従います。../core/pipeline-integration.md を参照）
• 前提条件：永続的な「テストケース ↔ コード ↔ 機能」のトレーサビリティマッピング。v0 の3層はすべてファイルに保存された成果物から取得し、セッションの記憶には依存しません：
  1. コードレベルのアンカー：テストケースの付録「コード根拠一覧（TC ↔ ファイル:行）」。Schema の code_refs により構造化します
  2. 機能レイヤー：要件モデル + Schema の module / risk_ref
  3. 実行ごとの差分：変更ファイルのマッピング付録（今回の diff に対して生成）

このデータ構造がなければ、影響範囲の分析は「モデルに diff を一度読ませて推測させる」だけです。開始前に3段階で資産を棚卸しします（進め方を決定し、資産がない状態でリストをでっち上げるのを防ぎます）：

• すべてそろっている（markmap と Schema のトレーサビリティマッピングがある）：ワークフローの完全な分析チェーンに進みます
• markmap のみで Schema がない：まず test-case-writing で既存の markmap から抽出して補完します（人手で書き直す必要はありません）。その後、ワークフローに進みます
• テストケース資産がない：diff からリストをでっち上げてはいけません。ユーザーに次の代替案を提示します。P0 のスモークテストを提案する（各項目に「トレーサビリティの根拠なし。カバレッジの保証なし」と明記する）、または、まず test-case-writing で最小限のテストケースセットを補完してから本プロセスを再実行する

ナレッジベースの入力（別途参照。この振り分けは変わりません）：プロジェクトに .qa/ ナレッジベースがある場合は、開始時にその INDEX.md を読み込みます。flaky-tests.md の active 項目は、「過去のノイズか、実際の回帰か」の判定と回帰レベル分けに直接入力します（記録と管理は qa-memory が担当します）。

使用する場面

• コード変更（feature／Bug 修正／リファクタリング）のマージ後に、回帰テストの範囲を選定する必要がある場合
• Bug 修正後に、「修正検証 + 関連する回帰テスト」のテストケースセットを決定する必要がある場合
• 各項目に根拠があり、調整可能な段階別回帰リストが必要な場合

使用しない場面

• テストケースファイル自体の差分更新（テストケースのマーク／追加／廃止）→ test-case-writing の差分更新ワークフロー
• 長期的な回帰戦略（アンカーテストケース、回帰の実施頻度）→ test-strategy の regression_plan
• 個々の失敗の切り分けと分類 → 実行系スキルの個別フロー（automated-e2e-testing ワークフロー二／api-testing §4）。1回の実行で失敗が3件以上の場合は、まず ../core/triage.md で振り分けます。Bug はユーザーが判定を確定してから bug-analysis に進めます（その入力は確認済みの Bug である必要があります）
• エンドツーエンドのパイプライン → qa によるオーケストレーション

分析チェーン

Changed Files（git diff）
    ↓
Changed Functions（diff 中被修改的函数/类/组件）
    ↓
Affected Features（函数 → 所属功能：经 Schema code_refs / module / 需求模型映射）
    ↓
Affected Test Cases（功能 → 用例：risk_ref / module / 附录改动文件映射）
    ↓
Regression Scope（三级回归清单 + 依据）

ワークフロー

1. 変更を棚卸しする

git diff <base>...<head> --stat          # 改动文件清单
git diff <base>...<head> -U3             # 逐文件读改动内容，定位改动函数

変更タイプの分類（基本の4種類。test-case-writing のフェーズ1「変更の棚卸し」と同じ列挙です）：🆕 新規作成 / ✏️ 変更（必要に応じて細分化して明記できます：動作変更、🐛 Bug 修正（関連する Bug チケット）、🔧 リファクタリング（動作は変わらないはず））/ 🗑️ 削除 / 💀 デッドコード。タイプごとに回帰テストの重点は異なります（リファクタリング → 動作アンカーを全件実施、Bug 修正 → 修正検証 + その Bug に過去関連付けられたテストケース、デッドコード → 回帰テストケースは発生しません）。

2. 影響範囲を分析する（分析チェーンに沿って段階的にマッピングする）

• コードレイヤー：Schema の code_refs が変更ファイル（または同じファイル内の近接行）に該当するテストケース → 直接影響を受けます。code_refs はテストケース作成時のスナップショットであり、リアルタイムのインデックスではありません。該当箇所が今回の diff の内容と明らかに一致しない（関数がすでにない／行番号が全体的に近接範囲からずれている／ファイル名が変更されている）場合は、アンカーが古くなっていると判断し、一括して参考シグナルに格下げして、機能レイヤー／リスクレイヤーのマッピングに切り替えます。その判断基準をリストの冒頭に明記します
• 機能レイヤー：変更関数が属する機能（module／要件モデル）の全テストケース → 間接的な影響を受けます。共有ツール／共通コンポーネントの変更 → 利用側をすべて確認します（参照元を grep し、1件ずつ判断します）
• リスクレイヤー：Risk Map で影響を受ける機能に紐づくリスク（risk_ref から逆引き）→ そのアンカーテストケース（Critical リスクは必ず「必須回帰」に含めます）
• 履歴レイヤー（Bug チケットがある場合）：その Bug に関連する機能の過去の回帰テストケース

分析中、各マッピングに根拠を示します（「TC-03-02 の code_refs が coupon_service.py:124 に該当」）。マッピングできないものを無理にでっち上げず、「影響不明。人による判断を推奨」に記載します。

3. 段階別の回帰リストを生成する

関連する Bug がある場合、修正検証テストケースは「必須回帰」に含めます：bug-analysis の「回帰の提案」にある修正検証テストケースを使用します（既存のテストケースがない場合は、新規 TC 番号を提案します。ファイルへの記録は test-case-writing が担当します）。その Bug の項目にある「回帰の提案」と相互にリンクします。

# 回归清单 — {日期}

- 变更基线：{base}...{head}（{commit 数} commits，{文件数} 文件）
- 变更类型：{新增/修改/修复/重构/删除}
- 关联 Bug：{Bug 编号列表，非修复类变更省略此行；有则与对应 Bug 条目的回归建议双向互链}

## 必须回归（P0）
| 用例 | 依据 |
|------|------|
| TC-01-01（SMOKE-1） | 改动文件 code_refs 直连 + Critical 风险 R1 锚点 |
| TC-03-01（修复验证） | Bug-001 修复验证，来源 bug-analysis「回归建议」（新增编号归 test-case-writing） |

## 建议回归（P1）
| 用例 | 依据 |
|------|------|
| TC-02-03 | 同功能模块间接受影响（module=发放流程） |

## 可选回归（P2）
| 用例 | 依据 |
|------|------|
| TC-06-02 | 公共组件改动，消费关系间接 |

## 影响不明（建议人工判断）
- {文件/功能}：{为什么映射不上}

## 无影响确认（显式排除）
- {模块}：{排除依据，如"改动仅涉日志文案，无行为变更"}

test-strategy の regression_plan と整合させます：アンカーテストケース（Critical リスク P0）はデフォルトで「必須回帰」に含めます。実行方法は automation_plan（e2e／api／手動）に従って記載します。

4. 成果物の引き渡しと実行の連携

• リストをファイルに保存した後、実行担当に引き渡します：自動化部分 → automated-e2e-testing / api-testing、手動部分 → テストエンジニア
• パイプラインでの段階的な実行：本リストの3段階の分類は、パイプラインの実行段階を決める基準にもなります——PR のスモークテストでは P0、夜間ジョブでは P1 の全件 + P2 のサンプリング、リリースのゲートでは全件を実行します。headless の非対話実行時におけるチェックポイントの格下げ／成果物の保存／終了コードの意味は ../core/pipeline-integration.md を参照します（この時点で読み込みます）。回帰後に戻された複数の失敗は ../core/triage.md に進みます
• 回帰結果をテストレポートに集約します（../core/report-template.md §5 回帰の概要）
• 複数の失敗は先に振り分ける：1回の回帰テストで失敗が3件以上の場合、まず ../core/triage.md の4分類に従って事前分類します——C 環境／D 不安定は今回の Bug 同期対象から除外します（C は修正後、影響を受けたバッチを必ず同じ内容で再実行します）。B 資産の問題は別途、対応待ちとして記録します。残った A 分類のみ、次の段階の状態同期に進みます
• 回帰結果を Bug の状態に反映する：修正検証に対応する Bug 項目を結果に応じて更新します——合格 → 検証済み、クローズ。失敗 → 修正済み、検証待ち（失敗の証拠を添付。項目がすでにその状態の場合は再検証ラウンド数 +1。3に達したら、対応方針の変更／修正しない方針の審査への移行についてユーザーに判定を促します）。フィールドの定義は ../core/report-template.md §3（使用上の注意 6）を参照します

よくある間違い

誤り	結果	正しい方法
変更ファイル名だけでテストケースを照合する	同名でもレイヤーが異なる場合があり、共通コンポーネントの利用側を見落とす	分析チェーンの最後まで進み、共通コンポーネントは参照元を grep する
Schema がない状態で「diff を読んで推測する」	影響範囲の分析が推測に退化する	まず既存の markmap から Schema を抽出する（test-case-writing）
リストに根拠を示さない	再確認できず、範囲を調整できない	各テストケースにマッピングの根拠を示す
一律に全件回帰する	回帰コストが膨らみ、重要なテストケースが埋もれる	3段階に分類し、明示的な除外リストを作成する
マッピングできないものを無理にリストに含める	信頼性の見せかけになる	「影響不明」として個別に記載し、人が判断する
テストケースファイルの変更と回帰範囲を混同する	担当範囲を逸脱する	テストケースの変更は test-case-writing が担当し、本 skill は回帰範囲の選定のみを行う
テストケース資産がゼロなのに通常どおり3段階のリストを作成する	diff からテストケース名をでっち上げ、見た目は専門的でも実行できないリストになる	まず3段階で資産を棚卸しする。資産がゼロならスモークテストの提案に格下げし、「トレーサビリティの根拠なし」と明記する
古くなった code_refs を直接関連する根拠として扱う	リファクタリング後の影響範囲に漏れや誤りが生じる（実際に影響を受ける項目の見落としや、すでになくなった項目の誤報）	該当箇所が diff と一致しなければ一括して格下げし、機能レイヤー／リスクレイヤーのマッピングに切り替える