Teste de interface da Web automatizado no Virto Commerce

Nos estágios iniciais de desenvolvimento, você pode realizar testes manuais de acordo com um determinado plano de teste. Mas com o advento da arquitetura modular, quando várias equipes de desenvolvimento podem fazer alterações ao mesmo tempo, há um aumento exponencial no número de scripts de teste. Afastá-los manualmente está ficando cada vez mais difícil.


Neste artigo, falaremos sobre como nós, no Virto Commerce, automatizamos os testes de importantes cenários de negócios.

Por que tudo isso?


Vou dar um exemplo de nossa experiência: uma pequena edição no estilo CSS fez com que o botão "Adicionar produto ao carrinho" não estivesse mais visível no dispositivo móvel. Infelizmente, nesta forma, foi testado e atingiu o lançamento. Existem muitos exemplos em que novas funcionalidades, pequenas correções e correções quebram cenários de negócios importantes. Infelizmente, geralmente aprendemos sobre eles após lançamentos e com os clientes. Para evitar isso, mais de dois anos atrás, começamos a implementar o teste E2E como parte do processo de desenvolvimento. Depois disso, a maioria dos erros foi identificada no estágio de desenvolvimento, e não no ambiente de combate.

O E2E está testando um cenário de negócios do início ao fim. O teste E2E simula ações reais do usuário em um navegador real, assim como o usuário real usará a solução.

Usamos testes E2E:

  1. Para controlar a regressão
  2. Para descrever o sistema
  3. Para integração no CI / CD

Isso inclui garantir que todos os módulos funcionem e trabalhem juntos de maneira correta e previsível.

Os testes E2E permitem cobrir seções do aplicativo que não são verificadas pelos testes de unidade e integração. Isso se deve ao fato de que os testes de unidade e de integração cobrem partes individuais do aplicativo e testam uma parte isolada da funcionalidade. Mesmo que essas peças funcionem bem por conta própria, você não pode ter certeza absoluta de que elas funcionarão juntas. Assim, a presença de um conjunto de testes E2E sobre a Unidade e a integração nos permite testar toda a solução da maneira mais completa.



Escrever e executar testes E2E leva tempo e recursos. O Google, por exemplo, oferece uma separação 70/20/10: 70% de testes de unidade, 20% de integração e 10% de E2E. A combinação exata será diferente para cada projeto, mas, em geral, deve preservar a forma da pirâmide.

Os testes E2E não são simples e, a princípio, parecem caros para desenvolver e manter. Na Virto Commerce, trabalhamos constantemente para simplificar o desenvolvimento e reduzir o custo de suporte aos testes E2E quando novos lançamentos são lançados. Esperamos que nossas soluções o ajudem a simplificar o uso do E2E em seus projetos.

Boa história do usuário - está quase pronto o teste E2E


Você pode ouvir muitas vezes que escrever testes E2E leva tempo; eles são difíceis de manter. Sim, é assim, eles não são fáceis de manter da mesma maneira que a documentação. Por que não torná-los parte do processo de desenvolvimento e escrever documentação, capturando assim os cenários de negócios.

A criação do E2E começa com uma descrição da história do usuário. Com que cuidado preparamos a descrição nesse estágio, será muito simples para a equipe de desenvolvimento escrever um teste E2E que demonstre que todos os sistemas funcionam corretamente ao implementar esse cenário.

Um exemplo de uma história de usuário para um botão para adicionar um item ao carrinho:

GIVEN I am signed in to the storefront AND Some product page is open (/product-name) AND my cart is empty WHEN I click to the "Add" button on the item with the following parameters: THEN I should see a dropdown menu where I can choose from 1 to 10+ 

que então se transforma no seguinte teste:



Após algum tempo, escritores técnicos ou uma nova equipe de desenvolvimento, em vez de ler a documentação, podem usar os testes para executar e ver os scripts implementados em um navegador real ou gravar automaticamente tutoriais em vídeo.

Fácil - instale e configure o transferidor


Como ferramenta de teste, escolhemos o Protractor, um sistema de automação de teste E2E de código aberto desenvolvido especificamente para aplicativos da web AngularJS.

O transferidor é um programa Node.js criado sobre o WebDriverJS. O transferidor funciona como um integrador de soluções que combina tecnologias poderosas como Node.js, Jasmine, Selenium, Mocha, Pepino e Web.



O transferidor conhece o AngularJS, o que facilita a gravação de testes sem perder tempo aguardando o lançamento do projeto AngularJS, atualizando a página, etc. ... A experiência mostra que o limite de entrada do desenvolvedor é muito baixo.
Use o npm para instalar o Transferidor globalmente:

 npm install -g protractor 

O webdriver-manager é um utilitário que facilita a configuração de uma instância do Selenium Server. Selenium Server - será usado para transferir comandos entre o teste e o ambiente real.

Execute este comando para instalar ou baixar:

 webdriver-manager update 

E execute:

 webdriver-manager start 

Este comando inicia o Selenium Server e abre uma janela para exibir o log. O transferidor enviará solicitações para este servidor para controlar o navegador.

