O documento fornece uma introdução sobre testes de software, discutindo princípios como verificação versus validação, técnicas estáticas e dinâmicas de teste, fatores psicológicos relacionados a testes, e a importância de planejamento e cobertura de casos de teste.

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. http://www.takenami.com.br
Classificação de defeitos adotado pela HP
• Origem: Onde?
• Tipo: O quê?
• Modo: Por quê?

20. http://www.takenami.com.br
Dúvidas ?