Aula 21 Testes 1. Alessandro Garcia Alexander Chávez LES/DI/PUC-Rio

Transcrição

1 Aula 21 Testes 1 Alessandro Garcia Alexander Chávez LES/DI/PUC-Rio

2 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; / 32

3 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 3 / 32

4 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 Bruno Cafeo - OPUS Group/LES/DI/PUC-Rio 4 / 49

5 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 Motivo da falha: Atualização de uma parte do sistema sem validar o sistema como um todo. Mai 2016 Bruno Cafeo - OPUS Group/LES/DI/PUC-Rio 5 / 49

6 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 Motivo da falha: 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 gerando uma falha de conversão!!! Mai 2016 Bruno Cafeo - OPUS Group/LES/DI/PUC-Rio 6 / 49

7 Motivação Alguém já testou algum produto de software? Quais foram os maiores desafios? Mai 2016 Bruno Cafeo - OPUS Group/LES/DI/PUC-Rio 7 / 49

8 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 8 / 32

9 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 9 / 32

10 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 10 / 32

11 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 11 / 32

12 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 12 / 32

13 Processo de teste Requisitos de qualidade Especificação Solicitação de alteração Corrigir artefato Selecionar critérios Produzir casos de teste Produzir artefato instrumentado Efetuar teste Falha do artefato Reduzir instrumentação Corrigir casos de teste Falha dos casos de teste Diagnosticar falhas OK final OK intermediário Solicitação de alteração Falha da especificação Artefato aceito Laudos finais fluxo de laudos fluxo do processo fluxo de informação Massas de teste aceitas Especificação aceita Armadura de teste aceita 13 / 32

14 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, vide 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: ou código morto ou código de interceptação de falha 14 / 32

15 Controle da suficiência dos testes 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 Interceptação de falha não é código morto interceptação de falhas é proteção contra lesões causas endógenas, exógenas ou decorrentes do mau uso tipicamente consta de assertivas executáveis e o código de tratamento para o caso das assertivas falharem evidentemente o código de tratamento jamais deveria ser executado caso o artefato esteja operando de forma correta 15 / 32

16 Controle da suficiência dos testes 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 16 / 32

17 Controle da suficiência dos testes 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 17 / 32

18 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 18 / 35

19 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 19 / 35

20 Critérios: caixa branca Passo 1: produção do fluxograma 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; }

21 Critérios: caixa branca MAT_tpCondRet f1(int i, int j) { } Passo 1: produção do fluxograma if ( ( i < 10 ) && ( j < 10 ) ) { } i = ( i + j ) / 2; if ( i > 5 ) { else { } j = 10; i = 10; return MAT_CondRetOK; S if ( ( i < 10 ) && ( j < 10 )) i = ( i + j ) / 2 ; if ( i > 5 ) j = 10 ; i = 10 ; S N N

22 Critérios de cobertura: instruções Cobertura de instruções A if ( ( i < 10 ) && ( j < 10 )) N (vértices) Cada instrução é executada pelo menos uma vez no B S i = ( i + j ) / 2 ; conjunto de todos os casos de teste rotulam-se as instruções e C criam-se os casos de teste S if ( i > 5 ) N cada caso percorre pelo D E menos uma instrução ainda não percorrida j = 10 ; i = 10 ; 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 Jun 2009 LES/DI/PUC-Rio 22 / 32

23 Critérios de cobertura: arestas Cobertura de arestas I Cada aresta é percorrida pelo if ( ( i < 10 ) && ( j < 10 )) N B menos uma vez no conjunto de todos os casos de teste D A i = ( i + j ) / 2 ; C S N if ( i > 5 ) j = 10 ; i = 10 ; F S E rotulam-se as arestas e criam-se os casos de teste cada caso percorre pelo menos uma aresta ainda não percorrida até que todas as arestas tenham sido percorridas i = 4 ; j = 8 I A C D F i = 4 ; j = 6 I A C E F Suficiente? Jun 2009 LES/DI/PUC-Rio 23 / 32

24 Critérios de cobertura: arestas Cobertura de arestas I Cada aresta é percorrida pelo if ( ( i < 10 ) && ( j < 10 )) N B menos uma vez no conjunto de todos os casos de teste D A i = ( i + j ) / 2 ; C S N if ( i > 5 ) j = 10 ; i = 10 ; F S E rotulam-se as arestas e criam-se os casos de teste cada caso percorre pelo menos uma aresta ainda não percorrida até que todas as arestas tenham sido percorridas 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 Jun 2009 LES/DI/PUC-Rio 24 / 32

25 Critérios de cobertura: decisões A (v, v) if ( ( i < 10 ) N D (f, f) && ( j < 10 )) S i = ( i + j ) / 2 ; S if ( i > 5 ) N B (v, f) C (f, v) E (v) F (f) j = 10 ; i = 10 ; Cobertura de decisões Cada combinação ao avaliar membros das expressões lógicas é exercitada pelo menos uma vez no conjunto de todos os casos de teste 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 Possíveis combinações de decisões: v,v,v v,v,f v,f f,v f,f LES/DI/PUC-Rio Neste caso, são necessários no mínimo 5 casos de teste 25 / 35

26 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 26 / 35

27 Critérios de cobertura: repetições 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 27 / 35

28 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 28 / 35

29 Critérios de cobertura: repetições 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 29 / 35

30 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]; } i somente é atualizado apenas depois do fim da 1a. Interação todos têm Arrasto == 1 Jun 2009 LES/DI/PUC-Rio 30 / 35

