Layout de teste? Fácil

Este artigo foi preparado por Anna anna-che e Ksenia KseMish .

Uma das razões pelas quais ativamente adotamos os layouts de teste foi, como sempre, um rake. Pisamos um bug que começou a aparecer após a próxima atualização do Chrome. Verificou-se que dentro de três horas, os usuários não podiam transferir fundos da conta através da conta pessoal do nosso banco na Internet. E tudo devido ao fato de que, na nova versão do navegador, a forma de transferência de fundos de uma conta para outra saiu da janela.

Erros semelhantes são inofensivos. Por exemplo, uma marca de roupas bem conhecida também se deparou com esse ancinho. Devido a testes de layout insuficientes, os usuários do site desta marca, em vez do botão "Saiba mais", há muito tempo veem "Aprenda a dor ...".


A inscrição no botão, é claro, está próxima da verdade, os preços são realmente muito dolorosos, mas isso claramente não é o que os criadores do site pretendiam. Em geral, esses momentos devem ser monitorados e corrigidos, independentemente do que causem - um inconveniente ou um sorriso.

Conscientes desses problemas, aplicamos a prática da revisão obrigatória do design por nossos designers de produtos, mas não estava lá. Verificou-se que nem todas as equipes têm um designer dedicado, ou não têm tempo suficiente, ou, pior ainda, a frente e o designer não podem chegar a uma abordagem comum ao layout de uma página, forma ou elemento.

Sem pensar duas vezes, partimos para procurar opções de como minimizar o número de defeitos de layout e os impasses do Front VS Designer. Tendo estudado as práticas e ferramentas possíveis para automatizar layouts de teste e coletar cones, implementamos a seguinte abordagem.

Brevemente sobre nós:
Agora, estamos desenvolvendo um único produto, no qual mais de 20 equipes de scrum estão trabalhando, cada uma delas responsável por uma certa funcionalidade, enquanto tentamos manter um único estilo e design do produto em si - apresentação visual, layout dos principais elementos etc.

Em relação à distribuição de usuários por navegador, hoje nossos usuários usam (os valores são arredondados):

• 60% Chrome
• 30% - Firefox,
• 10% - outros navegadores.

Testamos a funcionalidade com a ajuda da nossa estrutura Akita BDD (Java + Cucumber + Selenide), sobre o qual escrevemos aqui .

Para começar, queríamos resolver o problema com os acordos entre a frente e o designer. No estágio inicial da criação de uma maquete de funcionalidade, a frente e o designer descrevem juntos o "Contrato". Neste contrato, eles descrevem todos os arranjos para o arranjo de elementos, seus estilos, distância etc. Devido a isso, ao detectar incompatibilidades do layout com o layout da página, os caras não terão que descobrir por muito tempo quem está certo e quem é o culpado.

Eles descrevem seus arranjos em um arquivo galen-spec.

O que é galen-spec?

Para automatizar os testes de layout e, assim, minimizar o número de defeitos, decidimos implementar a ferramenta Galen Framework. Ele é baseado apenas em um arquivo .spec (especificação ou, como chamamos, "Contrato"). E integra-se facilmente aos testes de selênio.

Depois que o designer e a frente elaboraram o “Contrato”, o testador forma um arquivo .spec com base nele, de acordo com os requisitos de Galen. A estrutura usa seu próprio idioma para escrever especificações de verificação.

Em que consiste um arquivo .spec?

Logicamente, pode ser dividido em duas partes:

1. definições de objetos

Aqui, precisamos especificar quais objetos estão em nossa página - cabeçalho, rodapé, menu, conteúdo etc. Em geral, listamos os principais elementos que iremos verificar, fornecemos nomes e definimos localizadores.


@objects - elementos na página (você pode usar CSS, XPATH, ID)

2. Quando os localizadores são definidos, os estilos e especificações de objetos específicos devem ser definidos. Para fazer isso, usamos a parte da especificação de objeto , onde descrevemos em detalhes, por exemplo, que nosso bloco de texto (descrição-texto) está localizado dentro do formulário de descrição, abaixo do cabeçalho e contém determinado texto.


Seção principal - para cada elemento descrito, @objects descreve os parâmetros de verificação.

* A linguagem de especificação galen é sensível à indentação na seção principal, portanto, preste atenção especial a isso e observe as guias :)

Assim, o “Contrato”, concluído entre a frente e o designer e transferido para o idioma Galen, permite verificar automaticamente a localização e o conteúdo interno dos elementos, bem como a adaptabilidade e a compatibilidade entre navegadores.

Exemplo de início rápido

1. Descrevemos os elementos de uma página específica e verificamos os arquivos .spec usando a linguagem Galen Spec, e colocamos as especificações no pacote.
2. Adicionamos as capturas de tela de referência ao pacote de especificações / imagens
3. Como estamos trabalhando no BDD, o script no arquivo .feature pode ser algo como isto:
   
   
   
4. Execute o script de teste através do Cucumber Runner usual.

Nesse cenário, verificamos a página inicial do GitHub. Na última etapa, adicionamos a verificação de layout. Testes semelhantes podem complementar os testes funcionais existentes ou executá-los separadamente. Se alguma incompatibilidade for encontrada no layout, teremos uma imagem com o resultado esperado e com o resultado, mais a diferença entre eles. Essa coisa toda está anexada ao relatório do cuckumber.

A diferença nos relatórios é a seguinte:


error = Erro {[O elemento não se parece com "./akita-testing-template/src/test/resources/specs/images/registration-form.png". Existem 10,47% de pixels incompatíveis, mas o máximo permitido é 10%]

Aqui vemos que a verificação falhou, as imagens diferem em mais de 10% e todas essas diferenças de cores, exceto o preenchimento em preto, essa é a diferença entre os elementos.

Se os elementos forem completamente idênticos, a diferença será exibida em preto.

A pergunta mais comum é: onde posso obter uma captura de tela de referência?

Resposta: Adotamos o padrão do designer ou executando testes no ambiente prodov, que consideramos o padrão. A partir daí, tiramos fotos de nossos blocos, que serão comparados e colocados na pasta images, de onde as especificações puxam links para eles.

O que chegamos a usar essa abordagem

• conseguiu reduzir o número de testes de fumaça e seu tempo em cerca de 20% devido ao fato de a verificação de algumas formas e elementos similares ter sido recolhida em um teste, que verifica seu componente visual e imediatamente revela discrepâncias
• Agora podemos ter certeza de que nossos aplicativos são exibidos corretamente nos navegadores selecionados
• sabe que a adaptabilidade está bem e não se separou
• chegou a uma revisão automática do design.

Você pode ler a documentação sobre a compilação de arquivos galen-spec aqui - galen-spec-language-guide .

Conversamos sobre os aspectos técnicos do trabalho com o Galen Framework, seus recursos e verificações básicas no último Selenium Camp, e escreveremos mais no blog.

A capacidade de usar galen-spec e novas etapas para verificar o layout que adotamos em nossa biblioteca Akita , onde há um modelo para um início rápido , e também conduzimos um bate-papo por telegrama, no qual você pode fazer perguntas de seu interesse.

E nós responderemos.