Testes de Caixa Branca e Caixa Preta

Prof. Pasteur Ottoni de Miranda Junior PUC Minas Disponvel em www.pasteurjr.blogspot.com 1-Introduo hbito costumeiro do programador terminar um programa e em seguida iniciar uma bateria de testes com o objetivo de verificar correo e, muitas vezes, conformidade com determinados requisitos.Esta bateria de testes , na maioria das vezes, realizada sem qualquer sistemtica, sem anlise criteriosa dos caminhos e/ou situaes que devero ser testadas. A metodologia que aqui ser apresentada tem por objetivo principal orientar na obteno de casos de teste a serem utilizados para testar um determinado programa ou mdulo de programa.. Estas tcnicas no visam, portanto, orientar o programador em como testar. Muito menos determinam procedimentos para testar. O objetivo primordial de qualquer tcnica para testes : MAXIMIZAR (% defeitos encontrados/nmero de testes feitos) As tcnicas que vamos estudar auxiliam principalmente na minimizao do nmero testes. Deve-se deixar claro que testar no a nica maneira de se detectarem erros. As tcnicas do tipo "walkthroughs" (revises estruturadas) quando bem aplicadas chegam a detectar at 60% dos defeitos existentes. 2-Princpios sobre testes Testar completamente impossvel. Por mais tcnicas que empreguemos, dependendo da complexidade do programa sob teste, impossvel detectarem-se todos os erros nele existentes. bvio que isto no se aplica a programas do tipo "extremamente simples". Testar trabalho criativo e difcil. Ao contrrio do que normalmente se pensa, testar no fcil. Para se testar bem, necessrio que a pessoa responsvel pelos testes tenha experincia e seja suficientemente treinada nas tcnicas. Testar no simples pelo seguinte: -Para testar efetivamente, voc tem que conhecer profundamente o sistema sob teste. -Normalmente os sistemas no so simples e nem simples de entender. Testes devem ser planejados e projetados. Todo processo de testar deve ser precedido de um planejamento dos casos de teste a serem utilizados. O que torna um teste realmente bom a confiana que ele fornece, consequncia do aumento da probabilidade de se descobrirem erros. Esta confiana, porm, tem um custo que, muitas vezes, ocasionado pela complexidade do programa, acaba se tornando alto. Assim sendo, um bom teste deve ser tal que seu custo seja minimizado, principalmente pela minimizao do nmero de casos de teste necessrios para se testar o programa.

-1-

Testar requer independncia. Um testador independente aquele dito no polarizado, ou seja, sem vcios ocasionados pelo conhecimento profundo do programa. Um testador polarizado tende a ignorar aspectos que tem certeza de estarem corretos, mas que muitas vezes podem conter erros. O testador independente tem como maior meta medir precisamente a qualidade do software. 3-Conceitos Caso de Teste: Consiste em: -Um conjunto de entradas possveis do programa. -Um conjunto de sadas esperadas para as entradas. Por exemplo: Seja um programa para classificar tringulos com a seguinte especificao: ENTRADA: Os trs lados tal que a >= b >= c (a,b,c inteiros) SADA: Classificao do tringulo: 1- No tringulo 2-Tringulo equiltero 3- Tringulo issceles 4- Tringulo escaleno reto 5- Tringulo escaleno obtuso 6- Tringulo escaleno agudo Temos os seguintes casos de teste: SADA Tripla ilegal No tringulo Tringulo equil.. Tringulo issc. Tringulo esc. reto Tringulo esc. agudo Tringulo esc. obtuso ENTRADA (1,2,3) (a < b < c) (11,6,4) (1,1,1) (2,2,1) (5,4,3) (6,5,4) (4,3,2)

Estes pares entrada-sada (casos de teste) poderiam ser utilizados para testar o nosso programa. Porm, tais casos de teste foram gerados sem qualquer sistemtica. Teste: um conjunto de casos de teste a serem aplicados em um programa. Procedimentos de Teste: a sequncia de aes para se executar um teste ou um caso de teste. Mtodos de teste: So mtodos para se gerarem casos de teste. Classificao:

-2-

