手でログに触れないでください！ 自動テストを使用して分析時間を短縮する方法

最近、「Unified Frontal System」（ESF）プログラムで、テストシナリオの自動化に多くの注目が集まっています。 理由は客観的であり、プログラムの個々のサブシステムの成熟度レベルと回帰テストの量の増加に関連しています。

機能のボリュームが絶えず増加すると、自動テストの数が雪崩のように増加し、それに伴い、実行結果を分析してエラーの原因を見つける時間が増加します。 時間を短縮し、ログの手動解析を猫に任せた方法について読んでください。




実行結果からのデータ量は、エンジニアにとって重要な値に達し、欠陥を見落とすリスクの増加、データ分析の質の低下、意思決定の速度の低下を伴います。

実際には、固有の問題の実際の数は、テスト中に記録されたエラーの10分の1であることが示されています。

エンジニアが同じタイプのエラーのセットを迅速に決定することは困難です：バグ追跡システムに移動して手動で同様のソリューションを見つけ、メールで通信を読み、Confluenceを調べ、システムの適用部分のログファイル（ログデータベース、WebSphereアプリケーションサーバーファイル）から必要な抜粋を見つける必要があります、必要なスクリーンショットを見つけて勉強し、テスト手順のビデオを見てください。 もちろん、同様の解決策を探すことはできませんが、重複するオープンな欠陥を作成するリスクがあります。 時間を節約するために、エンジニアは不完全な情報を示す欠陥を作成することができます。これにより、修正時間が長くなり、洗練の品質が低下します。

この時点で、ESFプログラムで自動化システムを作成する必要が生じました。UnifiedLogfile Analyzer、または簡潔にULAと呼びましょう。これにより、2つの目標を達成できます。

• 自動テストの結果の分析時間の最小化;
  
• 重複する欠陥の数を最小限にします。
  

どこから始めましたか？

システムの設計と開発は、完全に自動化チームの肩にかかっていました。 実際、彼らは彼らの便宜のためにシステムを自分たちで作成しましたが、プログラムの現在のタスクのフレームワーク内だけでなく、将来的に適用される可能性がある製品をユニバーサルにすることを決めました。

技術スタックとして次のものが選択されました。

• 参照データ、履歴を保存するDBMS Oracle 11g。
  
• 帯状疱疹ハッシュを保存するためのOracle TimesTen In-Memory Database 11g。
  
• マイクロサービス用ジャージ。
  
• フロントエンドのJSを反応させます。
  

ULAは、自動テスト自体（XML、CSV、スクリーンショット、ビデオ）からのデータ、およびテスト済みサブシステムの該当部分（WebSphereログファイル、ジャーナリングデータベースからのデータ）からのデータを使用します。



システムは分散されており、いくつかのモジュールで構成されています。

• 自動テストログ分析エージェント。
  

現在、アリュールv.1.4、vのエージェントが開発されています。 1.5およびセレニティ。 エージェントはオープンAPIにアクセスし、WindowsまたはLinuxを実行します。

• プラグインジェンキンス;
  

自動テストをエージェントに転送するためのエージェントを管理します。

• Mavenプラグイン;
  

Jenkinsプラグインの代替ソリューション：実行結果は、mavenを使用してJenkinsをバイパスしてダウンロードできます。

• フロントエンド部分の機能のために、新しいメッセージを受信する機能、起動の完了に関するイベントを受信する機能を備えたマイクロサービスのセット。
  
  
• React JSに基づくフロントエンド。
  
• Oracle 11gを実行しているデータベース。
  
• テスト結果を特定のチャネルに送信するための通知サービス。
  

結果を受信するためのAPIは公開されています。システムはJenkinsおよび開発されたエージェントなしで使用できます。 この場合、自動テストまたはその他の補助ソフトウェア自体が、データロード仕様に従って、テスト中にメッセージを送信する必要があります。

メッセージ受信サービスは非同期に動作します。最初に、メッセージは処理キューに入ります。これにより、自動テストの起動時間に対するシステムの影響が最小限に抑えられます。

現時点では、いくつかのサブシステムが実装されており、テスト中です。詳細については検討します。

エラーメッセージ集約サブシステム

このサブシステムには次の機能があります。

• 自動テストからメッセージを受信します。
  
• 標準レポートの解析：APIテストの魅力とUIテストのセレニティ。
  
• ファジー検索を使用したメッセージ集約。 ファジー重複テキスト（シングル）を検索するためのアルゴリズムが基礎として選択されました。
  
• エラーパターンの自動確立（教師なしのトレーニング）。
  

決定サブシステム

このサブシステムでは、自動テストの実行中に受信したエラーに関する情報をさまざまなデータで強化する機会がユーザーに与えられます。

スクリーンショット

起動後、UIテストのスクリーンショットは数日間ディレクトリに保存されます。 この間に、打ち上げが正確に分析されると考えられています。 打ち上げが分析されなかった場合、それは必要ありませんでした。 分析後、スクリーンショットファイルは処理サーバーにコピーされ、無期限に保存されます。

テストビデオ

ビデオ録画は、テスターの要求に応じて作成され、グラフィカルインターフェイスをチェックするテストに対してのみ作成されます。 それらを操作するためのロジックは、スクリーンショットを操作するためのロジックに似ています。

Db

ESFの各サブシステムは、特別なデータベースにデータを記録します。 マーカー（ユーザーセッション）に基づいた自動テストステップの分析中に、ジャーナルデータベースのエントリがULAデータベースにコピーされます。

システムログを含むフラットテキストファイル

