Aula 18 Testes 1 - inf.puc-rio.brinf1628/docs/2017_1/INF1301_Aula18_Teste_1... · suficiência dos...

Aula 18Testes 1

Alessandro Garcia

Alexander Chávez

LES/DI/PUC-Rio

Ago 2008 2 / 32Arndt von Staa © LES/DI/PUC-Rio

Especificação

• Objetivo dessa aula

– Apresentar os conceitos básicos utilizados ao testar módulos

– Apresentar 3 critérios de seleção de casos de teste caixa

branca: cobertura de instruções, de arestas, de decisões

• Referência básica:

– Capítulo 15

• Slides adaptados de: Staa, A.v. Notas de Aula em

Programacao Modular; 2008.


Sumário

• Objetivos e Processo de teste

– Registro de falhas ou defeitos

• Critérios de seleção de casos de teste

– Critérios de cobertura de instruções, de arestas e de decisões

• Teste de repetições, arrasto

• Transformação de casos de teste abstratos em casos de

teste úteis

Motivação – “Trem fantasma”

• Na década de 90, na Inglaterra, ocorreu um problema nos

sensores das linhas férreas situadas em túneis

• O sistema alertava o trem a parar devido à suspeita de

outro trem na linha

• A causa do problema era a névoa de água salgada que

“confundia” os sensores

• Motivo da falha:

– Provavelmente os requisitos do sistema não levavam em conta

a névoa de água salgada como um possível evento

Mai 2016 4 / 49Bruno Cafeo - OPUS Group/LES/DI/PUC-Rio

Motivação – Metrô em Nova Iorque

• Em 1995, duas composições colidiram matando um

maquinista e ferindo 54 pessoas

• A distância entre os sinais (projetado em 1918) era menor

que a distância de parada necessária para os trens em 1995

(maiores, mais pesados e mais rápidos)

• Os trens foram atualizados sem modificação no sistema de

controle


– Atualização de uma parte do sistema sem validar o sistema

como um todo.


Motivação – Ariane 5

• Em 1996, o veículo espacial Ariane 5 saiu de sua rota e

explodiu segundos após o lançamento. Levou uma década

para ser desenvolvido e custou 7 bilhões de dólares

• Componentes reutilizados do veículo Ariane 4 foram a causa

do acidente


– A variável que armazenava cálculo da velocidade horizontal do

foguete deveria ter 64 bits (floating point), mas possuía 16 bits

(signed integer). O valor era maior que 32.767 gerando uma

falha de conversão!!!


Motivação

• Alguém já testou algum produto de software?

• Quais foram os maiores desafios?

7 / 49Mai 2016 Bruno Cafeo - OPUS Group/LES/DI/PUC-Rio

Qualidade do software

• Por que é difícil construir software com qualidade?

• Existe algum mecanismo para garantir a qualidade do

software? Como utilizá-lo eficientemente?






O que é qualidade?

É a totalidade de características e critérios de um produto ou serviço que exercem suas

habilidades para satisfazer às necessidades declaradas ou envolvidas.






• Garantia de qualidade: Conjunto de atividades aplicadas

durante todo o processo de desenvolvimento que visam a

garantir que tanto o processo de desenvolvimento quanto o

produto de software atinjam os níveis de qualidade

especificados


Garantia de Qualidade

• Nenhuma técnica de garantia da qualidade assegura que um

artefato nunca gerará erros

– medição

– revisão, inspeção

– argumentação, prova formal

– instrumentação

– teste

• Logo devemos utilizar uma variedade de técnicas a começar

com o desenvolvimento correto por construção



O que são testes?

• Testes são técnicas de controle da qualidade baseados na

condução de experimentos controlados

• Em um experimento controlado:

– dispõe-se de uma hipótese: o módulo a testar corresponde

exatamente à sua especificação

• não tem funcionalidade a mais

• não tem funcionalidade a menos

• satisfaz todos os requisitos não funcionais

– formula-se um conjunto de experimentos:

• a massa de teste

– conjunto de dados e comandos

• os resultados dos testes que suportam a hipótese

– os resultados esperados para cada dado e/ou comando

