Pessoal, segue um artigo publicado no Devmedia sobre teste de software, escrito por Danilo Cardilli. Fiquem com Deus, bons estudos e boa sorte.
Uma visão da técnica de teste de caixa branca
Introdução
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 dosoftware.
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.
Figura 1- Representação da idéia da técnica de teste de
caixa branca (BURNSTEIN, 2003).
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.
Figura 2-Representação base para o grafo de fluxo (PRESSMAN,
2006).
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*/ }
Figura 3-Representação do grafo de fluxo da listagem
1.
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.
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.
Figura 4-Representação da matriz de grafos (PRESSMAN, 2006).
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).
o 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).
o 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).
o 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).
o 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.
Figura 5-Classificações de ciclos existentes (PRESSMAN, 2006).
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:
o Bloco básico ou ramos,
o Todos os usos,
o Todos usos computacionais (c-uso),
o Todos usos predicativos (p-uso) e
o 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 subseqüê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.
Figura 6- Representação do Teste de fluxo de dados.
Conclusão
Esta técnica de teste de software embora
não é utilizada com freqüê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.
Para ver mais, visite o http://www.devmedia.com.br/uma-visao-da-tecnica-de-teste-de-caixa-branca/15610
Para ver mais, visite o http://www.devmedia.com.br/uma-visao-da-tecnica-de-teste-de-caixa-branca/15610
Nenhum comentário:
Postar um comentário