Com este artigo, estamos abrindo uma série de publicações sobre como automatizamos o processo de teste manual de um grande sistema de informação em um dos principais projetos da LANIT e o que aconteceu com ele.

A primeira parte - organizacional e gerencial - deve ser útil principalmente para os responsáveis ​​por testar a automação e criar esses sistemas como um todo. Os gerentes de projeto, líderes de grupo e proprietários de serviços de teste funcional e automático, todos que se preocupam com a questão “como criar um teste econômico de ponta a ponta do sistema de TI” encontrarão aqui um plano e uma metodologia concretos.

Fonte

Parte 1 - Organizacional e gerencial. Por que precisamos de automação. Organização do processo de desenvolvimento e gerenciamento. Organização de uso

Inicialmente, no início, havia um sistema de informações grande e complexo (que chamaremos de "Sistema") com vários cenários de negócios complexos, longos e interconectados. Todos os scripts foram testados como E2E por meio de interfaces da Web exclusivamente no modo manual (havia mais de um milhão e meio de cenários desse tipo, apenas da prioridade mais crítica). Além disso, todos esses cenários precisavam ser concluídos pelo menos uma vez durante a regressão de cada nova versão ou hotfix antes da próxima atualização de implantação do produto.

Em um determinado momento, quando se tornou completamente insuportável clicar com o mouse no modo manual, decidimos automatizar tudo. Isso foi o que eles fizeram através do desenvolvimento de um serviço separado baseado em java + selênio + seleneto + selenoide, que também é chamado de "estrutura de teste" ou simplesmente "autoteste" .

Historicamente, o código da estrutura de teste foi desenvolvido por duas equipes. Primeiro, a primeira equipe criou um protótipo com algumas dezenas de cenários. Em seguida, a segunda equipe por um ano escalou o protótipo em profundidade (número de testes) e em profundidade (foram introduzidos padrões típicos de codificação e implementação).

Sou o líder de equipe e de equipe da segunda equipe, que adotou a estrutura de protótipo para dimensionamento (em maio de 2018).

No momento da redação deste artigo, a tarefa definida há um ano foi concluída e a equipe do projeto recebeu um serviço de automação estável. Não foi em vão que enfatizei o serviço , porque, inicialmente, a tarefa não era definida como o desenvolvimento de um aplicativo, mas como um serviço de serviço para testar a automação a um grupo de "testes funcionais". E esse recurso posteriormente influenciou bastante a organização do desenvolvimento e a arquitetura da estrutura de teste.

Sumário

Cerca de 1.500 cenários de teste foram automatizados: em cada teste, de 200 a 2000 operações de usuário.

A capacidade total do serviço é de até 60 navegadores trabalhando simultaneamente, e esse não é o limite (o número pode ser aumentado em 5 vezes devido às máquinas virtuais).
A duração total de uma regressão completa não é superior a 3 horas e o teste PreQA é inferior a uma hora.

Uma ampla gama de recursos foi implementada:

• uso local (execução em tempo real) e remoto (via planos Bamboo);
• limitando a composição dos testes em execução por filtro;
• um relatório detalhado com os resultados de cada etapa do cenário de teste (através da estrutura Allure);
• baixar e carregar arquivos de / para o navegador, seguido pela verificação dos resultados de seu processamento em termos de formato e conteúdo dos arquivos;
• contabilidade e controle da natureza assíncrona da interface angular. Incluindo o controle de solicitações suspensas (solicitação pendente) entre os serviços Angular e REST;
• controle de logs do navegador;
• gravação de teste de vídeo;
• remoção do instantâneo da página no ponto de "queda" do teste;
• transmissão de eventos no ELK;
• muito mais sobre as pequenas coisas ...

Por que tudo isso era necessário?

No início, o objetivo do sistema era bastante simples e claro.

Imagine que você possui um grande sistema de registro para gerenciar uma extensa gama de documentos e seu ciclo de vida, o que fornece algumas centenas de processos de negócios. Além disso, existem milhões de pessoas, fornecedores - dezenas de milhares, serviços - milhares, documentos complexos, incluindo estrutura e modelo, e o fornecimento de processos de negócios são fornecidos de centenas de maneiras diferentes ...

