Introdução a Testes de Software

1,944 views

Published on

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,944
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
124
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Introdução a Testes de Software

  1. 1. http://www.takenami.com.br Introdução a Testes de Software Igor Takenami itakenami@gmail.com http://twitter.com/itakenami Versão 1.0
  2. 2. http://www.takenami.com.br “Sempre existe defeito em um SW mas com o passar do tempo os problemas ficam mais difíceis de serem detectados” “Os testes podem mostrar a presença de erro mas não a sua ausência” Dijkstra
  3. 3. http://www.takenami.com.br Verificação & Validação (V&V) Assegurar o funcionamento de acordo com o que foi especificado e atenda aos requisitos dos stakeholders
  4. 4. http://www.takenami.com.br Onde aplicamos V&V • Revisão dos requisitos • Revisões da análise e do projeto • Inspeções de Código • Testes
  5. 5. http://www.takenami.com.br Verificação • Averiguar se o software está de acordo com as especificações preestabelecidas • Estamos construindo certo o produto? • verifica problemas e defeitos nos componentes prontos
  6. 6. http://www.takenami.com.br Validação • Confirmar se a especificação é apropriado e consiste com os requisitos do Stakeholder • Estamos construindo o produto certo? • Avalia se a construção do componente segue os requisitos predefinidos.
  7. 7. http://www.takenami.com.br Verificação Validação Averiguar se o software está de acordo com Confirmar se a especificação é apropriado e as especificações preestabelecidas consiste com os requisitos do Stakeholder Estamos construindo certo o produto? Estamos construindo o produto certo? Verifica problemas e defeitos nos Avalia se a construção do componente segue componentes prontos os requisitos predefinidos.
  8. 8. http://www.takenami.com.br Técnica de V&V • Estática - Não envolve a execução do produto - Revisões a) Revisão de código b) Revisão em par • Dinâmica - Testes a) Caixa Branca e Preta b) Estresse c) Integração d) Aceitação
  9. 9. http://www.takenami.com.br Princípios de Teste de Software • Quando Planejado (sistêmica e rigorosa) = Confiabilidade e Qualidade do SW • Tempo X Custo X Quantidade de Defeitos • Devem ser planejados (Tempo, Ferramentas e Pessoas) • Teste Primeiros no XP: Identifica o que será testado (Entradas e Saídas), auxilia na codificação
  10. 10. http://www.takenami.com.br Princípios de Teste de Software • Pareto - 80% dos resultados estão estão relacionados a 20% de nossos esforços - Joseph Juran (20% dos componentes de um software concentram 80% dos defeitos) - Concentrar seus esforços no pronto mais frágil do sistema • Confiabilidade - Probabilidade de operar sem apresentar falhas
  11. 11. http://www.takenami.com.br Casos de Testes • Possibilidade de casos de teste podem ser astronômicas - int qualquer(char b) = 256 combinações possíveis - Se [int qualquer(char b, int i)] sendo i um inteiro de 32bis: 28 x 232 - Mais de um trilhão de possibilidades - Com 1 milhão de combinações por segundo seriam necessários 12 dias para testar tudo • Cobertura: Maior numero de possibilidades para execução de um casos de teste
  12. 12. http://www.takenami.com.br Plano de Teste • Propõe um planejamento com um padrão a ser seguido. • Padrão para Plano de Teste: IEEE 829-1998
  13. 13. http://www.takenami.com.br Fatores Psicológicos • “O autor não possui nenhuma motivação psicológica para inventar casos de teste que demonstrem que o seu produto está com falhas ou errado” (Yourdon,1989) • “O código é o resultado do trabalho intelectual do programador, procurar erros é uma especie de ataque a suas próprias convicções” (Weinberg,1971)
  14. 14. http://www.takenami.com.br Dissonância Cognitiva • Resistência a cumprir a tarefa • Os testes são sempre feitos com valores óbvios enquanto deveriam ser testados com situações “impossíveis”
  15. 15. http://www.takenami.com.br Cobertura • Cobrir o maior numero possíveis de possibilidades - if (a==b) e if (a>=b) - Testar {a=1;b=2} Estaria certo para os 2 casos. - O correto seria {a=2;b=1}
  16. 16. http://www.takenami.com.br Análise de Mutantes • Gerar versões com defeitos e verificar se os casos de teste são capazes de distinguir tais programas • Versões defeituosas são chamados mutantes • São feitos por modificações aleatórias - Substituição de sinal e retirada de uma linha
  17. 17. http://www.takenami.com.br Sendo P um programa e T casos de teste • Execução de P para cada T • Geração de mutantes M • Execução do Mutantes (Separar mutante morto). Para os que não são mortos → Os casos de teste T não distinguem entre P e M ou P e M são equivalentes • Calculo do Escore de mutação: N motos / N – N equivalentes • Análise dos mutantes: se estiver próximo de 1 (quão próximo é definido pelo avaliador) , então se considera T um bom conjunto de testes para P • A análise de mutantes clássica é inviável pois tem alto custo computacional. Uma técnica é criar mutações de requisitos e testar as especificações
  18. 18. http://www.takenami.com.br Classificação de Defeitos • Conhecer os defeitos para tratar com a técnica correta - Uso de dados históricos quantitativos (CMMI nível 4) - Prevenção de defeitos (CMMI nível 5) • Técnica para classificação de defeito: (Defect Prevenction Process) da IBM: - Analise causal (sistemática); - Equipe de ação; - Reuniões de partida; - Ferramentas e base de dados para registro de informação - Redução em média de 50% dos defeitos.
  19. 19. http://www.takenami.com.br Classificação de defeitos adotado pela HP • Origem: Onde? • Tipo: O quê? • Modo: Por quê?
  20. 20. http://www.takenami.com.br Dúvidas ?

×