Transferidor está pronto para ir. Uma descrição mais detalhada das etapas básicas para escrever testes pode ser encontrada no site principal .

A estrutura correta do projeto


Os testes E2E estão sempre no mesmo repositório que o aplicativo ou tema.
Recusamos o uso de serviços de teste E2E externos, porque, com aparente simplicidade, os serviços complicam o lançamento de testes na máquina local e a manutenção subsequente. O código e os testes estão localizados em diferentes locais físicos, o que leva ao fato de que os desenvolvedores esquecem de atualizá-los.

Encontrar o código do aplicativo e testar em um repositório facilita a manutenção e a manutenção do projeto.

Um exemplo básico pode ser encontrado aqui .

O projeto cria uma pasta E2E da seguinte estrutura, que usa Objetos de Página para organizar testes.

 E2E/ |--cart | |--cart.pageObject.js | |--*.spec.js |--home | |--home.pageObject.js | |--*.spec.js |--conf.js 

  • conf.js - o arquivo de configuração está na raiz
  • para cada objeto de interface, sua própria pasta é criada, na qual está localizada
    • Arquivo pageObject para descrever os elementos na página
    • vários arquivos de especificação - onde os testes estão localizados


No projeto, o uso de:

  • baseUrl - que permite usar o teste para testar diferentes ambientes
  • parâmetros - usados ​​para encontrar os principais elementos de uma página ou preencher formulários



github.com/VirtoCommerce/vc-storefront/blob/master/VirtoCommerce.Storefront.Test/e2e/conf.js#L21



github.com/VirtoCommerce/vc-storefront/blob/master/VirtoCommerce.Storefront.Test/e2e/conf.js#L29

Esses parâmetros podem ser alterados pelo administrador de TI ao configurar o lançamento no Jenkins, no modo automático para ambientes DEV e QA.

 protractor conf.js --baseUrl=https://some-url.azurewebsites.net/--params.api.endpoint=https://some-admin-url.azurewebsites.net 

Otimização de localização de elementos na página


O transferidor oferece métodos muito flexíveis para encontrar elementos na página:

  • by.binding
  • by.model
  • by.repeater
  • by.className
  • by.css
  • by.select ()
  • by.partialButtonText ()
  • ...

Mas em projetos recentes, chegamos ao modelo de que os elementos que participam do teste são marcados com uma classe especial com o prefixo transferidor. No teste, esses elementos são encontrados por byclassName.

Isso simplifica a manutenção dos testes e as alterações, para que um programador ou ferramentas automatizadas possam determinar que o elemento que participa do teste E2E foi alterado.

Que navegadores estamos testando


Por padrão, todos os processos estão configurados para executar testes no navegador Chrome. Como mostra nossa experiência no uso de testes E2E no Chrome, ele nos permite identificar a maioria dos problemas e, ao mesmo tempo, não complicar a gravação dos testes.

Se você precisar realizar testes em vários navegadores, isso será feito, por um lado, de maneira muito simples, por outro lado, haverá dificuldades com a configuração e erros na implementação de drivers para diferentes navegadores.

Em vários projetos de clientes, testamos adicionalmente no Firefox, Safari e IE. Os testes do Firefox na verdade duplicam os resultados no Chrome. Mas o lançamento do E2E no Safari e no IE exigiu configuração do sistema, abertura de portas, desativação da segurança e edição do registro, mas isso permitiu detectar automaticamente muitos problemas com a exibição e incompatibilidade de scripts no aplicativo.

Para adicionar testes no navegador, você precisa baixar e instalar o WebDriver necessário.

E adicione uma nova seção multiCapabilities no arquivo de configuração:

 exports.config = { … multiCapabilities: [ { 'browserName' : 'chrome' }, { 'browserName' : 'firefox' } ], … }; 

Como os aplicativos da Web modernos oferecem suporte a trabalhos com resoluções diferentes, isso deve ser levado em consideração ao se escrever testes.

O transferidor permite executar testes para diferentes resoluções de tela.

Para fazer isso, existe uma opção para definir o tamanho da tela através de browser.driver.manage (). Window (). SetSize. Neste exemplo, definimos o tamanho da tela como 1600 por 800.

 exports.config = { … capabilities: { 'browserName': 'chrome' }, onPrepare: function() { browser.driver.manage().window().setSize(1600, 800); }, … }; 

Ou através da seção multiCapabilities no arquivo de configuração. Neste exemplo, executaremos testes no navegador Chrome para três resoluções diferentes.

 multiCapabilities: [ { 'browserName': 'chrome', 'chromeOptions' : { args: ['--lang=en', '--window-size=1920,1080'] }, specs: ['specs.js'] }, { 'browserName': 'chrome', 'chromeOptions' : { args: ['--lang=en', '--window-size=1680,1050'] }, specs: ['specs.js'] }, { 'browserName': 'chrome', 'chromeOptions' : { args: ['--lang=en', '--window-size=1600,900'] }, specs: ['specs.js'] }] 

O E2E faz parte da documentação.