それらを取得するロジックはより複雑です。ユーザーセッションに加えて、境界時間値が追加され、その中の特定のファイルとセグメントを検索します。

すべての情報は1つの画面でシステムによって収集され、ユーザーは決定を下すように求められます。 ここでは、同様の決定を行った履歴のデータを表示し、関連性でソートし、エラーを既存の決定にバインドするか、新しい決定を作成します。 新しいソリューションを作成するときに、欠陥を作成することができます。 主な欠陥フィールドは、ULAで利用可能なデータに基づいて自動的に入力されます。 スクリーンショットとログを含むファイルは自動的に添付されます。

アラートサブシステム

特にテスト環境の管理者向けに、フィルター内の特定の値に該当する重大なエラーに関するアラートのサブシステムが開発されました。

たとえば、TCPレベルでサービスが利用できない、HTTPエラー（404、500）、および管理者の迅速な対応を必要とするその他の問題。 現在、テスト環境でインシデントを自動的に開始するタスクに取り組んでいます。

システムに実装された重複および集約を見つけるためのアルゴリズムのステップを簡略化した形で説明しましょう。

• ステップ1 テキストの正規化。
  

正規表現を使用してシステムに入るメッセージ（通常はスタックトレース）には、句読点、あらゆる種類の括弧、サービス文字などの「余分な文字」が消去されます。 出力は、スペースで区切られた単語の文字列です。

正規化されたテキストの例：
「口座の金額は指定された金額だけ変更されていません。口座の予想額は、173.40ユーロの補充後の残高173.40ユーロです。」

• ステップ2 フレーズへの分離（シングル）。
  

分離は1ワード単位で実行されます。 フレーズ内の単語の数は、シングル長と呼ばれます。

5つの帯状疱疹セット：
「アカウントの金額は変更されていません」; 「アカウントで変更されていません」; 「アカウントは指定されたものに変更されていません」。 「指定された量だけ変更されていない」。 「予想された量だけ変更されました」。 「指定された金額、予想される金額」。 「指定された金額は予想金額です」; 「金額はアカウントの予想金額です。」

• ステップ3 MD5アルゴリズムを使用したシングルハッシュの計算。
  

テキストのハッシュの結果セットは、システムで確立されたすべてのエラーパターンのシングルハッシュとの比較が完了するまで、一時テーブルに保存されます。

エラーパターンの帯状疱疹の各セットに対して、ハッシュのセットから類似度が計算されます。
類似性（i）= SIMCNT * 2 /（TSCNT + THCNT（i））、
ここで、SIMCNTは2セットの一致する一意のハッシュの数、TSCNTは分析されたテキストの一意のハッシュの数、THCNT（i）はテンプレートiの一意のハッシュの数です。

• ステップ4 適切なエラーパターンが選択されます。
  

SIMILARITY = MAX（SIMILARITY（i））を検索します。
SIMILARITYが指定された類似性しきい値以上の場合、既存のテンプレート識別子がテキストに付加されます。

SIMILARITYが類似度のしきい値よりも小さい場合、正規化されたテキスト自体がテンプレートになり、帯状疱疹ハッシュのセットがデータベースに書き込まれます。

• 最終段階。
  
  

テストスイートの起動後、見つかったエラーはテンプレート番号によって集計されます。ユーザーは、起動中に発生した固有の問題の数を確認します。

アナログについて話しましょう

公正な質問は、たとえばEPAMのReport Portalなど、類似の製品がすでに市場に存在するときに、システムを自分で作成した理由です。

成熟した高品質で美しいソリューション。開発は4年以上を費やし、しばらくの間は無料で配布されています。

ただし、アプローチには違いがあります。比較の便宜上、これを表に示しました。

レポートポータル	統合ログファイルアナライザー
自動テスト自体のログの分析に重点を置いており、ログの欠陥を含む欠陥もある可能性があります	テストに成功したとマークされているが、エラーがある場合、または逆にテストが失敗したがエラーが登録されていない場合は、疑わしい自動テストをユーザーに示します
類似性を決定するアルゴリズムは、レーベンシュタイン距離を使用します	長い言葉では距離が重要であるため、このアルゴリズムは私たちには適していません このソリューションでは、Shinglesアルゴリズム（ http://ethen8181.imtqy.com/machine-learning/clustering_old/text_similarity/text_similarity.html ）を使用します
レポートポータルでは、この機能はまだ見ていません。 おそらく将来的に表示されます。	自動テストからの情報（エラーテキスト、スクリーンショット、テストのビデオ録画）は、システム自体の適用可能な部分（ファイル、データベース）からの情報で強化され、分析の品質が向上します。
レポート作成には多くの注意が払われます：グラフ、さまざまな統計	レポート機能を個別に実装する予定です
HP ALMとの統合なし	HP ALMとの統合があり、それは私たちにとって重要です
非リレーショナルデータベースMongoDBが使用されます。 このトピックについては、長い間議論することができます。	私たちの意見では、Oracle 11gのソリューションはリソース消費に関してより予測可能な動作をします

統合ログファイルアナライザー-私たちの経験、同僚の経験、市場にある既存のソリューションの分析を考慮して、ゼロから構築、開発したシステム。 システムは独学であり、バグがない場合でも、バグをすばやく見つけて正確に修正するのに役立ちます。
現在、生産的な方法でULAを開始しています。ESFプログラムの製品とサービスを展開します。 次の投稿では、最初の結果について説明し、事例を共有します。

私たちは解決策について議論し、アプローチについて議論し、コメントで経験と事例を共有することを嬉しく思います！