Testando a superfície de observabilidade

O teste de aplicativos e serviços nativos da nuvem geralmente é feito no nível da UI ou da API para garantir que ambas as “superfícies” atendam aos seus requisitos funcionais e não funcionais.

Infelizmente, esses testes não fornecem informações sobre os componentes subjacentes envolvidos nas transações testadas. Isso resulta em um enorme ponto cego para testes que cresce com a complexidade e a natureza distribuída da sua infraestrutura de aplicativos.

A observabilidade, em geral, e o OpenTelemetry, em particular, visam obter insights detalhados sobre o funcionamento interno das transações distribuídas de um aplicativo. Eles são expostos como uma “superfície de observabilidade” que é ortogonal às superfícies API/UI voltadas para o consumidor mencionadas acima.

Aproveitar a superfície de observabilidade para fins de teste permite dois recursos principais que melhoram muito os testes para aplicativos distribuídos:

1. Testar observabilidade
2. Teste baseado em rastreamento

Observabilidade de teste

A observabilidade do teste fornece um novo artefato para cada execução de um teste — um rastreamento distribuído completo.

Os rastreamentos fornecem uma visão detalhada do fluxo de solicitações em diferentes serviços em um sistema distribuído. Eles auxiliam na compreensão de todo o percurso de uma solicitação, do início ao fim. Isto é crucial para diagnosticar problemas, otimizar o desempenho e garantir a confiabilidade. Quando um rastreamento é capturado para cada teste, a observabilidade do teste oferece vários benefícios importantes:

• Visibilidade de ponta a ponta: Todo o caminho de execução disparado pelo teste é capturado. Você pode ver o caminho da solicitação percorrido pelos diversos microsserviços, incluindo o tempo gasto em cada serviço e as interações entre eles.
• Detecção de erro: Erros e exceções que ocorrem no sistema são destacados, fornecendo contexto em torno dos pontos de falha e ajudando na resolução mais rápida de testes que falharam.
• Análise de latência: Os rastreamentos mostram claramente a quantidade de tempo gasto em cada etapa da execução do teste, permitindo a identificação de gargalos e pontos críticos de desempenho.
• Análise de causa raiz: Com informações detalhadas sobre tempos e erros, os problemas são rastreados até sua causa raiz, seja um serviço específico, uma consulta de banco de dados ou uma chamada de API externa.
• Resolução mais rápida: Os testes falham. Ter informações vinculadas a cada teste que podem ajudar a identificar a causa raiz e determinar a qual equipe pedir ajuda para resolver o problema melhora o tempo médio de resolução (MTTR).

A observabilidade do teste, assim como o uso tradicional da observabilidade, é uma ferramenta usada de forma reativa, assim que o teste é interrompido, em um esforço de solução de problemas amplamente manual. O segundo recurso principal, o teste baseado em rastreamento, permite o uso proativo desse novo artefato de teste.

Teste baseado em rastreamento

Todas as ferramentas de teste usam dados da superfície sob exame para criar afirmações e verificar a operação adequada do sistema.

Os testes de API normalmente funcionam como testes de caixa preta na superfície da API, limitados à verificação de atributos retornados de uma chamada de API, como o código de status, a duração da chamada ou os dados do corpo da resposta.

Os testes ponta a ponta (E2E) na superfície do navegador/IU normalmente oferecem mais informações e visibilidade do próprio mecanismo do navegador. Eles podem fazer declarações contra o conteúdo da página e a resposta de chamadas de rede, e alguns podem analisar informações de desempenho extraídas de fontes como o Chrome DevTools Protocol (CDP).

Os testes baseados em rastreamento permitem testar os dados expostos e capturados da superfície de observabilidade. Ortogonal às superfícies de API/UI voltadas para o consumidor, a superfície de observabilidade tem visibilidade de todo o fluxo. Isso fornece vários benefícios importantes:

• Testabilidade ponta a ponta: Refletir todo o fluxo do processo por meio da instrumentação OpenTelemetry permite que afirmações sejam feitas para verificar a operação adequada. As asserções podem ser funcionais e não funcionais. aqui estão alguns exemplos:
  • Verifique se uma chamada para um fornecedor externo responde corretamente, verificando o sucesso da chamada, os dados retornados ou a duração.
  • Verifique se processos assíncronos importantes foram chamados e finalizados corretamente, verificando sistemas que podem não refletir erros na API ou na superfície da UI.
• Asserções curinga para detectar erros desconhecidos: As especificações de teste baseadas em rastreamento têm dois componentes – o seletor e a afirmação. O seletor permite declarar exatamente a quais intervalos a asserção deve ser aplicada. Normalmente, as asserções são específicas para um determinado processo, mas ter asserções curinga é muito poderoso. Você pode afirmar que
  • Todas as chamadas gRPC envolvidas nesta transação foram bem-sucedidas.
  • Todas as transações do Postgres ocorrem mais rápido que 100 ms.
• Integral ao desenvolvimento orientado para a observabilidade: A observabilidade tem sido tradicionalmente uma reflexão tardia, necessária aos engenheiros de confiabilidade do local, mas dependente da organização de desenvolvimento da instrumentação. Permitir uma integração poderosa e testes E2E que aproveitam a observabilidade a ser criada pelos desenvolvedores muda essa dinâmica, agregando valor à instrumentação nas diversas funções.
• Minimize os defeitos liberados: Os testes baseados em rastreamento usam a visão ortogonal do plano de observabilidade para permitir testes mais profundos e completos, procurando e afirmando especificações funcionais e não funcionais, ao mesmo tempo que são capazes de verificar “desconhecidos/desconhecidos”. Esse uso proativo da observabilidade permite que os problemas sejam detectados em seus processos de CI/CD antes de serem liberados para produção.

Tracetest — Usando a Superfície de Observabilidade

Tracetest é uma solução que combina seu foco na superfície de observabilidade com recursos de teste tradicionais direcionados às superfícies de API ou UI, combinando os pontos fortes das duas abordagens ortogonais.

Tracetest executa testes nativamente na superfície da API, acionando testes por meio de sua API REST, endpoint gRPC ou colocando uma mensagem em uma fila. Ele pode até importar seus testes atuais do Postman ou executar testes em suas funções como uma arquitetura baseada em serviço.

Para aprimorar os testes na superfície da IU, o Tracetest combina com seus testes Cypress ou Playwright existentes. Com a superfície de observabilidade sendo exposta e aproveitada por um teste Tracetest incorporado, seu teste E2E aprimorado agora pode validar o front-end, a superfície da API e todo o seu fluxo de back-end, fornecendo visibilidade e afirmações em todo o processo.

Quer começar a usar o Tracetest para adicionar observabilidade de teste e testes baseados em rastreamento em seus pipelines de CI/CD? Primeiro, traga seu fornecedor existente de aplicativos instrumentados e observabilidade do OpenTelemetry. Tracetest funciona nativamente com os principais fornecedores de observabilidade, como Datadog, Honeycomb, Jaeger, Tempo ou Dynatrace. Segundo, faça seus testes existentes, como Postman, k6, Artillery, Cypress ou Playwright, e use o Tracetest com eles.

Disponível como plataforma SaaS ou local, o Tracetest aproveita o investimento que sua organização fez em observabilidade para permitir um uso proativo por toda a equipe de engenharia, reduzindo tanto o tempo para corrigir testes quanto a capacidade desses testes.

A postagem Testando a superfície de observabilidade apareceu pela primeira vez em The New Stack.