• procura-se identificar condições que tenham elevada chance de

mostrar que a hipótese não vale


O que são testes?

• Em um experimento controlado (cont.):

– executa-se o teste (efetua-se o experimento)

• obtêm-se os resultados dos testes

• comparam-se os resultados esperados com os obtidos

– caso todos os experimentos comprovem que o resultado

esperado é igual ao obtido, conclui-se que o programa

corresponde à sua especificação, considerando o teste realizado

• a conclusão será sempre dependente da massa de teste utilizada

– a rigor testes deveriam ser repetidos com variadas massas de teste e

variadas condições de realização deles

• quanto maior o rigor do experimento, mais confiança poder-se-á

depositar na conclusão


Postura ao testar

• Em geral o teste deve ser orientado à destruição

– procurar demonstrar que o módulo não corresponde

exatamente à especificação

• procurar demonstrar que o módulo “não funciona”

– ao invés de demonstrar que corresponde à especificação

• ao invés de “ver se funciona”

– algumas vezes o teste será orientado à avaliação (auditoria

funcional)

• verificar se resolve o problema do usuário

• quão bem o faz

• mesmo aqui o interesse é descobrir os casos em que não o faz tão

bem quanto o esperado


Características de testes

• Testes são

– caros

• há quem diga que testes correspondem a entre 30 e 50% do

esforço de desenvolvimento

– problema é como foi obtida esta estatística?

– demorados

• através da automação dos testes reduz-se significativamente

(ordens de grandeza) o esforço despendido

– ineficientes

• encontram poucas falhas a cada execução

– ineficazes

• estatísticas mostram que somente encontram cerca de 65% dos

problemas

– devem ser projetados cuidadosamente

• visando aumentar eficiência e eficácia


Objetivos do teste

• Encontrar o maior número de falhas relevantes possível

– encontrar todas é um ideal em geral não alcançável

• Encontrar falhas funcionais

– o módulo não corresponde exatamente à sua especificação

• Estimar o grau de qualidade do teste

– completeza (cobertura) do teste

• ver contadores de passagem

• riscos de defeitos remanescentes

• os defeitos remanescentes são sempre desconhecidos


Processo de teste

EspecificaçãoRequisitos de

qualidade

Solicitação dealteração

Produzirartefato

instrumentado

Selecionarcritérios

Corrigirartefato

Produzircasos de teste

Diagnosticarfalhas

Reduzirinstrumen-

tação

Corrigircasos de teste

Efetuarteste

Falha doscasos de teste

Falha daespecificação

OK final

OKintermediário

Falha doartefato

fluxo de laudos

fluxo do processo

fluxo de informação

Artefatoaceito

Massas de testeaceitas

Armadura de teste aceita

Especificaçãoaceita

Solicitação dealteração

Laudosfinais


Controle da suficiência dos testes

• Podem ser utilizadas diversas formas para controlar a

suficiência dos testes

– medir a cobertura dos testes

• mede-se com o uso de contadores, aula de instrumentação

(módulo CONTA)

• esta técnica de controle da suficiência de testes pode ser utilizada

junto com qualquer critério de seleção de casos de teste

• existem vários critérios de completeza

• caso um ou mais dos contadores contenha zero e não for possível

argumentar que o contador será sempre zero para qualquer

instância de uso estamos diante de:

– código morto



• Código morto é uma função ou fragmento de código, que

jamais poderá ser exercitado em qualquer condição de uso

– normal ou de tratamento de falha

• Código morto deve ser excluído do programa

– manutenção de código morto é uma despesa inútil



• Outra forma de avaliar a suficiência de testes é medir o

intervalo de tempo entre falhas

– realizam-se continuamente testes (ou utiliza-se o módulo em

produção) com dados variantes

– mede-se o intervalo de tempo decorrido entre falhas

consecutivas

• Caso o intervalo observado seja maior do que um número

estipulado, assume-se que o artefato tenha sido

suficientemente testado

– corre-se o risco de que o artefato ainda contenha um número

possivelmente grande de defeitos desconhecidos

• depende da forma do uso

– MTBF – mean time between failures é um indicador de risco,

quanto maior o MTBF menor o risco



