Testes de Sofware

850 visualizações

Publicada em

Publicada em: Tecnologia, Turismo
0 comentários
1 gostou
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
850
No SlideShare
0
A partir de incorporações
0
Número de incorporações
3
Ações
Compartilhamentos
0
Downloads
31
Comentários
0
Gostaram
1
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Testes de Sofware

  1. 1. Testes Prof. Dr. Alfredo Goldman Prof. Dr. Fabio Kon Departamento de Ciência da Computação IME / USP Lab. XP
  2. 2. Testar  Depurar <ul><li>Simplificando </li></ul><ul><ul><li>Depurar - o que se faz quando se sabe que o programa não funciona; </li></ul></ul><ul><ul><li>Teste - tentativas sistemáticas de encontrar erros em programa que você “acha” que está funcionando. </li></ul></ul><ul><li>“ Testes podem mostrar a presença de erros, não a sua ausência (Dijkstra)” </li></ul>
  3. 3. Teste enquanto você escreve código <ul><li>Se possível escreva os testes antes mesmo de escrever o código </li></ul><ul><ul><li>uma das técnicas de XP </li></ul></ul><ul><li>quanto antes for encontrado o erro melhor !! </li></ul>
  4. 4. Técnicas básicas <ul><li>Teste o código em seus limites; </li></ul><ul><li>Teste de pré e pós condições; </li></ul><ul><li>Uso de premissas (assert); </li></ul><ul><li>Programe defensivamente; </li></ul><ul><li>Use os códigos de erro. </li></ul>
  5. 5. Teste o código em seus limites <ul><li>Para cada pequeno trecho de código (um laço, ou if por exemplo) verifique o seu bom funcionamento; </li></ul><ul><li>Tente ume entrada vazia, um único item, um vetor cheio, etc. </li></ul>
  6. 6. Exemplo: int i; char s[MAX]; for(i=0; s[i] = getchar() != ‘ ’ && i < MAX - 1; i++); s[--i]=‘’; Primeiro erro fácil: // o = tem precedência menor do que o != for(i=0; (s[i] = getchar()) != ‘ ’ && i < MAX - 1; i++);
  7. 7. Exemplo: int i; char s[MAX]; for(i=0; i < MAX - 1; i++) if ((s[i] = getchar()) == ‘ ’) break; s[i]=‘’; Testes: linha vazia ok; 1 caractere ok; 2 caracteres ok; MAX caracteres ok e se o primeiro caractere já é o de fim de arquivo ?
  8. 8. Exemplo: int i; char s[MAX]; for(i=0; i < MAX - 1; i++) if (s[i] = getchar()) == ‘ ’ || s[i]==EOF) break; s[i]=‘’; Testes: ok. Mas o que se deve fazer se a string s fica cheia antes do ‘ ’ Depende, estes caracteres são necessários, ou não ?
  9. 9. Teste de pré e pós condições <ul><li>Verificar certas propriedades antes e depois de trechos de código </li></ul>double avg(double a[], int n){ int i; double sum = 0.0; for(i = 0; i < n; i++) sum += a[i]; return sum / n; }
  10. 10. Teste de pré e pós condições <ul><li>Solução possível </li></ul><ul><li>Não existe uma única resposta certa </li></ul><ul><ul><li>A única resposta claramente errada é ignorar o erro !! </li></ul></ul><ul><ul><li>Ex: USS Yorktown. </li></ul></ul>// mudar o return return n <= 0 ? 0.0 : sum / n;
  11. 11. Uso de premissas <ul><li>Em C e C++ use <assert.h>, jdk 1.4 </li></ul><ul><ul><li>ex: </li></ul></ul><ul><ul><li>assert (n>0); </li></ul></ul><ul><ul><li>se a condição for violadada: </li></ul></ul><ul><ul><ul><li>Assertion failed: n>0, file avgtest.c, line 7. </li></ul></ul></ul><ul><li>Ajuda a identificar “culpados” pelos erros </li></ul>
  12. 12. Programação defensiva <ul><li>Tratar situações que não “podem” acontecer </li></ul><ul><ul><ul><li>Exemplo: </li></ul></ul></ul>if (nota < 0 || nota > 10) // não pode acontecer letra = ‘?’; else if (nota > 9) letra = ‘A’; else ...
  13. 13. Utilizar códigos de erro <ul><li>Checar os códigos de erro de funções e métodos; </li></ul><ul><ul><li>você sabia que o scanf retorna o número de parâmetros lidos, ou EOF ? </li></ul></ul><ul><li>Sempre verificar se ocorreram erros ao abrir, ler, escrever e principalmente fechar arquivos. </li></ul><ul><li>Em Java sempre tratar as possíveis exceções </li></ul>
  14. 14. Exemplo: int fatorial( int n){ int fac = 1; while (n--) { fac *= n; } return fac; }
  15. 15. Testes sistemáticos (1/4) <ul><li>Teste incrementalmente </li></ul><ul><ul><li>durante a construção do sistema </li></ul></ul><ul><ul><ul><li>após testar dois pacotes independentemente teste se eles funcionam juntos </li></ul></ul></ul><ul><li>Teste primeiro partes simples </li></ul><ul><ul><li>tenha certeza que partes básicas funcionam antes de prosseguir </li></ul></ul><ul><ul><li>testes simples encontram erros simples </li></ul></ul><ul><ul><li>teste as funções/métodos individualmente </li></ul></ul><ul><ul><ul><li>Ex: teste de função que faz a busca binária em inteiros </li></ul></ul></ul>
  16. 16. Testes Sistemáticos (2/4) <ul><li>Conheça as saídas esperadas </li></ul><ul><ul><li>conheça a resposta certa </li></ul></ul><ul><ul><li>para programas mais complexos valide a saída com exemplos conhecidos </li></ul></ul><ul><ul><ul><li>compiladores - arquivos de teste; </li></ul></ul></ul><ul><ul><ul><li>numéricos - exemplos conhecidos, características; </li></ul></ul></ul><ul><ul><ul><li>gráficos - exemplos, não confie apenas nos seus olhos. </li></ul></ul></ul>
  17. 17. Testes Sistemáticos (3/4) <ul><li>Verifique as propriedades invariantes </li></ul><ul><ul><li>alguns programas mantém propriedades da entrada </li></ul></ul><ul><ul><ul><li>número de linhas </li></ul></ul></ul><ul><ul><ul><li>tamanho da entrada </li></ul></ul></ul><ul><ul><ul><li>freqüência de caracteres </li></ul></ul></ul><ul><ul><ul><ul><li>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. </li></ul></ul></ul></ul>
  18. 18. Testes Sistemáticos (4/4) <ul><li>Compare implementações independentes </li></ul><ul><ul><li>os resultados devem ser os mesmos </li></ul></ul><ul><ul><ul><li>se forem diferentes pelo menos uma das implementações está incorreta </li></ul></ul></ul><ul><li>Cobertura dos testes </li></ul><ul><ul><li>cada comando do programa deve ser executado por algum teste </li></ul></ul><ul><ul><ul><li>existem profilers que indicam a cobertura de testes </li></ul></ul></ul>
  19. 19. Automação de testes <ul><li>Testes manuais </li></ul><ul><ul><li>tedioso, não confiável </li></ul></ul><ul><li>Testes automatizados </li></ul><ul><ul><li>devem ser facilmente executáveis </li></ul></ul><ul><ul><ul><li>junte em um script todos os testes </li></ul></ul></ul>
  20. 20. Automação de testes <ul><li>Teste de regressão automáticos </li></ul><ul><ul><li>Comparar a nova versão com a antiga </li></ul></ul><ul><ul><li>verificar se os erros da versão antiga foram corrigidos </li></ul></ul><ul><ul><li>verificar que novos erros não foram criados </li></ul></ul><ul><li>Testes devem rodar de maneira silenciosa </li></ul><ul><ul><li>se tudo estiver OK </li></ul></ul>
  21. 21. 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
  22. 22. Automação de testes <ul><li>Crie testes autocontidos </li></ul><ul><ul><li>testes que contém suas próprias entradas e respectivas saídas esperadas </li></ul></ul><ul><ul><li>programas tipo awk podem ajudar </li></ul></ul><ul><li>O que fazer quando um erro é encontrado? </li></ul><ul><ul><li>se não foi encontrado por um teste </li></ul></ul><ul><ul><ul><li>faça um teste que o provoque </li></ul></ul></ul>
  23. 23. Arcabouço de testes <ul><li>As vezes para se testar um componente isoladamente é necessários criar um ambiente com características de onde este componente será executado </li></ul><ul><ul><li>ex: testar funções mem* do C (como memset ) </li></ul></ul>
  24. 24. Arcabouço de testes <ul><li>/* memset: set the first n bytes of s to the byte c */ </li></ul><ul><li>void *memset(void *s, int c, size_t n) { </li></ul><ul><li>size_t i; </li></ul><ul><li>char *p; </li></ul><ul><li>p = (char *) s; </li></ul><ul><li>for (i=0; i<n; i++) </li></ul><ul><li> p[i] = c; </li></ul><ul><li>return s; </li></ul><ul><li>} </li></ul><ul><li>// memset(s0 + offset, c, n); </li></ul><ul><li>// memset2(s1 + offset, c, n); </li></ul><ul><li>// compare s0 e s1 byte a byte </li></ul>Como testar funções do math.h ?
  25. 25. Testes de estresse <ul><li>Testar com grandes quantidades de dados </li></ul><ul><ul><li>gerados automaticamente </li></ul></ul><ul><ul><li>erros comuns: </li></ul></ul><ul><ul><ul><li>overflow nos buffers de entrada, vetores e contadores </li></ul></ul></ul><ul><ul><li>Exemplo: ataques de segurança </li></ul></ul><ul><ul><ul><li>gets do C - não limita o tamanho da entrada </li></ul></ul></ul><ul><ul><ul><li>o scanf(``%s’’, str) também não... </li></ul></ul></ul><ul><ul><ul><li>Erro conhecido por “buffer overflow error” NYT98 </li></ul></ul></ul>
  26. 26. 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
  27. 27. Dicas para fazer testes <ul><li>Cheque os limites dos vetores </li></ul><ul><ul><li>caso a linguagem não faça isto por você </li></ul></ul><ul><ul><li>faça com que o tamanho dos vetores seja pequeno; ao invés de criar testes muito grandes </li></ul></ul><ul><li>Faça funções de hashing constantes </li></ul><ul><li>Crie versões de malloc que ocasionalmente falham </li></ul><ul><li>Desligue todos os testes antes de lançar a versão final </li></ul>
  28. 28. Dicas para fazer testes <ul><li>Inicialize os vetores e variáveis com um valor não nulo </li></ul><ul><ul><li>ex: 0xDEADBEEF pode ser facilmente encontrado </li></ul></ul><ul><li>Não continue a implementação de novas características se já foram encontrados erros </li></ul><ul><li>Teste em várias máquinas, compiladores e SOs </li></ul>
  29. 29. Tipos de teste <ul><li>“ white box” </li></ul><ul><ul><li>testes feitos por quem conhece (escreveu) o código </li></ul></ul><ul><li>“ black box” </li></ul><ul><ul><li>testes sem conhecer o código </li></ul></ul><ul><li>“ usuários” </li></ul><ul><ul><li>encontram novos erros pois usam o programa de formas que não foram previstas </li></ul></ul>
  30. 30. Teste de Software Orientado a Objetos <ul><li>Testes em geral (não apenas a la XP); </li></ul><ul><li>Diferenças em relação a teste de software tradicional? </li></ul><ul><ul><li>Podemos não conhecer a implementação de objetos que o nosso código usa; </li></ul></ul><ul><ul><li>a modularização e o encapsulamento ajudam a organização dos testes. </li></ul></ul>
  31. 31. Tipos de testes em software OO <ul><li>testes das classes </li></ul><ul><li>testes de interações </li></ul><ul><li>testes de regressão </li></ul><ul><li>teste do sistema e sub-sistemas </li></ul><ul><ul><li>Está conforme aos requisitos? </li></ul></ul><ul><li>teste de aceitação </li></ul><ul><ul><li>Posso usar a componente X? </li></ul></ul><ul><li>testes de implantação </li></ul>
  32. 32. Abordagem de McGregor/Sykes <ul><li>Lema: </li></ul><ul><ul><li>Teste cedo. Teste com freqüência. Teste o necessário </li></ul></ul><ul><li>Processo iterativo: </li></ul><ul><ul><li>analise um pouco </li></ul></ul><ul><ul><li>projete um pouco </li></ul></ul><ul><ul><li>escreva um pouco de código </li></ul></ul><ul><ul><li>teste o que puder </li></ul></ul>
  33. 33. Análise de Riscos 1/2 <ul><li>Análise de Riscos ajuda a planejar quais testes devem ser feitos </li></ul><ul><li>Um risco - ameaça ao sucesso de um projeto </li></ul><ul><ul><li>riscos do gerenciamento do projeto </li></ul></ul><ul><ul><ul><li>testes não ajudam muito </li></ul></ul></ul><ul><ul><li>riscos do negócio </li></ul></ul><ul><ul><ul><li>testes da funcionalidade </li></ul></ul></ul><ul><ul><li>riscos técnicos </li></ul></ul><ul><ul><ul><li>testes unitários, das classes, componentes, etc. </li></ul></ul></ul>
  34. 34. Análise de Riscos 2/2 <ul><li>Uma boa especificação de um projeto deve incluir uma análise dos riscos. </li></ul><ul><li>Esta análise pode levar ao plano e processo de testes </li></ul>
  35. 35. Dimensões do Processo de Testes 1/2 <ul><li>Quem cria os testes? </li></ul><ul><ul><li>Os desenvolvedores? uma equipe especializada em testes? ambos? </li></ul></ul><ul><li>Quais partes são testadas? </li></ul><ul><ul><li>Todas? Nenhuma? Ou só as de alto risco? </li></ul></ul><ul><li>Quando os testes serão realizados? </li></ul><ul><ul><li>Sempre? Rotineiramente? No final do projeto? </li></ul></ul>
  36. 36. Dimensões do Processo de Testes 2/2 <ul><li>Como será feito? </li></ul><ul><ul><li>Baseado no que o software faz ou em como o software faz? </li></ul></ul><ul><ul><li>Os testadores conhecem a implementação ou só a interface? </li></ul></ul><ul><li>Quanto de testes é o adequado? </li></ul>
  37. 37. Papéis no Processo de Testes <ul><li>Testador de classes </li></ul><ul><li>Testador da Integração </li></ul><ul><ul><li>testa as interações entre  objetos </li></ul></ul><ul><li>Testador do sistema </li></ul><ul><ul><li>conhece o domínio e é capaz de verificar a aplicação como um todo </li></ul></ul><ul><ul><li>ponto de vista do usuário do sistema </li></ul></ul><ul><li>Gerente do Processo de Testes </li></ul><ul><ul><li>coordena e escalona os testes e as pessoas </li></ul></ul>
  38. 38. Planejamento de Testes 1/2 <ul><li>Muitas vezes é esquecido ou não é considerado pelos gerentes de projeto </li></ul><ul><li>Atividades de planejamento: </li></ul><ul><ul><li>Escalonamento das Atividades de Testes </li></ul></ul><ul><ul><li>Estimativas de custo, tempo e pessoal necessário para realizar os testes </li></ul></ul><ul><ul><li>Equipamento necessário </li></ul></ul>
  39. 39. Planejamento de Testes 2/2 <ul><li>Atividades de planejamento: </li></ul><ul><ul><li>Definição do Nível de cobertura: quanto maior, mais código será exigido. </li></ul></ul><ul><ul><ul><li>Beizer: 2% a 80% do tamanho da aplicação. </li></ul></ul></ul><ul><ul><li>métricas para avaliar eficácia de um conjunto de testes </li></ul></ul><ul><ul><ul><li>cobertura do código </li></ul></ul></ul><ul><ul><ul><li>cobertura das pós-condições </li></ul></ul></ul><ul><ul><ul><li>cobertura dos elementos do modelo </li></ul></ul></ul>
  40. 40. Testes das Classes (unidades) <ul><li>Uma maneira é o peer-review </li></ul><ul><ul><li>Errar é humano </li></ul></ul><ul><li>Testes automatizados são melhores </li></ul><ul><ul><li>Difíceis de construir </li></ul></ul><ul><li>Testes automatizados devem cobrir </li></ul><ul><ul><li>alguns casos normais </li></ul></ul><ul><ul><li>o maior número possível de casos limítrofes </li></ul></ul>
  41. 41. Testes das Interações <ul><li>Objetos podem interagir de 4 formas diferentes: </li></ul><ul><ul><li>um objeto é passado como parâmetro para outro objeto numa chamada de método </li></ul></ul><ul><ul><li>um objeto devolve uma referência para outro objeto numa chamada de método </li></ul></ul><ul><ul><li>um método cria uma instância de outro objeto </li></ul></ul><ul><ul><li>um método usa uma instância global de outra classe (normalmente evitado) </li></ul></ul>
  42. 42. Casos: Teste das interações 1/2 <ul><li>Chamadas de métodos </li></ul><ul><li>2 abordagens: </li></ul><ul><ul><li>Programação defensiva </li></ul></ul><ul><ul><ul><li>O receptor verifica os parâmetros </li></ul></ul></ul><ul><ul><li>Programação por contrato </li></ul></ul><ul><ul><ul><li>A mensagem é verificada antes do envio </li></ul></ul></ul>
  43. 43. Casos: Teste das interações 2/2 <ul><li>Subclasses/superclasses </li></ul><ul><ul><li>Use o diagrama de classes para identificar quais testes de regressão devem ser realizados quando uma classe é alterada ou uma nova classe é criada. </li></ul></ul><ul><ul><li>Execute os testes escritos para a superclasse mas agora usando a nova subclasse </li></ul></ul><ul><ul><li>Para testar classes abstratas, somos obrigados a criar classes concretas só para testá-las </li></ul></ul>
  44. 44. Lembre-se <ul><li>Por que não escrever testes ? </li></ul><ul><ul><li>estou com pressa </li></ul></ul><ul><li>Quanto maior a pressão </li></ul><ul><ul><li>menos testes </li></ul></ul><ul><li>Com menos testes </li></ul><ul><ul><li>menos produtividade e menor estabilidade </li></ul></ul><ul><li>Logo, a pressão aumenta.... </li></ul>
  45. 45. O único conceito mais importante de testes é DO IT
  46. 46. Baseado em <ul><li>Baseado em: </li></ul><ul><ul><li>The Practice of Programming: Kernighan & Pie </li></ul></ul><ul><ul><li>A Practical Guide to Testing Object-Oriented Software . John McGregor & David Sykes </li></ul></ul><ul><ul><li>http://www.testing.com/ </li></ul></ul>

×