Introdução
Teste de caixa preta é o teste que avalia o software apenas pelo comportamento externo: você fornece entradas, observa as saídas e compara com o resultado esperado pela especificação. O testador não olha o código-fonte, a estrutura interna nem a lógica de implementação.
O que ele valida?
Os testes se baseiam em requisitos, regras de negócio, casos de uso e user stories, e não no código. Por isso o teste vale para qualquer nível (unitário, integração, sistema, aceitação) e para testes funcionais e não funcionais.
Técnicas Principais
| Técnica | Ideia | Exemplo |
|---|---|---|
| Particionamento de equivalência | Divide as entradas em classes que o sistema deve tratar igual; testa um valor por classe | Idade aceita de 18 a 65: classes <18 (inválida), 18–65 (válida), >65 (inválida) |
| Análise de valor limite | Testa as bordas das partições, onde os defeitos se concentram | 17, 18, 65, 66 |
| Tabela de decisão | Mapeia combinações de condições para ações | Desconto depende de cliente VIP + valor da compra + cupom |
| Transição de estados | Testa mudanças de estado e quais são permitidas | Pedido: criado → pago → enviado; "enviado → criado" deve ser rejeitado |
| Casos de uso / cenários | Percorre fluxos completos do usuário | Login → adicionar ao carrinho → checkout |
Exemplo concreto
Regra: "Frete grátis para compras a partir de R$ 200,00."
Sem ver o código, você testa:
- R$ 199,99 → cobra frete
- R$ 200,00 → frete grátis (valor limite)
- R$ 200,01 → frete grátis
- R$ 0,00 e valor negativo → rejeita ou trata como inválido
O código pode estar escrito de qualquer forma. O que importa é se o comportamento bate com a regra.
Vantagens e limitações
Vantagens
- Independe da linguagem e da implementação.
- Testa do ponto de vista do usuário.
- Pode ser feito por quem não programa.
- Os casos de teste podem ser escritos assim que a especificação existe, antes do código.
Limitações
- Não garante cobertura do código: ramos internos podem nunca ser executados.
- Especificação ambígua ou incompleta gera testes ruins.
- É difícil identificar a causa exata de uma falha só pela saída.
- Sem técnica, há risco de testes redundantes ou de lacunas.
Contraste com caixa branca
- Caixa preta: parte da especificação e mede cobertura de requisitos.
- Caixa branca: parte do código e mede cobertura de código (comandos, decisões, caminhos).
- Caixa cinza: combina os dois, com conhecimento parcial da estrutura interna (por exemplo, saber o schema do banco ao testar uma API).
Na prática, os dois se complementam: a caixa preta encontra o que não está de acordo com o requisito, e a caixa branca encontra o que o requisito nem previa.
Top comments (0)