• Não são critérios que determinam a suficiência dos testes:

– esgotamento do prazo para entrega do artefato

– esgotamento dos recursos disponíveis para desenvolver o

artefato

• Infelizmente tendem a ser os critérios mais populares


Critérios de seleção de casos de teste

• Critérios de seleção de casos de teste são utilizados para

gerar os casos de teste que compõem a massa de teste

– a geração pode ser manual, ou parcial ou totalmente

automatizada

• Categorias de critérios de seleção de casos de teste

– teste caixa preta

• gera os casos utilizando somente a especificação

• a massa pode ser desenvolvida antes ou junto com o código

– teste caixa branca (teste estrutural)

• gera os casos de teste utilizando o código completo e a

especificação

– teste de estruturas de dados

• gera os casos de teste utilizando modelos e/ou o código de

declaração da estrutura de dados e a especificação


Critérios de seleção de casos de teste

• Um critério de seleção de casos de teste é

– válido:

• existindo defeitos no artefato testado, acusa falhas que permitam

localizar esses defeitos

– confiável:

• é indiferente à escolha dos dados e ações usados na massa de

teste

– completo:

• exercita todo o código segundo um padrão de completeza

– eficaz:

• quanto mais falhas encontrar, provocadas por diferentes defeitos

• quanto mais defeitos for capaz de identificar

– eficiente:

• quanto menos recursos necessitar para executar os testes

Critérios: caixa branca