31 Arrasto: exemplos Série de Fibonacci: 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89,... lei de formação F n = F n-2 + F n-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;? Jun 2009 LES/DI/PUC-Rio 31 / 35

32 Arrasto: exemplos Série de Fibonacci: 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89,... lei de formação F n = F n-2 + F n-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); Ainda não satisfaz as condições do arrasto Quando variável passa depender somente de valores gerados em iterações anteriores } 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 f Jun 2009 LES/DI/PUC-Rio 32 / 35

33 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 33 / 35

34 Arrasto: exemplos A Intercalar arquivos Buffer A Buffer B B Abrir arquivos E Ler 1o. reg de A Ler 1o. reg de B C 2 Efetuar a intercalação F Intercalar pares regs correntes D Fechar arquivos { enquanto RegA.Chave < máximo ou RegB.Chave < máximo } {RegA.Chave < RegB.Chave} {RegA.Chave == RegB.Chave} G Transferir reg de A para S H Transferir regs de A para E e de B para E {RegA.Chave > RegB.Chave} I Transferir reg de B para S Tem Arrasto ==? Jun 2009 LES/DI/PUC-Rio 34 / 35

35 Arrasto: exemplos Tem Arrasto == 2 A Intercalar arquivos Abrir arquivos MAIOR DOS... menores números de iterações B Buffer A Buffer B Caso 1 E Ler 1o. reg de A Ler 1o. reg de B Transferir reg de A para S C 2 Efetuar a intercalação Intercalar pares regs correntes {RegA.Chave < RegB.Chave} {RegA.Chave == RegB.Chave} G F Caso 2 H Transferir regs de A para E e de B para E Fechar arquivos { enquanto RegA.Chave < máximo ou RegB.Chave < máximo } {RegA.Chave > RegB.Chave} Transferir reg de B para S buffers mudam com duasbuffers mudam com somente uma interações interação Jun 2009 LES/DI/PUC-Rio 35 / 35 D I

36 Arrasto: exemplos A Intercalar arquivos B Abrir arquivos E Ler 1o. reg de A Ler 1o. reg de B C 2 Efetuar a intercalação F Intercalar pares regs correntes D Fechar arquivos { enquanto RegA.Chave < máximo ou RegB.Chave < máximo } {RegA.Chave < RegB.Chave} {RegA.Chave == RegB.Chave} G Transferir reg de A para S H Transferir regs de A para E e de B para E {RegA.Chave > RegB.Chave} I Transferir reg de B para S Tem Arrasto == 2 36 / 35

37 Critérios de cobertura: repetições 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 37 / 35

38 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 38 / 35

39 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 39 / 35

40 FIM 40 / 32