1 Testes Prof. Dr. Alfredo Goldman Prof. Dr. Fabio Kon Departamento de Ciência da Computação IME / USP Treinamento ALESP - 16/03/2005.

Apresentação em tema: "1 Testes Prof. Dr. Alfredo Goldman Prof. Dr. Fabio Kon Departamento de Ciência da Computação IME / USP Treinamento ALESP - 16/03/2005."— Transcrição da apresentação:

1

2 1 Testes Prof. Dr. Alfredo Goldman Prof. Dr. Fabio Kon Departamento de Ciência da Computação IME / USP Treinamento ALESP - 16/03/2005

3 16/03/05Copyleft © Alfabio2/48 Testar Depurar zSimplificando yDepurar - o que se faz quando se sabe que o programa não funciona; yTeste - tentativas sistemáticas de encontrar erros em programa que você acha que está funcionando. zTestes podem mostrar a presença de erros, não a sua ausência (Dijkstra)

4 16/03/05Copyleft © Alfabio3/48 Teste enquanto você escreve código zSe possível escreva os testes antes mesmo de escrever o código yuma das técnicas de XP zquanto antes for encontrado o erro melhor !!

5 16/03/05Copyleft © Alfabio4/48 Técnicas básicas zTeste o código em seus limites; zTeste de pré e pós condições; zUso de premissas (assert); zPrograme defensivamente; zUse os códigos de erro.

6 16/03/05Copyleft © Alfabio5/48 Teste o código em seus limites zPara cada pequeno trecho de código (um laço, ou if por exemplo) verifique o seu bom funcionamento; zTente ume entrada vazia, um único item, um vetor cheio, etc.

7 16/03/05Copyleft © Alfabio6/48 Exemplo: int i; char s[MAX]; for(i=0; s[i] = getchar() != \n && i < MAX - 1; i++); s[--i]=\0; Primeiro erro fácil: // o = tem precedência menor do que o != for(i=0; (s[i] = getchar()) != \n && i < MAX - 1; i++);

8 16/03/05Copyleft © Alfabio7/48 Exemplo: int i; char s[MAX]; for(i=0; i < MAX - 1; i++) if ((s[i] = getchar()) == \n) break; s[i]=\0; Testes: linha vazia ok; 1 caractere ok; 2 caracteres ok; MAX caracteres ok e se o primeiro caractere já é o de fim de arquivo ?

9 16/03/05Copyleft © Alfabio8/48 Exemplo: int i; char s[MAX]; for(i=0; i < MAX - 1; i++) if (s[i] = getchar()) == \n || s[i]==EOF) break; s[i]=\0; Testes: ok. Mas o que se deve fazer se a string s fica cheia antes do \n Depende, estes caracteres são necessários, ou não ?

10 16/03/05Copyleft © Alfabio9/48 Teste de pré e pós condições zVerificar certas propriedades antes e depois de trechos de código double avg(double a[], int n){ int i; double sum = 0.0; for(i = 0; i < n; i++) sum += a[i]; return sum / n; }

11 16/03/05Copyleft © Alfabio10/48 Teste de pré e pós condições zSolução possível zNão existe uma única resposta certa yA única resposta claramente errada é ignorar o erro !! yEx: USS Yorktown. // mudar o return return n <= 0 ? 0.0 : sum / n;

12 16/03/05Copyleft © Alfabio11/48 Uso de premissas zEm C e C++ use, jdk 1.4 yex: assert (n>0); yse a condição for violadada: Assertion failed: n>0, file avgtest.c, line 7. zAjuda a identificar culpados pelos erros

13 16/03/05Copyleft © Alfabio12/48 Programação defensiva zTratar situações que não podem acontecer Exemplo: if (nota 10) // não pode acontecer letra = ?; else if (nota > 9) letra = A; else...

14 16/03/05Copyleft © Alfabio13/48 Utilizar códigos de erro zChecar os códigos de erro de funções e métodos; yvocê sabia que o scanf retorna o número de parâmetros lidos, ou EOF ? zSempre verificar se ocorreram erros ao abrir, ler, escrever e principalmente fechar arquivos. zEm Java sempre tratar as possíveis exceções

15 16/03/05Copyleft © Alfabio14/48 Exemplo: int fatorial( int n){ int fac = 1; while (n--) { fac *= n; } return fac; }

16 16/03/05Copyleft © Alfabio15/48 Testes sistemáticos (1/4) zTeste incrementalmente ydurante a construção do sistema xapós testar dois pacotes independentemente teste se eles funcionam juntos zTeste primeiro partes simples ytenha certeza que partes básicas funcionam antes de prosseguir ytestes simples encontram erros simples yteste as funções/métodos individualmente xEx: teste de função que faz a busca binária em inteiros

