Eu só queria adicionar e dar um pouco mais de contexto sobre por que temos esses níveis de teste, o que eles realmente significam com exemplos
Mike Cohn, em seu livro “Successful with Agile”, criou a “Testing Pyramid” como uma maneira de abordar testes automatizados em projetos. Existem várias interpretações desse modelo. O modelo explica que tipo de testes automatizados precisam ser criados, com que rapidez eles podem dar feedback sobre o aplicativo em teste e quem os escreve. Existem basicamente três níveis de teste automatizado necessários para qualquer projeto e são os seguintes.
Testes de unidade - testam o menor componente do seu aplicativo de software. Isso poderia literalmente ser uma função em um código que calcula um valor com base em algumas entradas. Essa função faz parte de várias outras funções da base de código de hardware / software que compõe o aplicativo.
Por exemplo - vamos usar um aplicativo de calculadora baseado na web. Os menores componentes deste aplicativo que precisam ser testados em unidade podem ser uma função que executa adição, outro que executa subtração e assim por diante. Todas essas pequenas funções juntas formam o aplicativo da calculadora.
Historicamente, o desenvolvedor grava esses testes, pois geralmente são escritos na mesma linguagem de programação que o aplicativo de software. Estruturas de teste de unidade, como JUnit e NUnit (para java), MSTest (para C # e .NET) e Jasmine / Mocha (para JavaScript) são usadas para esse fim.
A maior vantagem dos testes de unidade é que eles são executados muito rapidamente sob a interface do usuário e podemos obter um feedback rápido sobre o aplicativo. Isso deve incluir mais de 50% dos seus testes automatizados.
Testes de API / integração - Eles testam vários componentes do sistema de software juntos. Os componentes podem incluir bancos de dados de teste, APIs (Application Programming Interface), ferramentas e serviços de terceiros junto com o aplicativo.
Por exemplo - no exemplo da calculadora acima, o aplicativo Web pode usar um banco de dados para armazenar valores, usar APIs para fazer algumas validações no servidor e usar uma ferramenta / serviço de terceiros para publicar resultados na nuvem e disponibilizá-lo em diferentes plataformas.
Historicamente, um desenvolvedor ou controle de qualidade técnico escreveria esses testes usando várias ferramentas, como Postman, SoapUI, JMeter e outras ferramentas como o Testim.
Eles são executados muito mais rapidamente do que os testes de interface do usuário, pois ainda são executados sob o capô, mas podem consumir um pouco mais de tempo do que os testes de unidade, pois precisam verificar a comunicação entre os vários componentes independentes do sistema e garantir uma integração perfeita. Isso deve incluir mais de 30% dos testes automatizados.
Testes de interface do usuário - Finalmente, temos testes que validam a interface do usuário do aplicativo. Esses testes geralmente são escritos para testar fluxos de ponta a ponta através do aplicativo.
Por exemplo - No aplicativo da calculadora, pode haver um fluxo de ponta a ponta, abrindo o navegador-> Inserindo o URL do aplicativo da calculadora -> Fazendo login com nome de usuário / senha -> Abrindo o aplicativo da calculadora -> Executando algumas operações na calculadora -> verificar esses resultados na interface do usuário -> Sair do aplicativo. Esse poderia ser um fluxo de ponta a ponta que seria um bom candidato à automação da interface do usuário.
Historicamente, os QAs técnicos ou os testadores manuais escrevem testes de interface do usuário. Eles usam estruturas de código aberto como Selenium ou plataformas de teste de interface do usuário como o Testim para criar, executar e manter os testes. Esses testes fornecem mais feedback visual, como você pode ver como os testes estão sendo executados, a diferença entre os resultados esperados e os reais através de capturas de tela, logs e relatórios de teste.
A maior limitação dos testes de interface do usuário é que eles são relativamente lentos se comparados aos testes de nível de unidade e API. Portanto, ele deve incluir apenas 10 a 20% dos testes automatizados gerais.
Os próximos dois tipos de testes podem variar com base no seu projeto, mas a idéia é:
Testes de fumaça
Isso pode ser uma combinação dos três níveis de teste acima. A idéia é executá-lo durante cada check-in de código e garantir que as funcionalidades críticas do sistema ainda estejam funcionando conforme o esperado; após as novas alterações de código serem mescladas. Eles normalmente precisam ser executados com 5 a 10 minutos para obter um feedback mais rápido sobre falhas
Testes de regressão
Eles geralmente são executados uma vez por dia, pelo menos, e abrangem várias funcionalidades do sistema. Eles garantem que o aplicativo ainda esteja funcionando conforme o esperado. São mais detalhes do que os testes de fumaça e abrangem mais cenários do aplicativo, incluindo os não críticos.