Tudo isso se transforma em mil e meio cenários de teste, e essa é apenas a prioridade mais alta e apenas positiva.

No processo de automação, foram reveladas várias nuances que exigiam o uso de várias soluções.

Por exemplo, um script pode conter até centenas de operações separadas, incluindo aquelas interessantes como: “Faça o download de um arquivo EXCEL com dados e verifique se o sistema processa cada registro do arquivo” (para resolver esse problema, foram necessárias várias etapas para preparar os dados e verificar o resultado do carregamento no Sistema). E agora adicionamos a limitação de reutilização dos dados de teste: os dados de teste para a conclusão bem-sucedida da maioria dos cenários de teste devem ser "atualizados" e não usados ​​anteriormente em cenários semelhantes (durante os testes, o estado dos dados no Sistema é alterado, para que não possam ser reutilizados as mesmas verificações).

Fonte

Em algum momento, o teste manual do sistema como parte da regressão deixou de parecer econômico e rápido o suficiente e eles decidiram automatizá-lo por meio da interface do usuário da web.

Em outras palavras, o grupo de teste funcional abre a “página”, seleciona o “grupo de teste”, pressiona o botão “executar” (usamos o Bamboo). Em seguida, os Autotestes (doravante denominados Autotestes. Designam o produto criado para testes em geral) emulam automaticamente as ações dos usuários no Sistema através do navegador ("pressione" os botões necessários, insira valores nos campos, etc.), após a conclusão, exiba um relatório detalhado sobre todos os etapas e ações e resultados concluídos da verificação (correspondência da reação esperada do Sistema ao seu comportamento real).

Total, o objetivo dos Autotestes é a automação do teste E2E manual. Este é um sistema "externo" que não participa do processo de desenvolvimento do sistema em teste e não está de forma alguma conectado aos testes de unidade ou integração usados ​​pelos desenvolvedores.

Objetivos

Foi necessário reduzir significativamente os custos de mão-de-obra da realização dos testes de ponta a ponta e aumentar a velocidade de regressões completas e reduzidas em termos de volume.

As tarefas

A principal tarefa do desenvolvimento foi formulada com muita simplicidade - para automatizar nos próximos 6 meses 1000 cenários de teste da mais alta prioridade.

O número previsto de ações básicas de teste variou de 100 a 300, o que nos deu cerca de 200 mil métodos de teste com 10 a 20 linhas de código, sem levar em consideração as classes gerais e auxiliares de auxiliares, provedores de dados e modelos de dados.

Dessa forma, verificou-se que, considerando as restrições de tempo (130 dias úteis), era necessário realizar pelo menos 10 testes por dia e, ao mesmo tempo, garantir a relevância dos autotestes implementados, levando em consideração as alterações ocorridas no sistema (o sistema está em desenvolvimento ativo).

Segundo estimativas de especialistas, o trabalho necessário para desenvolver um autoteste foi de 4-8 horas. Portanto, temos pelo menos uma equipe de 5 pessoas (na realidade, no auge do desenvolvimento de autotestes, a equipe tinha mais de 10 engenheiros de automação).

As tarefas que precisavam ser resolvidas também eram compreensíveis.

• Configure processos e comandos:
• definir o processo de interação com o cliente (grupo de teste funcional), corrigir o formato de descrição do caso de teste como entrada para a equipe de automação;
• organizar o processo de desenvolvimento e manutenção;
• formar uma equipe.
  
• Desenvolva autotestes com os seguintes recursos:
• clique automaticamente nos botões do navegador com uma verificação preliminar da presença de elementos e das informações necessárias na página;
• fornecer trabalho com elementos complexos, como Yandex.Map;
• garantir o carregamento de arquivos gerados automaticamente no sistema, garantir o download de arquivos do sistema com verificação de seu formato e conteúdo.
• Forneça um registro das capturas de tela do navegador, vídeos e logs internos.
• Para fornecer a capacidade de integração com sistemas externos, como um servidor de correio, sistema de rastreamento de tarefas (JIRA) para verificar os processos de integração entre o sistema testado e os sistemas externos.
• Forneça um relatório documentado sobre todas as ações tomadas, incluindo uma exibição dos valores inseridos e verificados, bem como todos os investimentos necessários.
• Execute testes no volume necessário no modo paralelo.
• Implante autotestes na infraestrutura existente.
• Refine os scripts de teste já automatizados do conceito de destino consoante (velocidade de refinamento - cerca de 50 testes por sprint semanal).

