O que é o teste funcional?
Nesta seção, você acompanhará a equipe da Tailspin enquanto ela define os testes funcionais do pipeline. Os testes funcionais verificam se cada função do software faz o que deveria.
A equipe primeiro define o que um teste funcional aborda. Ela explora alguns tipos de testes funcionais. Em seguida, ela decide o primeiro teste a ser adicionado ao pipeline.
Reunião semanal
A equipe está realizando a reunião semanal. Paulo está demonstrando o pipeline de lançamento. A equipe observa uma mudança de build bem-sucedida no pipeline, de uma fase para outra. Por fim, o aplicativo Web é promovido para Preparo.
Marina: Estou tão feliz com o pipeline. Facilita muito a minha vida. Por um lado, uma versão é implantada automaticamente no ambiente de teste. Isso significa que não preciso baixar e instalar manualmente os artefatos de compilação nos meus servidores de teste. Essa é uma economia de tempo significativa.
Além disso, os testes de unidade que a Clara e o Paulo escreveram eliminam todos os bugs de regressão antes que eu receba a versão. Isso remove uma grande fonte de frustração. Não gasto tempo localizando e documentando bugs de regressão.
Mas estou preocupada que todos os meus testes ainda são manuais. O processo é lento e não podemos mostrar nada para a gerência até terminá-lo. É difícil porque os testes são importantes. Eles garantem que os usuários tenham a melhor experiência. Mas há uma pressão para entregar com mais rapidez.
Paulo: Tenho certeza de que podemos ajudá-la. Que tipo de teste ocupa a maior parte do seu tempo?
Marina: Acho que os testes da interface do usuário. Eu tenho que clicar em cada etapa para garantir o resultado correto, e tenho que fazer isso para cada navegador com suporte. É um processo muito demorado. E, conforme aumenta a complexidade do site, o teste da interface do usuário não será prático a longo prazo.
Clara: Os testes de interface do usuário são considerados testes funcionais.
Pedro: Em oposição a quê, testes não funcionais?
Clara: Exato. E os testes não funcionais são importantes, especialmente para você.
Pedro: Certo, estou confuso.
O que são testes funcionais e não funcionais?
Clara: Testes funcionais verificam se cada função do software faz o que deveria. O modo como o software implementa cada função não é importante nesses testes. O que é importante é que o software se comporta corretamente. Você fornece uma entrada e verifica se a saída é a esperada. É assim que a Marina testa a interface do usuário. Por exemplo, se ela seleciona o melhor jogador no placar de líderes, ela espera ver o perfil desse jogador.
Os testes não funcionais verificam características como desempenho e confiabilidade. Um exemplo de um teste não funcional é verificar quantas pessoas podem entrar no aplicativo simultaneamente. O teste de carga é outro exemplo de um teste não funcional. Essas preocupações de desempenho e confiabilidade são importantes para você, Pedro.
Pedro: Sim, de fato. Preciso pensar um pouco sobre isso. Também gostaria de aumentar a automação do pipeline, mas não tenho certeza do que quero fazer. Que tipos de testes automatizados posso executar?
Clara: Por enquanto, vamos nos concentrar no teste funcional. Ele é o tipo de teste que a Marina realiza. E parece uma área que desejamos aprimorar.
Que tipos de testes funcionais posso executar?
Há vários tipos de testes funcionais. Eles variam de acordo com a funcionalidade que você precisa testar e o tempo ou o esforço que eles normalmente precisam para serem executados.
As seções a seguir apresentam alguns testes funcionais comumente usados.
Smoke test
O smoke test verifica a funcionalidade mais básica do seu aplicativo ou serviço. Esses testes costumam ser executados antes de testes mais completos e exaustivos. Os smoke tests devem ser executados rapidamente.
Por exemplo, digamos que você esteja desenvolvendo um site. O seu smoke test pode usar o curl para verificar se o site está acessível e se a busca da home page produz um status HTTP 200 (OK). Se a busca da home page produzir outro código de status, como 404 (Não Encontrado) ou 500 (Erro Interno do Servidor), você saberá que o site não está funcionando. Você também saberá que não há motivo para executar outros testes. Em vez disso, você diagnostica o erro, conserta-o e reinicia os testes.
Teste de unidade
Você trabalhou com os testes de unidade no módulo Executar testes de qualidade em seu pipeline de build usando o Azure Pipelines.
Em resumo, o teste de unidade verifica os componentes mais importantes do seu programa ou biblioteca, como um método ou função individual. Você especifica uma ou mais entradas, juntamente com os resultados esperados. O executor de teste executa cada teste e verifica se os resultados esperados e reais são correspondentes.
Por exemplo, digamos que você tenha uma função que executa uma operação aritmética que inclui divisão. Você pode especificar alguns valores que espera que os usuários insiram. Você também especifica valores de caso de borda, como 0 e -1. Se você esperar que uma determinada entrada produza um erro ou uma exceção, poderá verificar se a função produz esse erro.
Os testes de interface do usuário que você executará posteriormente neste módulo são testes de unidade.
Teste de integração
O teste de integração verifica se vários componentes de software funcionam em conjunto para formar um sistema completo. Por exemplo, um sistema de comércio eletrônico pode incluir um site, um banco de dados de produtos e um sistema de pagamento. Você pode escrever um teste de integração que adiciona itens ao carrinho de compras e compra os itens. O teste verifica se o aplicativo Web pode se conectar ao banco de dados de produtos e concluir o pedido.
Você pode combinar testes de unidade e testes de integração para criar uma estratégia de teste em camadas. Por exemplo, você pode executar testes de unidade em cada um dos seus componentes antes de executar os testes de integração. Se todos os testes de unidade forem aprovados, você poderá passar para os testes de integração com maior confiança.
Teste de regressão
Uma regressão ocorre quando o comportamento existente é alterado ou interrompido depois que você adiciona ou altera um recurso. O teste de regressão ajuda a determinar se o código, a configuração ou outras alterações afetam o comportamento geral do software.
O teste de regressão é importante porque uma alteração em um componente pode afetar o comportamento de outro componente. Por exemplo, digamos que você otimizou o desempenho de gravação de um banco de dados. O desempenho de leitura desse banco de dados, que é administrado por outro componente, pode cair inesperadamente. A queda no desempenho de leitura é uma regressão.
Você pode usar várias estratégias para testar a regressão. Essas estratégias normalmente variam de acordo com o número de testes que você executa para verificar se um novo recurso ou correção de bug não interrompe a funcionalidade existente. No entanto, quando você automatiza os testes, os testes de regressão podem envolver apenas a execução de todos os testes de unidade e de integração sempre que o software for alterado.
Teste de integridade
O teste de integridade envolve testar cada componente principal de um software para verificar se o software parece estar funcionando e pode passar por um teste mais completo. Você pode pensar nos testes de sanidade como menos completos do que os testes de regressão ou testes de unidade, mas os testes de sanidade são mais amplos do que os smoke tests.
Embora o teste de integridade possa ser automatizado, geralmente ele é feito manualmente em resposta a uma alteração de recurso ou a uma correção de bug. Por exemplo, um testador de software que está validando uma correção de bug também pode verificar se outros recursos estão funcionando inserindo alguns valores típicos. Se o software parecer estar funcionando conforme o esperado, ele poderá passar por uma etapa de teste mais completa.
Testar interface do usuário
O teste da IU (interface do usuário) verifica o comportamento da interface do usuário de um aplicativo. Os testes de UI (interface do usuário) ajudam a verificar se a sequência (ou ordem) das interações do usuário tem o resultado esperado. Esses testes também ajudam a verificar se os dispositivos de entrada, como o teclado ou o mouse, afetam a interface do usuário corretamente. Você pode executar testes de interface do usuário para verificar o comportamento de um aplicativo nativo do Windows, do macOS ou do Linux. Ou você pode usar testes de interface do usuário para verificar se a interface do usuário se comporta conforme o esperado nos navegadores da Web.
Um teste de unidade ou de integração pode verificar se a interface do usuário recebe os dados corretamente. Mas o teste da interface do usuário ajuda a verificar se a interface do usuário é exibida corretamente e se o resultado funciona como esperado para o usuário.
Por exemplo, um teste de interface do usuário pode verificar se a animação correta aparece em resposta a um clique de botão. Um segundo teste poderá verificar se a mesma animação é exibida corretamente quando a janela for redimensionada.
Neste módulo, você trabalha com testes de interface do usuário que são codificados manualmente. Mas você também pode usar um sistema de captura e reprodução para criar automaticamente os seus testes de interface do usuário.
Teste de usabilidade
O teste de usabilidade é uma forma de teste manual que verifica o comportamento de um aplicativo da perspectiva do usuário. O teste de usabilidade é normalmente feito pela equipe que cria o software.
Enquanto os testes da interface do usuário se concentram em se um recurso se comporta conforme o esperado, o teste de usabilidade ajuda a verificar se o software é intuitivo e atende às necessidades do usuário. Em outras palavras, o teste de usabilidade ajuda a verificar se o software é "utilizável".
Por exemplo, digamos que você tenha um site que inclui um link para o perfil do usuário. Um teste de interface do usuário pode verificar se o link está presente e se ele abre o perfil do usuário quando o link é clicado. No entanto, se as pessoas não conseguirem localizar esse link facilmente, elas poderão ficar frustradas ao tentar acessar o perfil.
Teste de aceitação do usuário
Um UAT (teste de aceitação do usuário), como o teste de usabilidade, se concentra no comportamento de um aplicativo da perspectiva do usuário. Ao contrário do teste de usabilidade, o UAT normalmente é feito por usuários finais reais.
Dependendo do software, pode ser solicitado que os usuários finais concluam tarefas específicas. Ou eles podem ter permissão para explorar o software sem seguir nenhuma diretriz específica. No software personalizado, o UAT normalmente ocorre diretamente com o cliente. Em um software com um uso mais geral, as equipes podem executar testes beta. Em testes beta, os usuários de diferentes regiões geográficas ou usuários que têm determinados interesses recebem acesso antecipado ao software.
Os comentários dos testadores podem ser diretos ou indiretos. Os comentários diretos podem vir na forma de comentários verbais. Os comentários indiretos podem ser decorrentes da linguagem corporal ou dos movimentos dos olhos dos testadores ou do tempo que eles levam para concluir determinadas tarefas.
Já abordamos a importância de escrever testes. Mas, apenas para enfatizar isso, veja um breve vídeo em que Abel Wang, Consultor de Nuvem na Microsoft, explica como ajudar a garantir a qualidade do seu plano de DevOps.
Pergunte ao Abel
O que a equipe escolhe?
Pedro: Todos esses testes parecem importantes. Qual devemos realizar primeiro?
Paulo: Os testes de unidade já estão funcionando. Ainda não estamos prontos para realizar o teste de aceitação do usuário. Com base no que ouvi, acho que devemos nos concentrar nos testes de interface do usuário. No momento, essa é a parte mais lenta de nosso processo. Marina, você concorda?
Marina: Sim, concordo. Ainda temos algum tempo restante nesta reunião. Paulo ou Clara, vocês querem me ajudar a planejar um teste de interface do usuário automatizado?
Clara: Com certeza. Mas vamos realizar algumas etapas preliminares primeiro. Gostaria de discutir qual ferramenta devemos usar e como executaremos os testes.
Quais ferramentas posso usar para escrever os testes de interface do usuário?
Clara: Quando se trata de escrever testes de interface do usuário, quais são nossas opções? Eu sei que há muitas. Algumas ferramentas são de software livre. Outras oferecem suporte comercial pago. Veja algumas opções que vêm à mente:
- WinAppDriver (Windows Application Driver): o WinAppDriver ajuda a automatizar testes de interface do usuário em aplicativos do Windows. Esses aplicativos podem ser gravados na UWP (Plataforma Universal do Windows) ou no WinForms (Windows Forms). Precisamos de uma solução que funcione em um navegador.
- Selenium: o Selenium é uma estrutura de teste de software livre portátil para aplicativos Web. Ele é executado na maioria dos sistemas operacionais e dá suporte a todos os navegadores modernos. Você pode escrever testes do Selenium em várias linguagens de programação, incluindo C#. Na verdade, você pode usar pacotes NuGet que facilitam a execução do Selenium como testes do NUnit. Já usamos o NUnit nos nossos testes de unidade.
- SpecFlow: o SpecFlow é usado em projetos .NET. Ele é inspirado por uma ferramenta chamada Cucumber. Tanto o SpecFlow como o Cucumber dão suporte ao BDD (desenvolvimento orientado por comportamento). O BDD usa um analisador de idioma natural chamado Gherkin para ajudar as equipes técnicas e não técnicas a definirem regras e requisitos de negócios. Você pode combinar o SpecFlow ou o Cucumber com o Selenium para criar testes de interface do usuário.
Paulo olha para Marina.
Paulo: Sei que essas opções são novas para você, então você se importa se escolhermos o Selenium? Tenho alguma experiência com ele e ele dá suporte a linguagens que já conheço. O Selenium também fornecerá suporte automático para vários navegadores.
Marina: Claro. É melhor que um de nós tenha alguma experiência.
Como faço para executar testes funcionais no pipeline?
No Azure Pipelines, os testes funcionais são executados da mesma forma que qualquer outro processo ou teste. Pergunte-se:
- Em qual fase os testes serão executados?
- Em qual sistema os testes serão executados? Eles serão executados no agente ou na infraestrutura que hospeda o aplicativo?
Vamos acompanhar a equipe enquanto eles respondem a essas perguntas.
Clara: Estou empolgada porque agora podemos testar em um ambiente que é igual ao de produção, no qual o aplicativo está realmente em execução. Os testes funcionais, como os testes de interface do usuário, fazem sentido nesse contexto. Podemos executá-los na fase de Teste do nosso pipeline.
Marina: Concordo. Será possível manter o mesmo fluxo de trabalho se executarmos testes de interface do usuário automatizados na mesma fase em que os testes manuais são executados. Os testes automatizados nos pouparão tempo e permitirão que eu me concentre na usabilidade.
Pedro: A Marina testa o site com um laptop do Windows porque é assim que a maioria de nossos usuários visita o site. Mas nós o compilamos no Linux e implantamos o Serviço de Aplicativo do Azure no Linux. Como administramos isso?
Clara: Ótima pergunta. Também podemos escolher onde executar os testes. Podemos executá-los:
- No agente: seja um agente da Microsoft ou um agente que hospedamos
- Na infraestrutura de teste: seja local ou na nuvem
Nossa fase de Teste existente inclui um trabalho. Esse trabalho implanta o site no Serviço de Aplicativo de um agente do Linux. Podemos adicionar um segundo trabalho que executa os testes de interface do usuário por meio de um agente do Windows. O agente do Windows hospedado pela Microsoft já está configurado para executar testes do Selenium.
Paulo: Mais uma vez, vamos nos concentrar no que sabemos. Vamos usar um agente do Windows hospedado pela Microsoft. Posteriormente, será possível executar os mesmos testes de agentes que executam o macOS e o Linux se precisarmos de cobertura de teste adicional.
O plano
Clara: OK. Veja o que vamos fazer:
- Executar testes de interface do usuário do Selenium em um agente do Windows hospedado pela Microsoft
- Fazer com que os testes busquem o conteúdo da Web do aplicativo em execução no Serviço de Aplicativo, na fase de Teste
- Executar os testes em todos os navegadores aos quais damos suporte
Paulo: Trabalharei com a Marina neste projeto. Marina, vamos nos encontrar amanhã de manhã. Gostaria de pesquisar um pouco antes de nos encontrarmos.
Marina: Legal! Então encontro você lá.
Criar um plano de teste funcional
Acabamos de ver a equipe decidir como implementar os primeiros testes funcionais. Se a sua equipe estiver começando a incorporar testes funcionais no seu pipeline (ou mesmo que você já esteja fazendo isso), lembre-se de que sempre precisa de um plano.
Muitas vezes, quando alguém solicita aos membros da equipe o plano de teste de desempenho, é comum que eles respondam com uma lista das ferramentas que serão usadas. No entanto, uma lista de ferramentas não é um plano. Você também deve descobrir como os ambientes de teste serão configurados. Você precisa determinar os processos a serem usados e o que é considerado sucesso ou falha.
Verifique se o seu plano:
- Considera as expectativas do negócio.
- Considera as expectativas dos usuários de destino.
- Define as métricas que serão usadas.
- Define os KPIs que serão usados.
O teste de desempenho precisa fazer parte do seu planejamento desde o início. Se você usar uma história ou quadro Kanban, considere ter uma área próxima a ele, na qual poderá planejar a sua estratégia de teste. Como parte do plano de iteração, as lacunas na estratégia de teste devem ser realçadas. Também é importante descobrir como o desempenho será monitorado depois que o aplicativo for implantado e não apenas medir o desempenho antes dele ser liberado.