Mais uma vez, o E2E é bom como elemento de documentação, demonstrando o que foi feito pela equipe de desenvolvimento. Uma nova equipe de desenvolvimento ou escritor técnico pode executar os testes e assistir os scripts implementados ao vivo. Portanto, documente como um novo funcionário pode executar esses testes.

Integração de CI / CD


Quaisquer testes devem ser relevantes e executados periodicamente. Se isso não for feito, você não deve perder tempo escrevendo testes, eles se tornarão inúteis em algumas semanas e será mais fácil reescrevê-los do zero.

Demos um passo importante na integração de testes do E2E no CI / CD e na inclusão do E2E no processo de implantação.

A integração ao CI / CD permite executar automaticamente os testes E2E para ambientes DEV e QA para fornecer feedback e adicionar informações de que o sistema permanece operacional mesmo após uma pequena alteração. E se a decisão for violada, forneça informações quando e com que mudança isso aconteceu.

Primeiro, os testes são iniciados quando um dos módulos é atualizado e a nova versão entra no ambiente de controle de qualidade.

Em segundo lugar, os testes E2E são executados à noite, de acordo com uma programação nos ambientes DEV e QA no modo automático.

Em terceiro lugar, se necessário, os próprios desenvolvedores podem executar os testes conforme necessário.
Com base nos resultados do lançamento, todos os participantes do projeto da equipe de desenvolvimento para o cliente recebem um email com um relatório HTML sobre os resultados do teste.

É importante observar a disponibilidade obrigatória de informações sobre o resultado do teste para toda a equipe do projeto. Isso dá confiança à equipe de desenvolvimento, por um lado, e gerencia as expectativas dos clientes, por outro. A equipe de desenvolvimento pode fazer alterações mais rapidamente, enquanto percebe que os principais cenários de negócios estão funcionando. E o cliente recebe informações sobre a qualidade do projeto, que identificam a maioria dos problemas antes do lançamento. E mesmo se o problema for identificado pelo teste e o release for adiado, serão exibidas informações sobre o que exatamente quebrou e como será o processo de trabalho da correção.

Para gerar relatórios, usamos a versão modificada do plug-in transferidor-jasmine2-html-reporter (https://github.com/VirtoCommerce/protractor-jasmine2-html-reporter). Este plug-in gera um relatório HTML e insere capturas de tela dos elementos embutidos.

A instalação é muito simples:

  1. Instalar transferidor-jasmine2-html-reporter
  2. Adicionando transferidor-jasmine2-html-reporter ao projeto
  3. Relatório de conexão onPrepare método

 var HtmlScreenshotReporter = require('protractor-jasmine2-html-reporter'); var reporter = new HtmlScreenshotReporter(self.options); var name = browser.suite; self.options.reportTitle = name + '-report.html'; jasmine.getEnv().addReporter(reporter); 



Melhorar constantemente o processo


Trabalhe constantemente em equipe para reduzir custos e aumentar a velocidade de desenvolvimento e suporte dos testes E2E.

Treine e revise o processo de redação do teste. Veja quais novos componentes e serviços podem ser usados.

Por exemplo, estamos considerando uma opção de conexão de pepino. Pepino é uma ferramenta para executar testes automatizados escritos em linguagem simples.

Conclusões


Os testes E2E não são tão simples e, a princípio, parecem caros para manutenção, mas são muito valiosos porque são um indicador da saúde de importantes cenários comerciais.

Com a experiência de usar testes E2E no projeto Virto Commerce, podemos tirar as seguintes conclusões:

  • Escrever E2E faz parte do processo de desenvolvimento. E é muito importante, porque testa o trabalho dos processos de negócios e toda a solução. Um grande número de erros foi detectado no estágio de DEV e QA, e não no ambiente de combate.
  • Os testes e o código devem estar no mesmo repositório e estar disponíveis para o desenvolvedor.
  • A qualidade do teste E2E depende da descrição da história do usuário; se for escrito corretamente, é mais fácil para a equipe de desenvolvimento criar um teste E2E.
  • Os testes E2E podem atuar como documentação e gravar scripts criados.
  • Os testes E2E devem ser executados de forma contínua e automática nos ambientes DEV e QA. Se você não automatizou o lançamento, não deve perder tempo com testes, pois eles se tornarão inúteis em algumas semanas.
  • Os resultados do teste devem estar disponíveis para todos os participantes do projeto. Isso dá uma imagem do que está acontecendo.
  • O E2E não é uma solução 100% para todos os problemas. Siga a regra 70/20/10: 70% de testes de unidade, 20% de testes de integração e 10% de testes E2E
  • Trabalhe constantemente em equipe para reduzir custos e aumentar a velocidade de desenvolvimento e suporte dos testes E2E.

Referências


www.protractortest.org

Transferidor para AngularJS - Escrever testes de ponta a ponta nunca foi tão divertido

github.com/angular/protractor/blob/master/docs/page-objects.md

github.com/VirtoCommerce/vc-storefront/tree/master/VirtoCommerce.Storefront.Test/e2e

Basta dizer não a mais testes de ponta a ponta testing.googleblog.com/2015/04/just-say-no-to-more-end-to-end-tests.html

Source: https://habr.com/ru/post/pt418293/


All Articles