Tcnicas de Teste de Software

Pressman

Teste de Software
a atividade de teste o processo de executar um programa com a inteno de descobrir um erro um bom caso de teste aquele que tem uma elevada probabilidade de revelar um erro ainda no descoberto um teste bem-sucedido aquele que revela um erro ainda no descoberto.

Teste de Software
Se realmente fossemos bons para programar no haveriam bugs. Se existem bugs, porque somos ruins naquilo que fazemos, e , se somos ruins nisso devemos sentir-nos culpados por isso. Assim, a atividade de teste e o projeto de casos de teste so uma admisso de falha, o que promove uma boa dose de culpa. O tdio de testar apenas uma punio por nossos erros.

Objetivos da Atividade de Teste de Software

O objetivo central deve ser o de maximizar a cobertura dos testes. Detectar a maior quantidade de erros possvel de defeitos que no foram apanhados pelas revises dentro de dados limites de custos e prazos. y Se a atividade de teste for conduzida com sucesso, ela descobrir erros no software. y A atividade de teste no pode mostrar a ausncia de bugs; ela s pode mostrar se defeitos de software esto presentes.

Projeto de Casos de Teste

Mtodos de Projeto de Casos de Teste oferecem uma abordagem sistemtica ao teste.

oferecem um mecanismo que ajuda a garantir

a integridade do teste e proporciona a mais alta probabilidade de revelar erros de software

Abordagens de Teste
para ser eficaz o teste deve ser cuidadosamente desenhado testes irreproduzveis ou improvisados devem ser evitados resultados devem ser inspecionados e comparados com os resultados esperados desenvolvedores no so as pessoas mais indicadas para testar seu prprio produto testadores independentes so importantes

Abordagens de Teste
testes so indicadores de qualidade do produto mais do que meios de deteco e correo de erros quanto maior o nmero de defeitos detectados maior o nmero de defeitos no detectados a ocorrncia de um nmero anormal de defeitos em uma bateria de testes indica uma provvel necessidade de redesenho dos itens testados

Abordagens de Teste

Teste de Caixa Preta (Black Box) Teste da Caixa Branca (White Box)

Abordagens de Teste
Teste de Caixa Preta: determina se os requisitos foram total ou parcialmente satisfeitos pelo produto
verifica apenas os resultados produzidos, no verifica como ocorre o processamento. demonstram que as funes dos softwares so operacionais, que a entrada adequadamente aceita e a sada corretamente produzida;

Abordagens de Teste
Teste de Caixa Branca: determina defeitos da estrutura interna do programa, atravs de testes que exercitem suficientemente os possveis caminhos de execuo.
So testados os caminhos lgicos atravs do software, fornecendo-se casos de teste que pem prova conjuntos especficos de condies e/ou laos.

Aproximadamente 1014 caminhos a serem executados

Lao <= 20

Teste de Caixa Branca

Podem ser derivados casos de teste que: garantam que todos os caminhos independentes dentro de um mdulo tenham sido exercitados pelo menos uma vez. exercitem todas as decises lgicas para valores falsos ou verdadeiros. executem todos os laos em suas fronteiras e dentro de seus limites operacionais. exercitem as estruturas de dados internas para garantir a sua validade.

Caixa Branca - Teste de Caminho Bsico

O mtodo de caminho bsico possibilita que o projetista do caso de teste derive uma medida de complexidade lgica de um projeto procedimental e use essa medida como guia para definir um conjunto bsico de caminhos de execuo. l

Caixa Branca - Teste de Caminho Bsico

GRAFO DE PROGRAMA: uma notao para representar o fluxo de controle. Cada construo estruturada tem um smbolo de grafo correspondente.

Cada instruo representa uma ou mais instrues sem ramificaes

1 2 3 6 7 9 4 5 10

11

GRAFO DE PROGRAMA
Cada crculo denominado n representa uma ou mais instrues procedimentais os arcos de fluxo so denominados ramos um ramo deve terminar em um n as reas delimitadas pelos ramos e ns so chamadas de regies ns predicativos so os que contm uma condio

Complexidade Ciclomtica
uma mtrica de software que proporciona uma medida quantitativa da complexidade lgica de um programa.
Usado no contexto do mtodo de teste de caminho bsico, o valor computado da complexidade ciclomtica define o nmero de caminhos independentes do conjunto bsico de um programa

Caminho Independente: Qualquer caminho atravs do programa que introduza pelo menos um novo conjunto de instrues de processamento ou uma nova condio.

Complexidade Ciclomtica Caminhos Independentes

Caminho 1: 1-11 Caminho 2: 1-2-3-4-5-10-1-11 Caminho 3: 1-2-3-6-8-9-10-1-11 Caminho 4: 1-2-3-6-7-9-10-1-11

Como vamos saber o nmero de caminhos possveis?