17 16/03/05Copyleft © Alfabio16/48 Testes Sistemáticos (2/4) zConheça as saídas esperadas yconheça a resposta certa ypara programas mais complexos valide a saída com exemplos conhecidos xcompiladores - arquivos de teste; xnuméricos - exemplos conhecidos, características; xgráficos - exemplos, não confie apenas nos seus olhos.

18 16/03/05Copyleft © Alfabio17/48 Testes Sistemáticos (3/4) zVerifique as propriedades invariantes yalguns programas mantém propriedades da entrada xnúmero de linhas xtamanho da entrada xfreqüência de caracteres Ex: a qualquer instante o número de elementos em uma estrutura de dados deve ser igual ao número de inserções menos o número de remoções.

19 16/03/05Copyleft © Alfabio18/48 Testes Sistemáticos (4/4) zCompare implementações independentes yos resultados devem ser os mesmos xse forem diferentes pelo menos uma das implementações está incorreta zCobertura dos testes ycada comando do programa deve ser executado por algum teste xexistem profilers que indicam a cobertura de testes

20 16/03/05Copyleft © Alfabio19/48 Automação de testes zTestes manuais ytedioso, não confiável zTestes automatizados ydevem ser facilmente executáveis xjunte em um script todos os testes

21 16/03/05Copyleft © Alfabio20/48 Automação de testes zTeste de regressão automáticos yComparar a nova versão com a antiga yverificar se os erros da versão antiga foram corrigidos yverificar que novos erros não foram criados zTestes devem rodar de maneira silenciosa yse tudo estiver OK

22 16/03/05Copyleft © Alfabio21/48 Automação de testes Exemplo de script: for i in Ka_data.* # laço sobre os testes do old_ka $i > out1 # versao antiga new_ka $i > out2 # nova versao if !cmp -s out1 out2# compara then echo $i: Erro # imprime mensagem fi done

23 16/03/05Copyleft © Alfabio22/48 Automação de testes zCrie testes autocontidos ytestes que contém suas próprias entradas e respectivas saídas esperadas yprogramas tipo awk podem ajudar zO que fazer quando um erro é encontrado? yse não foi encontrado por um teste xfaça um teste que o provoque

24 16/03/05Copyleft © Alfabio23/48 Arcabouço de testes zAs vezes para se testar um componente isoladamente é necessários criar um ambiente com características de onde este componente será executado ex: testar funções mem* do C (como memset )

25 16/03/05Copyleft © Alfabio24/48 Arcabouço de testes /* memset: set the first n bytes of s to the byte c */ void *memset(void *s, int c, size_t n) { size_t i; char *p; p = (char *) s; for (i=0; i<n; i++) p[i] = c; return s; } // memset(s0 + offset, c, n); // memset2(s1 + offset, c, n); // compare s0 e s1 byte a byte Como testar funções do math.h ?

26 16/03/05Copyleft © Alfabio25/48 Testes Automáticos (self-checking) zOs testes devem verificar a si mesmos. zA saída deve ser yOK ou ylista precisa das coisas que deram errado. zQuando os testes funcionam, sua saída deve ser apenas uma lista enxuta de Oks. zOu um botão e uma luz verde e outra vermelha.

27 16/03/05Copyleft © Alfabio26/48 O Testador Ideal executar Teste ver Detalhes OK Erro

28 16/03/05Copyleft © Alfabio27/48 Testes de estresse zTestar com grandes quantidades de dados ygerados automaticamente yerros comuns: xoverflow nos buffers de entrada, vetores e contadores yExemplo: ataques de segurança gets do C - não limita o tamanho da entrada o scanf(``%s, str) também não... xErro conhecido por buffer overflow error NYT98

29 16/03/05Copyleft © Alfabio28/48 Testes de estresse Exemplos de erros que podem ser encontrados: char *p; p = (char *) malloc (x * y * z); Conversão entre tipos diferentes: Ariane 5 conversão de double de 64 bits em int de 16 bits => BOOM

30 16/03/05Copyleft © Alfabio29/48 Dicas para fazer testes zCheque os limites dos vetores ycaso a linguagem não faça isto por você yfaça com que o tamanho dos vetores seja pequeno; ao invés de criar testes muito grandes zFaça funções de hashing constantes zCrie versões de malloc que ocasionalmente falham zDesligue todos os testes antes de lançar a versão final

31 16/03/05Copyleft © Alfabio30/48 Dicas para fazer testes zInicialize os vetores e variáveis com um valor não nulo yex: 0xDEADBEEF pode ser facilmente encontrado zNão continue a implementação de novas características se já foram encontrados erros zTeste em várias máquinas, compiladores e SOs

32 16/03/05Copyleft © Alfabio31/48 Tipos de teste zwhite box ytestes feitos por quem conhece (escreveu) o código zblack box ytestes sem conhecer o código zusuários yencontram novos erros pois usam o programa de formas que não foram previstas