Como mencionei na introdução, no início tínhamos um protótipo de MVP em funcionamento implementado por outra equipe, que tinha que ser aumentado de 20 testes para 1000, adicionando novos recursos ao longo do caminho e garantindo escalabilidade e flexibilidade aceitáveis ​​para fazer alterações.

A presença de um protótipo de trabalho adicionalmente na entrada nos deu uma pilha tecnológica, que incluía: Java SE8, JUnit4, Selenium + Selenide + Selenoid, Bamboo como um "corredor" de testes e um "construtor" de relatórios Allure. Como o protótipo funcionou bem e forneceu a funcionalidade básica necessária, decidimos não alterar a pilha tecnológica, mas focar no desenvolvimento da escalabilidade da solução, aumentar a estabilidade e desenvolver os recursos necessários ausentes.

Basicamente, tudo parecia viável e otimista. Além disso, lidamos completamente com as tarefas em um determinado momento.

A seguir, são descritos os aspectos tecnológicos e de processo individuais do desenvolvimento de Autotestes.

Descrição dos autotestes. Histórias e recursos do usuário

Fonte

Os autotestes implementam o seguinte conjunto de histórias de usuários no contexto de seu uso pelo grupo de teste:

• automação de teste manual;
• regressão completa automática;
• controle de qualidade de montagens na cadeia CI \ CD.

Os detalhes da implementação e as decisões de arquitetura serão discutidos na Parte 2 - Técnico. Arquitetura e pilha técnica. Detalhes de implementação e surpresas técnicas .

Teste automático e manual (histórias de usuários)

Como testador, desejo executar o teste E2E de destino, que será executado sem a minha participação direta (no modo automático) e fornecerá um relatório detalhado no contexto das etapas executadas, incluindo os dados inseridos e os resultados obtidos, bem como:

• Deve ser possível selecionar diferentes posições de alvo antes de iniciar o teste;
• deve ser capaz de gerenciar a composição dos testes em execução de todos os implementados;
• no final do teste, você precisa obter um vídeo do teste na tela do navegador;
• quando o teste falha, é necessário obter uma captura de tela da janela ativa do navegador.

Regressão completa automática

Como grupo de testes, desejo executar todos os testes todas as noites em um banco de testes específico no modo automático, incluindo todos os recursos do "Teste manual automático".

Controle de qualidade de montagem na cadeia CI \ CD

Como grupo de testes, desejo realizar testes automáticos de atualizações implantadas do Sistema em um suporte de pré-QA dedicado antes de atualizar os suportes de estágio de teste funcional de destino, que foram posteriormente utilizados para testes funcionais.

Recursos básicos implementados

Fonte

Aqui está um breve conjunto das principais funções implementadas dos AutoTests, que acabaram sendo vitais ou simplesmente úteis. Detalhes da implementação de algumas funções interessantes estarão na segunda parte do artigo.

Uso local e remoto

A função ofereceu duas opções para executar Autotests - local e remoto.

No modo local, o testador executou o autoteste necessário em seu local de trabalho e, ao mesmo tempo, pôde observar o que estava acontecendo no navegador. O lançamento foi realizado através do "triângulo verde" no IntelliJ IIDEA -). A função foi muito útil no início do projeto para depuração e demonstrações, mas agora é usada apenas pelos desenvolvedores dos autotestes.

No modo remoto, o testador inicia o autoteste usando a interface do plano Bamboo com os parâmetros da composição dos testes em execução, um suporte e alguns outros parâmetros.

A função foi implementada usando a variável de ambiente MODE = REMOTE | LOCAL, dependendo de qual navegador da Web local ou remoto foi inicializado na nuvem Selenoid .

Limitando a composição dos testes em execução por filtro

