Quando os casos de teste de endpoint e cenários de teste em um projeto continuam crescendo, o custo de gerenciá-los e executá-los individualmente aumenta drasticamente. O que era para salvaguardar a qualidade – o teste automatizado – pode se tornar um fardo de manutenção.
Tradicionalmente, as equipes selecionam os casos de teste manualmente. Quando um projeto acumulou muitos casos e cenários de teste, decidir manualmente quais incluir e quais executar para regressão se torna um trabalho manual pesado.
As Suítes de Teste do Apidog abordam isso com uma abordagem dinâmica. Em vez de armazenar rigidamente IDs, uma suíte armazena um conjunto de regras de filtro—por exemplo, por pasta, tag, prioridade ou uma combinação de condições.
Antes de cada execução, a suíte de teste reúne automaticamente todos os casos de teste e cenários de teste que correspondem a essas regras. Você pode se concentrar em escrever testes e aplicar tags; novos ativos de teste são detectados automaticamente e fluem para seu pipeline de CI/CD para uma integração contínua verdadeiramente autônoma.
Todos os resultados da execução são então resumidos em um único relatório agregado para facilitar a análise e a solução de problemas.
Crie e Orquestre Sua Primeira Suíte de Teste
Após atualizar o Apidog para a versão mais recente, abra o módulo Testes e encontre a seção Suíte de Testes. Clique no menu ... ao lado e escolha Criar Suíte de Testes.
No pop-up, insira um nome descritivo e defina opções como prioridade ou tags. Uma suíte de teste vazia é criada.
Em seguida, adicione conteúdo à suíte. Uma suíte de teste pode conter casos de teste de endpoint individuais ou cenários de teste compostos por várias etapas de teste.
Adicionando Conteúdo de Teste: Estático e Dinâmico
Ao clicar em Adicionar Caso de Teste de Endpoint ou Adicionar Cenário de Teste, você pode escolher o modo Estático ou Dinâmico. Esses modos determinam como a suíte decide o que executar e se adequam a diferentes objetivos de manutenção e teste.
O modo estático fixa o conjunto exato de itens a serem executados. Ao selecionar casos específicos no modo estático, o sistema armazena os IDs únicos desses casos. Se novos casos forem adicionados posteriormente à mesma pasta ou casos forem movidos, o escopo de execução da suíte não muda. O comportamento é determinístico e o mesmo em cada execução.
O modo dinâmico funciona de forma diferente. Ele não armazena IDs de casos específicos; ele armazena regras de filtro, como "todos os casos em uma determinada pasta" ou "todos os casos com a tag 'semantic-valid'", ou "todos os cenários de teste com prioridade P0".
No modo dinâmico, toda vez que a suíte de teste é executada, o sistema verifica novamente o projeto usando essas regras e inclui todos os casos que atualmente correspondem. Qualquer caso de teste ou cenário cujos atributos (pasta, tags, prioridade) correspondam às regras é incluído automaticamente.
Modo Estático vs. Dinâmico: Como Escolher?
Nenhum dos modos é universalmente melhor; eles atendem a necessidades diferentes. A escolha depende de como você deseja que a suíte se comporte ao longo do tempo.Para testes dedicados e com escopo bem definido (por exemplo, um conjunto de regressão fixo), o modo estático é mais previsível. Para iterações contínuas e testes de regressão ou smoke "automáticos", o modo dinâmico reduz muito a manutenção.
Para uma comparação rápida dos dois modos, veja a tabela abaixo:
| Aspecto | Modo Estático | Modo Dinâmico |
|---|---|---|
| Lógica principal | Armazena IDs de casos específicos | Armazena regras de filtro (pasta, tags, prioridade, etc.) |
| Conteúdo ao longo do tempo | Fixo, a menos que você o altere manualmente | Atualiza automaticamente conforme casos correspondentes são adicionados ou removidos |
| Custo de manutenção | Maior; novos casos devem ser adicionados manualmente | Menor; defina as regras uma vez, e as execuções permanecem sincronizadas |
| Uso típico | Verificação de correção de bugs, estabilidade do caminho principal, testes de compatibilidade | Regressão completa, smoke tests, aceitação de lançamento |
Ordem de Execução e Configuração Avançada
Após adicionar conteúdo, você pode reordenar os itens na lista de orquestração arrastando-os.
Para cada item de execução (por exemplo, cenário de teste), você pode controlar o comportamento da execução com mais detalhes através das opções à direita.
Por exemplo, Em Erro permite que você escolha se deseja continuar, pular a rodada atual ou parar toda a execução quando uma etapa falha. Iterações permite que você execute a suíte inteira várias vezes para verificações simples de estabilidade. Juntas, essas opções tornam uma suíte de teste não apenas uma coleção de casos, mas um fluxo de execução controlável.
Executando Suítes de Teste
Uma vez que a suíte de teste esteja configurada, você pode executá-la de várias maneiras: desde execuções manuais locais até automação baseada em nuvem, dependendo do seu estágio e ambiente.
Executando Suítes de Teste Localmente
A maneira mais direta é clicar em Executar no cliente Apidog. A execução ocorre na sua máquina local e é adequada para verificações pequenas e rápidas durante o desenvolvimento e depuração. Na configuração de execução, você pode alternar o ambiente de execução e definir uma notificação quando a execução terminar.
Quando a execução é concluída, o Apidog gera um relatório de teste e o exibe na interface do usuário. O relatório lista cada caso de teste de endpoint e cenário de teste na ordem de execução, com status claro de aprovação/falha. Você pode abrir itens individuais para mais detalhes.
Executando Suítes de Teste via CLI
Para conjuntos de testes maiores ou ambientes sem interface gráfica (por exemplo, servidores sem GUI), o CLI do Apidog é a melhor opção. Ele leva a execução de testes do Apidog para qualquer terminal.
Para executar via CLI, instale o CLI do Apidog e certifique-se de que esteja atualizado. Em seguida, na aba CI/CD da suíte de teste, use o comando gerado:
Copie esse comando para o seu terminal para executar a suíte e ver o mesmo fluxo e resultados que na interface do usuário.
Quando a execução termina, uma pasta chamada apidog-reports/ é criada no diretório atual e contém o relatório de teste em HTML.
A execução via CLI é a base para a integração CI/CD. Você pode conectar esse comando ao Jenkins, GitLab CI ou GitHub Actions e acionar testes de regressão em pontos-chave, como fusão de código.
Executando Suítes de Teste via Tarefas Agendadas
O Apidog suporta Tarefas Agendadas. Na aba Tarefas Agendadas da suíte de teste, crie uma tarefa e defina seu agendamento e ambiente de execução.
Ao contrário das execuções locais, as tarefas agendadas devem ser executadas em um Runner auto-hospedado.
O Runner é um programa leve que sua equipe pode implantar em um servidor interno. O uso de um Runner evita falhas quando as máquinas locais estão desligadas ou inacessíveis e permite que você use os recursos do servidor para execuções de testes maiores.
Depois que uma tarefa agendada é configurada, o Apidog executa a suíte de teste no Runner nos horários especificados e faz o upload do histórico de execução e dos relatórios. Você também pode configurar notificações de falha para que, quando um problema ocorrer, as pessoas certas sejam alertadas rapidamente.
Resumo
Com a orquestração estática e dinâmica, você pode manter testes dedicados com escopo bem definido e permitir que as suítes de regressão cresçam automaticamente com seu projeto, sem atualizações manuais constantes. Combinadas com execuções locais, integração CLI e tarefas agendadas, as suítes de teste podem se encaixar em todas as etapas do seu fluxo de trabalho — desde verificações rápidas durante o desenvolvimento até regressão automatizada em CI/CD e verificações agendadas em produção.
Para mais informações sobre suítes de teste, consulte a documentação do Apidog. Tente criar sua primeira suíte de teste, orquestre seus testes existentes e construa uma configuração de regressão automatizada sustentável passo a passo.