frontend regression validator
1.0.0
Fred es una herramienta de regresión visual de OpenSource utilizada para comparar dos instancias de un sitio web. Fred es responsable de las pruebas automáticas de regresión visual, con el propósito de garantizar que la funcionalidad no se rompa comparando una actualidad (línea de base) y una versión actualizada de un sitio web. Fred compara lo siguiente:
El análisis visual calcula el error cuadrático medio normalizado y el índice de similitud estructural en las capturas de pantalla de la línea de base y los sitios actualizados, mientras que la IA visual analiza el diseño y el contenido cambia de forma independiente mediante la aplicación de técnicas de aprendizaje automático de segmentación de imágenes para reconocer las estructuras visuales de texto e imágenes de alto nivel. Esto reduce el impacto del contenido dinámico que produce falsos positivos.
Use Fred si necesita:
Fred está diseñado para ser escalable. Tiene una cola interna y puede procesar sitios web en paralelo dependiendo de la cantidad de RAM y CPU (o GPU) disponibles.
_fred-v1 . Tenga en cuenta que v2.x (versión actual) no contiene el código para entrenar/volver a entrenar el modelo ML. Si necesita hacer eso, consulte el código original en la carpeta V1. Los modelos son idénticos, por lo que si crea su modelo capacitado a medida, conéctelo en V2 y funcionará. Puede comenzar a Fred como un Docker o como un proceso local.
Si solo desea clonar y ejecutar el software, hemos proporcionado un DockerFile. Para ejecutarlo:
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 aún encuentra problemas con errores fuera de memoria, asigne más memoria de la aplicación UI Docker. Simplemente haga clic en el icono Docker en su barra de herramientas, vaya a Preferences : Advanced y luego tire del control deslizante a 8GB o más, especialmente si planea usar ML (opcional). Recomendamos ejecutarlo localmente en lugar de usar DockerFile o aumentar la memoria asignada a Docker a at least 8GB, prefferably 16GB .
Asegúrese de haber instalado chromedriver . Si no lo tiene, instálelo en Mac con:
brew tap homebrew/cask && brew cask install chromedriver
o en Linux con:
sudo apt-get install chromium-chromedriver
Luego ejecute lo siguiente:
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
Esto iniciará una instancia de frasco que responde a las solicitudes, así como a ofrecer una interfaz de usuario web. QuickNote: Use --port para especificar el puerto de escucha, de forma predeterminada, escucha en 5000 . Vea más detalles sobre los parámetros de inicio de Fred aquí.
La interacción con Fred se realiza por interfaz de usuario web o por llamadas API. La interfaz de usuario simplemente permite que un usuario envíe llamadas al punto final de la API y ver los resultados.
Para abrir la interfaz web, navegue a http://0.0.0.0:5000/static/submit.html (ajuste el puerto en consecuencia). Complete todos los campos requeridos, ejecute el trabajo y espere hasta que se complete. Vea los resultados haciendo clic en el enlace Jobs en el encabezado.
Para usar la API, vea el readme de API dedicado aquí.
Fred espera hasta que reciba una solicitud para realizar una comparación de sitios web (Post Call a /api/verify ). Comienza el proceso de rastreo. Podemos solicitar ver todos los trabajos con una llamada Get a /api/viewjobs y obtener el estado de un trabajo en particular con un GOLE a /api/results que proporcionan la ID de trabajo como parámetro.
Como tal, la entrada a Fred es un par de URL para comparar.
El proceso comienza con Fred rastreando las URL para extraer varias páginas para comparar, y luego renderiza cada página y toma capturas de pantalla.
Se comparan la consola y los registros de red.
Cada captura de pantalla se analiza (como pares de capturas de pantalla de línea de base/actualizadas, para cada resolución especificada).
Si está habilitado, cada par de capturas de pantalla también sufre un análisis de ML
Los resultados se guardan localmente (un usuario debe verificar periódicamente a través de la API hasta que el status se Done y/o se establece algún error ).
Un resultado es un objeto JSON que en la clave report contiene una serie de puntajes. El puntaje overall_divergence es la suma ponderada de la red, visual y las divergencias A-visuales (si habilitadas). Una puntuación de 0 significa una coincidencia perfecta (sin diferencia entre la línea de base y la actualización), mientras que los puntajes más altos, hasta 100 resaltan las diferencias.
Si es necesario, use la interfaz visual para investigar rápidamente los resultados. De lo contrario, el report también contiene enlaces a las imágenes RAW, así como imágenes de análisis que resaltan las diferencias si desea usar Fred de manera automatizada.
Debido a que Fred está diseñado para ser escalable, se divide lógicamente en dos componentes: crawler y ML . El componente crawler es el principal punto de entrada con el que interactúa el usuario. El componente ML , aunque es el mismo código que el componente crawler , es simplemente otro punto final escuchando las llamadas API. La lógica detrás de esta división es que las GPU son caras, mientras que las CPU no lo son. Por lo tanto, podemos tener muchos rastreadores que a su vez hacen solicitudes a algunas instancias Fred habilitadas para GPU (llamadas componentes ML ) para realizar el análisis ML.
Por ejemplo, imagine un escenario en el que tenemos 1000 sitios web para analizar diariamente. Creamos 10 máquinas virtuales, cada una con 32 GB de RAM y 8 VCPU. Cada instancia recibirá 100 /api/verify Llamadas. Suponga que establecemos --crawler_threads a 5, lo que significa que podemos rastrear simultáneamente 5 sitios web. Además, como solo tenemos una sola máquina de GPU con 4 GPU, lanzamos una instancia de Fred, que llamaremos al componente ML . En este caso, establecemos --ai_threads a 4, lo que significa que realizamos simultáneamente 4 ml de validaciones. Ahora, en cada una de las solicitudes de API posteriores a los componentes crawler , establecemos el ml_address en la dirección del componente ml . Lo que ahora sucederá es que cada vez que un componente crawler termine para rastrear y analizar (no AI) un par de sitios web, enviará el componente ML sus capturas de pantalla y solicitará analizarlas. El componente ml agregará esta solicitud en su cola y cuando esté disponible una GPU, ejecutará la comparación en ella. Cuando termine, informará automáticamente al componente de crawler de origen su análisis. Básicamente, este enfoque escala linealmente el rendimiento con el número de máquinas de prueba disponibles.
Fred Runtimes varía mucho en la complejidad del sitio. La mayor parte del tiempo se gasta en el componente del rastreador, ya que (desafortunadamente) cargar un sitio web no es un proceso determinista. A veces, un sitio web simplemente cuelga, o aparece una ventana emergente al azar, o algún recurso externo se niega a cargarse. Internamente, tenemos el único remedio para esto: una especie de try-catch que recarga un sitio web si sucede algo horrible. Pero esto, junto con el hecho de que esperamos unos segundos después de que la página dice que se cargó, además de las capturas de pantalla repetidas para descubrir contenido dinámico, aumentan drásticamente el tiempo de rastreo.
La parte de rastreo generalmente lleva 2-10 minutos, dependiendo de la cantidad de páginas rastreadas.
El análisis visual (con cada captura de pantalla limitada a la mayoría de los 20 megapíxeles) toma ~ 5-10 segundos por par de imágenes. Cada resolución adicional significa otro conjunto de pares de imágenes.
El análisis visual AI (ML) toma 0-30 segundos por par de imágenes en una GPU . Cualquier GPU servirá, incluso un viejo K80 funcionará muy rápido, ya que el ML PAR es una red U (capas convolucionales apiladas). Siempre puede ejecutar una CPU, pero en lugar de 30 segundos por par de imágenes, puede esperar 5 minutos por par de imágenes.
En general, la regla general para un rastreo habilitado para ML, que comienza a terminar, es de 1 minuto o menos por página.
