Introdução a Testes de Software

http://www.takenami.com.br

Introdução a Testes de
Software
Igor Takenami

itakenami@gmail.com
http://twitter.com/itakenami

Versão 1.0


“Sempre existe defeito em um SW mas com o
passar do tempo os problemas ﬁcam mais
difíceis de serem detectados”

“Os testes podem mostrar a presença de erro
mas não a sua ausência”
Dijkstra


Veriﬁcação & Validação (V&V)

Assegurar o funcionamento de acordo com o
que foi especiﬁcado e atenda aos requisitos dos
stakeholders


Onde aplicamos V&V
• Revisão dos requisitos
• Revisões da análise e do projeto
• Inspeções de Código
• Testes


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


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.


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.


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


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


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
• Conﬁabilidade
- Probabilidade de operar sem apresentar falhas


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


Plano de Teste
• Propõe um planejamento com um padrão a ser
seguido.
• Padrão para Plano de Teste: IEEE 829-1998


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)


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”


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}


Análise de Mutantes
• Gerar versões com defeitos e veriﬁcar se os
casos de teste são capazes de distinguir tais
programas
• Versões defeituosas são chamados mutantes
• São feitos por modiﬁcações aleatórias
- Substituição de sinal e retirada de uma linha


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 é
deﬁnido 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 especiﬁcações


Classiﬁcaçã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 classiﬁcaçã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.


Classiﬁcação de defeitos adotado pela HP
• Origem: Onde?
• Tipo: O quê?
• Modo: Por quê?


Dúvidas ?

Introdução a Testes de Software

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a Introdução a Testes de Software

Semelhante a Introdução a Testes de Software (20)

Último

Último (20)

Introdução a Testes de Software