Fred ist ein OpenSource -Tool für visuelle Regressionen, mit dem zwei Instanzen einer Website verglichen werden. Fred ist für automatische visuelle Regressionstests verantwortlich, um sicherzustellen, dass die Funktionalität nicht durch Vergleich einer aktuellen (Grundlinie) und einer aktualisierten Version einer Website unterbrochen wird. Fred vergleicht Folgendes:
Die visuelle Analyse berechnet den normalisierten mittleren quadratischen Fehler und den strukturellen Ähnlichkeitsindex auf den Screenshots der Basislinie und den aktualisierten Standorten, während die visuelle KI sich unabhängig voneinander ändert, indem die maschinellen Lerntechniken für Bildsegmentierung angewendet werden, um hochrangige Text- und Bild-visuelle Strukturen zu erkennen. Dies verringert den Einfluss dynamischer Inhalte, die falsch positive Ergebnisse erzielen.
Verwenden Sie Fred, wenn Sie benötigen:
Fred ist so konzipiert, dass er skalierbar ist. Es verfügt über eine interne Warteschlange und kann Websites parallel abhängig von der Anzahl der verfügbaren RAM und CPUs (oder GPUs) verarbeiten.
_fred-v1 verfügbar. Bitte beachten Sie, dass v2.x (aktuelle Version) den Code zum Training/Retrain des ML -Modells nicht enthält. Wenn Sie dies tun müssen, überprüfen Sie bitte den Originalcode im Ordner v1. Die Modelle sind identisch. Wenn Sie also Ihr benutzerdefiniertes Modell erstellen, schließen Sie es in V2 an und es funktioniert. Sie können Fred entweder als Docker oder als lokaler Prozess starten.
Wenn Sie nur die Software klonen und ausführen möchten, haben wir eine Dockerfile bereitgestellt. Um es auszuführen:
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 Wenn Sie weiterhin Probleme ohne Speicherfehler stoßen, wenden Sie mehr Speicher aus der UI -Docker -App. Klicken Sie einfach auf das Docker -Symbol in Ihrer Symbolleiste, gehen Sie zu Preferences - Advanced und dann den Schieberegler auf 8GB oder mehr, insbesondere wenn Sie ML verwenden möchten (optional). Wir haben empfohlen, es lokal auszuführen, anstatt die DockerFile zu verwenden oder den Docker -Speicher auf at least 8GB, prefferably 16GB .
Stellen Sie sicher, dass Sie chromedriver installiert haben. Wenn Sie es nicht haben, installieren Sie es auf Mac mit:
brew tap homebrew/cask && brew cask install chromedriver
oder unter Linux mit:
sudo apt-get install chromium-chromedriver
Dann führen Sie Folgendes aus:
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
Dadurch wird eine Flask -Instanz gestartet, die Antworten auf Anfragen sowie eine Webbenutzeroberfläche anbietet. QuickNote: Verwenden Sie --port , um den Hörport anzugeben, standardmäßig hört er auf 5000 zu. Weitere Informationen zu Freds Startparametern finden Sie hier.
Die Interaktion mit Fred erfolgt entweder durch Web -Benutzeroberfläche oder durch API -Anrufe. Die Benutzeroberfläche ermöglicht es einem Benutzer einfach, Anrufe an den API -Endpunkt zu senden und Ergebnisse anzeigen.
So öffnen Sie die Webschnittstelle, navigieren Sie zu http://0.0.0.0:5000/static/submit.html (port entsprechend an). Füllen Sie alle erforderlichen Felder aus, führen Sie den Job aus und warten Sie, bis er abgeschlossen ist. Die Ergebnisse anzeigen, indem Sie auf den Link Jobs im Header klicken.
Um die API zu verwenden, anzeigen Sie sich hier die dedizierte API -Readme an.
Fred wartet, bis es eine Anfrage zur Durchführung eines Website -Vergleichs erhält (post cap to /api/verify ). Es startet den Crawl -Prozess. Wir können beantragen, alle Jobs mit einem Anruf zu /api/viewjobs zu sehen und den Status eines bestimmten Jobs mit einem Get zu /api/results zu erhalten, das die Job -ID als Parameter bereitstellt.
Als solches ist der Eingang zu Fred ein Paar URLs zum Vergleich.
Der Prozess beginnt damit, dass Fred die URLs krabbelt, um eine Reihe von Seiten zu extrahieren, um sie zu vergleichen, und dann jede Seite rendert und Screenshots aufnimmt.
Die Konsolen- und Netzwerkprotokolle werden verglichen.
Jeder Screenshot wird analysiert (als Paare von Basislinien-/aktualisierten Screenshots für jede angegebene Auflösung).
Wenn dies aktiviert ist, wird jedes Screenshot -Paar auch ML -Analyse unterzogen
Die Ergebnisse werden lokal gespeichert (ein Benutzer muss regelmäßig über die API prüfen, bis der status auf Done ist und/oder ein error festgelegt ist.)
Ein Ergebnis ist ein JSON -Objekt, das im report eine Reihe von Punktzahlen enthält. Der Gesamtwert overall_divergence ist die gewichtete Summe des Netzwerks, visuellen und Ai-visuellen (wenn auch aktivierten) Unterscheidungsmaßnahmen. Eine Punktzahl von 0 bedeutet eine perfekte Übereinstimmung (kein Unterschied zwischen Basislinie und aktualisiert), während höhere Punktzahlen bis zu 100 Unterschiede hervorheben.
Verwenden Sie bei Bedarf die visuelle Schnittstelle, um die Ergebnisse schnell zu untersuchen. Andernfalls enthält der report auch Links zu den Rohbildern sowie Analysebildern, die Unterschiede hervorheben, wenn Sie Fred automatisch verwenden möchten.
Da Fred so konzipiert ist, dass er skalierbar ist, ist es logisch in zwei Komponenten aufgeteilt: crawler und ML . Die crawler -Komponente ist der Haupteintrittspunkt, mit dem der Benutzer interagiert. Die ML -Komponente ist zwar der gleiche Code wie die crawler -Komponente, ist jedoch einfach ein weiterer Endpunkt, der nach API -Aufrufen hört. Die Logik hinter dieser Trennung ist, dass GPUs teuer sind, während CPUs nicht sind. So können wir viele Crawler haben, die wiederum Anfragen an ein paar GPU -fähigen Fred -Instanzen (als ML -Komponenten genannte ML -Komponenten) stellen, um die ML -Analyse durchzuführen.
Stellen Sie sich beispielsweise ein Szenario vor, in dem wir täglich 1000 Websites haben. Wir erstellen 10 virtuelle Maschinen mit jeweils 32 GB RAM und 8 VCPUs. Jede Instanz erhält 100 /api/verify Anrufe. Angenommen, wir setzen --crawler_threads auf 5, was bedeutet, dass wir gleichzeitig 5 Websites kriechen können. Da wir nur eine einzelne GPU -Maschine mit 4 GPUs haben, starten wir eine Fred -Instanz, die wir die ML -Komponente nennen werden. In diesem Fall setzen wir --ai_threads auf 4, was bedeutet, dass wir gleichzeitig 4 ml Validierungen durchführen. In jeder der Post -API -Anforderungen an die crawler -Komponenten setzen wir die ml_address auf die Adresse der ml -Komponente. Was jetzt passieren wird, ist, dass eine crawler -Komponente, wenn sie ein Website-Paar kriecht und analysiert (nicht ai), die ML Komponente seine Screenshots sendet und diese analysiert, um sie zu analysieren. Die ml -Komponente fügt diese Anfrage in der Warteschlange hinzu und wenn eine GPU verfügbar ist, wird der Vergleich darauf ausgeführt. Nach Abschluss der Fertigstellung meldet es automatisch die Ursprungs crawler -Komponente in ihrer Analyse zurück. Grundsätzlich skaliert dieser Ansatz die Leistung linear mit der Anzahl der verfügbaren Testmaschinen.
Fred Runtimes variieren stark von der Komplexität der Website. Die meiste Zeit wird in der Crawler -Komponente verbracht, da das Laden einer Website (leider) kein deterministischer Prozess ist. Manchmal hängt eine Website einfach auf oder ein Popup erscheint zufällig, oder eine externe Ressource weigert sich zu laden. Intern haben wir das einzige Mittel dazu: eine Art try-catch , der eine Website neu lädt, wenn etwas Schreckliches passiert. In Verbindung mit der Tatsache, dass wir einige Sekunden nach der geladenen Seite warten, und die wiederholten Screenshots, um dynamische Inhalte zu entdecken, erhöhen Sie die Crawl -Zeit dramatisch.
Der Crawl-Teil dauert normalerweise 2-10 Minuten, abhängig von der Anzahl der gekrabmierten Seiten.
Die visuelle Analyse (mit jedem Screenshot begrenzt auf höchstens 20 Megapixel) dauert ~ 5-10 Sekunden pro Bildpaar. Jede zusätzliche Auflösung bedeutet einen anderen Satz von Bildpaaren.
Die visuelle Analyse der AI (ML) dauert 0-30 Sekunden pro Bildpaar auf einer GPU . Jede GPU wird es tun, selbst ein alter K80 läuft sehr schnell, da die ML Par ist ein U-NET (gestapelte Faltungsschichten). Sie können immer auf einer CPU laufen, aber anstelle von 30 Sekunden pro Bildpaar warten Sie möglicherweise 5 Minuten pro Bildpaar.
Insgesamt beträgt die Faustregel für einen ML-fähigen Crawl, beginnt bis zu Ende, 1 Minute oder weniger pro Seite.