Complexidade Ciclomtica
oferece um limite mximo para o nmero de testes que deve ser realizado para garantir que todas as instrues sejam executadas pelo menos uma vez.
computada numa das 3 formas seguintes: 1. o nmero de regies do grfico de fluxo 2. V(G) = E-N+2, onde E o nmero de ramos do grafo e N
o nmero de ns do grafo de fluxo G

3. V(G) = P+1, onde P o nmero de ns predicativos (ns

que contm uma condio) contidos no grafo de fluxo G

Complexidade Ciclomtica
1) o grfico de fluxo tem 4 regies 2) V(G)=E-N+2 V(G)= 11 ramos - 9 ns + 2 = 4 3) V(G) = 3 ns predicativos + 1= 4 So preparados casos de teste que forcem a execuo de cada caminho observando valores a serem testados e resultados esperados

Exerccio
.Usando o projeto ou o cdigo como base trace um grafo de fluxo correspondente. .Determine a complexidade ciclomtica do grafo de fluxo resultante. .Determine um conjunto bsico de caminhos linearmente independentes. .Prepare os casos de teste que forcem a execuo de cada caminhos no conjunto bsico.

Teste da Caixa Preta

Concentram-se nos requisitos funcionais do software. O teste de caixa preta procura descobrir erros nas seguintes categorias: 1) funes incorretas ou ausentes 2) erros de interface 3) erros nas estruturas de dados ou no acesso a bancos de dados externos 4) erros de desempenho 5) erros de inicializao e trmino

Anlise do Valor Limite

A anlise do valor limite leva a escolha de casos de teste que pem a prova os valores fronteirios. Casos de teste para entradas vlidas:
intervalo delimitado pelos valores a e b - os casos de teste devem ser projetados com os valores imediatamente acima e logo abaixo de a e b. srie de valores - os casos de teste que ponham a prova valores mximos, mnimos, logo acima e abaixo devem ser testados

Anlise do Valor Limite

Casos de teste para entradas vlidas:
aplique as diretrizes 1 e 2 s condies de sada. Ex:
supondo que uma tabela de temperatura X presso seja exigida em uma sada de um programa de anlise, casos de teste devem ser criados para criar um relatrio que produza nmeros mximos e mnimos

se as estruturas de dados do programa tiverem prescrito fronteiras (vetor de 100 entradas), certifique-se de projetar um caso de teste para a estrutura de dados em sua fronteira

Particionamento de Equivalncia
Divide o domnio de entrada de um programa em classes de dados a partir das quais os casos de teste podem ser derivados.
Procura deduzir uma classe de erros evitando um nmero maior de testes Em um programa de gesto de pessoal a idade do funcionrio varia de 15 a 80. A classe de equivalncia so todos os valores inteiros menores do que 15, valores inteiros entre 15 e 80, inclusive, e valores inteiros maiores do que 80. Para cada uma dessas classes qualquer valor tem potencialmente a mesma capacidade de encontrar erros sendo dispensvel a execuo de vrios teses para valores pertencentes a mesma classe.

Desenho de classes de equivalncia

Intervalo vlido - uma vlida para os valores pertencentes ao intervalo, duas invlidas para os valores maiores e menores que o limite inferior e superior Lista de valores vlidos - uma vlida para os valores includos na lista, uma invlida para todos os outros valores Valor especfico - uma vlida que inclui o valor, duas invlidas para valores maiores e menores Lgica - uma vlida e uma invlida

Testes de Comparao
Quando necessrio comparar as sadas de diferentes verses de um sistema. Estes testes se aplicam quando:

i uso de sistemas redundantes para aplicaes crticas

como controle de aeronaves; i comparao de resultados para produtos em evoluo.

Testes de Sistema de Tempo Real

1. Testes de Tarefas - cada tarefa em um software de
tempo real deve ser testada independentemente. Teste de caixa preta e branca devem ser projetados e executados para cada tarefa (revela erros de funo).

2. Teste Comportamental- os eventos so categorizados

para o teste, cada um dos eventos testado individualmente o comportamento do sistema executvel examinado para detectar erros conseqentes dos processamentos associados aos eventos. Quando todas as classes de eventos tiverem sido testadas, os evento sero apresentados de forma aleatria e com freqncia aleatria, detectando erros de comportamento. Posso fazer isto usando ferramentas de
simulao, simulando o comportamento de sistemas em tempo real e verificando como ele responde a eventos externos.

Testes de Sistema de Tempo Real

3. Teste Inter-tarefas detectam erros de sincronizao
de tarefas. Tarefas assncronas que comunicam-se entre si so testadas com diferentes taxas de dados e dados e cargas de processamento para determinar se ocorrero erros de sincronizao inter-tarefas.

4. Teste do Sistema - o software e o hardware so

integrados e uma variedade completa de testes de sistema levado a feito numa tentativa de descobrir erros na interface software/hardware.