introdução a testes de software

http://www.takenami.com.br

Introdução a Testes de Software

Igor Takenami

Versão 1.0

[email protected]://twitter.com/itakenami

mailto:[email protected]

mailto:[email protected]

http://www.t

http://www.t


“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


Verificação & Validação (V&V)

Assegurar o funcionamento de acordo com o que foi especificado 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 as especificações preestabelecidas

Confirmar se a especificação é apropriado e consiste com os requisitos do Stakeholder

Estamos construindo certo o produto? Estamos construindo o produto certo?

Verifica problemas e defeitos nos componentes prontos

Avalia se a construção do componente segue 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

• Confiabilidade

- 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 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


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


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.


Classificação de defeitos adotado pela HP

• Origem: Onde?

• Tipo: O quê?

• Modo: Por quê?


Dúvidas ?

introdução a testes de software

Education