DEV Community

Cover image for Cenário de Teste vs Caso de Teste: Principais Diferenças Explicadas
Lucas
Lucas

Posted on • Originally published at apidog.com

Cenário de Teste vs Caso de Teste: Principais Diferenças Explicadas

“Cenário de teste” e “caso de teste” costumam aparecer como sinônimos, mas não são. Confundir os dois deixa o plano de testes vago demais para executar ou detalhado demais para revisar. O cenário define o que testar; o caso define como testar. Quando você separa essas camadas, sua cobertura fica mais auditável, executável e fácil de manter.

Experimente o Apidog hoje

Este guia mostra a diferença prática entre cenário e caso de teste, como estruturar os dois em testes de API e como aplicar esse fluxo usando Apidog.

O que é um cenário de teste?

Um cenário de teste é uma declaração de alto nível sobre um comportamento que precisa ser validado. Ele descreve a intenção do teste, sem entrar em endpoint, payload, headers ou valores esperados.

Pense no cenário como o item de cobertura no plano de teste.

Para um checkout de e-commerce, bons cenários seriam:

  • Verificar checkout para um usuário registrado com cartão salvo
  • Verificar checkout para um usuário convidado
  • Verificar checkout quando um item fica sem estoque durante a compra
  • Verificar checkout quando o pagamento é recusado

Cada cenário responde:

Que comportamento do produto ou da API precisa funcionar?

Ele não responde:

  • Qual endpoint chamar?
  • Qual payload enviar?
  • Qual status HTTP esperar?
  • Qual campo validar na resposta?

Exemplo de cenário:

Cenário: Usuário convidado consegue finalizar uma compra.
Enter fullscreen mode Exit fullscreen mode

Isso é legível para produto, QA e engenharia. Também serve como mapa de cobertura: se o cenário não existe, nenhum caso de teste detalhado vai cobrir aquela lacuna.

O que é um caso de teste?

Um caso de teste é a verificação concreta e executável dentro de um cenário. Ele define pré-condições, entrada, ação e resultado esperado com precisão suficiente para que qualquer pessoa ou ferramenta obtenha o mesmo veredito.

Para o cenário:

Cenário: Verificar checkout para um usuário convidado.
Enter fullscreen mode Exit fullscreen mode

Você pode criar casos como:

  • POST /orders com payload válido de convidado retorna 201 e um order_id
  • POST /orders sem endereço de entrega retorna 400 e validation_error
  • POST /orders com SKU fora de estoque retorna 409 e error: out_of_stock

Um caso de teste precisa ser específico. Por exemplo:

POST /orders
Content-Type: application/json
Enter fullscreen mode Exit fullscreen mode 
{
  "customer": {
    "type": "guest",
    "email": "guest@example.com"
  },
  "shipping_address": {
    "street": "Rua A",
    "city": "São Paulo",
    "zip": "01000-000"
  },
  "items": [
    {
      "sku": "SKU-123",
      "quantity": 1
    }
  ],
  "payment_method": "credit_card"
}
Enter fullscreen mode Exit fullscreen mode

Resultado esperado:

Status: 201
Response body:
- order_id existe
- status = "created"
- total > 0
Enter fullscreen mode Exit fullscreen mode

A diferença é simples:

"O checkout funciona"                     -> cenário vago
"POST /orders com convidado válido..."    -> caso de teste executável
Enter fullscreen mode Exit fullscreen mode

Se você precisa de um modelo completo, veja como escrever casos de teste de API. Para entender onde entram scripts automatizados, veja caso de teste vs script de teste.

As principais diferenças

Dimensão Cenário de teste Caso de teste
Nível Alto nível: o que testar Baixo nível: como testar
Detalhe Breve, normalmente uma linha Passo a passo, com dados
Foco Objetivo de negócio ou funcional Execução técnica
Entradas Não especificadas Payloads, headers e parâmetros exatos
Resultado esperado Implícito Declarado com precisão
Público Produto, QA e engenharia QA, desenvolvedores e automação
Quantidade Poucos por funcionalidade Muitos por cenário
Momento de criação Planejamento do teste Depois que os cenários são definidos

A relação é hierárquica:

Funcionalidade
└── Cenário de teste
    ├── Caso de teste 1
    ├── Caso de teste 2
    └── Caso de teste 3
Enter fullscreen mode Exit fullscreen mode

O cenário controla a amplitude da cobertura.

Os casos controlam a profundidade da validação.

Um erro comum é criar dezenas de casos detalhados sem mapear os cenários. O resultado é uma lista plana de testes, sem resposta clara para perguntas como:

A funcionalidade de checkout de convidado está realmente coberta?

Outro ponto importante:

  • Um cenário pode estar coberto ou não coberto
  • Um caso de teste pode estar aprovado ou reprovado

Você precisa dos dois níveis para gerenciar qualidade.

Como cenários e casos funcionam juntos

Um fluxo prático vai do geral para o específico.

1. Identifique cenários a partir dos requisitos

Leia a documentação da API, histórias de usuário ou especificação funcional. Liste os comportamentos que precisam ser validados, incluindo caminhos de erro.