-Mtodos de caixa branca- Nesta metodologia os casos de teste so gerados tendose conhecimento da estrutura interna (lgica) do programa. So tambm denominados testes estruturais. So os seguintes os que iremos estudar: -Cobertura Lgica (Critrios Myers): -Mtodo dos Caminhos Bsicos. -Mtodos de caixa preta- Nesta metodologia os casos de teste so gerados sem o conhecimento da estrutura interna do programa. Apenas o conhecimento das entradas e sadas possveis para o programa necessrio. So tambm denominados testes funcionais. Estudaremos os seguintes mtodos: -Partio em Classes de Equivalncia -Grafos de Causa-Efeito -Teste de Condies de Fronteira. 4-Mtodos de Caixa Branca 4.1 - Cobertura Lgica (Critrios Myers) Este mtodo constitudo de critrios que, quando obedecidos, determinam os casos de teste a serem gerados. Os critrios vo se tornando cada vez mais abrangentes e rigorosos, partindo-se do mais simples, ineficiente e menos rigoroso (Cobertura de Comandos) at o mais complexo, eficiente e rigoroso (Cobertura de Mltiplas Condies). A escolha do critrio adequado ser norteada pelos seguintes fatores: -Complexidade do programa a testar: Programas mais simples podem ser satisfeitos pela utilizao de critrios menos rigorosos.Muitas vezes a utilizao de critrios mais rigorosos em programas muito simples acaba por onerar excessivamente o processo de testes. -Estrutura do programa a ser testado. Certas estruturas so mais adequadas a determinados critrios. Por exemplo, programas ricos em comandos, podem ser testados utilizando-se o critrio de cobertura de comandos, programas com decises complexas devem ser testados por cobertura de decises /condies. -Criticidade do programa a testar: Programas cujo funcionamento no crtico podem exigir testes menos rigorosos. Portanto, critrios menos rigorosos podem ser suficientes para se testar o programa. -Nvel de confiana que se deseja atingir. Se o nvel de confiana de bom funcionamento alto,critrios mais rigorosos so necessrios. 4.1.1 - Cobertura de Comandos Neste critrio os casos de teste devem ser gerados de forma que ao serem executados, o fluxo do programa passe por todos os COMANDOS existentes no mesmo. Por exemplo: Seja o fluxograma da fig. 1:

-3-

a A >1e B=0 N X=X/A b Y c

A = 2 ou X>1 N d

Y e

X=X+1

Fig. 1 - Fluxograma a utilizar nos exemplos

Um nico caso de teste suficiente para que este critrio seja satisfeito : A = 2, B=0 , X qualquer ( caminho a c e, passa por todos os comandos, quais sejam: X = X/ A e X= X + 1) O critrio satisfeito, porm, podemos verificar que mesmo para um programa simples como este ele falha em algumas situaes. Se por exemplo, houvesse os seguintes erros no programa:
-4-

A > 1 OU (no lugar de E) B= 0 A=2 OU X > 0 (no lugar de 1) O caso de teste no detectaria, pois o fluxo do programa continuaria passando por a c e. A sada do programa estaria inalterada, no denunciando, portanto, o erro cometido.
4.1.2-Cobertura de Decises

Neste critrio os casos de teste sero gerados de tal forma que cada deciso tenha todas as suas opes de sada (V ou F) percorridas ao menos uma vez. Este critrio engloba o anterior. No exemplo da fig. 1, dois casos de teste so suficientes para satisfazer este critrio: A=3, B=0, X=3 faz o fluxo do programa passar por a c d A=2, B=1, X=1 faz o fluxo do programa passar por a b e Os erros exemplificados no critrio anterior seriam detectados. Porm, observe que se na segunda deciso houvesse um erro como X < 1 ao invs de X > 1, a sada do programa permaneceria inalterada, no permitindo a deteco do erro.
4.1.3-Cobertura de Condies

Neste critrio os casos de teste so tais que cada condio em uma deciso deve ser testada ao menos uma vez em todas as suas sadas possveis. No exemplo da fig.1 temos as seguintes condies: A> 1, B=0, A=2, X > 1 Temos que gerar casos de teste para testar as situaes : A>1 e A <=1 B=0 e B <> 0 A=2 e A <> 2 X>1 e X <= 1 Os seguintes casos de teste satisfazem a estas situaes: A= 2, B=0, X=3 A=2, B= 1, X=1 Observe que com este critrio conseguiramos detectar o erro descrito no critrio anterior. Porm ocorre que nem todas as sadas das decises so percorridas.

-5-

