frontend regression validator

フロントエンド回帰バリデーター（フレッド）

フレッドは、Webサイトの2つのインスタンスを比較するために使用されるOpenSourceの視覚回帰ツールです。フレッドは、現在（ベースライン）とウェブサイトの更新バージョンを比較することで機能が破らないようにすることを目的として、自動視覚回帰テストを担当します。フレッドは以下を比較します：

• コンソールとネットワークログ
• ビジュアル：スクリーンショット分析
• ビジュアルAI：機械学習技術を使用したスクリーンショット分析

視覚分析では、ベースラインおよび更新されたサイトのスクリーンショットの正規化された平均二乗誤差と構造類似性インデックスを計算しますが、視覚AIは、画像セグメンテーションの機械学習技術を適用して高レベルのテキストと画像の視覚構造を認識することにより、レイアウトとコンテンツを独立して変化させます。これにより、動的なコンテンツが誤検知をもたらす影響が軽減されます。

必要に応じてフレッドを使用してください。

• スクリーンショットの比較
• 自動レイアウト/コンテンツ検証

フレッドはスケーラブルになるように設計されています。内部キューがあり、利用可能なRAMとCPU（またはGPU）の量に応じてWebサイトを並行して処理できます。

注：バージョン1.0のリポジトリ全体は_fred-v1で利用できます。 V2.x（現在のバージョン）には、MLモデルをトレーニング/再訓練するコードが含まれていないことに注意してください。それを行う必要がある場合は、V1フォルダーの元のコードを確認してください。モデルは同一です。したがって、カスタムトレーニングを受けたモデルを作成する場合は、V2にプラグインすると機能します。

フレッドを始めましょう

FredをDockerとして、またはローカルプロセスとして開始できます。

QuickStart Docker

ソフトウェアをクローンして実行したい場合は、DockerFileを提供しています。それを実行するには：

git clone https://github.com/adobe/frontend-regression-validator.git
cd frontend-regression-validator/docker
docker build --no-cache -t fred .
docker run -p 5000:5000 -m 8g --memory-reservation=8g --oom-kill-disable=True --memory-swap 8G fred

メモリのエラーが発生している場合でも問題が発生した場合は、UI Dockerアプリからより多くのメモリを割り当てます。ツールバーのDockerアイコンをクリックして、 Preferences移動します - Advancedに進み、特にML（オプション）を使用する場合は、スライダーを8GB以上に引きます。 Dockerfileを使用する代わりに、またはDockerに割り当てられたメモリat least 8GB, prefferably 16GBに増やすことをお勧めします。

ローカルで開始します

chromedriverをインストールしていることを確認してください。持っていない場合は、次のようにMacにインストールします。

 brew tap homebrew/cask && brew cask install chromedriver

またはLinuxで：

 sudo apt-get install chromium-chromedriver

次に、以下を実行します。

 git clone https://github.com/adobe/frontend-regression-validator.git
cd frontend-regression-validator
pip install -r requirements.txt
cd fred/ml
cat model_files.bz2.parta* > model_files.bz2
tar xjf model_files.bz2
cd ..
python3 run.py

これにより、Webユーザーインターフェイスを提供するだけでなく、リクエストに応答するフラスコインスタンスが起動します。 QuickNote：使用--portリスニングポートを指定するには、デフォルトでは5000に耳を傾けます。フレッドのスタートアップパラメーターの詳細については、こちらをご覧ください。

フレッドを使用してください

Fredとの相互作用は、Web UIまたはAPI呼び出しによって行われます。 UIを使用すると、ユーザーがAPIエンドポイントに呼び出しを送信して結果を表示できます。

Webインターフェイスを開くには、 http://0.0.0.0:5000/static/submit.html 5000/static/submit.htmlに移動します（それに応じてポートを調整します）。必要なすべてのフィールドを入力し、ジョブを実行し、完了するまで待ちます。ヘッダーのJobsリンクをクリックして結果を表示します。

APIを使用するには、こちらの専用API Readmeをご覧ください。

フレッドがどのように動作するかを見落としています

Fredは、Webサイトの比較を実行するリクエストを受信するまで待機します（ /api/verifyへの呼び出しを投稿します）。クロールプロセスを開始します。 Get Call to /api/viewjobsですべてのジョブを表示し、PARAMETERとしてジョブIDを提供するget to /api/resultsで特定のジョブのステータスを取得することをリクエストできます。

• そのため、フレッドへの入力は、比較するURLのペアです。