Exemplo:

Funcionalidade: Notas

Cenários:
- Usuário cria uma nota
- Usuário lista suas notas
- Usuário edita uma nota existente
- Usuário exclui uma nota
- Usuário não autenticado não acessa notas
Enter fullscreen mode Exit fullscreen mode

Inclua também unhappy paths:

- Criar nota sem título
- Criar nota com payload inválido
- Criar nota com token expirado
Enter fullscreen mode Exit fullscreen mode

2. Defina o objetivo de cada cenário

Escreva o que significa o cenário estar correto.

Exemplo:

Cenário: Usuário cria uma nota

Objetivo:
Um usuário autenticado deve conseguir criar uma nota válida.
Payloads inválidos devem ser rejeitados com mensagens claras.
Usuários não autenticados não devem criar notas.
Enter fullscreen mode Exit fullscreen mode

Isso evita interpretações diferentes entre QA, backend e produto.

3. Escreva casos de teste para cada cenário

Expanda o cenário em casos concretos.

Para cada caso, defina:

  • Pré-condição
  • Endpoint
  • Método HTTP
  • Headers
  • Payload
  • Resultado esperado
  • Asserções

Modelo simples:

Caso: Criar nota com dados válidos

Pré-condição:
- Usuário autenticado
- Token válido disponível

Requisição:
POST /notes

Resultado esperado:
- Status 201
- Campo id existe
- title corresponde ao enviado
- created_at existe
Enter fullscreen mode Exit fullscreen mode

4. Revise a completude

Antes de executar, revise a cobertura.

Perguntas úteis:

  • Cada cenário tem pelo menos um happy path?
  • Cada cenário tem casos negativos?
  • Todos os status HTTP documentados aparecem em algum caso?
  • Campos obrigatórios têm validação?
  • Permissões e autenticação foram cobertas?
  • Há casos para limites de tamanho, formato e valores inválidos?

Lacunas encontradas nessa etapa são baratas. Lacunas encontradas em produção não são.

5. Execute e rastreie resultados

Execute os casos e registre:

  • Aprovado/reprovado por caso
  • Cenários afetados
  • Erros por endpoint
  • Status HTTP inesperados
  • Diferenças no contrato da API

O relatório ideal mostra os dois níveis:

Cenário: Usuário cria uma nota
Status: Em risco

Casos:
✅ Criar nota válida
❌ Criar nota sem título
✅ Criar nota sem autenticação
Enter fullscreen mode Exit fullscreen mode

Assim, engenharia sabe qual caso falhou, e produto entende qual comportamento está em risco.

Para equipes que usam BDD, cenários também podem ser escritos em Given-When-Then. Veja o guia Gherkin para teste de API BDD.

Exemplo prático: do cenário aos casos

Considere uma API de notas.

O comportamento principal:

Cenário: Um usuário pode criar uma nota.
Enter fullscreen mode Exit fullscreen mode

Esse cenário é intencionalmente simples. Ele pertence ao plano de teste e deve ser compreensível por qualquer pessoa.

Agora transforme esse cenário em casos executáveis.

Caso 1: criar nota com sucesso

Requisição:

POST /notes
Authorization: Bearer <token>
Content-Type: application/json
Enter fullscreen mode Exit fullscreen mode 
{
  "title": "Compras",
  "body": "leite, ovos"
}
Enter fullscreen mode Exit fullscreen mode

Resultado esperado:

Status: 201
Response:
- id não vazio
- title = "Compras"
- body = "leite, ovos"
- created_at existe
Tempo de resposta: < 600 ms
Enter fullscreen mode Exit fullscreen mode

Caso 2: criar nota sem campo obrigatório

Requisição:

POST /notes
Authorization: Bearer <token>
Content-Type: application/json
Enter fullscreen mode Exit fullscreen mode 
{
  "body": "leite, ovos"
}
Enter fullscreen mode Exit fullscreen mode

Resultado esperado:

Status: 400
Response:
- error = "validation_error"
- details contém "title"
Enter fullscreen mode Exit fullscreen mode

Caso 3: criar nota sem autenticação

Requisição:

POST /notes
Content-Type: application/json
Enter fullscreen mode Exit fullscreen mode 
{
  "title": "Compras",
  "body": "leite, ovos"
}
Enter fullscreen mode Exit fullscreen mode

Resultado esperado:

Status: 401
Response:
- nenhum id é retornado
Enter fullscreen mode Exit fullscreen mode

Caso 4: criar nota com payload muito grande

Requisição:

POST /notes
Authorization: Bearer <token>
Content-Type: application/json
Enter fullscreen mode Exit fullscreen mode 
{
  "title": "Arquivo grande",
  "body": "<texto com 2 MB>"
}
Enter fullscreen mode Exit fullscreen mode

Resultado esperado:

Status: 413
Response:
- mensagem de erro clara
Enter fullscreen mode Exit fullscreen mode

Resultado da estrutura:

Cenário: Um usuário pode criar uma nota
├── Caso 1: payload válido
├── Caso 2: campo obrigatório ausente
├── Caso 3: sem autenticação
└── Caso 4: payload muito grande
Enter fullscreen mode Exit fullscreen mode

Um cenário, quatro casos. O cenário define o que validar. Os casos definem como validar.

Se depois você adicionar:

Cenário: Um usuário pode anexar um arquivo a uma nota.
Enter fullscreen mode Exit fullscreen mode

Esse é um novo cenário, com seus próprios casos. O plano cresce de forma estruturada, em vez de virar uma pilha solta de verificações.

Construindo cenários e casos no Apidog

Apidog permite modelar essa hierarquia diretamente no fluxo de teste de API.

Um cenário de teste no Apidog pode ser montado como uma sequência ordenada de requisições. Cada etapa representa uma chamada de API com suas próprias validações.

Exemplo de fluxo:

1. POST /auth/login
   - Extrair token da resposta

2. POST /notes
   - Usar token no header Authorization
   - Validar status 201
   - Validar campo id

3. GET /notes/{id}
   - Confirmar que a nota criada pode ser consultada
Enter fullscreen mode Exit fullscreen mode

Esse encadeamento é útil quando uma requisição depende do resultado da anterior, como:

  • Login retorna token
  • Criação retorna id
  • Consulta usa o id
  • Exclusão usa o mesmo id

Cada bloco de requisição com asserções funciona como um caso de teste. Você pode validar:

  • Código de status
  • Campos do corpo da resposta
  • Schema
  • Tempo de resposta
  • Valores esperados
  • Dados extraídos de respostas anteriores

Também é possível usar teste orientado a dados para executar o mesmo caso com múltiplas entradas de CSV ou JSON. Isso ajuda a cobrir variações inválidas sem duplicar manualmente cada teste.

Exemplo de massa de dados:

title,body,expected_status
Compras,"leite, ovos",201
,"sem título",400
Titulo,"",201
Enter fullscreen mode Exit fullscreen mode

Depois, os cenários podem ser agrupados em conjuntos de teste (test suites) para execuções repetíveis.

Você pode executar esses conjuntos:

  • Localmente
  • Em uma programação
  • Dentro de CI
  • Como parte de um fluxo de validação antes do deploy

O valor está no relatório em dois níveis:

Caso falhou:
POST /notes sem title retornou 500 em vez de 400

Cenário afetado:
Usuário pode criar uma nota
Enter fullscreen mode Exit fullscreen mode

Engenharia vê o detalhe técnico. Liderança vê o impacto na funcionalidade.

Para começar, baixe o Apidog e crie seu primeiro cenário com múltiplos casos.

Por que você precisa de ambos

Pular uma das camadas cria problemas diferentes.

Se você escreve apenas casos de teste:

❌ Lista longa de requisições
❌ Sem mapa de cobertura
❌ Difícil responder se uma funcionalidade está completa
Enter fullscreen mode Exit fullscreen mode

Se você escreve apenas cenários:

❌ Plano legível, mas não executável
❌ Resultados inconsistentes entre testadores
❌ Automação difícil ou impossível
Enter fullscreen mode Exit fullscreen mode

Use os dois:

Cenários = cobertura e intenção
Casos = execução e evidência
Enter fullscreen mode Exit fullscreen mode

Eles também atendem públicos diferentes:

  • Produto lê cenários para validar se as funcionalidades certas estão cobertas
  • QA usa cenários para organizar o plano
  • Desenvolvedores usam casos para entender contratos e falhas
  • Automação executa casos
  • Liderança acompanha o status por cenário

A regra prática:

Mantenha cenários estáveis.
Atualize casos sempre que o contrato da API mudar.
Enter fullscreen mode Exit fullscreen mode

Cenários mudam quando a intenção da funcionalidade muda. Casos mudam quando endpoints, payloads, autenticação, schemas ou regras de validação mudam.

Perguntas frequentes

Um cenário de teste é o mesmo que um conjunto de testes?

Não. Um cenário descreve um comportamento a ser validado. Um conjunto de testes é uma coleção de testes executáveis agrupados para uma execução.

Um conjunto pode conter casos de vários cenários.

Veja também: conjunto de testes vs caso de teste.

Quantos casos de teste um cenário deve ter?

O suficiente para cobrir:

  • Happy path
  • Validações obrigatórias
  • Erros esperados
  • Permissões
  • Limites relevantes
  • Códigos de status documentados

Um cenário simples pode ter três ou quatro casos. Um cenário crítico ou complexo pode exigir muito mais.

Quem escreve cenários e quem escreve casos?

Cenários geralmente são definidos em conjunto por produto, QA e engenharia, porque representam a intenção do comportamento.

Casos normalmente são escritos por QA ou desenvolvedores, porque exigem detalhes técnicos da API.

Para padronizar a escrita, veja o formato de especificação de caso de teste.

Preciso de cenários se meus testes são automatizados?

Sim. A automação executa casos, mas os cenários dizem se os casos corretos existem.

Automação sem mapa de cobertura apenas executa lacunas mais rápido.

Top comments (0)