4.1.4 - Cobertura de Decises-Condies

uma combinao dos dois ltimos critrios. Cada condio em uma deciso testada em todas as suas sadas possveis e cada deciso tem sua sada V ou F percorrida ao menos uma vez. Ainda para o fluxograma da fig. 1 temos que os seguintes casos de teste satisfazem este critrio: A= 1, B=1, X= 1 ( satisfaz A <= 1, B<> 0 e X <=1, fazendo com que o fluxo do programa passe pelo N das duas decises) A= 2, B=0, X= 3 ( satisfaz A > 1, B = 0 e X > 1, fazendo com que o fluxo do programa passe pelo Y das duas decises) Ocorre que, em algumas situaes, uma condio pode mascarar outras.
4.1.5-Cobertura de mltiplas condies

Os casos de teste so tais que todas as combinaes de condies em cada deciso so cobertas. Combinaes de condies a serem cobertas: 1- A > 1, B= 0 2- A > 1, B<>0 3- A <= B= 0 4- A > =1 B= 0 5- A=2, X> 1 6- A=2, X<=1 7- A<>2, X> 1 8- A<>2, X<= 1

Os casos de teste que cobrem estas combinaes so: A=2,B=0,X=5 A=2,B=1,X=1 A=1,B=0,X=2 A=1,B=1,X=1 cobre 1,5 cobre 2,6 cobre 3,7 cobre 4,8

Este sem dvida o critrio mais abrangente. Porm esta abrangncia tem um preo: o nmero de casos de teste para satisfaz-lo maior. As falhas deste critrio esto relacionadas ao nmero de caminhos percorridos: ele no garante que este nmero seja suficiente para testar com confiana o programa.

-6-

4.2 - Mtodo dos Caminhos Bsicos 4.2.1 - Introduo

Mtodo criado pelo matemtico norte-americano Thomas McCabe baseado na teoria de grafos. Sua lgica consiste essencialmente em fazer com que os casos de teste sejam gerados de forma a fazer com que o fluxo do programa passe por um nmero mnimo de caminhos entre a entrada e a sada do programa, sem o risco de ocorrerem redundncias.
4.2.2- Grafo de Controle

um grafo orientado (ou seja, suas arestas possuem setas) que descreve o fluxo de controle do programa. Na realidade, o grafo de controle no passa de um fluxograma com smbolos diferentes, quais sejam:
C

B Sequncia if A then B else C; A estrutura CASE idntica de seleo com mais opes While A do B; repeat do A until B

Fig. 2 - Estruturas do grafo de controle Por exemplo, o procedimento: procedure Teste(A,B,C : integer); begin if A=B then A:=A+1 else if B = C then B : = B+1 else B : = B -1; end; teria o seguinte grafo de controle:
-7-

R1

V d

c g

R2
f

R3

Fig. 3- Grafo de controle

4.2.3-Caminhos independentes

No grafo de controle identificamos os chamados caminhos independentes. Dentre um conjunto de caminhos identificados para um grafo, dizemos que eles so independentes quando nenhum deles formado da combinao de dois ou mais outros.

Para determinarmos os caminhos independentes de um grafo, temos que inicialmente determinar quantos so. Existem 3 formas de se determinar este nmero, tambm denominado complexidade ciclomtica: -Contar o nmero de regies no grafo de controle. No exemplo da figura 3, temos trs regies, R1, R2 e R3: as duas internas(R1 e R2) e a externa (R3). Logo, este grafo tem 3 caminhos independentes. -Aplicar a frmula: C=E-N+2 onde C = nmero de caminhos independentes E = nmero de arestas N = nmero de ns No exemplo da figura 3 temos E = 7, N = 6 , logo C = 7-6+2 = 3

-Contar o nmero de estruturas de deciso no programa e somar 1. No exemplo da figura 3, temos 2 "if". Logo, o nmero de caminhos independentes 3.

-8-

Para identificar os caminhos independentes em um grafo fazemos o seguinte: -Determinar o nmero de caminhos independentes conforme visto anteriormente. -Tomar o caminho mais a esquerda possvel no grafo como primeiro caminho lindependente. No exemplo da fig. 3, este caminho o ac. -Tomar o prximo caminho direita, tendo o cuidado de incluir nele pelo menos uma aresta que no tenha sido includa nos outros caminhos j determinados. No exemplo, caminho bdg. -Repetir o passo anterior at que se obtenham todos os caminhos. No exemplo, s nos resta o caminho bef.
4.2.4 - Gerao dos casos de teste

