Uma visão da técnica de teste de caixa branca

A preocupação do engenheiro de sistema quando testa o software deve estar em encontrar alguma anomalia existente.

Os testes de software estabelecem os engenheiros de sistema pensar de maneira diferente do que estão freqüentemente acostumados, eles precisam elaborar casos de testes para descobrir defeitos no software (PRESSMAN, 2006).

A forma que a técnica de teste de caixa branca é aplicada torna se totalmente diferente da abordagem da técnica de caixa preta.

A técnica de teste de caixa branca é conhecida por vários nomes tais como teste estrutural e teste de caixa de vidro. O engenheiro de sistema realiza o teste direto no código fonte do software. São determinados os dados de entrada para analisar a lógica do software (MYERS, 2004).

A desvantagem da técnica de caixa de caixa branca é que não analisa se a especificação esta certa, concentra apenas no código fonte e não verifica a lógica da especificação (LEWIS e VEERAPILLAI, 2005).

Na representação da Figura 1 (um) demonstra a visão do engenheiro de sistema que vai realizar a técnica de teste de caixa branca, onde o quadrado representa o software e o desenho de dentro do quadrado demonstra como se fosse o código fonte que passará por teste.

Teste do caminho básico

O teste é uma técnica de caixa branca, onde calcula se a complexidade lógica do software e utiliza esta medida como base para descobrir os caminhos básicos do software e exercendo o teste de modo que todos os caminhos sejam efetuados (PRESSMAN, 2006; MCCABE, 1976).

Notação de grafo de fluxo

Para usar a técnica de teste de caixa branca o código fonte deve estar pronto, neste código fonte terminada, extrai se o grafo de fluxo que representa a lógica do código fonte (GAO, TSAO e WU, 2003).

O grafo de fluxo é um gráfico que demonstra a lógica do código fonte através de fios e ramos (MCCABE, 2010).

De acordo Pressman (2006) na construção do grafo de fluxo existem representações simbólicas correspondentes do grafo de fluxo. Usando o grafo de fluxo consegui visualizar os controles lógicos do software. Para cada círculos (ramos) demonstra uma ou varias linhas do código fonte e para cada setas (arestas) mostra o caminho ou caminhos que o código fonte pode fazer. Quando a existência de condições composta torna se mais difícil à construção do grafo de fluxo, encontra se quando ocorrem operações booleanas (ou, e, não-e, não-ou lógicos).

Todos os grafo de fluxo são construído através uma base principal de grafos tais como: seqüência, se, enquanto, até que e o caso (BURNSTEIN, 2003).

Na representação da Figura 2 (dois) demonstram conjuntos de notações bases de grafos que auxiliam para construções de grafos de fluxo.

Na representação da Listagem 1 (um) demonstra um código fonte que realiza um calculo potencial.

Na demonstração da Figura 3 (três) representa o grafo de fluxo do código fonte do calculo potencial representado na Listagem 1 (um), que podemos ver que os ramos estão sendo representados pelos números que estão ao lado esquerdo do código fonte e as arestas são as direções possíveis.

Listagem 1-Representação do código fonte de calculo potencial.

 /*1*/      import javax.swing.JOptionPane;  
 /*1*/      public class PotencialTeste {
 /*1*/      public static void main( String args[] )
 /*1*/      {
 /*1*/                      String PrimeiroNumero,SegundoNumero;
 /*1*/                      float Base, Expoente,Resultado, Potencial;              
 /*1*/                      PrimeiroNumero = JOptionPane.showInputDialog( "Entra com a base:" );
 /*1*/                      SegundoNumero = JOptionPane.showInputDialog( "Entra com o expoente:" );
 /*1*/                      Base = Integer.parseInt( PrimeiroNumero ); 
 /*1*/                      Expoente = Integer.parseInt( SegundoNumero );
 /*1*/                      if (Expoente < 0 ){
 /*2*/                                      Potencial=0-Expoente;
 /*3*/                      }
 /*3*/                      else {
 /*3*/                                      Potencial=Expoente;
 /*4*/                      }
 /*4*/      Resultado=1;
 /*4*/                      while (Potencial !=0 ){
 /*5*/                                      Resultado = Resultado * Base;
 /*5*/                                      Potencial=Potencial-1;
 /*5*/                      }
 /*6*/                      if (Expoente<0 && Base !=0){
 /*7*/                                                     Resultado=1/Resultado;
 /*8*/                      }
 /*8*/                      else{
 /*8*/                      if(Base ==0){
 /*9*/                                      JOptionPane.showMessageDialog( null, "A potencia é um valor finito " );}         
 /*10*/                    }
 /*10*/                    JOptionPane.showMessageDialog( null, "A potencia é " + Resultado, "Resultado", JOptionPane.PLAIN_MESSAGE );
 /*10*/    System.exit( 0 );   
 /*10*/    }
 /*10*/    }

