frontend regression validator

前端回歸驗證器（FRED）

弗雷德（Fred）是一種用於比較網站的兩個實例的OpenSource視覺回歸工具。弗雷德（Fred）負責自動回歸測試，目的是通過比較當前（基線）和更新的網站版本來確保功能不會破壞。弗雷德比較以下內容：

• 控制台和網絡日誌
• 視覺：屏幕截圖分析
• Visual AI：使用機器學習技術的屏幕截圖分析

視覺分析計算歸一化的平方誤差以及基線和更新站點的屏幕截圖上的結構相似性索引，而視覺AI則通過應用圖像分割機器學習技術來識別高級文本和圖像視覺結構來獨立地進行佈局和內容獨立變化。這降低了動態內容產生誤報的影響。

如果需要，請使用弗雷德：

• 屏幕截圖比較
• 自動佈局/內容驗證

弗雷德（Fred）設計為可擴展。它具有內部隊列，可以根據可用的RAM和CPU（或GPU）的數量並行處理網站。

注意： _fred-v1中可用版本1.0的整個存儲庫。請注意，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 ，然後將滑塊拉到8GB或更多，尤其是當您打算使用ML（可選）時。我們建議在本地運行它，而不是使用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的啟動參數的更多詳細信息。

使用弗雷德

與FRED的互動是由Web UI或API調用完成的。 UI僅允許用戶將呼叫發送到API端點並查看結果。

要打開Web接口導航到http://0.0.0.0:5000/static/submit.html 5000/static/submit.html（相應地調整端口）。填寫所有必需的字段，運行工作並等到完成。通過單擊標題中的Jobs鏈接來查看結果。

要使用API​​，請在此處查看專用的API讀數。

忽略弗雷德的運作方式

弗雷德（Fred）等待，直到收到執行網站比較的請求（發佈到/api/verify ）。它啟動了爬網過程。我們可以請求查看所有作業，並呼叫/api/viewjobs ，並獲得特定作業的狀態，並以a get /api/results提供作業ID作為參數。

• 因此，弗雷德的輸入是一對可以比較的URL。

• 該過程開始於Fred爬上URL以提取許多頁面以進行比較，然後渲染每個頁面並進行屏幕截圖。

• 比較控制台和網絡日誌。

• 分析每個屏幕截圖（作為基線/更新的屏幕截圖，對於每個指定分辨率）。

• 如果啟用，每個屏幕截圖對也會進行ML分析

• 結果將在本地保存（用戶必須通過API定期檢查狀態，直到設置status Done和/或設置某些error為止。）

• 結果是report密鑰中包含許多分數的JSON對象。 overall_divergence分數是網絡，視覺和視覺（如果啟用）差異的加權總和。得分為0意味著完美匹配（基線和更新之間沒有差異），而得分較高，最多100突出顯示差異。

• 如果需要，請使用視覺接口快速研究結果。否則，該report還包含指向原始圖像的鏈接以及分析圖像，如果您想以自動方式使用Fred，則突出顯示差異。

由於Fred設計為可擴展，因此在邏輯上分為兩個組件： crawler和ML 。 crawler組件是用戶與之交互的主要入口點。 ML組件雖然與crawler組件的代碼相同，但只是偵聽API調用的另一個端點。這種分裂背後的邏輯是GPU昂貴，而CPU卻不是。因此，我們可以有許多爬行者，又可以向啟用GPU的FRED實例（稱為ML組件）提出請求來執行ML分析。

例如，想像一個場景，我們每天有1000個網站進行分析。我們創建10台虛擬機，每台具有32GB RAM和8個VCPU。每個實例將接收100 /api/verify調用。假設我們將--crawler_threads設置為5，這意味著我們可以同時爬網5個網站。此外，由於我們只有一台帶有4 GPU的GPU機器，因此我們在其上啟動了FRED實例，我們將稱為ML組件。在這種情況下，我們將--ai_threads設置為4，這意味著我們同時運行4個ML驗證。現在，在每個帖子API請求上，我們將ml_address設置為crawler組件ml地址。現在將發生的事情是，每當crawler組件完成爬網和分析（非AI）網站對時，它將發送其ML組件的屏幕截圖並要求進行分析。 ml組件將在隊列中添加此請求，當有GPU時，它將在其上進行比較。完成後，它將自動報告給原始的crawler組件的分析。基本上，此方法與可用測試機的數量線性縮放性能。

績效分析

Fred Runtimes在網站的複雜性上差異很大。大部分時間都花在爬網組件中，因為（不幸的是）加載網站不是確定性的過程。有時，網站只是懸掛，或者隨機出現彈出窗口，或者某些外部資源拒絕加載。在內部，我們有唯一的補救措施：如果發生可怕的事情，可以重新加載網站的一種try-catch 。但是，這是一個事實，即我們在頁面上說加載後等待幾秒鐘，再加上重複的屏幕截圖以發現動態內容，大大增加了爬網時間。

爬行部分通常需要2-10分鐘，具體取決於爬行的頁面數量。

視覺分析（每個屏幕截圖最多限於20百萬像素）每個圖像對需要約5-10秒。每個額外的分辨率表示另一組圖像對。

AI（ML）視覺分析在GPU上的每個圖像對需要0-30秒。任何GPU都會做，即使是舊的K80也會非常快，因為ML PAR是U-NET（堆疊的捲積層）。您總是可以在CPU上運行，但是每圖像對可能會等待5分鐘，而不是每個圖像對30秒。

總體而言，啟用ML的爬網的經驗法則是每頁1分鐘或更短的時間。