Cada caminho obtido dar origem a um caso de teste. Os casos de teste so gerados de forma que faam com que os caminhos aos quais correspondam sejam percorridos. No exemplo da figura 3 temos:
Caminho ac: Entradas: A=3, B=3, C=3. Sadas: A=4, B=3. Caminho bdg: Entradas: A=3, B=4, C=4. Sadas: A=3, B=4. Caminho bef: Entradas: A=3, B=5, C=6. Sadas: A=3, B=4. 4.2.5-Passos do mtodo

Passo 1: Desenhar o grafo de controle Passo 2: Determinar o nmero de caminhos independentes (complexidade ciclomtica) Passo 3: Obter os caminhos independentes Passo 4: Para cada caminho, gerar os casos de teste, utilizando a especificao do programa para inferir os resultados esperados. Passo 5: -Executar cada caso de teste -Checar os resultados obtidos contra os esperados -O teste estar completo quando houver confiana absoluta em que todos os casos de teste obtm resultados satisfatrios.

-9-

5-Testes de Caixa Preta 5.1 - Partio em Classes de Equivalncia 5.1.1-Introduo

Esta metodologia adequada ao teste de valores tpicos de entrada de um programa. Os casos de teste so gerados a partir do conhecimento das entradas , de maneira sistemtica e direta.

5.1.2 Definio - Classe de Equivalncia

Uma classe de equivalncia nada mais do que um subconjunto das entradas possveis de um programa, de tal forma que um teste efetuado para um valor representativo da mesma equivalente ao teste para qualquer outro valor valor nesta classe.
5.1.3-Passos do mtodo

1)Definir as classes de equivalncia 1.1)Definir as chamadas condies de entrada Definio: Condio de entrada. Uma condio de entrada qualquer intervalo de entradas vlidas de um programa. Tipos: a)Faixa de valores. Ex.: 1 < ITEM <1000 b)A entrada envolve um certo nmero de valores. Ex: Um vetor de at 6 elementos c)Conjunto de Valores. {caminho,carro,nibus} letra 1.2)Definir as classes de equivalncia propriamente ditas, que podem ser vlidas ou invlidas. Estas classes so definidas a partir da condio de entrada.Ex: a) 1< ITEM < 1000 Classe vlida : 1 <ITEM < 1000 Classes invlidas : ITEM <= 1 e ITEM >= 1000 b)Vetor de at 6 elementos. Classe vlida: vetor com 4 elementos Classes invlidas: Vetor com zero elemento e Vetor com 7 elementos c)Conjunto de valores. Classe vlida: {caminho, carro, nibus} Ex: Conjunto dos veculos motorizados =

d)Condio booleana. Ex: O primeiro caracter de um identificador deve ser uma

-10-

Classe invlida : {carroa} d)Classe vlida: O primeiro caracter do identificador uma letra Classe invlida: O primeiro caracter do identificador no uma letra 1.3)Se for constatado que todos os elementos de uma classe no podem ser tratados da mesma forma, dividir a mesma em outras classes. 2)Identificar casos de teste 2.1)Numerar as classes vlidas e invlidas 2.2) -Cada classe invlida gera um caso de teste (ou seja, gerar a entrada tal que cubra a classe invlida). -Para as classes vlidas, cada caso de teste gerado de forma a cobrir o maior nmero possvel delas
5.1.4-Exemplo

Suponhamos que se queira testar um compilador (verifcador de sintaxe) para o seguinte comando: INSERT VALUE / MNEMONIC = <nome do mnemnico> / VALUE = <valor> Restries: -Comando s aceita maisculas -<nome do mnemnico> provm de uma tabela de 1168 mnemnicos -Tamanho do mnemnico no mximo 8 -<valor> = faixa de validade do mnemnico

-11-

Condies de entrada

Tipo de condio

Comando s tem maiscula Tamanho do menmnico Mnemnico vlido Valor do mnem. ABSBRG .. Valor do mne. XTKTE004 Prximo token aps insert VALUE ... Casos de teste:

Booleana Faixa Booleana Faixa Faixa Booleana

Classes vlidas sim (1)

