PreventativeTestProは、AI駆動のテストフレームワークであり、観測可能性データと大規模言語モデルを活用して根本原因分析、テスト生成、継続的検証を自動化し、フロントエンドおよびバックエンドシステムの両方のソフトウェア信頼性向上と品質保証の最適化を目的とし、より効率的なサポートチケット管理を促進します。
Research Article
PreventativeTestProは、AI駆動のテストフレームワークであり、観測可能性データと大規模言語モデルを活用して根本原因分析、テスト生成、継続的検証を自動化し、フロントエンドおよびバックエンドシステムの両方のソフトウェア信頼性向上と品質保証の最適化を目的とし、より効率的なサポートチケット管理を促進します。
本論文では、観察可能性駆動型の自動化とAIを活用した積極的な品質エンジニアリングを統合し、現代のソフトウェア提供の課題に取り組む高度でスケーラブルなテストシステムを紹介します。提案されたシステムは、ブラックボックスとホワイトボックス手法を組み合わせたオープンソースのハイブリッドテストプラットフォームであるPreventativeTestProを、革新的な観察可能性ベースのテストオーケストレーションレイヤーを組み込むことで強化しています。このプラットフォームは、ログ、メトリクス、イベント、トレースとブラウザおよびサーバーサイドの監視を組み合わせて、異常を迅速に特定し、テストケースの選択を強化し、機能的、パフォーマンス的、セキュリティのテストスイートの作成を自動化します。特徴的な点は、大規模言語モデル(LLM)を導入し、根本原因の洞察を提供し、生産行動や特定された異常に基づいて自律的に新しいテストケースを構築し、適応回帰カバレッジと知能的な修復を実現していることです。
このシステムは、AI駆動の即時ログ解析による同時テスト実行を促進し、運用とテスト間の継続的なフィードバックループを促進します。マイクロサービスベースのSaaSプラットフォームやSAP BTPエコシステムなど、複数のエンタープライズシナリオで検証されています。4回の本番展開と49人のベータエンジニアによる実証結果によると、平均解決までの時間は最大30%減少し、SLA遵守率は95%以上、テストカバレッジと欠陥トレーサビリティの大幅な改善が見られます。業界標準のツールとの簡単な連携が、プラグアンドプレイの能力を示しています。
本研究は、アジャイルおよびDevOpsの原則に沿った、包括的でツールに依存しない、かつ先見的な品質工学手法を提示します。今後の取り組みには、機械学習による動的異常分類、モバイルおよびユーザー体験指向システムへの拡張、ドメイン固有のテスト開発や失敗予測のための大規模言語モデルの拡張が含まれます。
ソフトウェアビジネスにおけるアジャイルパラダイムの人気が高まる中、継続的統合環境への関心も高まっています。このようなシステムの利点は、定期的なプログラム修正をシームレスに統合できることであり、ソフトウェアの進化が加速かつコスト効率の高いものとなっています。その結果、ビルド手順、テスト実行、テスト結果報告などの業務を効率的に管理します。ソフトウェアテストはソフトウェア工学の始まり以来、実施されています。ソフトウェアテストの実践は、ソフトウェアの品質を評価するために実施されました。1.テストは、エンドユーザーに導入される前にソフトウェアの潜在的なエラーを検出し解決することを目的としたさまざまな作業を含みます。ソフトウェアテストは開発プロセスのコストのかかる段階です。ソフトウェアのテストとデバッグのコストは、総開発コストの50%以上を占めます。回帰分析にかかる費用は、アプリケーションの複雑さやテストスイート5の規模に依存します。
アジャイル手法は本番環境での迅速な変更を生み出し、その結果、フィードバックによるサポート問題が増加します。サポートの問題を管理することは非常に重要かつ重要な責任であり、優れたカスタマーサービスで知られる企業の製品やサービスに対して68%の消費者がプレミアムを支払う意思があると表明していることからも明らかです。ある調査によると、優れたカスタマーサービスを受けた顧客の86%が、長期的にビジネスの忠実な支持者になる可能性が高いとされています。ある調査によると、89%の購入者は、良好なカスタマーサービス体験があればリピート購入をする傾向が高いとされています。ある調査によると、93%の顧客が優れたカスタマーサービスを提供する企業にリピート購入する傾向があります。優れたカスタマーサービスを提供するためには、迅速かつ効果的に高品質なサポート要望を解決することが不可欠です。品質の要素は、サポート問題の解決コストが時間とともに増加し、エスカレーションレベル10に上がるため、迅速な納品を目指す際に非常に重要です。
高品質を得るためには、サポートの問題を特定し対処しつつ、チケット上で回帰テストの包括的なテストカバレッジを確保する必要があります。この任務は複雑であり、支援問題の迅速な発見と解決という運用上の困難が増加しています。サポートの困難は、システム性能の低下や予期せぬ不具合など、さまざまな問題を含み、ソフトウェアシステムの運用段階で頻繁に発生します。これらの問題が迅速に発見され解決されなければ、長期間の活動停止、消費者の不満、経済的な打撃につながる可能性があります。現在の可観測性情報のテスト利用方法は、手動手順、積極的ではなく応答的な手法、異常検出とテスト実行の統合が不十分であることに制約されていることが多いです。リアルタイムの観察データを用いたサポート問題の積極的な検出や、事前に適切なテストケースを自動実行して潜在的な故障を防ぐことが明らかに不足しています。
包括的で統一されたソリューションが存在しないことは、ソフトウェアの保守や信頼性に多くの悪影響をもたらします。これらの要因には、問題の特定が遅れることによるシステムの長期間の非稼働、関連するテストケースの特定における手作業の増加、そしてシステムの信頼性に対する信頼の低下が含まれます。さらに、特定された異常をテストケースと正確に関連付けられないことは、テストカバレッジの不足を招き、未解決の重要な問題を引き起こす可能性があります。
この格差の根本的な理由は、既存の監視・検査システムの断片的な構造に起因すると考えられます。多くの現行システムは、観測可能性データ分析と関連するテストケースの実行を円滑に統合する能力を欠いています。さらに、不正をテストケースと関連付けるための固定された規制や人的手続きに依存していることが、新たな問題を迅速かつ正確に解決する能力を妨げています。
業界がサポート問題をどのように扱い、予防テストを実施しているかを理解するために、私たちは分野の専門家にインタビューする記述的研究を行いました。インタビューデータに基づき、ソリューションの実装時に直面する最大の障害は品質を保証するための十分な時間の不足であることが強調されています。面接中、個人のスキルアップ、維持費、投資収益率の低さ、ツールの選択と統合など、いくつかの懸念が指摘されました。 この情報はKatalonの「The State of Quality Report 2024」でも検証されています。インタビューで言及された問題に対する解決策を提供する前に、既存のツールやアルゴリズムが存在するかどうかを比較評価し、指摘された懸念に対応するものがあるかどうかを確認しました。現在、インタビューで議論された困難に対処するための必要なツールやアルゴリズムが不足しています。
本研究では、可観測性データを活用してサポートの問題を早期(報告される前)に検出し、適切なテストケースを実行する革新的な手法を導入し、ソフトウェアシステムの信頼性と堅牢性を向上させています。この戦略は、観測可能性データを活用して異常を特定し、問題の可能性と関連性を確立し、問題の根本原因を明らかにする可能性が高いターゲットテストケースの実行を開始することに基づいています。提案されたソリューションは、ソフトウェア運用とテストの境界を埋め、サポートの懸念に対して積極的かつ迅速な対応を可能にすることを目的としています。提案されたソリューションでは、スイートにテストケースが欠けている場合に新たなテストケースを作成でき、テストカバレッジが向上します。提案された戦略は、インタビューやKatalon11、12、13、14の報告書で指摘された懸念にも対応することを目的としています。
制御理論の文脈における可観測性とは、システムの外部出力から内部状態をどの程度導き出せるかを指します。ソフトウェア工学の分野では、観測可能性の概念とは、ログ、メトリクス、トレース、イベント15、16、17などの出力を用いてソフトウェアシステムの状態を監視し理解する能力を指します。文献分析には、可観測性とそのソフトウェアテストにおける利用の検討が含まれています。しかし、このテーマに関する利用可能な文献は限られています。そのため、革新的な予防検査や関連研究についての議論も含めています。私たちの文献レビューはさらに3つの異なるグループに分類されています。
BogatinovskiらはCLogという文脈認識ニューラルネットワークおよびクラスタリング技術を提示 しており、不安定なログデータや不十分な障害カバレッジに対応するために、重要なサブプロセスを特定し、突然のコンテキスト遷移中の障害を検出することを目的としています。Busbyら19 は、匿名化されたテストケースを生成するログベースの手法を提案し、個人データを含まない複製のためのユーザーシーケンスを予測します。しかし、同時実行やロガーレベルの変動は依然として重要な制約として存在します。LeeとKang(20 )は、変動メカニズムが存在する場合における可観測性と制御性を向上させるためにソフトウェア製品ラインのテストアーキテクチャを実装することを提案しています。QEXモデル21 は、異なるテストソースからのデータを統合し、テスト中に明確で有用な情報を提供します。ラルとクマール22 は、インテリジェントテストを視認し制御できることの重要性を強調しています。彼らは、AI搭載の自動化を活用してテストをより速く、効率的かつ徹底的にすることを提案しています。Briandら23 は、Javaにおけるアスペクト指向プログラミングの適用を契約や不変量の効果的な計装化に示している一方、BaralとOffutt24 は誤ったテスト主張が「ブラインドテスト」を引き起こす問題を強調し、誤った挙動を特定できない問題を指摘している。
Rott25 は、Teamscale内の最新の分析や可視化が、テスターが問題や状況に特化した処理された成果物にアクセスできることで、ソフトウェアテストプロセスを重視していると論じています。CollinsとLucena26 は、本番環境にデプロイする前にCIパイプラインで多くのテストを実行することの重要性を強調しています。彼らは、レイヤーテストが製品の品質を確保し、サポートの問題を減らす良い方法だと言っています。
BugSwarm27 は、根本原因とその解を相関させることでCIテストの失敗を検証する方法を提供します。DudilaとLetia28 はホワイトボックスとブラックボックスのテスト手法を検討し、開発プロセス中のデバッグ作業を軽減するための一貫した戦略を提案しています。伏原らはPythonアプリケーションにおける「テスト匂い」を調査し 、テストコード管理を強化するためのコード変更による進行を分析しました。SUPERNOVA30 は、データ、自動化、機械学習を用いて品質保証を向上させるテストの選択と故障防止のためのシステムです。Araujo31 はソフトウェアの老化に焦点を当てた保守戦略を提案しています。この戦略は、コード変更が可能な場合は是正保守を用い、システム停止の可能性がある場合は予防策を用い、サービス障害の発生率を減らします。Andrewらは並列変異検査を調査しており 、これはクラスを繰り返し変異させ、テストし、再読み込みし、すべての変異が評価される過程です。Dunnらは、徹底的なテストの重要性を強調するために、コンポーネントに重みを割り当てるセキュリティ脆弱性指標を提案 しています。最後に、Huoらは連続集合インデックスを用 いて欠陥箇所を特定し問題を確認しています。これは、ソフトウェアアプリケーションにおけるほとんどの失敗したテストケースに根本原因がしばしば結びついていることを示しています。
Access restricted. Please log in or start a trial to view this content.
システムアーキテクチャとプロトタイプ概要:
本研究は、可観測性データと大規模言語モデル(LLM)を活用し、支援の問題解決をさらに改善するために、積極的な品質工学アプローチを示す改良され適応可能なプロトタイプシステム「PreventativeTestPro」を提示します。このシステムは、異常検出、根本原因分析、合成モニタリング、観測可能性データ、生成AI統合を用いて未解決カバレッジのテストケースのインテリジェント実行と開発を自動化することで、現代のソフトウェア提供課題に取り組もうとしています。アーキテクチャはモジュール式で、図 1に詳細に示されているように、3つのコアコンポーネントから構成されています:オブザーバビリティデータ収集器およびアナライザー、GenAI駆動インテリジェンス層、テストオーケストレーションおよび実行エンジンです。

