Teste de Software RESUMO

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

Testes Essenciais 1
UERJ – CTC/IME – Engenharia de Software 09-1 © Prof. A Padua Oliveira
Tópicos:
1. Introdução
2. Método Funcional (Método da CAIXA PRETA)
3. Método Estrutural (Método da CAIXA BRANCA)
4. Exercícios propostos
TESTES DE SOFTWARE
UERJ – CTC/IME – Engenharia de Software 09-1 © Prof. A Padua Oliveira
2/40
1. Introdução
1.1 Definições
1.2 Psicologia e Economia em Testes de Programas
1.3 Considerações usadas durante a fase de testes
1.4 Abordagens para projetos de casos de testes
2. Método Funcional (Método da CAIXA PRETA)
2.1 Análise de participações de equivalência
2.2 Análise de valores limites
2.3 Análise por gráficos de causa-efeito
2.4 Análise por conjeturas do erro
3. Método Estrutural (Método da CAIXA BRANCA)
3.1 Testes de cobertura de instruções
3.2 Testes de cobertura de loops
3.3 Testes de cobertura de caminhos
4. Exercícios propostos
Tópicos TESTES DE SOFTWARE
Testes Essenciais 2
UERJ – CTC/IME – Engenharia de Software 09-1 © Prof. A Padua Oliveira
3/40
DEFINIÇÕES:
TESTAR SOFTWARE:
Processo de executar um programa 
com a finalidade de encontrar erros;
ERRO: item de informação ou estado de funcionamento 
defeituoso ou inconsistente com as especificações;
DEFEITO: deficiência de implementação que, se ativada, 
pode provocar uma falha no sistema;
FALHA: evento em que o sistema viola as especificações ou 
os requisitos originais.
DEFEITOERRO FALHA
1. Introdução TESTES DE SOFTWARE
UERJ – CTC/IME – Engenharia de Software 09-1 © Prof. A Padua Oliveira
4/40
1. As falhas aparecem durante o uso do sistema.
2. A maior parte dos defeitos é de origem humana. 
3. Quanto mais cedo os defeitos forem 
encontrados maior a chance do acerto e menor o 
custo da correção. 
4. A melhor estratégia é a prevenção:
Verificações: a equipe de desenvolvimento deve revisar 
cada artefato produzido;
Validações: os clientes podem participar da aceitação dos 
artefatos produzidos;
Testes: é um mecanismo eficaz para a prevenção de 
defeitos.
Constatações 1:
1. Introdução TESTES DE SOFTWARE
Testes Essenciais 3
UERJ – CTC/IME – Engenharia de Software 09-1 © Prof. A Padua Oliveira
5/40
1. As falhas do sistema afetam a confiabilidade.
2. A maior parte dos defeitos são encontradas em 
situações pouco executados.
3. Existem 10 defeitos por 1.000 linhas de código.
4. Uma ferramenta automatizada torna mais 
eficiente o processo de testar software.
5. Sitio de ferramentas:
http://www.sqa-test.Com/toolpage.html.
Constatações 2:
1. Introdução TESTES DE SOFTWARE
UERJ – CTC/IME – Engenharia de Software 09-1 © Prof. A Padua Oliveira
6/40
Custo de 
alterações:
B. Bohem:
1987: 100x
2001: 5x
1. Introdução TESTES DE SOFTWARE
Testes Essenciais 4
UERJ – CTC/IME – Engenharia de Software 09-1 © Prof. A Padua Oliveira
7/40
O Processo:
Testar Software
“fluxo de trabalho”
Avaliação
Depuração
Planejamento
Preparação
Analista Testador
Execução
Programador
[ OK ]
SIM
NÃO
1. Introdução TESTES DE SOFTWARE
UERJ – CTC/IME – Engenharia de Software 09-1 © Prof. A Padua Oliveira
8/40
� Testar:
Objetivos errados ou incompletos:
"Testar é o processo que leva a se confiar que um programa 
faz o que se supõe que deva fazer”.
"Testar é demonstrar que não existem erros no programa”.
"A finalidade é mostrar que o programa realiza 
corretamente as funções esperadas“.
� "Depurar é o processo de corrigir os erros encontrados."
1. Introdução TESTES DE SOFTWARE
Testes Essenciais 5
UERJ – CTC/IME – Engenharia de Software 09-1 © Prof. A Padua Oliveira
9/40
Princípios gerais dos testes
Um bom caso de teste é aquele que tem uma chance elevada de 
encontrar um erro ainda não descoberto.
Um caso de teste com êxito é aquele que descobre um erro novo.
A economia dos testes
Teste exaustivo: - uso de todas as possíveis situações de teste.
O teste exaustivo é impraticável devido ao custo e ao tempo para 
sua realização.
Projetos típicos consomem até 50% do tempo de desenvolvimento do 
software, nas tarefas de testar e depurar.
Motivo: Falta de um plano de testes.
1. Introdução TESTES DE SOFTWARE
UERJ – CTC/IME – Engenharia de Software 09-1 © Prof. A Padua Oliveira
10/40
1. Introdução
Considerações usadas durante a fase de testes
1) A definição do resultado esperado é uma parte integrante e 
necessária.
2) Para se evitar erros de interpretação, o programador deve 
evitar testar seu próprio programa (mas deve corrigir os erros 
encontrados).
� A busca de falhas na própria tarefa parece estar contra a 
psicologia humana.
3) Deve-se inspecionar cuidadosamente o resultado de cada teste. 
A experiência mostra que em cada caso de teste com problema 
ficam muitos sintomas de erros ainda por descobrir.
4) Os casos de teste devem ser escritos tanto para as condições de 
entrada inválidas e inesperadas como para as condições válidas e 
esperadas.
5) O teste deve investigar se o programa faz o que se supõe que 
faça e se também faz o que não tem que fazer.
TESTES DE SOFTWARE
Testes Essenciais 6
UERJ – CTC/IME – Engenharia de Software 09-1 © Prof. A Padua Oliveira
11/40
Considerações usadas durante a fase de testes
6) Os casos de teste devem ser documentados com todos os dados 
previamente preparados para sua realização. 
7) Não planejar um caso de teste com a suposição de que não serão 
encontrados erros. 
8) A probabilidade de se encontrar erros adicionais em um trecho 
do programa é proporcional ao número de erros já encontrados 
no mesmo trecho. 
9) Os casos de teste planejados e não executados devem ser 
justificados. 
10) O teste é uma tarefa altamente criativa, é um desafio 
intelectual. 
• A criatividade requerida para testar programas grandes 
pode superar a criatividade necessária de implementação.
Não altere o programa durante os testes.
1. Introdução TESTES DE SOFTWARE
UERJ – CTC/IME – Engenharia de Software 09-1 © Prof. A Padua Oliveira
12/40
Objetivo: selecionar um conjunto mínimo de casos de teste.
A. Método Funcional (Teste Caixa Preta)
Características:
O elaborador da massa de testes não considera os detalhes de
implementação da estrutura interna do módulo ou programa.
Se baseia em encontrar circunstâncias nas quais o programa não se
comporta de acordo com suas especificações ou requisitos.
Deseja encontrar os erros testando, de forma sistemática e organizada,
o comportamento do software, através dos seus dados de entrada.
B. Técnica Estrutural (Teste Caixa Branca) 
Características:
O elaborador da massa de testes não considera a especificação do
programa. Baseia-se apenas na estrutura interna da implementação, ou
seja, nos algoritmos e nas estruturas de dados, para encontrar situações
de erro.
Deseja-se encontrar os erros em um programa testando a execução da 
lógica de suas linhas de código. No teste, faz-se que cada linha de código 
seja executada pelo menos uma vez.
C. Teste Caixa Cinza (Técnica funcional e estrutural)
• Abordagem que combina os dois métodos anteriores. 
2. Métodos Abordagens para projetos de casos de testes
Testes Essenciais 7
UERJ – CTC/IME – Engenharia de Software 09-1 © Prof. A Padua Oliveira
13/40
Possui as seguintes as técnicas:
a) Participações de equivalência
b) Análise de valores limites
c) Gráficos de causa-efeito
d) Conjecturas do erro. 
a) Análise das participações de equivalência
1º Passo: Identificar as classes de equivalência (válidas e inválidas)
para as entradas e para as saídas.
Método Funcional (Teste Caixa Preta)
Entrada Classes sugeridas 
um intervalo
ex.: inteiros [1,5]
uma classe válida e duas inválidas
] - ∞ ; 0 ] , [ 1; 5] , [ 6; + ∞ [ 
um valor uma classe válida e duas inválidas
valor abaixo, o
próprio, valor acima 
elemento de um conjunto uma classe válida e uma inválida
uma condição lógica uma classe válida e uma inválida
2.1a Partições
UERJ – CTC/IME – Engenharia de Software 09-1 © Prof. A Padua Oliveira
14/40
Recomendações:
• As entradas com classes complexas devem ser
desmembradas em classes mais simples, fazendo-se
depois a combinação entre os casos mais simples
elaborados.
• Prever casos de saída e de processamento anormal.
• Criar casos de teste para valores muito grandes
(overflow), e para valores muito pequenos (underflow).
• Simular casos de divisão por zero, e de valores
indeterminados como: tan (90), log 0.
• Prever casos para valores especiais de estruturas de
dados, tais como: vetor nulo, matriz unitária, fila ou pilha
vazia, etc.
Método Funcional (Teste Caixa Preta)2.1a Partições
Testes Essenciais 8
UERJ – CTC/IME – Engenharia de Software 09-1 © Prof. A Padua Oliveira
15/40
a) Análise das participações de equivalência
2º Passo: Definir os casos de teste, a partir das classes de
equivalência identificadas.
1) Numerar as classes de equivalência;
2) Estabelecer os casos de teste para a cobertura das
classes válidas;
- cada caso de teste deve cobrir o maior número
possível de classes válidas;
3) Estabelecer os casos de teste para a cobertura das
classes inválidas;
- cada caso de teste deve cobrir uma e somente uma
das classes inválidas ainda não cobertas.
Método Funcional (Teste Caixa Preta)2.1a Partições
UERJ – CTC/IME – Engenharia de Software 09-1 © Prof. A Padua Oliveira
16/40
2.1b Limites Método Funcional (Teste Caixa Preta)
b) Análise de valores limites
A técnica da análise de valores limites seleciona os casos de
teste que valorizam as condições de contorno das classes de
equivalência.
• selecionar as situações limites de cada partição de 
equivalência;
• explorar as situações limites de entrada como também as 
situações limites de saída.
Fato: "Um número maior de erros tende a aparecer nos 
limites, ou contornos, das classes de equivalência do 
módulo testado.“
------------------------------------------------------------
Sugestões de casos de teste: intervalo de datas: [ a, b [ 
� imediatamente abaixo de a;
� valor de a;
� imediatamente acima de a;
� imediatamente abaixo de b;
� valor de b;
� imediatamente acima de b;
Testes Essenciais 9
UERJ – CTC/IME – Engenharia de Software 09-1 © Prof. A Padua Oliveira
17/40
2.1c Causa-efeito Método Funcional (Teste Caixa Preta)
c) Análise de causa-efeito
A técnica de análise de causa e efeito, recomenda a
representação das condições de entrada e as ações
correspondentes através de “grafos”. A posterior identificação
dos casos de teste é feita com o uso de uma tabela de decisão.
São os seguintes os passos recomendados:
1. Identificar as condições de entrada e as partições de 
equivalência; 
2. Identificar as ações correspondentes provenientes das 
condições de entrada identificadas;
3. Construir o grafo de causa e efeito ou uma tabela de 
decisão para as associações das condições e ações; 
4. Elaborar os casos de teste. 
UERJ – CTC/IME – Engenharia de Software 09-1 © Prof. A Padua Oliveira
18/40
2.1d Conjecturas
d) Análise por conjecturas de erro 
A "técnica" se baseia na intuição (suposição sem fundamento
preciso) ou na experiência do “testador”. Ele deve elaborar uma
relação de casos de teste para prováveis erros, os quais ele
supõe que possam ocorrer.
• Deve ser visto como um recurso complementar e não
como uma técnica.
Exemplos:
teste de um módulo para atualização de um arquivo;
- inclusão do primeiro registro;
- exclusão de todos os registros;
teste de interrupção do programa em pontos escolhidos.
- falta de energia;
- falta de comunicação;
Método Funcional (Teste Caixa Preta)
Testes Essenciais 10
UERJ – CTC/IME – Engenharia de Software 09-1 © Prof. A Padua Oliveira
19/40
3.2 Caixa Branca Método Estrutural (Teste Caixa Branca)
Os casos de teste, neste método, são escolhidos de modo que:
• todas as decisões sejam executadas;
• todos os "loops" sejam executados, nos seus limites
de especificação;
• todos os caminhos sejam considerados;
• todas as estruturas de dados sejam utilizadas.
Motivação:
Os erros de software ocorrem com mais freqüência nos
casos especiais, normalmente nos casos eventuais e pouco
executados.
UERJ – CTC/IME – Engenharia de Software 09-1 © Prof. A Padua Oliveira
20/40
São três as principais abordagens técnicas :
a) Testes de cobertura de instruções.
b) Testes de cobertura de loops.
c) Testes de cobertura de caminhos.
a) Testes de cobertura de instruções.
Técnica elementar para determinação geral de casos de teste.
Examina o comportamento de um módulo através do teste
isolado de cada linha de código sob o efeito das operações
elementares de "seleção ou repetição (loop)", não considerando
os testes da operação completa com estes componentes.
3.2a Instruções Método Estrutural (Teste Caixa Branca)
Testes Essenciais 11
UERJ – CTC/IME – Engenharia de Software 09-1 © Prof. A Padua Oliveira
21/40
3.2a Instruções
X = 1
X = X+10 X = X+20
a
a
Y < 10
Y = Y+1
X = X+30
VF
V
F
Possibilidades:
1) X falso X = 5
2) X verdadeiro X = 1
3) Y verdadeiro Y = 9
4) Y falso Y = 20
Obs.: Devido a combinações impróprias de hipóteses, a técnica pode sugerir 
casos de teste para situações impossíveis de ocorrer. Estes casos não devem 
ser selecionados. A utilização do "bom senso" recusa a seleção destes casos.
Exemplo de testes de cobertura de instruções
UERJ – CTC/IME – Engenharia de Software 09-1 © Prof. A Padua Oliveira
22/40
b) Testes de cobertura de loops
Técnica para determinação de casos de teste para
repetições/loops. Examina o comportamento de um módulo
através de testes sob o efeito da associação combinada, ou não,
das operações de "repetição (loop)".
Tipos de loops:
i) Simples ii) Aninhados iii)Seqüenciais
Método Estrutural (Teste Caixa Branca)3.2b Loops
Testes Essenciais 12
UERJ – CTC/IME – Engenharia de Software 09-1 © Prof. A Padua Oliveira
23/40
iv) Loops não estruturados
Devem ser convertidos em loops estruturados.
A técnica:
Loops simples: ( número máximo de iterações = n )
1) não executar o loop
2) apenas uma execução
3) duas execuções
4) m execuções (m < n)
5) execuções para as situações: n - 1; n; n +1;
total de casos de teste: 6 + 1 (não executar)
Obs.: Esta técnica usa o artifício de indução matemática
para produzir os casos de teste.
Método Estrutural (Teste Caixa Branca)3.2b Loops
UERJ – CTC/IME – Engenharia de Software 09-1 © Prof. A Padua Oliveira
24/40
Loops aninhados:
Estratégia sugerida:
i. Iniciar pelo laço (loop) mais interno e operar os
demais loops com os valores mínimos;
ii. Elaborar os casos de teste de loop simples;
iii. Trabalhar sucessivamente do loop mais interno para
o loop externo seguinte;
Loops seqüenciais:
Estratégia sugerida:
i. Quando os loops são independentes, ou seja, a
expressão de controle do 2 loop não é afetada pelo
primeiro, então usar a abordagem para elaborar
casos de teste para loop simples;
ii. Quando os loops não são independentes, então
elaborar casos de teste da mesma forma que para
loops aninhados;
Método Estrutural (Teste Caixa Branca)3.2b Loops
Testes Essenciais 13
UERJ – CTC/IME – Engenharia de Software 09-1 © Prof. A Padua Oliveira
25/40
Método Estrutural (Teste Caixa Branca)3.2c Caminhos
c) Testes de cobertura de caminhos.
Técnica para definição de casos de teste com base nos critérios
anteriormente definidos, de modo que, o conjunto de casos de
teste escolhido seja relativamente pequeno (minimizado).
Os casos de teste são produzidos com base em um "grafo de
fluxo de controle".
Grafo de Fluxo de Controle:
a) Características
principais:
� Possuem como elementos básicos: o nó e o ramo.
� Cada nó representa um ou mais comandos
seqüenciais do módulo.
� Cada ramo inicia e termina em um nó.
� As áreas delimitadas pelos ramos são denominadas
regiões.
UERJ – CTC/IME – Engenharia de Software 09-1 © Prof. A Padua Oliveira
26/40
Método Estrutural (Teste Caixa Branca)3.2c Caminhos
Grafo de Fluxo de Controle: 
b) Notação: 
c) Determinação da complexidade de 
um grafo: 
� pelo número de regiões do 
grafo ou;
� pela expressão: 
C = NR - NN + 2
NR = número de ramos
NN = número de nós
A complexidade de um grafo, 
fornecida pela expressão, é 
equivalente ao grau de 
complexidade, ou a dificuldade 
de construção, do módulo que 
gerou o grafo. 
Nó Seqüência Decisão
Do 
While
Repeat 
Until Case
. . .
Ramo
Testes Essenciais 14
UERJ – CTC/IME – Engenharia de Software 09-1 © Prof. A Padua Oliveira
27/40
Exemplo de testes de cobertura de caminhos
3.2c Caminhos
1
2
3
4
8
9 106
5
7
11
y
x
z
O fluxograma do módulo: O grafo associado:
complexidade = número de regiões = 4 
c = 12 - 10 + 2 = 4
UERJ – CTC/IME – Engenharia de Software 09-1 © Prof. A Padua Oliveira
28/40
Exemplo do planejamento de testes combinados
3.2 Caixa Branca
Testes Essenciais 15
UERJ – CTC/IME – Engenharia de Software 09-1 © Prof. A Padua Oliveira
29/40
X = 1
X = X+10 X = X+20
a
a
Y < 10
Y = Y+1
X = X+30
VF
V
F
Exemplo de testes combinados
C = 3
Casos de Teste
 entrada saida