Classes invlidas No (2)

1-8 (3) sim (6) 0-360 (8) -30..+30 (11) Sim (14)

0, (4) > 8 (5) no (7) < 0 (9) >360 (10)

< -30 (12) > +30 (13) No (15)

Para as classes vlidas, pegar o maior nmero delas com um nmero mnimo de casos de teste: INSERT VALUE / MNEMONIC = ABSBRG / VALUE = 30 => Pega as classes nmero 1,3,6,8,14 INSERT VALUE / MNEMONIC = XTKTE004 / VALUE = -2.5 => Pega as classes nmero 1,3,6,11,14 Para as classes invlidas: um caso de teste para cada. Classe 2: INSERT VALUE / mnem = ABSBRG / VALUE = 30 Classe 4: INSERT VALUE / MNEM = / VALUE = 30 Classe 5: INSERT VALUE / MNEM = XUSASAASASAS / VALUE = 30 Classe 7: INSERT VALUE / MNEM = AAX / VALUE = 30 (Supondo que AAX no esteja na tabela) Classe 9: INSERT VALUE /MNEM = ABSBRG / VALUE = -35 Classe 10: INSERT VALUE / MNEM = ABSBRG / VALUE = 400 Classe 12: INSERT VALUE / MNEM = XTKTE004 / VALUE = -50 Classe 13: INSERT VALUE / MNEM = XTKTE004 / VALUE = 60 Classe 15: INSERT VALOR / MNEM = XUSASAASASAS / VALUE = 30 Obviamente o exemplo acima no inclui todos os 1168 mnemnicos existentes . Na prtica teramos que gerar os casos de teste para todos eles. O exemplo tambm no inclui outras verificaes sintticas, como por exemplo, depois da palavra VALUE vir a barra (/).

-12-

5.2 Mtodo do Grafo de Causa e Efeito 5.2.1-Introduo

Mtodo baseado em especificaes de ENTRADAS (causas) e SADAS (efeitos). Representa a combinao de entradas em sadas de forma bastante representativa, no redundante e, muitas vezes, de tamanho minimizado. Alm disso possui uma vantagem extra, pois aponta ambiguidades e incompletezas na especificao. Porm, quando o grafo de causa-efeito torna-se muito complexo, fica bastante difcil a gerao da tabela de deciso. Nesta situao, a utilizao deste mtodo s vivel com o auxlio do computador.
5.2.2 -O Grafo de Causa-Efeito

uma rede lgica combinatorial que representa a especificao do programa. anlogo a um circuito lgico digital. Para constru-lo procedemos da seguinte forma -Identificar as causas : as causas so as entradas do programa. Tomar o cuidado de no identificar causas complementares, como por exemplo "x > 60" e "x <=60". Coloc-las esquerda no diagrama. -Identificar efeitos: os efeitos so as sadas do programa. Coloc-los direita no diagrama. -Relacionar as causas com os efeitos atravs da seguinte notao:

-13-

Identidade

~
Negao

Causas Simultneas

E ^ Conectivo e C

Causas Mut. Exclus.

Causas Consequentes

v Conectivo ou M Causas Mascaradas

Fig. 4 Notao para conexes intercausas

5.2.3-Passos do Mtodo

1)Desenhar o grafo 2)Transformar o grafo em tabela de deciso. Como? Para cada um dos efeitos, gerar combinaes entre causas que faam com que sejam ativados. 3)Cada combinao de causas geradas no passo 2) vai dar origem a um caso de teste
5.2.4 - Exemplo

Seja a seguinte especificao para um compilador de um comando bem simples: O caracter na coluna 1 deve ser "A" ou "B" . O caracter na coluna 2 deve ser um nmero. Se isto ocorrer, o comando est correto. Se o primeiro caracter est incorreto, emitir mensagem X12. Se o segundo caracter no um dgito, emitir mensagem X13. Causas identificadas: So as entradas possveis ao programa: 1-Caracter "A" na primeira coluna
-14-

2-Caracter "B" na primeira coluna 3-Caracter na coluna 2 dgito Observe que no colocamos, por exemplo, a causa "caracter na coluna 2 no dgito", pois esta causa complementar causa 3, sendo obtida por negao desta. Efeitos identificados: 70- Comando correto 71- Mensagem X12 72-Mensagem X13 O grafo obtido o seguinte:

