O que é o teste de caos?

O teste de caos é uma técnica usada para testar a resiliência de sistemas de software, introduzindo falhas ou interrupções inesperadas. O teste de caos também é conhecido como engenharia do caos. O objetivo do teste de caos é identificar fraquezas e melhorar a resiliência do seu aplicativo.

Os testes de caos baseiam-se na ideia de que os sistemas falham de formas inesperadas. Os métodos de teste tradicionais muitas vezes não conseguem descobrir esses modos de falha inesperados. Ao usar o teste de caos, você simula cenários do mundo real, como falhas de servidor, latência de rede ou esgotamento de recursos. Simular esses comportamentos ajuda a expor problemas ocultos e fraquezas que podem não ser evidentes em condições normais de teste.

Aqui estão alguns pontos-chave a ter em mente sobre os testes de caos:

  • Seja proativo. Em vez de esperar que as falhas aconteçam, os testes de caos introduzem proativamente falhas para ver como o sistema responde. O teste de caos permite identificar e corrigir problemas antes que eles se tornem grandes problemas.
  • Obtenha perceções. O objetivo dos testes do caos é aprender com as falhas. Ao introduzi-los, pode obter insights valiosos sobre como o sistema se comporta sob pressão e usar essa informação para o melhorar.
  • Promova um esforço de equipa. O teste de caos é mais eficaz quando você o faz de forma colaborativa. Você quer informações de desenvolvedores, testadores, operações e outras partes interessadas. Trabalhando em conjunto, pode identificar as áreas mais importantes a testar e garantir que todos estão informados.
  • Comece pequeno e acumule. Quando você começa com testes de caos, é uma boa ideia começar pequeno e aumentar gradualmente a complexidade de seus testes. Começar pequeno ajuda-o a ganhar confiança e a desenvolver uma melhor compreensão de como o sistema se comporta em diferentes condições.

Em resumo, o teste de caos é uma técnica poderosa que pode ajudá-lo a melhorar a resiliência de seus aplicativos. Ao introduzir proativamente falhas e aprender com elas, você pode identificar e corrigir problemas antes que eles se tornem grandes problemas.

Testes de caos para as APIs que a tua aplicação chama

Os testes do caos focam-se frequentemente na infraestrutura: servidores, redes e contentores. Se a sua aplicação depende de APIs, algumas das falhas que os seus utilizadores notam vêm dessas APIs: um 500 de um fornecedor de pagamentos, um 429 do GitHub ou OpenAI, ou uma resposta que demora 8 segundos em vez de 80 milissegundos. Pode aplicar as mesmas ideias de testes de caos a essas dependências, ao nível das respostas individuais da API:

  • Erros. Gera 5xx erros aleatoriamente e verifica se a tua aplicação tenta novamente o que é seguro tentar e mostra uma mensagem útil para o resto.
  • Regulação Devolva 429 com um Retry-After cabeçalho e verifique se a sua aplicação espera antes de voltar a ligar.
  • Latência. Simula atrasos nas respostas e verifica os teus tempos mortos, spinners e o que acontece quando as respostas chegam fora de ordem.
Approach O que encontra Do que sente falta
Aguardar a produção Fracassos reais Tudo, até que um utilizador clique nele
Simula a API nos teus testes, ou deixa o teu agente de programação escrever o mock Se os seus ramos de erro são executados Os verdadeiros formatos de falha da API, a política de retentativas do teu SDK e o comportamento da aplicação em execução. A tua aplicação também precisa de um switch só de teste para chegar ao mock.
Danificar infraestrutura real (por exemplo, eliminar um serviço ou bloquear o tráfego de rede) Como o seu sistema lida com falhas Falhas ao nível da API, como um código de erro específico ou um cabeçalho Retry-After
Intercete o tráfego real da sua aplicação e injete falhas na API Erros, limitação de taxa e latência nos URLs reais, à taxa que escolheres Falhas de infraestrutura. Usa ferramentas de chaos engineering de infraestrutura para isso.

Experimente na sua app

Dev Proxy introduz falhas na API na sua aplicação enquanto continua a chamar os URLs reais. Funciona com qualquer tipo de aplicação, em qualquer stack tecnológico, sem alterar o teu código. Por exemplo, para falhar metade dos pedidos para uma API com erros aleatórios, siga Teste a minha aplicação com erros aleatórios e, para os tornar lentos, veja Simular respostas lentas da API. Para executar os mesmos testes no seu pipeline de CI, veja Usar Dev Proxy em CI/CD.

Próximo passo