# テスト障害診断 ## 定義 テスト障害診断(test fault diagnosis / test alarm diagnosis)は、ソフトウェアのシステム統合テスト(System and Integration Testing, SIT)フェーズで失敗したテストケースが発生させる**テストアラーム**の原因を自動的に特定する取り組み。障害分類(fault classification)と障害箇所特定(fault localization)の 2 つのサブタスクから成る。 **障害分類**: 失敗テストケースが属する障害カテゴリを決定する。マイクロサービスのテスト環境では代表的なカテゴリとして以下が挙げられる: | カテゴリ | 原因 | 対応策 | |---|---|---| | Service Issue | サービス内部の問題 | 開発者へのバグ報告 | | Environment Issue | サービス外部・テストステップと無関係の問題 | テストケースの再実行や環境設定のリセット | | Script Defect | テストステップの誤り | テストスクリプトの修正 | | Tool Defect | サードパーティ製テストツールの欠陥 | ツール提供者へのサポート依頼 | **障害箇所特定**: どのログエントリが根本原因に関連するか(障害指示ログエントリ)を特定して順位付けする。 (Source: [[@2024__FSE__SynthoDiag - Fault Diagnosis for Test Alarms in Microservices through Multi-source Data]]) ### 本番環境障害診断との違い テスト障害診断は、[[マルチモーダル障害診断]]や[[ログベース障害診断]]で扱う本番環境の障害診断と以下の点で異なる: - **診断対象の違い**: テスト段階(リリース前)の失敗テストケースを対象とする。本番環境では稼働中のサービスの異常を対象とする - **ログ構造の違い**: テストケースには実行ログ(クライアントサイド)・トレースログ(サーバーサイド)・テストケース情報という複数の特有のデータソースが存在し、テスト操作単位で構造化されている - **利用者の違い**: テスト担当者が診断結果を使い適切な修正アクション(バグ報告・環境リセット・スクリプト修正)をとる。本番環境では SRE・オペレータが対応する - **過去データの形式**: テスト障害診断では「成功したテストケースのログ」が参照ベースとして使えるため、失敗ケースとの差分分析が可能 ## 横断的知見 - **テストログの 90% 以上が障害と無関係であり、フィルタリング戦略の選択が診断精度を大きく左右する**: SynthoDiag([[@2024__FSE__SynthoDiag - Fault Diagnosis for Test Alarms in Microservices through Multi-source Data]])の Huawei Cloud 調査では、失敗テストケースのログエントリの 90% 以上が障害と無関係であることが判明した。テンプレートベース差分(LFF)は障害関連ログを誤除去するためコンテキスト情報を失い、フィルタなしより性能が低下する場合もある。一方、テスト操作単位のログブロック差分は無関係ログを除去しつつコンテキストを保持する点で優れる(Macro-F1: ブロックフィルタ 0.891 vs ラインフィルタ 0.637 vs フィルタなし 0.577)。この結果は[[ログベース障害診断]]のフィルタリング問題とも共鳴する——情報を絞ってから診断するという骨格は共通するが、テスト環境では「テスト操作」という構造的区切りを活用できる点がユニーク。(Source: [[@2024__FSE__SynthoDiag - Fault Diagnosis for Test Alarms in Microservices through Multi-source Data]] §4.3.1) ## 未解決の問い - **新規テストシナリオへの汎化**: SynthoDiag は Huawei Cloud の単一クラウドサービスプロバイダで評価されているが、異なるテスト環境(異なるアーキテクチャ・ログ形式・操作体系)でも同様の性能が得られるか未検証。テストケース情報とログ間の関係の記録機構がない環境への適用可能性は未評価 - **コールドスタート問題**: ラベル付き過去事例が少ない初期段階(新規サービスや新規テストシナリオ)での診断性能はどうなるか。KNN の近傍探索は過去事例の十分な蓄積を前提とする - **ラベル品質の自動保証**: 複数のテスト担当者がラベルを付けると曖昧さが生じ診断精度に影響する。将来的なラベル補正自動化の手法は未解決 - **SIT から CI/CD パイプラインへの統合**: 現在の SynthoDiag はバッチ診断を想定するが、継続的インテグレーション(CI)では各コミット後に即座にフィードバックが必要。リアルタイム診断への要件への対応は未検討 - **LLM との統合可能性**: [[ログベース障害診断]]では LLM ファインチューニングが高精度・高解釈性を示した([[@2025__nkcs.iops.ai__Accurate and Interpretable Log-Based Fault Diagnosis using Large Language Models]])。テスト障害診断ドメインにおける LLM の有効性は未評価 ## 関連 - 親概念: [[ログベース障害診断]] / [[マルチモーダル障害診断]] - 関連概念: [[Fault Localization]] / [[知識グラフ]] / [[AIOps]] / [[ログパース]] - 主要システム: SynthoDiag([[@2024__FSE__SynthoDiag - Fault Diagnosis for Test Alarms in Microservices through Multi-source Data]])・CAM・LFF - 関連 MOC: [[structures/AIOps - Log Analysis - MOC]] ## 出典 - [[@2024__FSE__SynthoDiag - Fault Diagnosis for Test Alarms in Microservices through Multi-source Data]](§2.1 背景・問題設定, §2.2 動機, §3 設計, §4 評価, §5 実装・展開)