Caminho independente de programa

Seria algum caminho ao longo do código fonte que execute um novo comando e no grafo de fluxo seria uma nova área que não foi exercida antes (PRESSMAN, 2006).

Com esta ferramenta permite calcular um valor para os atributos do software e o calculo de complexidade ciclomática (V(G)) para o grafo de fluxo (BURNSTEIN, 2003).

V(G) é o calculo de complexidade da decisão estrutural do código fonte. É o numero de caminhos independentes possíveis e o numero mínimo de caminhos que pode ser testado para garantir que o código esteja livre de defeito (MCCABE, 2010).

Conforme Pressman (2006) a V(G) podem ser calculadas de três formas:

1. Pelos números de regiões do grafo de fluxo.
2. V(G)= E – N + 2.

   
   Onde

   
   V(G) = e a complexidade ciclomática.

   G = representa o grafo de fluxo.

   E = representa a quantidade de arestas no grafo.

   N = representa a quantidade de ramos no grafo.

3. V(G)= P + 1.
   Onde
   V(G) = e a complexidade ciclomática.

   G = representa o grafo de fluxo.

   P = representa a quantidade de ramos predicativos.

Através dos grafos de fluxo representados na Figura 3 serão retirados os valores dos V(G) dessas formas:

1. Cinco regiões.
2. V(G) = 13 arestas – 10 ramos + 2 = 5.
3. V(G) = 4 ramos predicativos + 1 = 5.

Por estas formulas calculada chegamos que o grafo de fluxo usado tem cinco caminhos diferentes para testar o código fonte por completo. Tais como:

1. Caminho 1: 1-2-4-5-4-6-7-10.
2. Caminho 2: 1-2-4-5-4-6-8-9-10.
3. Caminho 3: 1-3-4-6-8-10.
4. Caminho 4: 1-3-4-5-4-6-8-10.
5. Caminho 5: 1-3-4-5-4-6-8-9-10.

Matrizes de grafos

A maneira para transforma o grafo de fluxo e executar os caminhos possíveis no grafo de fluxo de forma automática, é usada uma estrutura de dados. Uma matriz quadrada é usada e o tamanho é igual à quantidade de ramos encontrados no grafo de fluxo, onde cada linhas e colunas da matriz são correspondentes às quantidades de ramos (PRESSMAN, 2006).

Na demonstração da Figura 4 (quatro) representa a utilização da matriz de grafos para um grafo de fluxo qualquer. As linhas e colunas são as mesmas quantidades de ramos e as arestas que são representadas as ligações entre os ramos por letras.

Teste de estrutura de controle

Com o uso do teste de estrutura de controle serve como um complemento para o teste do caminho básico e assim garantir uma alta qualidade para técnica de caixa branca (PRESSMAN, 2006).

Teste de condição

Este tipo de teste são feitos nas condições booleana simples ou composto para analisar os desvios possíveis existentes, onde o teste examina os lados positivos ou falsos da condição booleana (PEZZÈ e YOUNG, 2008).

Uma condição encontra se errada das seguintes formas:

1. Erros de operador booleano,
2. Erros de variáveis booleana,
3. Erros de parêntese booleano,
4. Erros de operador relacional e
5. Erros de expressão aritmética (PRESSMAN, 2006).

Teste de ciclo

Os ciclos têm uma utilização freqüente na estrutura de controle. Com isso muitos erros são encontrados nas construções deles (BURNSTEIN, 2003).

O teste de ciclo é uma técnica de caixa branca que concentra se na validação da construção de ciclo (PRESSMAN, 2006).

São classificados quatro tipos de ciclos como: ciclos simples, concatenados, aninhados e desestruturados (PRESSMAN, 2006; BEIZER, 1990).

• Ciclos simples. O teste é aplicado em no ciclo com o tamanho n de modo que:
1. Pule o ciclo completamente;
2. Uma passagem pelo ciclo;
3. Duas passagens pelo ciclo;
4. k passagens pelo ciclo em que k< n.
5. n -1 passagens pelo ciclo;
6. n +1 passagens pelo ciclo (BURNSTEIN, 2003).

• Ciclos concatenados. Utiliza no ciclo concatenado a abordagem de ciclos simples para o caso dos ciclos forem independente um do outro, caso contrario é recomendado o uso da abordagem de ciclos aninhados (PRESSMAN, 2006).