A função possibilita limitar a composição dos testes em execução no modo de uso remoto para conveniência dos usuários e reduzir o tempo de teste. É usada filtração em duas etapas. A primeira etapa bloqueia a execução de testes com base na variável FILTER_BLOCK e é usada principalmente para excluir a execução de grandes grupos de testes. O segundo passo "pula" apenas os testes que correspondem à variável FILTER.

O valor dos filtros é especificado como um conjunto de expressões regulares REGEXP1, ..., REGEXPN, aplicado pelo princípio de "OR".

Ao iniciar no modo manual, o testador foi solicitado a definir uma variável de ambiente especial como uma lista de expressões regulares aplicáveis ​​à anotação especial @ Filter (String value), que anotou todos os métodos de teste nas classes de teste. Para cada teste, essa anotação é exclusiva e é construída com base em um conjunto de tags separadas por um sublinhado. Usamos o seguinte modelo mínimo SUBSYSTEM_FUNCTION_TEST-ID_ {DEFAULT}, em que a tag DEFAULT é para testes incluídos na regressão noturna automática.

A função é implementada por meio de uma extensão personalizada da classe org.junit.runners.BlockJUnit4ClassRunner (os detalhes serão fornecidos na Parte 2-1 da continuação deste artigo)

Documentando o relatório com os resultados para todas as etapas

Os resultados do teste são exibidos para todas as ações de teste (etapas) com todas as informações necessárias disponíveis no Allure Framework. Listá-los não faz sentido. Há informações suficientes no site oficial e na Internet como um todo. Não houve surpresas ao usar o Allure Framework e, em geral, eu o recomendo.

As principais funções utilizadas são:

• exibição de cada etapa do teste (o nome da etapa corresponde ao seu nome na especificação do teste - script de teste);
• exibir parâmetros de etapa em uma forma legível por humanos (através da implementação necessária do método toString de todos os valores transmitidos);
• Anexar capturas de tela, vídeos e vários arquivos adicionais ao relatório;
• classificação de testes por tipos e subsistemas, bem como a vinculação do autoteste à especificação de teste no sistema de gerenciamento de link de teste Test Link através do uso de anotações especializadas.

Baixe e faça o upload de arquivos de / para o navegador com a verificação e análise subsequentes

Trabalhar com arquivos é um aspecto extremamente importante dos scripts de teste. Era necessário fornecer o upload de vários arquivos e o download.

O download de arquivos implica, em primeiro lugar, o carregamento de arquivos EXCEL gerados dinamicamente no Sistema, de acordo com o contexto de execução do script de teste. O download foi implementado usando métodos padrão fornecidos pelas ferramentas selênio.

O upload de arquivos implicava o download de arquivos pressionando o "botão" no navegador para um diretório local com a subsequente "transferência" desse arquivo para o servidor em que os AutoTests foram executados (o servidor no qual o agente Bamboo remoto foi instalado). Além disso, esse arquivo foi analisado e analisado em termos de formato e conteúdo. Os principais tipos de arquivo foram arquivos EXCEL e PDF.

A implementação dessa função acabou sendo uma tarefa não trivial, principalmente devido à falta de recursos padrão de manipulação de arquivos: no momento, a função é implementada apenas para o navegador Chrome por meio da página de serviço "chrome: // downloads /".

Vou falar detalhadamente sobre os detalhes da implementação na segunda parte.

Contabilidade e controle da natureza assíncrona da interface Angular. Controle de solicitação pendente entre os serviços Angular e REST

Como o objeto do nosso teste foi baseado no Angular, tivemos que aprender a "lutar" com a natureza assíncrona do frontend e dos tempos limite.

Em geral, além de org.openqa.selenium.support.ui.FluentWait, usamos um método de espera especialmente projetado que verifica através de Javascript interações "incompletas" com serviços REST de front-end e, com base nesse tempo limite dinâmico, os testes obtêm informações sobre a seguinte então espere um pouco mais.

Do ponto de vista da funcionalidade, fomos capazes de reduzir significativamente o tempo necessário para concluir os testes devido à rejeição de expectativas estáticas, onde não há como determinar diferentemente a conclusão da operação. Além disso, isso nos permitiu definir serviços REST "suspensos" com problemas de desempenho. Por exemplo, eles capturaram um serviço REST para o qual o número de registros exibidos na página foi definido para 10.000 elementos.