1) X =1 , Y = 20; X =11, Y = 20
2) X =21, Y = 20; X =41, Y = 20
3) X =1, Y = 9; X =41, Y = 10
• Aplicação da Cobertura de Caminhos:
• Aplicação da combinação das 
técnicas:
Combinando as técnicas 
anteriores 
⇒ O número mínimo de casos 
de teste segundo o método da 
caixa branca é de 13 casos de 
teste. Serão dois grupos de 
casos para teste de loop 
simples, então 2 x 6 + 1= 13.
3.2 Caixa Branca
UERJ – CTC/IME – Engenharia de Software 09-1 © Prof. A Padua Oliveira
30/40
Beizer, B.; Software Testing Techniques; Van Nostrand
Reinhold Company, New York, 1983.
Fairley, Richard E.; Software Engineering Concepts;
McGraw-Hill Book Co., 1985.
Myers G. J.; The Art of Software Testing; John Wiley,
New York, 1979.
Pressman, Roger S.; Software Engineering: A
Practioner's Approach; McGraw-Hill Book Co. New York,
1982.
Staa, Arndt von; Engenharia de Programas; 2ed., LTC -
Rio de Janeiro, 1987.
Weinberg G. M.; The Psycology of Computer
Programming; Van Nostrand Reinhold Co., 1971.
Bibliografia