33 16/03/05Copyleft © Alfabio32/48 Teste de Software Orientado a Objetos zTestes em geral (não apenas a la XP); zDiferenças em relação a teste de software tradicional? yPodemos não conhecer a implementação de objetos que o nosso código usa; ya modularização e o encapsulamento ajudam a organização dos testes.

34 16/03/05Copyleft © Alfabio33/48 Tipos de testes em software OO ztestes das classes ztestes de interações ztestes de regressão zteste do sistema e sub-sistemas yAtende os requisitos? zteste de aceitação yPosso usar a componente X? ztestes de implantação

35 16/03/05Copyleft © Alfabio34/48 Abordagem de McGregor/Sykes zLema: y Teste cedo. Teste com freqüência. Teste o necessário z Processo iterativo: analise um pouco projete um pouco escreva um pouco de código teste o que puder

36 16/03/05Copyleft © Alfabio35/48 Análise de Riscos 1/2 Análise de Riscos ajuda a planejar quais testes devem ser feitos Um risco - ameaça ao sucesso de um projeto riscos do gerenciamento do projeto testes não ajudam muito riscos do negócio testes da funcionalidade riscos técnicos testes de unidades, das classes, componentes, etc.

37 16/03/05Copyleft © Alfabio36/48 Análise de Riscos 2/2 Uma boa especificação de um projeto deve incluir uma análise dos riscos. Esta análise pode levar ao plano e processo de testes

38 16/03/05Copyleft © Alfabio37/48 Dimensões do Processo de Testes 1/2 Quem cria os testes? Os desenvolvedores? uma equipe especializada em testes? ambos? Quais partes são testadas? Todas? Nenhuma? Ou só as de alto risco? Quando os testes serão realizados? Sempre? Rotineiramente? No final do projeto?

39 16/03/05Copyleft © Alfabio38/48 Dimensões do Processo de Testes 2/2 Como será feito? Baseado no que o software faz ou em como o software faz? Os testadores conhecem a implementação ou só a interface? Quanto de testes é o adequado?

40 16/03/05Copyleft © Alfabio39/48 Papéis no Processo de Testes zTestador de classes zTestador da Integração testa as interações entre objetos Testador do sistema conhece o domínio e é capaz de verificar a aplicação como um todo ponto de vista do usuário do sistema zGerente do Processo de Testes coordena e escalona os testes e as pessoas

41 16/03/05Copyleft © Alfabio40/48 Planejamento de Testes 1/2 zMuitas vezes é esquecido ou não é considerado pelos gerentes de projeto zAtividades de planejamento: yEscalonamento das atividades de testes yEstimativas de custo, tempo e pessoal necessário para realizar os testes yEquipamento necessário

42 16/03/05Copyleft © Alfabio41/48 Planejamento de Testes 2/2 zAtividades de planejamento: yDefinição do nível de cobertura: quanto maior, mais código será exigido. xBeizer: 2% a 80% do tamanho da aplicação. métricas para avaliar eficácia de um conjunto de testes xcobertura do código cobertura das pós-condições xcobertura dos elementos do modelo

43 16/03/05Copyleft © Alfabio42/48 Testes das Classes (unidades) zUma maneira é o peer-review yErrar é humano zTestes automatizados são melhores yDifíceis de construir (não mais verdade!) zTestes automatizados devem cobrir y alguns casos normais yo maior número possível de casos limítrofes

44 16/03/05Copyleft © Alfabio43/48 Testes das Interações zObjetos podem interagir de 4 formas diferentes: yum objeto é passado como parâmetro para outro objeto numa chamada de método yum objeto devolve uma referência para outro objeto numa chamada de método yum método cria uma instância de outro objeto yum método usa uma instância global de outra classe (normalmente evitado)

45 16/03/05Copyleft © Alfabio44/48 Casos: Teste das interações 1/2 zChamadas de métodos z2 abordagens: yProgramação defensiva xO receptor verifica os parâmetros yProgramação por contrato xA mensagem é verificada antes do envio

46 16/03/05Copyleft © Alfabio45/48 Casos: Teste das interações 2/2 zSubclasses/superclasses yUse o diagrama de classes para identificar quais testes de regressão devem ser realizados quando uma classe é alterada ou uma nova classe é criada. yExecute os testes escritos para a superclasse mas agora usando a nova subclasse yPara testar classes abstratas, somos obrigados a criar classes concretas só para testá-las

47 16/03/05Copyleft © Alfabio46/48 Lembre-se zPor que não escrever testes ? yestou com pressa zQuanto maior a pressão ymenos testes zCom menos testes ymenos produtividade e menor estabilidade zLogo, a pressão aumenta....

48 16/03/05Copyleft © Alfabio47/48 O único conceito mais importante de testes é DO IT

49 16/03/05Copyleft © Alfabio48/48 Baseado em zBaseado em: yThe Practice of Programming: Kernighan & Pie yA Practical Guide to Testing Object-Oriented Software. John McGregor & David Sykes yhttp://www.testing.com/http://www.testing.com/