As informações sobre o serviço REST "congelado" com todos os parâmetros de sua chamada, devido ao qual o teste "cai" devido a razões de infraestrutura, são adicionadas aos resultados do teste eliminado e também são transmitidas como um evento no ELK. Isso permite transferir imediatamente os problemas identificados para as equipes de desenvolvimento apropriadas do sistema.

Controle de Log do Navegador

A função de controle de log do navegador foi adicionada para controlar erros nas páginas no nível SEVERE para receber informações adicionais para testes eliminados, por exemplo, para monitorar erros como "... Falha ao carregar o recurso: o servidor respondeu com um status de 500 (Erro Interno do Servidor)".

A composição dos erros de processamento de página no navegador é aplicada a cada resultado do teste e também é descarregada adicionalmente como eventos no ELK.

Gravação de vídeo do teste e remoção do instantâneo da página no ponto de "queda" do teste

Funções são implementadas para a conveniência de diagnosticar e analisar testes eliminados.

A gravação de vídeo é ativada separadamente para o modo de execução de teste remoto selecionado. O vídeo é anexado como um anexo aos resultados no relatório Allure.
Uma captura de tela é feita automaticamente quando o teste falha e os resultados também são aplicados ao relatório Allure.

Passando eventos para ELK

A função de enviar eventos para o ELK é implementada para permitir a análise estatística do comportamento geral dos AutoTestes e a estabilidade do objeto de teste. No momento, foram enviados eventos para concluir os testes com resultados e duração, além de erros do navegador no nível SEVERE e serviços REST "congelados" fixos.

Organização de Desenvolvimento

Fonte

Equipe de desenvolvimento

Então, precisávamos de pelo menos 5 desenvolvedores. Adicione outra pessoa para compensar ausências não planejadas. Temos 6. Além disso, um líder de equipe, responsável pela funcionalidade transversal e pela revisão de código.

Portanto, tivemos que levar 6 desenvolvedores de Java (na realidade, no auge do desenvolvimento de autotestes, a equipe excedeu 10 engenheiros de automação).

Dado o estado geral do mercado e uma pilha tecnológica bastante simples, a equipe era formada principalmente por estagiários, a maioria deles recém-formados em universidades ou no último ano. Na verdade, estávamos procurando pessoas com um conhecimento básico de Java. Foi dada preferência a especialistas em testes manuais que gostariam de se tornar programadores e a candidatos motivados com alguma experiência de desenvolvimento (insignificante) que no futuro desejavam se tornar programadores.

, ( 2 – . . ).

, , . CodeRush . .

. , , «» .

() . code review merge request ( GitLab). code review «» ( ) .

– . / , .

ode review , , () - , . ode review .

code review , .

: , , , , . , , , / .

« », - -. -.

, . sprint retrospective event.

- ( ) , stakeholder .

– . , , . , - . .

- ( , . .), . () , « » / « » ( , , ).

- - ( : - – , - , — , ). , - / : « - ( )».

- , - (-) - («» ). «» - - « X» ( , -).

, . master, -. - - code review.

, – , .

:

(+) ;
(+) ;
(+) «» ;
(-) ();
(-) hotfix .

.

• MASTER.
• .
• FEATURE .
• , « » rebase.
• Gitlab merge request . merge request- :
• — «Jira»;
• — Bamboo.

GateKeeper ( )

• Bamboo.
• .
• (merge) FEATURE DEVELOP, .
• .

---

kotalesssk .

1, , . 2.

A segunda parte - a técnica - é focada principalmente nos líderes dos grupos de automação de testes de interface do usuário de ponta a ponta e na automação de teste líder. Aqui eles encontrarão receitas específicas para a organização arquitetônica de código e implantação, que suporta o desenvolvimento paralelo em massa de grandes grupos de testes em face da constante variabilidade das especificações de teste. Além disso, você pode encontrar na segunda parte a lista completa de funções necessárias para testes de interface do usuário com alguns detalhes de implementação. E uma lista de surpresas que você também pode encontrar.