1 E 2 v ^

70

71

72

Fig. 5 - Grafo de Causa-Efeito do exemplo A tabela de deciso a seguinte.

1 2 3 70 71 72

1 0 1 1 0 0

0 1 1 1 0 0

0 0 X 0 1 0

X X 0 0 0 1

Repare que, ao invs de gerarmos 8 combinaes entre as entradas (todas as possveis), obtivemos apenas 4, que so coerentes com a especificao do programa. Por este mtodo, no precisamos testar todas as combinaes. Cada coluna de combinao da tabela vai ento gerar um caso de teste: PRIMEIRO CARACTER A SEGUNDO CARACTER 1 SADA Comando Correto

-15-

B X X

1 3 B

Comando Correto Mensagem X12 Mensagem X13

5.3 - Anlise de Valores de Fronteira 5.1 - Introduo

Quando testamos um determinado programa, muito comum utilizarmos apenas valores tpicos da entrada ou sada do mesmo. Porm, a experincia mostra que testes que exploram condies de fronteira do mais retorno que testes que no o fazem. O chamado "Princpio da Timidez" postula o seguinte:
"Os 'BUGS' se concentram nos cantos e nas frestas"

Este mtodo complementa o Partio em Classes de Equivalncia (que utiliza valores tpicos), testando valores focalizados nas fronteiras dos intervalos de validade. Na realidade no existe uma metodologia para se testar nas fronteiras, e sim diretrizes para tal.
5.2 - Diretrizes

1)Para cada faixa de valores (na entrada ou na sada), se os extremos da faixa so os valores a e b , geramos os seguintes casos de teste: -Entrada sobre a (sobre a fronteira inferior) -Entrada sobre a - um valor bem pequeno (um pouco abaixo da fronteira inferior) -Entrada sobre b (sobre a fronteira superior) -Entrada sobre b + um valor bem pequeno (um pouco acima da fronteira superior) 2)Para estruturas do tipo conjunto ordenado (arquivo sequencial, lista tabela), gerar os casos: -Conjunto vazio -Conjunto com 1 elemento -Conjunto cheio -Conjunto cheio + 1 3)Quando possvel, gerar casos de teste que levem cada sada para zero (ou nulo) 4)Buscar outras situaes limites especficas do problema, por exemplo:

-16-

Suponha um programa cuja sada uma lista de itens. Alguns casos de fronteira seriam: O nmero de itens na lista tal que: A)Encha uma pgina (sai alguma pgina extra?) B)Encha uma pgina + 1 item C)Um item apenas D) Zero item (Sai cabealho?)
ESTUDO DIRIGIDO 1)Seja o seguinte procedimento:

Procedure ResultFin( NOTA, FREQUENCIA : real); begin readln(NOTA, FREQUENCIA); if (NOTA >= 60) then begin if (FREQUENCIA >= 75) then begin writeln('APROVADO'); readln; end else if (FREQUENCIA > =50) then begin writeln('RECUPERACAO'); readln; end else begin writeln('REPROVADO'); readln; end; end else if (NOTA >=40) then begin writeln('RECUPERACAO'); readln; end else begin writeln('REPROVADO'); readln; end; end. a)Fazer um grafo de causa-efeito para este programa. b)Gerar a tabela de deciso e os casos de teste

-17-

2)Para o procedimento do exerccio anterior faa:

a)Desenhe o grafo de controle b)Determine a complexidade ciclomtica eos caminhos independentes c)Determine os casos de teste

3)Seja a seguinte especificao de sintaxe:

COPY -------->> ORIGEM DIRECIONAMENTO

------->>

DESTINO

----->>

>

------>>

ORIGEM E DESTINO : so arquivos no formato NOME.EXTENSO, onde NOME tem um mximo de 8 caracteres alfanumricos, exceto "[" , "]", "/", ",", ". ". EXTENSO tem um mximo de 3 caracteres e as mesmas excees de NOME.. DIRECIONAMETO,PODE SER : PRN (impressora) NULL (sem ecoar) ARQUIVO (com as mesmas definies deORIGEM e DESTINO) a)Gerar as classes de equivalncia vlidas e invlidas. b) Gerar os respectivos casos de teste.
REFERNCIAS MYERS, G.F. The Art of Software Testing. 1a edio, John Wiley and Sons, 1979.

-18-