frontend regression validator
1.0.0
Fred é uma ferramenta de regressão visual OpenSource usada para comparar duas instâncias de um site. Fred é responsável pelo teste automático de regressão visual, com o objetivo de garantir que a funcionalidade não seja quebrada comparando uma corrente (linha de base) e uma versão atualizada de um site. Fred compara o seguinte:
A análise visual calcula o erro quadrático médio normalizado e o índice de similaridade estrutural nas capturas de tela dos sites de linha de base e atualizados, enquanto a IA visual analisa o layout e o conteúdo muda de forma independente, aplicando técnicas de segmentação de máquinas para reconhecer o texto de alto nível e as estruturas visuais da imagem. Isso reduz o impacto do conteúdo dinâmico que produz falsos positivos.
Use Fred se precisar:
Fred foi projetado para ser escalável. Possui uma fila interna e pode processar sites em paralelo, dependendo da quantidade de RAM e CPUs (ou GPUs) disponíveis.
_fred-v1 . Observe que v2.x (versão atual) não contém o código para treinar/treinar o modelo ML. Se você precisar fazer isso, verifique o código original na pasta V1. Os modelos são idênticos; portanto, se você criar seu modelo personalizado, conecte-o ao V2 e ele funcionará. Você pode iniciar Fred como um docker ou como um processo local.
Se você deseja apenas clonar e executar o software, fornecemos um Dockerfile. Para executá -lo:
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 Se você ainda encontrar problemas com erros fora da memória, aloque mais memória do aplicativo Docker da interface do usuário. Basta clicar no ícone do docker na barra de ferramentas, ir para Preferences - Advanced e puxar o controle deslizante para 8GB ou mais, especialmente se você planeja usar o ML (opcional). Recomendamos executá -lo localmente, em vez de usar o Dockerfile ou aumentar a memória alocada para o Docker para at least 8GB, prefferably 16GB .
Certifique -se de instalar chromedriver . Se você não tiver, instale -o no Mac com:
brew tap homebrew/cask && brew cask install chromedriver
ou no Linux com:
sudo apt-get install chromium-chromedriver
Em seguida, execute o seguinte:
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
Isso iniciará uma instância do Flask que atende a solicitações e também oferece uma interface do usuário da Web. QuickNote: use --port para especificar a porta de escuta, por padrão, ele ouve em 5000 . Veja mais detalhes sobre os parâmetros de inicialização de Fred aqui.
A interação com Fred é feita pela interface do usuário da Web ou por chamadas de API. A interface do usuário simplesmente permite que um usuário envie chamadas para o terminal da API e visualize os resultados.
Para abrir a interface da web, navegue para http://0.0.0.0:5000/static/submit.html (ajuste a porta de acordo). Preencha todos os campos necessários, execute o trabalho e aguarde até concluir. Veja os resultados clicando no link Jobs no cabeçalho.
Para usar a API, veja a API ReadMe dedicada aqui.
Fred espera até receber uma solicitação para executar uma comparação de sites (pós -chamada para /api/verify ). Inicia o processo de rastreamento. Podemos solicitar todos os trabalhos com uma chamada para /api/viewjobs e obter o status de um trabalho específico com uma API /api/results fornecendo o ID do trabalho como um parâmetro.
Como tal, a entrada para Fred é um par de URLs para comparar.
O processo começa com Fred rastejando os URLs para extrair várias páginas para comparar e, em seguida, renderiza cada página e tira capturas de tela.
Os logs de console e rede são comparados.
Cada captura de tela é analisada (como pares de capturas de linha de base/atualizadas, para cada resolução especificada).
Se ativado, cada par de captura de tela também sofre análise de ML
Os resultados são salvos localmente (um usuário deve verificar periodicamente através da API até que o status seja definido como Done e/ou algum error seja definido.)
Um resultado é um objeto JSON que na tecla report contém uma série de pontuações. A pontuação overall_divergence é a soma ponderada da rede, divergências visuais e visuais (se ativadas). Uma pontuação de 0 significa uma combinação perfeita (sem diferença entre a linha de base e a atualização), enquanto pontuações mais altas, até 100 diferenças de destaque.
Se necessário, use a interface visual para investigar rapidamente os resultados. Caso contrário, o report também contém links para as imagens brutas, bem como as imagens de análise que destacam diferenças se você deseja usar o Fred de maneira automatizada.
Como o Fred foi projetado para ser escalável, é dividido logicamente em dois componentes: crawler e ML . O componente crawler é o principal ponto de entrada com o qual o usuário interage. O componente ML , apesar de ser o mesmo código do componente crawler , é simplesmente outro ponto final ouvindo as chamadas da API. A lógica por trás dessa divisão é que as GPUs são caras enquanto as CPUs não. Portanto, podemos ter muitos rastreadores que, por sua vez, solicitam algumas instâncias de Fred (chamadas componentes ML ) para executar a análise ML.
Por exemplo, imagine um cenário em que temos 1000 sites para analisar diariamente. Criamos 10 máquinas virtuais, cada uma com 32 GB de RAM e 8 VCPUs. Cada instância receberá 100 /api/verify chamadas. Suponha que definimos --crawler_threads para 5, o que significa que podemos rastejar simultaneamente 5 sites. Além disso, como temos apenas uma única máquina GPU com 4 GPUs, lançamos uma instância Fred, que chamaremos o componente ML . Nesta instância, definimos --ai_threads para 4, o que significa que executamos simultaneamente as validações de 4 mL. Agora, em cada uma das solicitações de API post para os componentes crawler , definimos o ml_address para o endereço do componente ml . O que acontecerá agora é que sempre que um componente crawler terminar para rastejar e analisar (não-AI) um par de sites, ele enviará ao componente ML suas capturas de tela e solicitará para analisá-los. O componente ml adicionará essa solicitação em sua fila e, quando uma GPU estiver disponível, ele executará a comparação nela. Quando terminar, ele se reportará automaticamente ao componente de crawler de origem em sua análise. Basicamente, essa abordagem escala o desempenho linearmente com o número de máquinas de teste disponíveis.
O Fred Run Times varia muito na complexidade do site. Na maioria das vezes, é gasto no componente rastreador, pois (infelizmente) carregar um site não é um processo determinístico. Às vezes, um site simplesmente pendura, ou um pop -up aparece aleatoriamente, ou algum recurso externo se recusa a carregar. Internamente, temos o único remédio para isso: uma espécie de try-catch que recarrega um site se algo horrível acontecer. Mas isso, juntamente com o fato de aguardarmos alguns segundos após a página que ela carregou, além das repetidas capturas de tela para descobrir conteúdo dinâmico, aumentar drasticamente o tempo de rastreamento.
A parte de rastreamento geralmente leva de 2 a 10 minutos, dependendo do número de páginas rastejadas.
A análise visual (com cada captura de tela limitada a no máximo 20 megapixels) leva ~ 5-10 segundos por par de imagem. Cada resolução extra significa outro conjunto de pares de imagens.
A análise visual da AI (ML) leva de 0 a 30 segundos por par de imagem em uma GPU . Qualquer GPU fará, mesmo um K80 antigo funcionará muito rápido, pois o ML PAR é uma rede U (camadas convolucionais empilhadas). Você sempre pode ser executado em uma CPU, mas, em vez de 30 segundos por par de imagem, você pode esperar 5 minutos por par de imagem.
No geral, a regra prática para um rastreamento habilitada para ML, inicia o fim, é de 1 minuto ou menos por página.
