Teste de Caixa-Branca
Também conhecido como teste estrutural. É aquele em que o analista tem total acesso à estrutura interna da entidade sendo analisada e permite, por exemplo, que o analista escolha partes específicas de um componente para serem testadas.
O fato de conhecer o código do programa permite que o avaliador projete testes mais precisos. Por exemplo, se a definição de uma função g(), para um determinado programa, afirma que ela não aceita valores negativos, um avaliador poderia provocar uma chamada fun(-1) e descobrir que um tratamento de exceções não está corretamente implementado.
Esses testes são projetados em função da estrutura do componente e podem permitir verificação mais precisa de comportamento do produto. Ele permite ao avaliador concentrar a atenção nos pontos mais importantes ou “perigosos” do código, de uma maneira mais precisa do que no caso do teste caixa-preta. Tais pontos podem até ser identificados durante o desenvolvimento e cobertos com o uso de assertivas e testes.
Há, entretanto, um elemento comum entre os testes caixa-preta e caixa-branca: em ambos os casos, o avaliador não sabe qual será o comportamento produto em uma determinada situação. Esse fato pode parecer, a princípio, paradoxal para o teste caixa-branca, uma vez que o avaliador tem total acesso aos componentes internos do produto. Contudo, a imprevisibilidade resulta da complexidade combinatória.
Por exemplo:
Seja a linha de código... n = a/(f(i)*(h – g(j)));
Essa linha pode levar a uma divisão por zero em dois casos...
Sem conhecer a função f(), sabe-se que se o tipo de dado da variável i tiver 32 bits, existirão no total 232 casos a serem testados. Conhecer a estrutura de f() não é suficiente para reduzir a quantidade de testes. Essa estrutura pode ser complexa contendo várias chamadas a outras funções.
Alguns testes caixa-branca podem ser realizados efetuando modificações no programa. Seja a linha...
fun (r1 -> ptr, n, tst.count());
Supondo que o avaliador esteja interessado em saber o que ocorre se o campo ptr contiver um valor nulo, ou, ainda, quando r1 é um ponteiro nulo ou inválido, uma vez que uma falha em fun teria conseqüências desastrosas. Pode ser difícil forçar essa condição dentro do código apenas operando a interface do programa. Uma maneira de fazê-lo é efetuar uma modificação temporária no programa:
fun (NULL, n, tst.count());
A versão de testes resultante deve ser executada e os resultados, observados. Naturalmente, é preciso um cuidado especial com o controle de versões de software: a versão de teste, bem como o executável resultante, não deve jamais ser confundida com a versão correta que será entregue ao cliente.
Veja também:
Teste de Caixa-Preta
Testes de Estresse
Teste de Integração
Teste de Orientado a Objetos
Teste de Aceitação
O fato de conhecer o código do programa permite que o avaliador projete testes mais precisos. Por exemplo, se a definição de uma função g(), para um determinado programa, afirma que ela não aceita valores negativos, um avaliador poderia provocar uma chamada fun(-1) e descobrir que um tratamento de exceções não está corretamente implementado.
Esses testes são projetados em função da estrutura do componente e podem permitir verificação mais precisa de comportamento do produto. Ele permite ao avaliador concentrar a atenção nos pontos mais importantes ou “perigosos” do código, de uma maneira mais precisa do que no caso do teste caixa-preta. Tais pontos podem até ser identificados durante o desenvolvimento e cobertos com o uso de assertivas e testes.
Há, entretanto, um elemento comum entre os testes caixa-preta e caixa-branca: em ambos os casos, o avaliador não sabe qual será o comportamento produto em uma determinada situação. Esse fato pode parecer, a princípio, paradoxal para o teste caixa-branca, uma vez que o avaliador tem total acesso aos componentes internos do produto. Contudo, a imprevisibilidade resulta da complexidade combinatória.
Por exemplo:
Seja a linha de código... n = a/(f(i)*(h – g(j)));
Essa linha pode levar a uma divisão por zero em dois casos...
- f(i) retorna um valor nulo;
- g(j) retorna um valor igual a h.
Sem conhecer a função f(), sabe-se que se o tipo de dado da variável i tiver 32 bits, existirão no total 232 casos a serem testados. Conhecer a estrutura de f() não é suficiente para reduzir a quantidade de testes. Essa estrutura pode ser complexa contendo várias chamadas a outras funções.
Alguns testes caixa-branca podem ser realizados efetuando modificações no programa. Seja a linha...
fun (r1 -> ptr, n, tst.count());
Supondo que o avaliador esteja interessado em saber o que ocorre se o campo ptr contiver um valor nulo, ou, ainda, quando r1 é um ponteiro nulo ou inválido, uma vez que uma falha em fun teria conseqüências desastrosas. Pode ser difícil forçar essa condição dentro do código apenas operando a interface do programa. Uma maneira de fazê-lo é efetuar uma modificação temporária no programa:
fun (NULL, n, tst.count());
A versão de testes resultante deve ser executada e os resultados, observados. Naturalmente, é preciso um cuidado especial com o controle de versões de software: a versão de teste, bem como o executável resultante, não deve jamais ser confundida com a versão correta que será entregue ao cliente.
Veja também:
Teste de Caixa-Preta
Testes de Estresse
Teste de Integração
Teste de Orientado a Objetos
Teste de Aceitação
Comentários
Postar um comentário
Indique ou comente o post. Obrigado pela visita!