Estratégias de teste para seu aplicativo
O teste é um dos componentes fundamentais do DevOps e do desenvolvimento ágil em geral. Se a automação fornecer ao DevOps a velocidade e a agilidade necessárias para implantar o software rapidamente, somente por meio de testes extensivos essas implantações atingirão a confiabilidade necessária que os clientes exigem.
Um conceito principal de uma prática de DevOps para atingir a confiabilidade do sistema é o princípio de deslocar à esquerda. Se você descrever seu processo para desenvolver e implantar um aplicativo como uma série de etapas que se movem da esquerda para a direita. Em seguida, o teste deve ser deslocado o máximo possível para o início do processo (à esquerda) e não colocado no final do processo (à direita). Os erros são muito mais baratos de reparar quando são percebidos antecipadamente, e problemas podem ser caros ou impossíveis de serem corrigidos posteriormente no ciclo de vida do aplicativo.
Os testes devem ocorrer tanto no código do aplicativo quanto no código da infraestrutura e eles devem estar sujeitos aos mesmos controles de qualidade. O ambiente em que os aplicativos estão em execução deve ter controle de versão e ser implantado por meio dos mesmos mecanismos do código do aplicativo. Como resultado, você pode testar e validar o código do aplicativo e o código da infraestrutura usando paradigmas de teste de DevOps.
Você pode usar sua ferramenta de teste favorita para executar os testes, incluindo o Azure Pipelines para testes automatizados e o Azure Test Plans para teste manual.
Há várias fases em que você pode executar testes no ciclo de vida do código, e cada tipo de teste tem diversas considerações que são importantes para você entender. Nesta unidade, você pode encontrar um resumo de vários dos diferentes testes que você deve considerar ao desenvolver e implantar aplicativos.
Teste automatizado
Automatizar testes é a melhor maneira de garantir que eles serão executados. Dependendo da frequência dos testes, eles normalmente são limitados em duração e escopo. As descrições a seguir listam alguns dos aspectos que você precisa considerar ao criar sua estratégia de teste.
Teste de Unidade
Os testes de unidade são geralmente executados em cada nova versão do código que é confirmada em seu sistema de controle de versão. Os testes de unidade devem ser extensos (o ideal é cobrir 100% do código) e rápidos (normalmente menos de 30 segundos, embora esse número não seja uma regra imutável). O teste de unidade pode verificar aspectos como a exatidão da sintaxe do código do aplicativo, modelos do Resource Manager ou configurações do Terraform. Ele também pode verificar se o código está seguindo as melhores práticas ou se eles produzem os resultados esperados quando recebem determinadas entradas.
Os testes de unidade devem ser aplicados ao código do aplicativo e ao código da infraestrutura.
Smoke test
Os smoke tests são mais completos do que os testes de unidade, mas ainda não tanto quanto os testes de integração. Os smoke tests normalmente são executados em menos de 15 minutos. Embora os smoke tests não verifiquem a interoperabilidade de seus diferentes componentes entre si, eles verificam se cada componente pode ser compilado corretamente e se cada componente atende aos seus critérios de funcionalidade e desempenho esperados.
Os smoke tests geralmente envolvem a compilação do código do aplicativo. Se você estiver implantando a infraestrutura como parte do processo, os smoke tests poderão envolver o teste da implantação em um ambiente de teste.
Testes de integração
Depois de verificar se os diferentes componentes do aplicativo operam corretamente de maneira individual, o teste de integração determina se os componentes podem interagir entre si como deveriam. Os testes de integração geralmente levam mais tempo do que os smoke tests e, como consequência, às vezes são executados com menos frequência. Por exemplo, executar testes de integração toda noite ainda oferece um bom comprometimento entre os diferentes tipos de teste automatizado; seu teste de integração detectará problemas de interoperabilidade entre os componentes do aplicativo, no máximo um dia depois que eles foram introduzidos.
Teste manual
Os testes manuais são muito mais caros do que os testes automatizados e, como consequência, são usados com menos frequência do que os testes automatizados. No entanto, o teste manual é fundamental para o funcionamento correto do loop de comentários do DevOps. Os testes manuais são usados para corrigir erros antes que eles se tornem muito caros para serem reparados ou antes que causem a insatisfação do cliente.
Teste de aceitação
Há muitas maneiras diferentes de confirmar que o aplicativo está fazendo o que deveria.
Implantações azuis/verdes: ao implantar uma nova versão de aplicativo, você pode implantá-la em paralelo à existente. Dessa maneira, você pode começar a redirecionar seus clientes para a nova versão. Se tudo correr bem, você encerrará a versão antiga. Se houver algum problema com a nova implantação, você poderá redirecionar seus clientes de volta para a implantação mais antiga.
Versões do canário: você pode expor a nova funcionalidade do seu aplicativo (de preferência usando sinalizadores de recurso) para um grupo selecionado de usuários. Se esses usuários estiverem satisfeitos com a nova funcionalidade, você poderá estendê-la para o restante da sua comunidade de usuários. Neste cenário, estamos falando sobre a liberação da funcionalidade, e não necessariamente sobre a implantação de uma nova versão do aplicativo.
Teste A/B: o teste A/B é semelhante ao teste de versão canário. As versões canário se concentram na redução de riscos, enquanto o teste A/B se concentra na avaliação da eficácia de duas maneiras semelhantes de atingir a mesma meta. Por exemplo, se você tiver duas versões do layout de uma determinada área do seu aplicativo, poderá enviar metade de seus usuários para uma versão A e a outra metade dos seus usuários para uma versão B e, em seguida, poderá usar algumas métricas para ver qual layout funciona melhor para suas metas de aplicativo.
Um aspecto importante a ser considerado é como medir a eficácia dos novos recursos em um aplicativo. Uma maneira de medir isso é por meio da Análise de Comportamento do Usuário do Application Insights, que você pode usar para determinar como as pessoas estão usando seu aplicativo. Analisando os resultados, você pode decidir se um novo recurso aumentou ou diminuiu a usabilidade do seu aplicativo.
Certos serviços no Azure oferecem funcionalidades que podem ajudar na implementação desses tipos de testes. Por exemplo: a funcionalidade do slot de implantação no Serviço de Aplicativo do Azure permite que você tenha duas versões diferentes do mesmo aplicativo em execução ao mesmo tempo e você pode redirecionar os usuários para uma versão ou outra.
Teste de estresse
Como as outras seções desta estrutura explicaram, projetar o código do aplicativo e a infraestrutura para escalabilidade é de extrema importância. Com a escalabilidade em mente, é essencial que você teste se o código do aplicativo e da infraestrutura pode se adaptar às condições variáveis de carga. Por exemplo, se houver um pico na atividade do usuário, você precisará ter certeza de que seu aplicativo e sua infraestrutura serão dimensionados automaticamente para atender à maior demanda.
Durante os testes de estresse, é essencial que você monitore todos os componentes do sistema para identificar se há limitações de escala. Todos os componentes do sistema que não puderem ser escalados horizontalmente podem se transformar em um gargalo (como os componentes de rede ativos/passivos ou bancos de dados). É importante conhecer os limites de cada um dos componentes para que você possa reduzir o impacto na escala do aplicativo. Conforme você aprende mais sobre as características de desempenho de cada um de seus componentes, as descobertas feitas ao longo do caminho podem motivar você a substituir alguns dos componentes por equivalentes mais escalonáveis.
Após a conclusão do teste de estresse, é igualmente importante verificar se a sua infraestrutura é reduzida de volta para a condição normal dela, a fim de manter os custos sob controle.
Injeção de falha
Seu aplicativo deve ser resiliente a falhas de infraestrutura e a introdução de falhas na infraestrutura subjacente e a observação de como seu aplicativo se comporta é fundamental para aumentar a confiança em seus mecanismos de redundância. Exemplos de testes de injeção de falha incluem desligar incorretamente componentes de infraestrutura, degradar o desempenho de determinados elementos, como equipamentos de rede. Esses testes oferecem a você um modo de verificar se o aplicativo vai continuar a se comportar ou reagir conforme o esperado, caso essas situações ocorram na vida real.
A maioria das empresas usa uma forma controlada de injetar falhas no sistema; porém, se você confiar na resiliência de seu aplicativo, poderá usar estruturas automatizadas. A engenharia de caos é uma prática adotada por algumas organizações para identificar áreas em que podem ocorrer falhas, tornando as principais partes da infraestrutura não disponíveis propositadamente.
Teste de segurança
Outro componente crítico da estratégia de teste deve ser testar rotineiramente o aplicativo em busca de vulnerabilidades de segurança. Você deve executar regularmente testes de segurança em seu aplicativo para identificar as vulnerabilidades do aplicativo que são introduzidas por meio de defeitos de código ou por meio de dependências de software. Esses testes podem incluir verificações de segurança automatizadas para testar as vulnerabilidades comuns, como scripts entre sites ou injeção de SQL. Os testes de segurança também podem incluir exercícios da equipe vermelha, em que as equipes de segurança tentam comprometer seu aplicativo.
Use os resultados desses testes para fornecer comentários por todo o processo de desenvolvimento e resolver problemas de segurança que você encontrar em suas dependências de código ou de software.