- Implementação de testes de API e E2E em vários estágios com Cypress, AWS Canary e funções Lambda sem servidor para garantir a confiabilidade e a escalabilidade do sistema.
- Utilizar verificações de integridade, alertas automatizados e OpsItems para evitar falhas, otimizar recursos e acelerar a resolução de incidentes.
- Adotar estratégias de monitoramento econômicas com painéis de controle do Sorry Cypress, execução de testes baseados em Docker sem servidor e validação de front-end em tempo real.
Introdução
No atual cenário digital, a confiabilidade e a alta disponibilidade são requisitos fundamentais para qualquer aplicativo. A Blue Media Services (BMS), por exemplo, adota uma arquitetura de monitoramento e testes que garante a qualidade de seus produtos de forma integrada. Esse cuidado é essencial para conquistar a confiança dos usuários, principalmente em ambientes em que o desempenho e a estabilidade impactam diretamente a experiência do usuário final e os resultados dos negócios.
Para atender a essas demandas, é fundamental ter processos de verificação de qualidade que abranjam tanto os aspectos comerciais (como campanhas e regras específicas) quanto os aspectos de infraestrutura (testes de API, monitoramento de serviços e automação de alertas). Nesse contexto, surge o conceito de verificações de integridade, que envolve a verificação contínua do estado de um produto, serviço ou recurso, avaliando se ele permanece dentro dos parâmetros operacionais aceitáveis. Nas arquiteturas modernas – geralmente distribuídas e baseadas em microsserviços – essas verificações são essenciais para antecipar possíveis problemas antes que eles se transformem em falhas mais graves.
A adoção de verificações de integridade traz vários benefícios. Em termos de confiabilidade, a identificação precoce de falhas permite uma resposta rápida das equipes de desenvolvimento e operações, aumentando a resiliência do sistema. Com relação à economia de recursos, a detecção de serviços ou campanhas inoperantes evita a alocação desnecessária de recursos. A satisfação do usuário é influenciada positivamente pela disponibilidade e pelo desempenho, o que se traduz em melhores resultados comerciais. Além disso, as verificações de integridade ajudam a evitar falhas em cascata, pois a sinalização de um problema local permite a correção antes que ele afete outros componentes ou serviços.
Nas operações diárias, os sistemas de verificação de integridade normalmente classificam o status de cada recurso em categorias, como
- Saudável: quando tudo funciona adequadamente
- Degradado: indica funcionalidade parcial ou limitada
- Não saudávelQuando o serviço não está disponível ou não consegue cumprir sua finalidade
- Não avaliadoUsado quando os dados não podem ser coletados, tornando o status incerto.
Um exemplo prático para ilustrar esses conceitos é uma campanha publicitária com datas de início e término e um orçamento diário. Enquanto estiver ativa, dentro do prazo e do orçamento, podemos considerá-la "saudável". Entretanto, uma falha ou o esgotamento do orçamento pode colocá-la em um estado "degradado" ou "insalubre", de acordo com a gravidade. Se o sistema de verificação de integridade ficar indisponível, a campanha será automaticamente classificada como "não avaliada", pois não há dados confiáveis para confirmar seu status real.
Uma das lacunas comuns nos testes e monitoramento de API é a falta de verificação frequente. Muitas equipes confiam nos testes apenas durante os principais eventos, como implementações e lançamentos, o que permite que as falhas intermediárias passem despercebidas. Além disso, a ausência de testes mais profundos também representa um risco, pois o foco exclusivo nos chamados "caminhos felizes" deixa o sistema vulnerável a cenários complexos e exceções não mapeadas. Outro desafio é a escalabilidade, pois o aumento do número de rotas e serviços pode tornar os testes mais caros, tanto em termos de tempo quanto de infraestrutura. Como resultado, as equipes podem acabar reduzindo a frequência ou o escopo das verificações. Por fim, a má integração com os alertas compromete a eficácia do monitoramento, pois os testes sem um sistema de alerta bem estruturado não conseguem acionar respostas imediatas aos problemas detectados.
Ao longo deste artigo, discutiremos como aplicar esses conceitos de forma sistemática. Destacaremos as principais lacunas nos testes e no monitoramento de APIs e compartilharemos estratégias para solucioná-las. Os tópicos incluem testes em vários estágios (Smoke e E2E), automação com Cypress e Sorry Cypress e monitoramento usando o AWS Canary. Por fim, exploraremos a redução de custos e as melhorias de escalabilidade por meio de recursos sem servidor, como o AWS Lambda e o Docker. Concluiremos com as lições aprendidas e recomendações práticas para aumentar a confiabilidade dos projetos digitais.
Nossa jornada de soluções: Estratégia e processo
Para resolver as lacunas identificadas, a BMS desenvolveu uma solução que combina testes de API, testes de ponta a ponta (E2E) e monitoramento integrado, com ênfase na automação de alertas e no uso de recursos sem servidor para reduzir custos. A estratégia envolve a criação de um pipeline de testes em vários estágios, o que permite separar as verificações rápidas das mais complexas e, ao mesmo tempo, acelerar a identificação e a resolução de problemas.
Arquitetura de teste com a Cypress
A arquitetura de teste com a Cypress na BMS está sendo estruturada com base em estágios bem definidos, seguindo uma abordagem ideal que equilibra agilidade e profundidade na validação do sistema. O primeiro nível planejado é o Smoke Testing (teste de fumaça), que é executado com frequência (idealmente a cada hora) e se concentra em rotas críticas e funcionalidades essenciais – garantindo que o "fluxo de trabalho esperado" funcione corretamente. O objetivo é que, em caso de falha, o sistema acione automaticamente um OpsItem no AWS com prioridade média, iniciando um segundo estágio para uma investigação mais profunda.
Em seguida, a camada de teste de ponta a ponta (E2E) amplia o escopo, abrangendo fluxos de negócios mais complexos, vários caminhos de uso e aspectos como desempenho e usabilidade. A visualização e os relatórios dos resultados dos testes aproveitam o Sorry Cypress, uma alternativa auto-hospedada ao Cypress Cloud, escolhida por suas funcionalidades semelhantes a um custo menor. Os testes E2E podem ser executados de forma programada (por exemplo, diariamente ou durante a noite) ou sob demanda, especialmente quando uma falha crítica identificada no Smoke Testing exige uma análise mais detalhada.
Essa estrutura em camadas – com testes de fumaça frequentes e testes E2E mais abrangentes – serve como princípio orientador para a evolução contínua da estratégia de qualidade da BMS. Para garantir a sustentabilidade e a eficiência a longo prazo desse modelo, a equipe também está investindo em práticas recomendadas, padronização e ferramentas que melhoram a legibilidade e a capacidade de manutenção dos testes automatizados.
Ferramentas e padrões adotados
- Cucumber (BDD): Um dos pilares dessa abordagem é o uso do Cucumber para testes de desenvolvimento orientado por comportamento (BDD), que permite que os cenários sejam descritos em uma linguagem próxima à linguagem natural. Isso facilita a comunicação entre desenvolvedores, QAs e partes interessadas, garantindo o alinhamento sobre o comportamento esperado do sistema.
Exemplo de um recurso para validação de login bem-sucedido e malsucedido:
- Padrão de objeto de página: Outro padrão adotado é o Page Object Pattern, que promove a separação entre a lógica de interação com a interface (seletores e métodos) e os cenários de teste. Isso torna o código mais limpo, mais reutilizável e mais fácil de manter.
Abaixo está um exemplo de implementação para a tela de login:
Exemplo: um teste de login que valida o sucesso e a falha com diferentes credenciais, usando o Gherkin para descrever cenários de forma clara e acessível para toda a equipe.
Usando o AWS Canary para testes E2E de front-end
Como parte da evolução contínua de sua estratégia de qualidade e do monitoramento da experiência do usuário, a BMS está implementando o AWS Canary (Amazon CloudWatch Synthetics) para testes de front-end na produção. O objetivo é simular interações reais na interface da plataforma, complementando o monitoramento da API com validações que reflitam de perto a jornada do usuário.
Atualmente, os testes automatizados do Cypress já estão integrados às rotinas do AWS Lambda, incluindo alguns cenários E2E que são executados com sucesso nesse modelo. O uso do Canary está em fase de implementação, sendo estruturado para cobrir os cenários mais críticos de navegação e interface.
Principais considerações para a implementação futura da Canary:
- Frequência: Execução a cada 12 horas, ajustável com base na criticidade de cada funcionalidade.
- Escopo: Simulações de navegação front-end real (cliques, preenchimento de formulários, validações visuais).
- Ação em caso de falha: Criação automática de um OpsItem com prioridade máxima, pois as falhas na interface do usuário afetam diretamente a experiência do usuário final.
Essa iniciativa visa aumentar a confiança na estabilidade do aplicativo em produção, permitindo respostas mais rápidas a regressões visuais ou problemas de navegação.
Estratégias de otimização de custos e infraestrutura sem servidor
Para garantir o desempenho e a eficiência de custos, o BMS adota uma arquitetura sem servidor, utilizando o AWS Lambda com imagens personalizadas do Docker que incluem todas as dependências necessárias para executar o Cypress no modo sem cabeça.
- Pagamento por uso: Em vez de manter VMs ou instâncias do EC2 em execução, você paga apenas pelo tempo de execução dos Lambdas.
- Escalabilidade automática: Se muitos testes precisarem ser executados em paralelo, o AWS cuidará do dimensionamento.
Criando a imagem do Docker para executar o Cypress no Lambda
Para que o Cypress seja executado em um Lambda, é necessário criar uma imagem personalizada do Docker que inclua as bibliotecas necessárias, especialmente para o Chromium sem cabeçaque requer algumas dependências gráficas (por exemplo, libgtk, libnss3, libx11 etc.).
Um típico Dockerfile incluiria:
Isso possibilita acionar o Lambda e executar testes Cypress sem cabeça em paralelo, integrando-se às verificações de integridade e aos acionadores de monitoramento do AWS.
Dashboards e alarmes (exemplos visuais)
- Desculpe, Cypress Dashboards
Para monitorar a execução dos testes (incluindo os executados via AWS Lambda), o BMS usa os painéis do Sorry Cypress, que fornecem:
- Visualização do status em tempo real das execuções de teste – o número de testes aprovados/fracassados.
- Histórico de execução – permite a comparação de resultados e a identificação de tendências.
- Registros detalhados para cada suíte – facilitando a análise de erros e acelerando a resolução de incidentes.
Detalhes do caso:
Alarmes Lambda e OpsItems no AWS
Quando a função Lambda que executa os testes (Smoke, E2E ou Canary) identifica falhas críticas, algumas etapas automáticas são executadas:
- Os alarmes do CloudWatch são acionados para monitorar o status das execuções do Lambda. Se a taxa de falha exceder um limite predefinido, um alarme será ativado.
- Os OpsItems são abertos no AWS Systems Manager OpsCenter, facilitando a triagem e a priorização de problemas. Cada OpsItem documenta o tipo de falha, o impacto estimado e a pessoa responsável pela resolução.
Gerente de sistemas do AWS OpsCenter
*Dentro de um OpsItem criado no AWS Systems Manager OpsCenter, é possível adicionar um playbook na descrição (usando Markdown) para orientar a análise do alarme. Dessa forma, ao abrir o OpsItem, toda a equipe já tem um roteiro de solução de problemas e verificação, eliminando a necessidade de consultar várias fontes externas.
Lições aprendidas e conclusão
O monitoramento contínuo (verificações de integridade) é essencial para manter as campanhas e as funcionalidades sob supervisão constante, evitando o desperdício de recursos e garantindo a alta disponibilidade da plataforma. A estratégia de testes em etapas, combinando testes de fumaça e testes de ponta a ponta (E2E), provou ser eficaz: enquanto os testes rápidos atuam como uma barreira de verificação inicial, os testes abrangentes são acionados sob demanda quando realmente necessários.
Os alertas automatizados também são um fator importante. A geração automática de OpsItems em caso de falhas acelera a triagem, a priorização e a resolução de incidentes, contribuindo diretamente para uma tomada de decisão mais rápida e eficaz.
No debate entre soluções auto-hospedadas e SaaS, o Sorry Cypress provou ser uma alternativa econômica ao Cypress Cloud, oferecendo funcionalidades semelhantes a um custo menor – ideal para equipes que executam um grande volume de testes automatizados.
Outra lição importante envolve o monitoramento de front-end. Concentrar-se apenas nas APIs pode criar pontos cegos, pois os problemas visuais ou de usabilidade nem sempre são detectados nesses testes. É nesse ponto que o AWS Canary desempenha um papel crucial, simulando a jornada do usuário final, complementando a cobertura de testes e reforçando a confiabilidade do aplicativo – uma área que está evoluindo atualmente na BMS.
Por fim, a adoção de uma arquitetura sem servidor com o AWS Lambda, combinada com imagens personalizadas do Docker, permitiu maior escalabilidade, custos operacionais mais baixos e maior flexibilidade para desenvolver e manter testes automatizados – uma abordagem promissora alinhada com as necessidades de crescimento e estabilidade da plataforma.
Em resumo, a adoção de um sistema integrado de verificações de integridade, testes (API e E2E) e monitoramento com automação de alertas traz confiabilidade, economia de custos e escalabilidade aos projetos digitais. Para as equipes que desejam evoluir suas práticas, vale a pena investir em BDD, Page Object Pattern, Sorry Cypress (auto-hospedado) e soluções sem servidor, como o AWS Lambda, para a execução contínua e otimizada de testes.
Referências
Cypress:
Desculpe, Cypress:
AWS Canary (CloudWatch Synthetics):
https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html
AWS Systems Manager OpsCenter:
https://docs.aws.amazon.com/systems-manager/
Escrito por: João Paulo.
