frontend regression validator
1.0.0
Fred est un outil de régression visuelle OpenSource utilisé pour comparer deux instances d'un site Web. Fred est responsable des tests de régression visuelle automatique, dans le but de s'assurer que la fonctionnalité n'est pas rompue en comparant un courant (ligne de base) et une version mise à jour d'un site Web. Fred compare ce qui suit:
L'analyse visuelle calcule l'erreur quadratique moyenne normalisée et l'indice de similitude structurelle sur les captures d'écran de la ligne de base et des sites mis à jour, tandis que l'IA visuel examine la mise en page et les changements de contenu indépendamment en appliquant des techniques d'apprentissage automatique de segmentation d'image pour reconnaître les structures visuelles de texte et d'image de haut niveau. Cela réduit l'impact du contenu dynamique produisant de faux positifs.
Utilisez Fred si vous avez besoin:
Fred est conçu pour être évolutif. Il a une file d'attente interne et peut traiter les sites Web en parallèle en fonction de la quantité de RAM et de CPU (ou GPU) disponibles.
_fred-v1 . Veuillez noter que V2.x (version actuelle) ne contient pas le code pour former / recycler le modèle ML. Si vous devez le faire, veuillez vérifier le code d'origine dans le dossier V1. Les modèles sont identiques, donc si vous créez votre modèle formé sur mesure, branchez-le en V2 et cela fonctionnera. Vous pouvez démarrer Fred soit en tant que Docker, soit comme processus local.
Si vous voulez simplement cloner et exécuter le logiciel, nous avons fourni un dockerfile. Pour l'exécuter:
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 Si vous rencontrez toujours des problèmes avec les erreurs hors mémoire, allouez plus de mémoire à partir de l'application Docker d'interface utilisateur. Cliquez simplement sur l'icône Docker dans votre barre d'outils, accédez aux Preferences - Advanced , puis retirez le curseur sur 8GB ou plus, surtout si vous prévoyez d'utiliser ML (facultatif). Nous avons recommandé de l'exécuter localement au lieu d'utiliser le DockerFile ou pour augmenter la mémoire allouée à Docker à at least 8GB, prefferably 16GB .
Assurez-vous que vous avez installé chromedriver . Si vous ne l'avez pas, installez-le sur Mac avec:
brew tap homebrew/cask && brew cask install chromedriver
ou sur Linux avec:
sudo apt-get install chromium-chromedriver
Ensuite, exécutez ce qui suit:
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
Cela lancera une instance FLASK qui répond aux demandes ainsi que l'offre d'une interface utilisateur Web. QuickNote: utilisez --port pour spécifier le port d'écoute, par défaut, il écoute 5000 . Veuillez consulter plus de détails sur les paramètres de démarrage de Fred ici.
L'interaction avec Fred se fait soit par UI Web, soit par des appels API. L'interface utilisateur permet simplement à un utilisateur d'envoyer des appels au point de terminaison de l'API et d'afficher les résultats.
Pour ouvrir l'interface Web, accédez à http://0.0.0.0:5000/static/submit.html (ajustez le port en conséquence). Remplissez tous les champs requis, exécutez le travail et attendez jusqu'à ce qu'il se termine. Affichez les résultats en cliquant sur le lien Jobs dans l'en-tête.
Pour utiliser l'API, veuillez consulter l'API dédié Readme ici.
Fred attend jusqu'à ce qu'il reçoive une demande pour effectuer une comparaison de site Web (Post Call to /api/verify ). Il commence le processus de rampe. Nous pouvons demander à voir tous les travaux avec un appel à /api/viewjobs et obtenir le statut d'un travail particulier avec un Get TO /api/results fournissant l'ID de travail en tant que paramètre.
En tant que tel, l'entrée de Fred est une paire d'URL à comparer.
Le processus commence par Fred rampant les URL pour extraire un certain nombre de pages à comparer, puis rend chaque page et prend des captures d'écran.
Les journaux de console et de réseau sont comparés.
Chaque capture d'écran est analysée (sous forme de paires de captures d'écran de base / mises à jour, pour chaque résolution spécifiée).
S'il est activé, chaque paire de captures d'écran subit également une analyse ML
Les résultats sont enregistrés localement (un utilisateur doit vérifier périodiquement via l'API jusqu'à ce que l' status soit défini sur Done et / ou une error est définie.)
Un résultat est un objet JSON qui, dans la clé report , contient un certain nombre de scores. Le score overall_divergence est la somme pondérée du réseau, des divergences visuelles et visuelles AI (si activées). Un score de 0 signifie une correspondance parfaite (pas de différence entre la ligne de base et la mise à jour), tandis que des scores plus élevés, jusqu'à 100 mettent en évidence les différences.
Si nécessaire, utilisez l'interface visuelle pour étudier rapidement les résultats. Sinon, le report contient également des liens vers les images brutes ainsi que des images d'analyse qui mettent en évidence les différences si vous souhaitez utiliser Fred de manière automatisée.
Parce que Fred est conçu pour être évolutif, il est logiquement divisé en deux composants: crawler et ML . Le composant crawler est le principal point d'entrée avec lequel l'utilisateur interagit. Le composant ML , tout en étant le même code que le composant crawler , est simplement un autre point de terminaison écoutant les appels d'API. La logique derrière cette scission est que les GPU sont chers tandis que les processeurs ne le sont pas. Nous pouvons donc avoir de nombreux robots qui font à leur tour les demandes de quelques instances FRED ont permis à GPU (appelées composantes ML ) pour effectuer l'analyse ML.
Par exemple, imaginez un scénario où nous avons 1000 sites Web pour analyser quotidiennement. Nous créons 10 machines virtuelles, chacune avec 32 Go de RAM et 8 VCPU. Chaque instance recevra 100 /api/verify les appels. Supposons que nous définissons --crawler_threads sur 5, ce qui signifie que nous pouvons compenser simultanément 5 sites Web. De plus, comme nous n'avons qu'une seule machine GPU avec 4 GPU, nous lançons dessus une instance Fred, que nous appellerons le composant ML . Sur cette instance, nous définissons --ai_threads sur 4, ce qui signifie que nous exécutons simultanément 4 ml de validations. Maintenant, sur chacune des demandes de l'API Post aux composants crawler , nous définissons le ml_address sur l'adresse du composant ml . Ce qui se passera maintenant, c'est que chaque fois qu'un composant crawler se termine pour ramper et analyser (non AI) une paire de sites Web, il enverra le composant ML ses captures d'écran et demandera de les analyser. Le composant ml ajoutera cette demande dans sa file d'attente et lorsqu'un GPU sera disponible, il exécutera la comparaison dessus. Une fois terminé, il relèvera automatiquement de la composante crawler d'origine de son analyse. Fondamentalement, cette approche évolue linéairement avec le nombre de machines de test disponibles.
Fred Runtime varie considérablement sur la complexité du site. La plupart du temps est consacré à la composante du robot, car (malheureusement) le chargement d'un site Web n'est pas un processus déterministe. Parfois, un site Web est simplement suspendu, ou une popup apparaît au hasard, ou une ressource externe refuse de se charger. En interne, nous avons le seul remède à cela: une sorte de try-catch qui recharge un site Web si quelque chose d'horrible se produit. Mais cela, associé au fait que nous attendons quelques secondes après que la page le soit chargée, ainsi que les captures d'écran répétées pour découvrir le contenu dynamique, augmentent considérablement le temps de rampe.
La partie d'exploration prend généralement 2 à 10 minutes, selon le nombre de pages rampées.
L'analyse visuelle (avec chaque capture d'écran limitée au plus 20 mégapixels) prend ~ 5 à 10 secondes par paire d'images. Chaque résolution supplémentaire signifie un autre ensemble de paires d'images.
L'analyse visuelle de l'IA (ML) prend 0 à 30 secondes par paire d'images sur un GPU . Tout GPU fera l'affaire, même un vieux K80 fonctionnera très rapidement, car le ML PAR est un U-Net (couches convolutionnelles empilées). Vous pouvez toujours courir sur un processeur, mais au lieu de 30 secondes par paire d'images, vous pouvez attendre 5 minutes par paire d'images.
Dans l'ensemble, la règle de base pour une rampe compatible ML, commencez à terminer, est de 1 minute ou moins par page.
