Aula 27 Testes Caixa Branca Alessandro Garcia Willian Oizumi LES/DI/PUC-Rio Novembro 2014
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 Apresentar o uso do módulo CONTA Referência básica: Capítulo 15 Slides adaptados de: Staa, A.v. Notas de Aula em Programacao Modular; 2008. 2 / 28
Sumário O que são testes? Objetivos dos testes Critérios de cobertura de instruções, de arestas e de decisões Uso do módulo conta 3 / 28
Por que testar? Se desenvolvemos módulos corretos por construção, por que testar? Existem diversas técnicas para controle de qualidade: medição revisão, inspeção argumentação, prova formal instrumentação teste Porém, nenhuma delas assegura que um artefato nunca gerará erros Logo devemos utilizar uma variedade de técnicas 4 / 28
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 5 / 28
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 (dentro de uma tolerância), concluise 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 6 / 28
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 7 / 28
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 8 / 28
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 Encontrar falhas não funcionais utilizabilidade desempenho tempo de resposta capacidade... Estimar o grau de qualidade do teste completeza (cobertura) do teste contadores de passagem riscos de defeitos remanescentes os defeitos remanescentes são sempre desconhecidos 9 / 28
Objetivos do teste: como chegar lá Almejar corretude por construção o artefato está sem defeito antes do primeiro teste é um ideal raras vezes alcançado visa minimizar o retrabalho inútil retrabalho inútil tende a ser responsável por até 50% do custo de desenvolvimento requer rigor ao desenvolver Almejar corretude por desenvolvimento o artefato está sem defeito antes de ser posto em uso é um ideal que pode ser alcançado visa reduzir o custo total do artefato especialmente: danos e correção após entrega requer rigor ao controlar a qualidade 10 / 28
Níveis de abstração dos testes Teste de unidade (teste de módulo) examina se um módulo (ou alguns poucos módulos) está em conformidade exata com as suas especificações não faz nem mais nem menos do que o especificado possui propriedades adequadas ao seu uso ênfase na organização interna dos módulos Teste de integração examina se os módulos de um construto se compõem corretamente uns com os outros ênfase nas interfaces entre módulos 11 / 28
Níveis de abstração dos testes Teste de programa examina se o programa (conjunto de módulos) satisfaz exatamente as suas especificações ênfase na demonstração que o programa realiza o que foi especificado, do ponto de vista dos desenvolvedores Teste de funcionalidade examina se o programa atende as necessidades dos usuários ênfases em verificar adequação do serviço do programa às necessidades e expectativas do usuário verificar a uzabilidade do programa verificar outros requisitos não funcionais 12 / 28
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 (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 13 / 28
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 pode ocorrer conflito com o controle de contadores dificuldade de provocar os erros: gere mutantes 14 / 28
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 15 / 28
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 (aula passada) 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 16 / 28
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; }
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
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 = 6 A B C E 19 / 28
Critérios de cobertura: arestas Cobertura de arestas (T4) 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? 20 / 28
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 21 / 28
Critérios de cobertura: decisões B (v, f) C (f, v) A (v, v) D (f, f) if ( ( i < 10 ) && ( j < 10 )) S i = ( i + j ) / 2 ; S if ( i > 5 ) N E (v) F (f) j = 10 ; i = 10 ; N 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 22 / 28
Exercício Determine os casos de teste usando o critério de arestas 23 / 28
Instrumentação de medição Como saber se um módulo foi testado suficientemente? Uma possível forma: medir a cobertura do código exercitado no conjunto de todos os testes O arcabouço de apoio ao teste disponibiliza um módulo para a contagem de passagens CONTA e um interpretador de comandos de teste de contagem INTRPCNT Modo de uso devem ser inseridos contadores de passagem no módulo a ser medido (mark up) cada vez que a execução passa por um contador, ele é incrementado de um ao final verifica-se o estado dos contadores A chamada a esta função deverá ser inserida em um ou mais pontos do módulo a ser medido Nov 2014 Willian Oizumi - OPUS Group/LES/DI/PUC-Rio 24 / 28
Contadores: medição da cobertura de testes Se, após a execução de todos os casos de teste sobrar algum contador com valor igual a zero, o respectivo ponto (CNT_CONTA) nunca foi executado, o teste foi insuficiente Contadores têm nomes simbólicos strings Contadores utilizados na função ARV_InserirEsquerda "Inserir no a esquerda do corrente" "Inserir a esquerda em arvore vazia" "Inserir a esquerda em arvore nao vazia" "Efetuar a insercao a esquerda" "Nao e folha a esquerda" Os contadores precisam ser fornecidos antes de medir para que possamos determinar se algum deles não foi percorrido no conjunto de todos os testes Nov 2014 Willian Oizumi - OPUS Group/LES/DI/PUC-Rio 25 / 28
Contadores: medição da cobertura de testes O esquema de contagem deve ser escolhido em acordo com o objetivo do teste, exemplos: contar se todas ativações de uma função são testadas inserir contador antes de cada chamada de função contar se chamada de função é testada pelo menos uma vez inserir contador em cada início de função contar cada condição de retorno de uma função inserir contador antes de cada retorno Nov 2014 Willian Oizumi - OPUS Group/LES/DI/PUC-Rio 26 / 28
Contadores: controle de caminho Programa: Intercalar arquivos while ( ( Arq_A.Buffer.chave < MAX ) && ( Arq_B.Buffer.chave < MAX )) { CONTAR( "repete" ) ; if ( Arq_A.Buffer.chave == Arq_B.Buffer.chave ) { CONTAR( "chaves iguais" ) ; TransferirRegistro( &Arq_A, Arq_D ) ; TransferirRegistro( &Arq_B, Arq_D ) ; } else if ( Arq_A.Buffer.chave < Arq_B.Buffer.chave ) { CONTAR( "chave Arq_A menor" ) ; TransferirRegistro( &Arq_A, Arq_S ) ; } else { CONTAR( "chave Arq_B menor" ) ; TransferirRegistro( &Arq_B, Arq_S ) ; } } Nov 2014 Willian Oizumi - OPUS Group/LES/DI/PUC-Rio 27 / 28
Instrumentação de medição Instrumentação Manual (Módulo Conta) Instrumentação Automatizada Gcov Trucov Testwell CTC++ Visual Studio Código C Compilação Código Assembly Linkedção Código Binário Nov 2014 Willian Oizumi - OPUS Group/LES/DI/PUC-Rio 28 / 28
Considerações Finais Instrumentação manual é uma forma didática para aplicar os conceitos de teste caixa branca Porém, a instrumentação automatizada é mais adequada para projetos reais: O código fonte fica mais limpo Reduz a probabilidade de falha humana O critério de cobertura pode ser modificado com facilidade Nov 2014 Willian Oizumi - OPUS Group/LES/DI/PUC-Rio 29 / 28
Próximas Aulas Data Aula 26/11 Testes Caixa Branca II 01/12 Exercício Nov 2014 Willian Oizumi - OPUS Group/LES/DI/PUC-Rio 30 / 28
FIM 31 / 28