testes

Testes

 Uma vez que o código já está pronto, é preciso

assegurar que a aplicação esteja de acordo com as especificações definidas e que atenda às

necessidades dos clientes

 Para isso, é preciso utilizar dois processos

complementares

 _Validação  _{Verificação}

Verificação e Validação

(V & V)



Validação

 Tem o objetivo de garantir a adequação do

produto ao que foi pedido (requisitos funcionais e não-funcionais, expectativa do cliente)

Verificação e Validação

(V & V)



Verificação

 Tem o objetivo de garantir que a qualidade do

produto produzido esteja de acordo com os padrões definidos (Ex: taxa de erros)

Técnicas de V & V



Inspeções

 Analisam a documentação do projeto em busca de

erros

 Documento de requisitos, modelos, código-fonte

 Técnica estática

 Não requer a execução do sistema

 Devem ser realizadas ao longo de todo o

Técnicas de V & V



Testes de software

 O sistema é executado com dados de teste e as

saídas e o comportamento operacional são examinados

 Técnica dinâmica

 Requer a execução do sistema

 Podem ser realizados em protótipos e no

Tipos de Testes



Testes de defeitos



Procuram inconsistências entre o programa

e a especificação



Ex: erros lógicos, saídas inesperadas,

Tipos de Testes



Testes estatísticos



Usados para verificar o desempenho e a

confiabilidade do sistema



Ex: indicar quantas falhas são observadas

para um conjunto de dados de entrada do

usuário, observar o tempo de resposta para

cada usuário

V & V e Qualidade



O objetivo das técnicas de V & V não é

deixar o software inteiramente livre de

defeitos, mas suficientemente bom para

o uso pretendido

V & V e Qualidade



A qualidade esperada depende de alguns

fatores



Qual o propósito do sistema?

 Sistemas críticos (ex: aplicações de controle

de tráfego aéreo) devem ter taxas de erro mínimas

 Sistemas de informação e outros sistemas

não-críticos têm um nível de exigência menor e usuários mais tolerantes

V & V e Qualidade



Quanto tempo o cliente pode esperar?



Às vezes, é mais importante colocar logo o

produto no mercado para garantir uma

vantagem em relação à concorrência,

mesmo que a aplicação ainda apresente

algumas falhas

V & V e Qualidade



Quanto dinheiro o cliente deseja

investir?



Adotar técnicas de V & V no

desenvolvimento custa caro e a quantidade

de erros que poderão ser removidos

depende da qualidade que o cliente pode

pagar

V & V e Depuração



O objetivo das técnicas de V & V é detectar a

presença de erros na aplicação



O objetivo da depuração é localizar o erro

detectado e corrigi-lo

 O erro na rotina X era uma declaração inválida de

Como encontrar erros?



Certamente esta não é uma tarefa fácil, mas

há técnicas que podem ser usadas pelos

desenvolvedores

 Procurar erros comuns

 Acompanhar valores das variáveis durante a

execução

 Verificar mensagens de erro

 Executar o código parcialmente (colocar trechos

substituí-Cuidado!



Às vezes, corrigir um erro pode implicar em

introduzir outros erros!



É preciso realizar testes de regressão para evitar

esse problema

 Realizar novamente todos os testes feitos no código anterior para garantir que eles ainda funcionam. Isso pode ser bastante caro e demorado!

 O que se pode fazer é executar apenas os testes relacionados ao trecho modificado e aos trechos dependentes dele

Planejamento de V & V



V & V é uma atividade bastante cara e

demorada no desenvolvimento



Por isso, é importante planejá-la bem para

obter o melhor das inspeções e testes e para

controlar os custos

Como testar um software?



Os testes podem ser divididos em duas

grandes etapas

 Testes de componentes

 Os próprios desenvolvedores testam seu código

isoladamente para assegurar que ele não apresente erros

 Testes de integração

 Uma equipe de testes integra os componentes

produzidos para formar um subsistema ou o sistema completo e remove os erros restantes

Testes para detecção de defeitos

 O objetivo é expor os defeitos do sistema antes que

ele seja entregue ao cliente

 Isso é feito simulando-se uma operação incorreta do

sistema e observando os resultados obtidos

 Ex: ver o que acontece quando um dado inválido é

Etapas para detecção de defeitos

 Projetar casos de teste

 _{Definir o que será testado, as entradas para o sistema e as}

saídas esperadas

 Preparar dados de teste

 _{Alimentarão o sistema; podem ser gerados}

automaticamente

 Executar programa com os dados de teste  Comparar resultados com os casos de teste

Testes de caixa preta

 Os testes são escritos com base apenas na

especificação do componente

 O componente funciona como uma caixa preta: apenas

recebe entradas e processa saídas, mas seu funcionamento interno não é considerado

 _{São também conhecidos como testes funcionais, pois}

apenas verificam se as funções previstas são realizadas com sucesso

Partições de equivalência

 Testar um programa para todos os dados de entrada

existentes é uma tarefa inviável

 Entretanto, é possível identificar diferentes valores

de dados de entrada que devam ser processados de maneira semelhante

 Ou seja, definir partições de equivalência, de modo que

qualquer valor daquela partição pode ser escolhido para representá-la em um teste

Partições de equivalência

 Exemplos de partições: suponha um programa para

imprimir se um determinado número lido é positivo ou negativo

 Números maiores que zero, números menores que zero,

zero

 _{Dados válidos (números) e inválidos (texto)}

 Identificadas as partições, é possível escolher casos

Testes de estrutura

 Também chamados de testes de caixa branca

 _{Os testes são definidos a partir da estrutura e da}

implementação do componente

 Os desenvolvedores analisam o código para descobrir

quantos casos de teste serão necessários para garantir que todos os trechos sejam executados pelo menos uma vez

 _{É preciso escolher os dados de entrada a partir das}

Testes de caminho

 Tipo de teste de estrutura que analisa as diferentes

possibilidades de execução de um componente em relação a suas estruturas de controle

 Comandos condicionais: expressão verdadeira, expressão

falsa

 _{Comandos de repetição: nenhuma repetição, uma única}

repetição, n repetições

Testes de caminho

 Não é possível testar todas as combinações possíveis

de caminhos

 Mesmo em componentes pequenos, há muitas

possibilidades

 A definição dos casos de teste é feita com base num

grafo de fluxo do programa

 _{Percepção dos caminhos}

 _{Os ramos verdadeiros e falsos de todas as condições têm}

Testes de integração

 Após os testes individuais de cada componente, é

preciso integrar as partes para observar o comportamento do sistema completo

 A principal dificuldade desses testes é localizar os

defeitos detectados

 Como saber, no meio de tantas interações entre os

componentes, qual delas causou o erro?

Testes de estresse

 Mais que garantir que o sistema executa suas

funções de maneira correta, é preciso verificar requisitos não-funcionais importantes, como desempenho e confiabilidade

 _{Qual a capacidade máxima de processamento do sistema}

com um desempenho satisfatório?

 Testes de estresse extrapolam os limites definidos

para o sistema para observar como ele se comporta em caso de falha

Testes de estresse

 Testes de estresse podem revelar defeitos que

normalmente não se manifestariam

 São bastante úteis para sistemas distribuídos que

utilizam uma rede de processadores

 Desempenho tende a cair à medida que a carga exigida do

sistema aumenta

 _{Podem ser tomadas medidas para evitar o colapso do}