MAT_tpCondRet f1(int i, int j) {

if ( ( i < 10 ) && ( j < 10 ) ) {

i = ( i + j ) / 2;

if ( i > 5 ) {

j = 10;

else {

i = 10;

}

}

return MAT_CondRetOK;

}

• Passo 1: produção do fluxograma

Critérios: caixa branca

MAT_tpCondRet f1(int i, int j) {

if ( ( i < 10 ) && ( j < 10 ) ) {

i = ( i + j ) / 2;

if ( i > 5 ) {

j = 10;

else {

i = 10;

}

}

return MAT_CondRetOK;

}

• Passo 1: produção do fluxograma

i = ( i + j ) / 2 ;

j = 10 ; i = 10 ;

if ( ( i < 10 )

&& ( j < 10 ))

if ( i > 5 )

S

N

S N

Jun 2009 26 / 32LES/DI/PUC-Rio

Critérios de cobertura: instruções

• Cobertura de instruções

(vértices)

– Cada instrução é executada

pelo menos uma vez no

conjunto de todos os casos de

teste

– rotulam-se as instruções e

criam-se os casos de teste

• cada caso percorre pelo

menos uma instrução ainda

não percorrida

• até que todas as instruções

tenham sido percorridas

– i = 4 ; j = 8 A B C D

– i = 4 ; j = 4 A B C E

i = ( i + j ) / 2 ;

j = 10 ; i = 10 ;

if ( ( i < 10 )

&& ( j < 10 ))

if ( i > 5 )

S

N

S N

D E

A

B

C


Critérios de cobertura: arestas

• Cobertura de arestas

– Cada aresta é percorrida pelo

menos uma vez no conjunto

de todos os casos de teste

– rotulam-se as arestas e



menos uma aresta ainda não

percorrida

• até que todas as arestas


– i = 4 ; j = 8 I A C D F

– i = 4 ; j = 6 I A C E F

– Suficiente?

i = ( i + j ) / 2 ;

j = 10 ; i = 10 ;

if ( ( i < 10 )

&& ( j < 10 ))

if ( i > 5 )

S

N

S N

D E

B

A

C

F

I


Critérios de cobertura: arestas

• Cobertura de arestas

– Cada aresta é percorrida pelo



– rotulam-se as arestas e



menos uma aresta ainda não

percorrida

• até que todas as arestas


– i = 4 ; j = 8 I A C D F

– i = 4 ; j = 6 I A C E F

– i = 3 ; j = 10 I B F

i = ( i + j ) / 2 ;

j = 10 ; i = 10 ;

if ( ( i < 10 )

&& ( j < 10 ))

if ( i > 5 )

S

N

S N

D E

B

A

C

F

I

29 / 35LES/DI/PUC-Rio

Critérios de cobertura: decisões

• Cobertura de decisões

– Cada combinação ao avaliar

membros das expressões

lógicas é exercitada pelo



– Neste caso, as decisões são

rotuladas

– i = 4 ; j = 9 A, E

– i = 1 ; j = 1 A, F

– i = 4 ; j = 10 B

– i = 10 ; j = 4 C

– i = 10 ; j = 10 D

i = ( i + j ) / 2 ;

j = 10 ; i = 10 ;

if ( ( i < 10 )

&& ( j < 10 ))

if ( i > 5 )

S

N

S N

A (v, v) D (f, f)

E (v) F (f)

Neste caso, são necessários

no mínimo 5 casos de teste

B (v, f)

C (f, v)

Possíveis combinações de decisões:

v,v,v

v,v,f

v,f

f,v

f,f


Critérios de cobertura: repetições

• Caso cobertura de instrução

– executar a repetição para n > 1 iterações;

• Caso cobertura de arestas

– executar a repetição para:

• n = 0 iterações

• n = 1 iteração

• n >= 2 iterações

• Caso cobertura de decisões

– como na cobertura de arestas

– em adição: cada uma das possibilidades de se decidir pelo

término foi exercitada para os 3 casos acima

• break, ou return no corpo da repetição

• expressão de controle de término composta



• O custo do teste cresce com o número de iterações

– portanto o número de iterações a testar no caso n > 1 deverá

• ser pequeno e

• ser suficientemente grande para que o teste possa ser assumido

válido


Arrasto

• Arrasto

– é o maior dos menores números de iterações necessárias para

que todas as variáveis ou estados inicializados antes e

modificados durante a repetição passem a depender

exclusivamente de valores computados em iterações anteriores

de uma mesma instância de execução dessa repetição

• Exemplos:

• A[0] = 0 ; A[1] = 0 ; A[2] = 0 ; A[3] = 0 ;

• memset( A , 0 , sizeof( A )) ;

• pElem = ProcurarSimbolo( pTabela , pSimbolo ) ;

– todos têm Arrasto == 0

• Arrasto: força de resistência ao avanço de um objeto em um fluido, resultante da ação do meio



• O arrasto é o número mínimo de iterações a realizar para

que todos os valores que possam ser modificados durante a

repetição tenham sido de fato modificados


Arrasto: exemplos

• Série de Fibonacci: 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, ...

– lei de formação Fn = Fn-2 + Fn-1

– tem Arrasto == ?

int main() {

int tam, f1, f2, f3, cont;

do {

printf("Digite o tamanho da sequencia: ");

scanf("%i", &tam);

if (tam <= 0)

printf("Digite um numero positivo!!");

} while (tam <= 0);

printf("0 - 1 - ");

f1 = 0; f2 = 1;

for (cont = 3; cont <= tam ; cont++) {

f3 = f2 + f1;

printf("%i - ", f3);

f1 = f2; f2 = f3;

}

return 0;

}

?


Arrasto: exemplos

• Série de Fibonacci: 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, ...

– lei de formação Fn = Fn-2 + Fn-1

– tem Arrasto == 3

int main() {

int tam, f1, f2, f3, cont;

do {

printf("Digite um numero: ");

scanf("%i", &tam);

if (tam <= 0)

printf("Digite um numero positivo!!");

} while (tam<=0);

printf("0 - 1 - ");

f1 = 0; f2 = 1;

for (cont = 3; cont <= tam ; cont++) {

f3 = f2 + f1;

printf("%i - ", f3);

f1 = f2; f2 = f3;

}

return 0;

}

cont f3 f1 f2

3 1 1 1

4 2 1 2

5 3 2 3

6 5 3 5

7 8 5 8

5 13 8 13

Quando variável passa

depender somente de valores

gerados em iterações anteriores

Ainda não satisfaz as

condições do arrasto


Arrasto

• Arrasto

– é o menor número de iterações necessárias para que todas as variáveis

ou estados inicializados antes e modificados durante a repetição

passem a depender exclusivamente de valores modificados em

iterações anteriores de uma mesma instância de execução dessa

repetição

• Exemplos:

• for (i = 0; i < TamVet; i++) {

Vet[i] = 0;

}

• Soma = 0;

for (i = 0; i < TamVet; i++) {

Soma += Vet[i];

}

– todos têm Arrasto == 1

i somente é atualizado

apenas depois do fim da

1a. Interação…


Arrasto: exemplos

• for ( i = 0 ; i < 10 ; i++ ) ...

• for ( pElem = pOrg ; pElem != NULL ; pElem = pElem->pProx ) ...

• fgets, fputs, fread, fwrite

• tpEstado Corrente ;

Corrente = DefinirPrimeiro( ValorProcurado ) ;

while ( !Terminou( Corrente ))

{

if ( Comparar( ObterValor( Corrente ), ValorProcurado )

== EH_IGUAL )

{

return Corrente ;

} /* if */

Corrente = DefinirProximo( Corrente , ValorProcurado ) ;

} /* while */

return ESTADO_NIL ;

• Todos têm Arrasto == 1


Arrasto: exemplos

• Tem Arrasto == ?

Intercalararquivos

Abrirarquivos

Efetuar aintercalação

Fechararquivos

Ler 1o. reg de ALer 1o. reg de B

Intercalar paresregs correntes

Transferir reg de A para S

Transferir regsde A para E

e de B para E

Transferir regde B para S

{RegA.Chave < RegB.Chave} {RegA.Chave == RegB.Chave} {RegA.Chave > RegB.Chave}

{ enquanto RegA.Chave < máximo ou RegB.Chave < máximo }

H

F

C 2

A

B

I

D

G

E

Buffer A

Buffer B


Arrasto: exemplos

• Tem Arrasto == 2Intercalararquivos

Abrirarquivos


Fechararquivos





e de B para E




H

F

C 2

A

B

I

D

G

E

Buffer A

Buffer B

Caso 2

buffers mudam com somente uma

interação

Caso 1

buffers mudam com duas

interações

menores números de iterações

MAIOR DOS...


Arrasto: exemplos

• Tem Arrasto == 2

Intercalararquivos

Abrirarquivos


Fechararquivos





e de B para E




H

F

C 2

A

B

I

D

G

E



• O arrasto é o número mínimo de iterações a realizar para

que todos os valores que possam ser modificados durante a

repetição tenham sido de fato modificados

– corresponde ao número mínimo de iterações para atingir o

estado “genérico”

– é função do projetista determinar o arrasto

• Os casos de teste a para as repetições são:

– caso 0 iteração (caso especial)

– caso 1 iteração (base da indução)

– caso n >= arrasto + 1 iterações (simula o passo de indução)

– devem sempre ser considerados os casos de término:

• break ou return no corpo da iteração

• atingiu a condição de término


Critério cobertura de decisões: exemplo

• Esquema do algoritmo para pesquisa em qualquer tabela

tpEstado Corrente ;

Corrente = DefinirPrimeiro( ValorProcurado ) ;

while ( !Terminou( Corrente ))

{

if ( Comparar( ObterValor( Corrente ),

ValorProcurado ) == EH_IGUAL )

{

return Corrente ;

} /* if */

Corrente = DefinirProximo( Corrente , ValorProcurado ) ;

} /* while */

return ESTADO_NIL ;

• arrasto == 1


Critério cobertura de decisões: exemplo

• Caso 0 iterações:

– tabela vazia

– tabela com 1 ou mais elementos e acha o primeiro elemento

• Caso 1 iteração:

– tabela com 1 elemento e não acha o elemento

– tabela com 2 ou mais elementos e acha o segundo elemento

• Caso arrasto + 1 iterações:

– tabela com 2 elementos e não acha o elemento

– tabela com 3 ou mais elementos e acha o segundo elemento


FIM

Aula 18 Testes 1 - inf.puc-rio.brinf1628/docs/2017_1/INF1301_Aula18_Teste_1... · suficiência dos...

Documents

Transcript of Aula 18 Testes 1 - inf.puc-rio.brinf1628/docs/2017_1/INF1301_Aula18_Teste_1... · suficiência dos...