• Ciclos aninhados. Para esta abordagem testa se os ciclos mais internos que são aplicados à abordagem de ciclos simples e os outros ciclos externos permanecem com o valor mínimo (PRESSMAN, 2006; BEIZER, 1990).

• Ciclos desestruturados. Sempre que ocorrer este caso deve se refazer o ciclo para pensar no uso da construção da programação estruturada (PRESSMAN, 2006).

Na demonstração da Figura 5 (cinco) representam os quatros tipos dos ciclos.

Teste de decisão

Conseguir a cobertura inteira dos comandos sem executar todos os desvios existentes do código fonte. E conseguir com um único caso de teste a adequação de desvio para que o desvio do código fonte seja exercido (PEZZÈ e YOUNG, 2008).

Teste de fluxo de dados

Conforme Pressman (2006) o teste de fluxo de dados descobre os caminhos para que teste o código fonte, selecionar as definições (def) e uso das variáveis do código fonte. Para demonstrar o fluxo de dados de cada comando do código fonte é representada por números.

Esta abordagem de teste de software demonstra que na def das variáveis ao longo do grafo de fluxo localiza se caminhos simples. Assim torna o teste de caixa branca mais poderoso (Moreira Filho e Rios, 2003).

Com este teste de software verifica se o comportamento das variáveis ate localizar algum defeito que tenha passado despercebido e a propagação dele no código fonte (PEZZÈ e YOUNG, 2008).

As principais categorias do fluxo de dados são:

• Bloco básico ou ramos,
• Todos os usos,
• Todos usos computacionais (c-uso),
• Todos usos predicativos (p-uso) e
• Caminho livre de def (Todos-du-Caminhos).

O bloco básico ou ramo são trechos de códigos fonte que são executados todos de uma vez. Todos o c-uso, todos o p-uso e todos usos são categorias mais mencionadas do fluxo de dados (PETERS e PEDRYCZ, 2001).

Todos os usos solicitam todas def de variáveis, seus p-uso e seus c-uso que sejam realizados no caso de teste pelo menos uma vez pelo caminho livre de def. Toda def solicita que cada def seja exercida pelo menos uma vez, não implicam os c-uso e os p-uso (MOREIRA FILHO e RIOS, 2003).

Todos os usos c-uso seriam quando uma variável utilizada na def troca o seu valor ou como uma produção de valor. Todos os p-uso são utilizados para definir o verdadeiro ou falso de um valor predicativo e um predicativo associado para um limite (GAO, TSAO e WU, 2003).

Os Todos-du-Caminhos solicitam que todas as def de variáveis e subsequências como c-uso e p-uso das variáveis sejam executadas por todos os caminhos livres de def e de laços (MOREIRA FILHO e RIOS, 2003).

Na representação da Figura 6 demonstra como usar o teste de fluxo de dados em um grafo de fluxo.

Esta técnica de teste de software embora não é utilizada com frequência, porém analisa o funcionamento do código fonte de maneira gráfica e possibilita ver a trajetória que o código fonte realiza. A aplicação desta técnica é interessante quando os códigos fonte possuem muitas condições.

Referencias Bibliográfica

• BURNSTEIN, I. Practical software testing: a process-oriented approach., New York: Springer, 2003, 709p. GAO, J.. Z.; TSAO, H. -S. J. e WU, Y.. Testing and Quality Assurance for Component Based Software. Massachusetts: Atech House, 2003, 439p. LEWIS, W. E.; VEERAPILLAI, G.. Software Testing and Continuous Quality Improvement. 2.ed., Florida: Auerbach, 2005, 534p. MCCABE, T. “Glossary of Terms”. Disponível em < http://www.mccabe.com/iq_research_iqgloss.htm >. Acesso em 14 jan. 2010. MYERS, G. J. The Art of Software Testing. 2. ed., New York: John Wiley & Sons, 2004, 234p.
• MOREIRA FILHO, T. R.; RIOS, E. Projeto & Engenharia de Software: teste de software. Rio de Janeiro: Alta Books, 2003, 208p.
• PETERS, J. F.; PEDRYCZ, W. Engenharia de software: teoria e prática. Rio de Janeiro: Campus, 2001,602p.
• PEZZÈ, M.; YOUNG, M. Teste e Análise de Software: processos, princípios e técnicas. Porto Alegre: Bookman, 2008, 512p.
• PRESSMAN, R. S. Engenharia de Software. 6. ed. Rio de Janeiro: McGraw-Hill,2006, 720p.