White Box Testing

 

Num post anterior (Técnicas de desenho de testes) tentei expressar as diferenças entre Black Box Testing e White Box Testing. Neste post vou tentar detalhar um pouco mais os conceitos envolvidos em white box testing (o lado do white box).

Os testes de caixa branca são de uma natureza diferente dos testes caixa preta. No teste de caixa preta, o foco das actividades é apenas sobre a funcionalidade do sistema e não no que está acontecendo dentro de um sistema ou componente.  Por outro lado os objectivos de teste de caixa branca é ter certeza de que a funcionalidade é adequada usando informação sobre o desenho da mesma para elaborar os testes. Os testes de caixa branca são essencialmente efectuados pelas equipas de desenvolvimento, geralmente a partir da criação de testes unitários, embora o principio possa ser estendido a outros tipos de testes. Usando técnicas de caixa branca, um especialista de software pode desenhar casos de teste que:

• Exercitam caminhos independentes dentro de um módulo ou unidade.
• Exercitam as decisões lógicas em ambas as vertentes, a parte verdadeira e a parte falsa do seu resultado.
• Exercita ciclos usando os seus limites e os seus conteúdos.
• Exercita estruturas de dados internas de modo a garantir a sua validade.

Existem seis tipos básicos de teste mais comuns que podem ser usados como teste de caixa branca, que são:

• Testes Unitários – Teste a elementos de hardware ou software de forma individual ou a um conjunto de de unidades relacionadas. Uma unidade é um componente de software que não pode ser subdividido em unidades mais pequenas. Segundo Bezier (Colocar Link para o artigo de 1990) aproximadamente 65% dos bugs de software podem ser apanhados com a utilização de testes unitários.
• Testes de Integração – Conjunto de testes onde os componentes de hardware ou software são combinados com outros componentes.
• Testes de Regressão – Repetição selectiva dos testes a um componente ou a um sistema de modo a verificar que modificações no software, como a implementação de novas funcionalidades ou a correcção de alguns defeitos não introduziu efeitos indesejados no sistema em uso e que os requisitos especificados continuam a ser cumpridos.
• Além dos referidos acima mais conhecidos temos ainda os Testes de Aceitação, Beta Testing e Testes de Sistema/Função.

Basis Path Testing

Basis Path Testing é um modo para assegurar que todos os caminhos independentes existentes num módulo de código são testados. Um caminho independente é qualquer caminho no código que introduz pelo menos um novo grupo de instruções a executar ou pelo menos uma nova instrução.

Uma das características dos testes de caixa branca é que permitem avaliar qual a cobertura do código que estamos a analisar. Existem várias possibilidades para verificar a cobertura que pode ser medida aquando do uso de testes de caixa-branca, entre os quais se destacam:

• Statement coverage
• Condition (ou Branch) coverage

Statement Coverage

Statement Coverage ou cobertura por instrução, identifica quais as instruções que num dado método ou classe são executadas. É uma métrica simples que calcula o nível de cobertura do código. O grande benefício deste tipo de cobertura reside na  capacidade para identificar quais os blocos de código que são ou não executados. No entanto este método possui a desvantagem de não encontrar erros no fluxo da execução.

Para medir a cobertura por instrução deve ser usada a seguinte formula:

Statement Coverage = (Nº de instruções executadas/Nº Total de instruções) * 100%

Condition (ou Branch) Coverage

Um branch é o resultado de uma decisão. A cobertura por branch verifica os resultados de cada decisão depois de esta ser tomada. Determinar o número de ramos num método é relativamente fácil, basta procurar por decisões booleanas. Estas decisões podem ter dois resultados o verdadeiro ou o falso. No caso de um switch existiria um caso possível para cada alternativa possível.

Para medir a cobertura por condição deve ser usada a seguinte formula:

Decision Coverage = (Nº de saídas de decisão executadas/Nº Total de decisões existentes) * 100%

FlowCharting

Para melhor compreender como é medida a cobertura relembre-se as seguintes noções na criação de diagramas.

Condições – Correspondem geralmente aos if existentes no código e são representados por um losangulo.

Instruções – Correspondem ao conjunto de instruções de código e são representadas por rectângulos com a instrução descrita no interior.

Podemos compor num único algoritmo vários exemplos dos mostrados acima. Como pode ser visto no exemplo abaixo.

Medir a cobertura a partir do diagrama

A partir da representação do diagrama anterior podemos determinar qual a decision coverage e a statement coverage. Assim começando pela decision coverage e recordando a formula anteriormente referida vemos que para possuirmos uma cobertura de 100% necessitamos de criar dois casos de teste. Um em que o resultado da condição é verdadeiro outro em que o mesmo resultado é falso. Se estivéssemos a medir a cobertura usando a statement coverage precisaríamos também de dois casos de teste. Uma para cobrir o caso de teste “GetUp” e outro para cobrir o caso de teste “Sleep”.

Para identificarmos os casos de testes seguimos o fluxo através do diagrama (da topo para a base do fluxograma). Então olhando para os caminhos possíveis no diagrama vamos desenhando um caso de teste por cada caminho possível de modo a cobrir todas as instruções, ou por outro lado de modo a passar por todas as tomadas decisão. Alguns peritos na matéria recomendam que se deve sempre ir tão longe para a direita quanto possível com o seu primeiro caso de teste e depois trabalhar o seu caminho de volta para a esquerda.

Sim, é certo que ainda existe muito mais para escrever sobre o assunto, mas fica para a próxima.

 

Bom, até à próxima.