• このプロセスは、フレッドがURLをクロールして複数のページを抽出して比較し、各ページをレンダリングしてスクリーンショットを撮影することから始まります。

• コンソールとネットワークログが比較されます。

• 各スクリーンショットが分析されます（指定された解像度ごとに、ベースライン/更新されたスクリーンショットのペアとして）。

• 有効にすると、各スクリーンショットペアもML分析を受けます

• 結果はローカルに保存されます（ユーザーは、 statusがDoneように設定されるまで、および/または何らかのerrorが設定されるまでAPIを介して定期的にチェックする必要があります。）

• その結果、 reportキーに多くのスコアが含まれているJSONオブジェクトがあります。 overall_divergenceスコアは、ネットワーク、視覚的およびAI-Visual（有効な場合）の発散の加重合計です。 0のスコアは、完全な一致（ベースラインと更新の差はありません）を意味しますが、より高いスコアは最大100差を強調します。

• 必要に応じて、視覚インターフェイスを使用して結果をすばやく調査します。それ以外の場合、 reportは、RAW画像へのリンクと、Fredを自動化された方法で使用する場合の違いを強調する分析画像も含まれています。

フレッドはスケーラブルになるように設計されているため、2つのコンポーネントの2つのcrawlerで論理的に分割されていますML crawlerコンポーネントは、ユーザーが対話するメインエントリポイントです。 MLコンポーネントは、 crawlerコンポーネントと同じコードですが、API呼び出しをリスニングする別のエンドポイントです。この分割の背後にあるロジックは、GPUは高価であり、CPUはそうではないということです。したがって、多くのクローラーを使用すると、いくつかのGPUがFredインスタンス（ MLコンポーネントと呼ばれる）を有効にしてML分析を実行できるようにリクエストを行うことができます。

たとえば、毎日分析する1000のWebサイトがあるシナリオを想像してください。それぞれが32GB RAMと8つのVCPUを備えた10個の仮想マシンを作成します。各インスタンスは、100 /api/verifyコールを受信します。 --crawler_threadsを5に設定したと仮定します。つまり、5つのWebサイトを同時にクロールできることを意味します。さらに、4つのGPUを搭載したGPUマシンが1つしかないため、 MLコンポーネントを呼び出すフレッドインスタンスを起動します。このインスタンスでは、 --ai_threads 4に設定します。つまり、4 mlの検証を同時に実行します。次に、 crawlerコンポーネントへのPost API要求のそれぞれで、 ml_address mlコンポーネントのアドレスに設定します。今起こるのは、 crawlerコンポーネントが終了し、Webサイトのペアをクロールして分析する（非AA）、 MLコンポーネントにスクリーンショットを送信し、それらを分析するためのリクエストが送信されることです。 mlコンポーネントはこのリクエストをキューに追加し、GPUが利用可能になると比較が実行されます。終了すると、その分析の発信crawlerコンポーネントに自動的に報告されます。基本的に、このアプローチは、利用可能なテストマシンの数とともに直線的にパフォーマンスをスケーリングします。

パフォーマンス分析

Fred Runtimesは、サイトの複雑さによって大きく異なります。ほとんどの時間はクローラーコンポーネントで費やされています。（残念ながら）ウェブサイトを読み込むことは決定論的なプロセスではないためです。ウェブサイトが単純にハングアップしたり、ポップアップがランダムに表示されたり、外部リソースがロードを拒否する場合があります。内部的には、これに唯一の救済策があります。何か恐ろしいことが起こった場合にウェブサイトをリロードする一種のtry-catch 。しかし、これは、ページがロードされたと言ってから数秒後に待っているという事実と、動的なコンテンツを発見するために繰り返されるスクリーンショットが劇的にクロール時間を増やすという事実と相まって。

クロール部分は通常、クロールされたページの数に応じて2〜10分かかります。

視覚分析（各スクリーンショットが最大20メガピクセルに制限されている場合）は、画像ペアごとに約5〜10秒かかります。各追加解像度は、別の画像ペアのセットを意味します。

AI（ML）視覚分析は、GPUで画像ペアごとに0〜30秒かかります。 GPUは、ML PARがU-NET（積み重ねられた畳み込み層）であるため、古いK80でさえ非常に速く実行されます。いつでもCPUで実行できますが、画像ペアごとに30秒ではなく、画像ペアごとに5分間待つことができます。

全体として、ML対応のクロールの経験則は終了し、ページごとに1分以下です。