図1:提案されたシステムの入力出力。 オブザービリティデータに加え、オブザーバー出力、テストリポジトリ、マッピングルールが入力として提供され、BHRAMARIテストベッドはAI駆動のテストベッドを構築し、テストケースの堅牢性を高めます。提案されたシステムは、異常の計測、AIによる推奨、関連するテストケースの実行、文書化と報告、さらには欠落したテストケースの特定と作成を行っています。 この図の拡大版はこちらをクリックしてご覧ください。
図2 は提案されたアプローチのアーキテクチャを示しています。図はシステムの入力、処理、出力を示しています。また、システムの包括的な描写を提供し、それを説明に翻訳して基礎的な特徴の理解を深めます。

図2:提案されたシステムのシステムアーキテクチャで、観測性データ収集器とアナライザー、GenAI駆動のインテリジェンス層、テストオーケストレーションおよび実行エンジンを備えています。 この図は、PreventativeTestProシステムの内部アーキテクチャを示しており、3層に分かれています。オブザーバビリティコレクタ層は、ブラウザイベント、ログ、HARファイル、バックエンドログ、メトリクス、トレースなど複数のソースからデータを集約します。生成AIインテリジェンスレイヤーは、このデータを活用して根本原因分析を行い、異常の優先順位付けを行い、LLMを活用してテストケース(UI、API、マニュアル)やドキュメントを自律的に作成します。BHARAMARIモジュールは新たな試験台も設置します。テストオーケストレーションおよび実行エンジンは、不一致をテストケースにマッピングし、テストを同時に実行し、成果を評価し、エンジニアリングチーム、チケットシステム、ダッシュボードにリアルタイムの監督と解決監視を提供します。 この図の拡大版はこちらをクリックしてご覧ください。
観測データ収集・アナライザーモジュールはプラットフォームのセンサーシステムとして機能し、評価対象アプリケーションのデータを大規模かつ多面的に継続的に収集します。フロントエンド監視の場合、合成監視エージェントがブラウザ側イベント(ドキュメントオブジェクトモデル(DOM)構造、クリック、ホーバー、入力などのユーザーアクション、ネットワークおよびAPIのリクエスト・レスポンス情報をキャプチャするHARファイルを監視するために展開されます。PreventativeTestProはOBSERVERにも組み込まれており、ブラウザの機能向上を図っています。バックエンド監視はログ分析を対象としており、サーバー側の観察可能性情報が要求・処理されます。これにはアプリケーションログ、エラー、情報、デバッグメッセージ、スタックトレースおよび例外ログ、応答時間などのパフォーマンス指標、OpenTelemetryやNew Relicなどの技術を用いたトレースが含まれます。システムはユーザーのトラフィックやインタラクションをシミュレートする合成エージェントと連携し、ログコレクターはリアルタイムのデータを凝縮します。収集されたデータは構造化されたフォーマットに正規化され、他の処理ユニットに渡されてさらに解析されます。
PreventativeTestProの本質は、GPTなどの大規模言語モデル(LLM)を用いて観測可能性データを読み取り分析し、文脈化・応答を生成するGenAI駆動のインテリジェンスレイヤーです。このモジュールは根本原因分析を行います。これは、特定のコード行のNullPointerExceptionや、初期化されていない変数のような問題の推定原因を理解可能な形で技術的故障を説明するために、根本原因ログやトレースを解釈するプロセスです。テストケース生成では、例外パターンや一連のイベントを実行可能なテストスクリプト(例:SeleniumやAPIテスト)に変換して自動テストを生成しますが、品質保証スタッフが実行可能な人間が読みやすいテスト手順も生成します。APIテストは、HARやトレースログを期待されるアサーション付きの一連のAPIリクエストへと変換することで進化し、生成されたすべてのテストケースはBHRAMARIとの統合により効果的なテストベッドでさらに強化されています。分析されたシステムの挙動に応じて、さらなる改善、テストカバレッジの強化、CI/CD統合の機会が推奨システム内で提案されます。AIエンジンは、プロンプトエンジニアリングとコンテキスト強化を通じて構造化された観察可能性データを用いてログコンテキストをプロンプトテンプレートで提示し、構造化クエリをLLMに渡し、最終的にコードスニペット、テストケース仕様、自然言語ドキュメントなどの機能的な出力を生成します。
テストオーケストレーションおよび実行エンジンモジュールは、テストの優先度、スケジューリング、実行を担当し、コード変更カバレッジの詳細、タグ、異常マッピングに基づく自動検証を可能にします。テストのマッピングと選択は、マッピングルールエンジンを用いてマップや計測パターンの異常を既知のテストケースと関連付け、確立されたマッピングに従ってテストケースを実行することを含みます。並行テスト実行の機能により、機能テスト、パフォーマンステスト、セキュリティテストなど、異なる環境で複数のテストを同時に実行でき、Selenium、JMeter、ZAPを自動化パイプラインのツールとして活用する調整が可能です。フィードバックループの実装により、実行結果が記録され、テスト失敗時にはJiraやAzure DevOpsなどのサポートシステムに変更が伝えられ、追跡・解決されます。
仮説:
H1(運用効率):観測データとAI駆動のインテリジェンスの融合は、運用指標を向上させると考えられており、特に平均解決時間(H1a)、平均解析時間(H1b)、平均本番問題検出時間(H1c)、本番での修正展開平均時間(H1d)を短縮する。これらの変更により、検知、分析、展開を迅速化しつつ、システムのダウンタイムを最小限に抑え、サービスレベル契約(SLA)要件(H1e)の達成が容易になるはずです。
H2(テスト効果):ソフトウェアテストの効果は、より多くのテストカバレッジ(H2a)、テストケースの並列実行(H2b)、スマートテスト優先順位付け(H2c)によって向上すると考えられています。AI生成の推奨(H2d)もテストや運用ワークフローの支援が期待されています。これによりバグの発見が速くなり、フィードバックループが速くなり、予防的かつ長期的な品質保証の実践が支えられます。
範囲と読者:
このプロトタイプは、システム全体の設計、主要なアイデア、そしてPreventativeTestProフレームワークのセットアップと運用方法をステップバイステップで示しています。また、適切なテストベッドやサンプル入力の設置方法や問題解決のヒントについても詳しく説明しています。この内容は、すでにJavaの基礎を知っているソフトウェア品質エンジニア向けで、予防テストを使ってソフトウェアをより信頼性と効率的にする方法を学びたい人向けです。
環境のセットアップ:
補足ファイル1 には、PreventativeTestProとの通信に必要なステップバイステップの説明とプログラムが含まれています。これには、必要な環境のインストール手順、ツールのサービスの開始・停止方法、ツールの基本的な使い方の明確な説明が含まれます。より詳細なドキュメントや、高度なツールの使い方、セットアップ手順、その他の整理に関する詳細については、プロジェクト専用の公式GitHubソースを参照してください。https://github.com/sohambpatel/PreventativeTests/wiki の場所にある特定のWikiページと、https://github.com/sohambpatel/PreventativeTests?tab=readme-ov-file/readme のメインREADMEです。
サンプル入力:
サンプル入力ファイルはGitHubリポジトリの「https://github.com/sohambpatel/PreventativeTests/tree/main/preventativetestframework/Inputs」で見ることができます。フレームワークはこれらのファイルの事前設定されたテストケースやデータセットをすぐに実行できます。これらは環境設定の確認や、このプロトコルで説明されている結果を得るための参照入力として使用されます。
サンプル出力:
GitHubリポジトリ(https://github.com/sohambpatel/PreventativeTests/tree/main/preventativetestframework/SampleOutputs)には、予防テストフレームワークの出力データの具体的なサンプルが生形式で収録されています。これらのファイルを通じて、ユーザーは生成されたレポートや指標のレイアウトや詳細を直接確認でき、運用中に達成した成果を実演できます。このガイドは、データパイプラインを理解し、実験プロセスの再現における予想されるフレームワークの挙動を確認するのに役立ちます。
実行プロトタイプ:
このセクションでは、PreventativeTestProフレームワークの使い方について、詳細なステップバイステップのガイドを提供します。ユーザーがワークフローを再現しやすくするために、各段階は順番に説明されています。このセクションでは、実行手順を構造化された形式で提示し、結果の再現、重要なチェックポイントの提示、そしてPreventativeTestProフレームワークがさまざまな実験的または運用環境で一貫して使用できるようにします。
このステップでは、PreventativeTestPro GUIを使って最適な予防テストワークフローを選択できます。 図3 は5つの選択肢を示しており、それぞれがテストプロセスの異なるステップを表しています。テストを並行して実行する、既存のテストケースを優先して出力を監視してテストスイートを作成する、手動でテストケースを作成する、自動化されたテストケースを作成する、そして根本原因の特定です。ユーザーが選択をすると、指定されたワークフローが始まります。その後、AI駆動のテストケース生成や根本原因分析などの追加モードを後期段階で追加できます。このよく整理されたインターフェースは、予防テストの研究を行い、繰り返し行うための小さな部分に分解する手段を提供します。

図3:システムのユーザーインターフェース1。 この図はPreventativeTestProのユーザーインターフェースを示しており、5つの異なる予防テスト方法から選択できます:1. 予防テスト(並列実行:テスト開始)、2. 予防テスト(合成アプリモニタリングに基づく最終化テストスイート)、3. 予防テスト(GenAIを用いた手動テストケース生成)、4. 予防テスト(GenAIを用いた自動テストケース生成)、5. 予防テスト、 GenAIを用いた根本原因分析。一度に選べる選択肢は一つだけです。モジュール設計により予防検査が容易になり、AIによるテスト作成や診断機能も追加されています。 この図の拡大版はこちらをクリックしてご覧ください。
図4 はフレームワークの並列実行インターフェースを示しています。このステップでは、ユーザーがテストしたいアプリケーションのURLと設定設定が記載されたプロパティファイルの絶対パスを入力します。入力が設定された後、ユーザーはテスト開始ボタンをクリックして同時にテストを開始できます。このボタンはテスト対象のウェブサイトを監視し、セキュリティ、パフォーマンス、コンソール、JavaScriptログも生成します。進行中の実行を停止するには、テストを停止するボタンをクリックしてください。「推薦取得」ボタンを使うと、記録されたログからAI駆動の洞察を得ることができます。この設計により、複数のテストカテゴリ(機能、パフォーマンス、セキュリティ)が同時に実行されることが保証され、問題をより迅速に発見できるようになります。

図4:システムのユーザーインターフェース2。 この図はPreventativeTestProフレームワークの並列実行モードを示しています。ユーザーはターゲットアプリケーションのURLと設定詳細を含むプロパティファイルへのパスを指定します。オプションには、Start Testing(機能、セキュリティ、パフォーマンステストを並行して実行しログを記録)、Stop Testing(実行を停止)、Get Recommendation(ログや指標からAI駆動の洞察を得る)があります。 この図の拡大版はこちらをクリックしてご覧ください。
図5 はPreventativeTestProフレームワークのモニタリングベースのテスト最終化インターフェースを示しています。このステップでは、ユーザーは監視出力ファイルのパス、エラーや例外ノードを取得するためのJSONパスクエリ、そして作成されたケースを保存するためのテストリポジトリパスを設定します。入力が設定された後、ユーザーはまずそれに対応するクラスとメソッドの名前を取得し、テストプルから見つけたクラスとメソッドに基づいてテストケースをソートできます。この優先順位付けのステップは、モニタリングデータを活用してテストケースを効果的にランク付けする方法を示しています。

図5:システムのユーザーインターフェース3。 この図は、合成モニタリング出力を用いてPreventativeTestProフレームワークでテストスイートの優先順位付け方法を示しています。ユーザーは監視出力ファイルのパス、例外やエラーを取得するためのJSONパス、そしてオフラインのテストリポジトリへのパスを入力します。「Get class/method name」と「Get Test Cases」オプションを使って、マッピング異常を実行可能なテストケースに変換できます。これにより、ランタイムの問題がテストプロセスに含まれるようになっています。 この図の拡大版はこちらをクリックしてご覧ください。
図6 はPreventativeTestProの手動テストケース生成インターフェースを示しています。このステップでは、ユーザーが異常を示すスタックトレースファイルの絶対パスと設定プロパティファイルへのパスを提供することで、異常を示すスタックトレースファイルの場所をプログラムに伝えます。入力が設定されたら、「テストケース生成」オプションを実行し、異常を構造化された手動テストケースに変換します。これにより、以前に発生したランタイムエラーがテストプロセスに必ず含まれるようになっています。このフレームワークはプロセスを自動化することでテストケースの作成を容易にします。これにより手作業が減り、テストカバレッジが向上し、テストの信頼性が向上し、同じ問題の再発を防ぎます。このステップは、問題を見つけることと、問題が起こる前に品質を確実に保つこととの間に非常に重要な役割を果たします。

図6:システムのユーザーインターフェース3。 この図はPreventativeTestProのテストケース生成インターフェースを示しています。異常スタックの痕跡をBehavior Driven Development(BDD)で手動テストケースに変換し、それを利用できるようにします。ユーザーはスタックトレースファイルとプロパティファイルのパスを渡し、「テストケース生成」をクリックすると、発見された失敗に一致するケースを自動的に作成します。これにより、実行時の問題は常に繰り返し可能な回帰テストに変換されます。 この図の拡大版はこちらをクリックしてご覧ください。
図7 はPreventativeTestProの自動テストケース生成インターフェースを示しています。このステップでは、ユーザーが観測可能性のJSON出力ファイルの絶対パスとプロパティの設定ファイルへのパスを示します。「自動テストケース生成」ボタンをクリックすると、システムは監視データを処理し、同じ問題を示すテストケースを作成します。

図7:システムのユーザーインターフェース4。 この図は、PreventativeTestProの自動テストケース生成インターフェースを示しており、観測可能性データを使って実行可能なテストを作成します。ユーザーはプロパティファイルのパスと観測可能性のJSON出力ファイルを指定します。その後、「自動テストケース生成」をクリックして、実行可能なスクリプトを作成します(SeleniumおよびTestNG形式)。 この図の拡大版はこちらをクリックしてご覧ください。

図8:システムのユーザーインターフェース5。 この図は、PreventativeTestPro for Root Cause Analysis(RCA)の異常計測インターフェースを示しています。ユーザーはプロパティファイルとスタックトレースファイルのパスを入力し、その後RCAを選択してAI駆動の解析を開始します。このステップでは、検出された異常を構造化された診断洞察に変換し、故障を繰り返し修正でき、問題に特化した方法で修正できるようにします。 この図の拡大版はこちらをクリックしてご覧ください。
トラブルシューティング:
表1は アプリケーションコードに関する最も重要なトラブルシューティングポイントを示しています。これらのポイントは、PreventativeTestProフレームワークを実行する際に発生するコードレベルの問題を修正する方法を素早く覚えておくための方法です。プロジェクトのドキュメントは、アプリケーション全体の機能に影響を与える問題のトラブルシューティングを助けたい読者向けに、より多くの情報とステップバイステップの指示を提供しています。全リソースはリンク https://github.com/sohambpatel/PreventativeTests/wiki/How-to-use%3F から入手できます。この追加の参照により、ユーザーはコーディングの問題を解決するだけでなく、機能のトラブルシューティング方法も学べるようになり、フレームワークをより効果的に活用できるようになります。
| エラー挙動 | 根本原因 | どうやって直せばいい? |
| 申請は始まっていません | Javaパスは設定されていません | 環境変数でJAVA_HOMEを設定します。 |
| 起動時にサーバーが故障します | ポート8080/9090の使用中(特にDocker使用中) | Docker ポートマッピングの更新 |
| 生成AIコンテンツは無効です | トークンが期限切れになっている可能性があります | トークンを生成し、config.propertiesを更新してから入力してください |
| フレームワークによって生成されたブラウザインスタンスはネットワークに接続していません | ZAPサーバーが稼働していないか、ZAPの認証情報が間違っているかのどちらかです | アプリケーションを実行する前にZAPをオンにしてください。もし動作中でも問題が続く場合は、config.propertiesのZAP認証情報を入力として入力する前に更新してください |
表1:よく提案されるシステムエラーと迅速な解決策。 この表は、問題を解決するために適用できる一般的なアプリケーション固有のエラー、トラブルシューティング、そして迅速な対処法を示しています。
Access restricted. Please log in or start a trial to view this content.
当初は、さまざまな業界と協力して実施されたケーススタディから得られた成果をリアルタイムで共有しました。さらに、このフレームワークとアルゴリズムを用いたベータテスターから導き出された結果と、結果の妥当性に対する潜在的なリスクに関する最終的な観察も提供しています。
業界のケーススタディ結果:
実用的な応用に焦点を当て、サポートに関する懸念に対応する研究に基づき、4つのソフトウェア企業と提携し、フレームワークを共有しリアルタイムの結果を得ています。業界への参加と成果は、その実用性と実際の利用の利点を示しています。
ケーススタディ1:
GazonTechは、ネットワーキング、ストリーミングプラットフォーム、オンラインゲーム、ビデオ会議、スマートホームオートメーションを専門とするソフトウェア企...
Access restricted. Please log in or start a trial to view this content.
本研究では、合成監視、観測可能性データ、生成AI駆動の自動化を統合し、ソフトウェア品質保証を向上させる包括的なテストおよび観測可能性プラットフォーム「PreventativeTestPro」を紹介します。システムは、観測データ収集器とアナライザー、生成AI駆動の知能層、テストオーケストレーションおよび実行エンジンの3つの基本モジュールで構成されています。これらのコンポーネントは、リアルタイムのシステム動作がテストケースの作成、故障検出、継続的なテスト検証を導くフィードバックループを形成します。この手法は、知的で文脈に敏感なテスト生成をソフトウェア開発プロセスに直接組み込むことで、古典的なブラックボックスおよびホワイトボックステスト技術を統合しています。
本研究の科学的貢献は、大規模言語モデル(LLM)を革新的に応用し、複雑な観察可能性データを分析し、根本原因分析(RCA)、テストケース生成、システム挙動の提案など、実行可能な洞察を得ることです。PreventativeTestProは、ログ、トレース、HARファイル...
Access restricted. Please log in or start a trial to view this content.
著者らは、本論文で報告された研究に影響を与えた可能性のある競合する財政的利害関係や個人的な関係は既知のものではないと述べています。私たちは、Geminiが文法の磨き上げや読みやすくするための言い換えにのみ適用されたことを証言しています。正しく倫理的に正しいとするために、著者たちはAIが提案したすべての変更を慎重に修正し、元の科学的含意を保持しました。
著者は、本研究を通じて以下の組織から提供された多大な支援と協力に感謝の意を表します。これらの企業との共同実験ケーススタディは、提案されたツールと方法を裏付ける上で極めて重要でした。実験段階で実用的な環境へのアクセス、技術的知見、貴重な意見を提供してくださったGazonTech、Lopa Engineering、Afour Technologies、QJ Technologies、SecureLayer7に感謝申し上げます。彼らの積極的な関与により、研究成果の実用的な意義と利用可能性が大幅に向上しました。著者は、彼らが学術研究に参加する準備と、ソフトウェア工学およびサイバーセキュリティ分野における革新と継続的な向上への献身に深く感謝の意を表しています。
Access restricted. Please log in or start a trial to view this content.
| Name | Company | Catalog Number | Comments |
|---|---|---|---|
| アパッチ・メイヴン | アパッチソフトウェア財団 | 3.9.6 | Javaプロジェクト向けの依存関係およびプロジェクト管理ツール |
| ChatGPT(GPT-3.5 Turbo API) | OpenAI | https://platform.openai.com/api-keys | ログからAIベースのテスト推奨を作成し、手動テストケースを作成し、自動化テストケースを作成し、根本原因分析を得るために |
| コンピュータ(開発/テストマシン) | 標準デスクトップ/ノートパソコン | - | PreventativeTestProの開発、実行、テストに使用されます |
| ディスクスペース | - | - | ログ、レポート、テストアーティファクト用に推奨される空きディスク容量は少なくとも10GBです |
| Docker | Docker Inc. | 27(https://docs.docker.com/desktop/setup/install/windows-install/) | 環境間での再現性を確保するためのコンテナ化に使用されます |
| ギット | Git SCM | git バージョン 2.45.2.windows.1 | 開発およびコラボレーションに使用されるバージョン管理システム |
| GitHubリポジトリ | GitHub | https://github.com/sohambpatel/PreventativeTests | ソースコード、ドキュメント、データセット、例を含む公開リポジトリ |
| Google Chrome | グーグル | 140.0.7339.128 | 合成監視およびテストに使用される主要ブラウザ |
| ジャワ | Oracle / OpenJDK | 21.0.2 | PreventativeTestProのソフトウェア開発および実行に使用されます |
| オペレーティングシステム | プラットフォーム独立 | - | ToolはJavaとMavenがインストールされているすべてのOS(Windows、Linux、macOS)で動作します |
| オワスプ・ザップ | OWASP財団 | 2.14.0 | セキュリティスキャンおよび脆弱性検出ツール |
| プロセッサ | - | - | 並列実行およびAI処理にはIntel i5以上(または同等)が推奨されています |
| RAM | - | - | テストおよびブラウザベースの監視には最低8GBのRAMが推奨されています |
Access restricted. Please log in or start a trial to view this content.
Request permission to reuse the text or figures of this JoVE article
Request Permission