NB-076
50995d3335
- SETUP.md: 完整环境搭建指南（同事用） - SETUP_QUICK.md: 快速搭环境（4步） - s22~s26: TNA端到端、覆盖率报告、回归检查 - procedure_grammar.lark: 实验性Lark语法 Co-Authored-By: Claude <noreply@anthropic.com>
66 lines
4.0 KiB
Markdown
66 lines
4.0 KiB
Markdown
# テストカバレッジ 真のギャップ分析レポート
|
||
|
||
## ギャップ1: `pure_vs_mixed` の判定ロジックが一度も検証されていない
|
||
|
||
`resolve_pure_vs_mixed()` は `has_switch AND has_counter AND if_count >= 3` の場合のみ `混合マッチング` を返す。この条件を満たすテストプログラムが存在しないため、**この分岐は一度も通過したことがない**。未テストのreturn文が存在する。
|
||
|
||
```
|
||
resolve_pure_vs_mixed():
|
||
if has_switch and has_counter and if_count >= 3:
|
||
return "混合マッチング" ← 未テスト
|
||
else:
|
||
return "unknown" ← これしか通らない
|
||
```
|
||
|
||
## ギャップ2: `mn_output_mode` が `select_files` dict に脆く依存
|
||
|
||
extract_structure() は FILE-CONTROL パースに成功したときのみ `select_files` に値を入れる。SELECT...ASSIGN TO パターンにマッチしないファイル定義（例：古いCOBOLのASSIGN TO なし）では空dictになる → `len({}) == 0` → `file_count` も0 → 判定バイパス。
|
||
|
||
これは他の混淆組にも波及する: `matching_vs_keybreak` の `file_count` が0になるため、マッチング判定がファイル数条件を満たさない。
|
||
|
||
## ギャップ3: L1キーワードの文字列マッチが脆弱
|
||
|
||
`EXEC SQL`, `CALL`, `SYSIN`, `ORGANIZATION IS` などのキーワードは **部分文字列マッチ** であり、以下のFPを引き起こす可能性がある：
|
||
|
||
| キーワード | FPシナリオ | 現状 |
|
||
|:-----------|:-----------|:------|
|
||
| `EXEC SQL` | `DISPLAY 'EXEC SQL...'` の文字列リテラル | FP確認済み |
|
||
| `CALL` | `COMPUTE WS-CALL = WS-X` の変数名 | FP確認済み |
|
||
| `MAP` | `WS-MAP` という変数名 | FP確認済み（CICSと判定） |
|
||
| `SYSIN` | `SYSIN` という変数名 | FP確認済み |
|
||
| `ORGANIZATION IS` | コメント内の `ORGANIZATION IS` | 未確認だがリスクあり |
|
||
|
||
## ギャップ4: 8つのCOBOL文が実パイプラインで未テスト
|
||
|
||
以下のCOBOL文はL0(解析)テストではカバーされているが、実際の `classify_program()` パイプラインを通すテストが存在しない：
|
||
|
||
| 文 | L0テスト | パイプラインテスト | リスク |
|
||
|:---|:---------|:-------------------|:-------|
|
||
| SEARCH ALL | ✅ | ❌ | Lark OCCURS＋ASCENDING KEY に依存、崩れる可能性 |
|
||
| SEARCH(逐次) | ❌ | ❌ | INDEXED BY の添字解決に依存 |
|
||
| SORT INPUT/OUTPUT PROCEDURE | ❌ | ❌ | PROCEDURE段落の展開が必要 |
|
||
| MERGE OUTPUT PROCEDURE | ❌ | ❌ | 同上 |
|
||
| RELEASE/RETURN | ❌ | ❌ | SORT/MERGEサブ文、パーサー素通り |
|
||
| ALTER | ❌ | ❌ | 旧式だが大型機には残っている |
|
||
| USE Declaratives | ❌ | ❌ | パーサーが完全未対応 |
|
||
| MOVE CORRESPONDING | ❌ | ❌ | CORR 句が非対応 |
|
||
|
||
## ギャップ5: パーサー例外時の分類パイプラインの挙動が未検証
|
||
|
||
`extract_structure()` が失敗（日本語変数名、固定形式の不正など）した場合、`classify_program()` は空の `structure` dict でパイプラインを続行する。このとき：
|
||
|
||
1. `keyword_matches` は空（detect_keyword は extract_structure 非依存だが source_upper を再生成しない）
|
||
2. `max_keyword_confidence = 0.0` → Path C(fallback)
|
||
3. `structure = {}` → `features = {}` → 全混淆組が unknown
|
||
4. 最終的に `項目チェック(重複含まず) conf=0.12` のデフォルト値になる
|
||
|
||
構造抽出に失敗しても「静かに誤った分類を返す」という設計が、問題の隠蔽を引き起こしている。
|
||
|
||
## 総評
|
||
|
||
現在のテストスイートは「正常系」と「既知のFP」をカバーしているが、**以下の3つが完全に欠落している**：
|
||
|
||
1. **ルールエンジンの全分岐カバレッジ** — pure_vs_mixed、mn_output_mode の特定条件分岐が未到達
|
||
2. **実COBOL構文のパイプライン結合テスト** — 8つの重要文がパイプライン通過未検証
|
||
3. **パーサー障害時の異常系テスト** — 抽出失敗→デフォルト値の挙動が未確認
|