Boa tarde, queridos leitores.
Quero falar sobre a experiência de construir um sistema de automação de teste quando não há nenhum teste no projeto ou seu grau é mínimo.
Espero que o artigo seja útil para autotestes iniciantes.
- Na primeira parte, somos a favor da abordagem geral.
- Na segunda parte ( Parte 1 ), com exemplos, faremos um projeto de autoteste em JAVA + para ensinar como testar rapidamente a API.
- Na terceira parte, suplementaremos o projeto para testes de interface do usuário, faremos testes paralelos.
Quando fazer autoteste?
A resposta curta é o mais cedo possível.
Um completo será revelado abaixo. De qualquer forma, quando o projeto funciona por 3 anos e tudo foi verificado manualmente, a vida se torna muito monótona. E uma frota de 5000 cenários para automatizar em um mês ou dois é problemática. Como regra, nesses projetos, você terá que começar a elaborar os scripts novamente. Porque será mais rápido. E não o fato de que o antigo será capaz de automatizar sem alterações significativas.
Porque
Porque autotets:
- Acumular cenários para regressão
- Imparcial
- Rápido
Cenários Acumulados
Quanto maior a frota de cenários automatizados, maior a probabilidade de encontrar uma regressão, especialmente se os dados forem alterados a cada execução.
Se o teste automático passou de forma estável e caiu em alguma ramificação, eles mudaram os requisitos ou um bug ou a infraestrutura falhou.
Imparcialidade
Se os requisitos forem alterados, o autoteste deve passar para a alteração, juntamente com a alteração da funcionalidade principal. É por isso que os testadores estão participando da aprovação do TK.
Se um teste for vinculado automaticamente a uma tarefa, ninguém poderá dizer que não foi testado. Ou vice-versa, ele pode. Em geral, existem definitivamente menos problemas.
Velocidade
Se cada teste satisfizer as condições tediosas:
Pré-condição - Teste - Pós-condição
Tais testes são fáceis de automatizar.
E então é fácil paralelizar. Porque eles são independentes.
O número de threads - quantos servidores de teste podem suportar e para não incomodar os outros.
O segundo ponto é a própria velocidade. No modo manual, clique na criação do produto, sua busca e compra na loja online é de 5 minutos. 4 navegadores. Total de 20 minutos. Em apenas um pequeno cenário.
O autoteste neste cenário leva 1,5 minutos. Mas em 8 navegadores. (Versões mais recentes e penúltimas de cada navegador).
Por onde começar?
Com scripts personalizados.
O valor dos testes atômicos cai o tempo todo, especialmente em microsserviços. Em geral, em um mundo ideal, essa é a área de responsabilidade do programador. Tais erros devem ser detectados no estágio de teste da unidade.
O controle de qualidade deve funcionar a partir da história do usuário. Porque o programador geralmente não a conhece e não quer saber.
Consequentemente, o caso lógico 1 teste - 1 usuário (cenário de negócios) é o mais próximo da realidade.
Obviamente, há dificuldades com a preparação dos dados, por exemplo, no caso de uma loja online, o processo de pagamento com cartão exige a presença de itens na cesta e dados para um novo usuário ou dados de autorização para um existente.
Sim, algumas vezes as pré-condições demoram mais que um teste, mas não é difícil reutilizar scripts.
Quais scripts automatizar
Menos suscetível a alterações a curto prazo. Para automação, pelo menos, alguns viveram.
Ou mais comumente usado. Faz sentido ajudar o teste manual na geração de dados de teste. Por exemplo, no quadro de avisos, faz sentido automatizar a criação de anúncios, porque Além disso, qualquer cenário requer um anúncio criado.
O que exatamente fazer?
Geralmente em projetos lá
- Backend
- Frontend
- Aplicativos móveis
- Glândulas
E os dois últimos pontos - geralmente vivem separadamente. Os telefones móveis são testados em seus próprios scripts e poucos são capazes de abordar a depuração de ferro de acordo com o JTAG sem preparação.
Portanto, proponho lidar com o back-end e a frente.
Escolha um cenário
Digamos que temos uma loja online.
Há um painel de administração, há uma frente de cliente e administrador.
Existe uma API que serve tudo isso.
Por onde começar a automação?
Vamos assistir.
Existem clientes, existem funcionários.
O cliente tem o primeiro caso - visualizando e pesquisando o produto, adicionando-o ao carrinho e projetando.
O funcionário tem o caso mais comum - adicionar um cartão de produto.
Qual caso será automatizado primeiro? E como
O mais importante para a loja são as vendas.
Portanto, o histórico do cliente é mais importante para os negócios. Portanto, encontrar as mercadorias, colocá-las na cesta e concluir o pagamento com qualquer forma de pagamento é a primeira coisa a fazer.
Pela API. Mas sem frente. Aqui você pode argumentar, mas provavelmente o design mudará 2-3 vezes mais, mas o back-end é improvável. Portanto, no estágio 1, você deve verificar a interface manualmente.
Em seguida, verifique a API que está editando o cartão do produto e sua frente.
E volte para o cliente. Nesse estágio, já haverá estatísticas sobre as ações mais freqüentes do usuário e os caminhos mais freqüentes do cliente. Sim, o Yandex Metric e o Webvisor também ajudam os testadores.
Não faz sentido, no primeiro estágio, verificar se a função de pagamento para a conta da empresa através do sistema de pagamento gerado funciona se 0,5% dos visitantes usarem essa função. Obviamente, você pode fazer uma pergunta ao gerente por que isso é necessário aqui, mas não é sobre isso.
Suponha que 40% das pessoas paguem no site com um cartão, 30% em dinheiro, 20% em dinheiro na entrega e 10% em todos os outros métodos.
Que tipo de pagamento vamos verificar primeiro? Claro que o mapa.
Ou seja, precisamos entender claramente qual cenário é o mais importante para os negócios no momento. E sua qualidade é antes de tudo.
Pós-condições
Criamos tudo, tudo nos testes. Ninhada. Seria necessário limpar depois de si mesmo. É necessário prever com antecedência quais testes limparemos depois de nós mesmos e em quais - não.
Se as mercadorias puderem ser deixadas na loja e nada de ruim acontecer, será necessário devolver a adição de direitos de administrador ao usuário comum. E então o próximo teste relacionado a direitos pode cair. Ou pior - seja positivo, embora deva ter caído.
Extravagâncias
Existe uma abordagem estranha quando eles automatizam scripts nos quais os usuários encontram um bug. Geralmente, esses são cenários muito exóticos, e gastar um recurso neles não faz sentido. Houve uma situação em que a funcionalidade de atualização dos dados do banco da contraparte foi interrompida. A sincronização com o diretório BIC falhou.
Ou seja, o novo BIC não foi atualizado. Mas o novo banco começou normalmente.
Faz sentido automatizar esse cenário? Se os contratantes mudam todos os dias - talvez. E então foi uma falha no planejamento.
Se isso for feito de 5 a 6 vezes por ano, será melhor executar uma tarefa de maior prioridade?
O que acontecerá depois?
No próximo artigo, mostrarei como iniciar rapidamente o teste da API, incorporar esses testes em lançamentos, paralelizar testes, como selecionar dados para testes e o que isso nos dará.
Deixe-me lembrá-lo sobre o efeito de um pesticida e como reduzi-lo ao mínimo.
Tecnologias: Java + maven + testng + allure + RestAssured + Pict.