Introdução
Teste de caixa branca (também chamado de estrutural, transparente ou glass box) é o teste que se baseia na estrutura interna do código. O testador conhece a implementação e projeta casos de teste para exercitar comandos, decisões, condições e caminhos específicos. A pergunta é: "o código foi exercitado o suficiente?".
Se aplica principalmente em teste unitário e de integração, porque exige acesso ao código. Em geral é feito por quem desenvolve ou sabe ler o código.
Este tipo de teste é fundamental para garantir que todos os caminhos e condições do código sejam devidamente validados, promovendo uma maior confiabilidade do sistema. Ele é particularmente importante para identificar erros em uma fase inicial do desenvolvimento, evitando problemas maiores no futuro. Ele envolve a análise minuciosa do código-fonte, verificando sua lógica e fluxos de execução.
Características Principais
- Conhecimento do Código: O testador precisa ter acesso ao código-fonte e um profundo conhecimento sobre a estrutura interna do aplicativo.
- Cobertura de Código: Foca na cobertura de código, incluindo instruções, ramos, caminhos e condições. A cobertura é medida em termos de elementos estruturais como declarações, decisões e interfaces.
Técnicas Comuns de Teste de Caixa-Branca
- Teste e Cobertura de Declarações: Esta técnica foca em testar e avaliar a cobertura de todas as declarações individuais no código-fonte. O objetivo é garantir que cada linha de código seja executada pelo menos uma vez durante os testes. A fórmula de cobertura é: Cobertura = (declarações executadas) / (total de declarações).
- Teste e Cobertura de Decisões: Nesta técnica, o objetivo é testar e garantir a cobertura de todas as decisões no código, como instruções condicionais (if, else, switch). O objetivo é garantir que todas as possíveis ramificações de decisão sejam exercitadas durante os testes. A fórmula de cobertura é: Cobertura = (resultados da decisão executados) / (resultados da decisão total).
Critérios de cobertura
Cada critério define o que significa "ter testado o suficiente". Do mais fraco ao mais forte:
| Critério | Exige que... | Observação |
|---|---|---|
| Comandos (statement) | Cada linha/comando execute ao menos uma vez | O mais fraco: não garante que cada if tenha sido avaliado como falso |
| Decisões (branch) | Cada decisão seja verdadeira e falsa ao menos uma vez | Padrão de mercado como mínimo |
| Condições | Cada condição atômica (A, B em A && B) seja verdadeira e falsa |
Pode passar sem cobrir os dois desfechos da decisão |
| MC/DC | Cada condição, sozinha, mude o resultado da decisão | Exigido em software crítico (aviação, DO-178C); custa n+1 testes para n condições |
| Caminhos (path) | Todas as combinações de caminhos sejam percorridas | Inviável com loops: o número de caminhos explode |
Top comments (0)