Teste de Software: Detecção de Defeitos

Prévia do material em texto

Slide 1
Teste de Software
Engenharia de Software
2o. Semestre de 2005
UNIVERSIDADE ESTADUAL PAULISTA
INSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS 
DEPARTAMENTO DE CIÊNCIAS DE COMPUTAÇÃO E ESTATÍSTICA
Slide 2
Testes para a detecção de defeitos
l Testar programas para 
estabelecer a presença de 
defeitos no sistema.
Slide 3
Tópicos
l Testes para a detecção de defeitos
l Testes de integração
l Testes orientados a objetos
Slide 4
O processo de teste
l Testes de componentes 
• Testes de componentes de programas individuais.
• Usualmente os programadores assumem a responsabilidade 
pelo teste de seu código (exceto em caso de sistemas 
críticos).
• Testes são derivados da experiência do desenvolvedor.
l Testes de integração
• Testes de grupos de componentes integrados para formar 
subsistemas ou sistemas completos.
• Uma equipe independente de teste fazem o teste de 
integração.
• Os testes são baseados em uma especificação do sistema.
Slide 5
Teste para detecção de defeitos
l O objetivo de testes para a detecção de 
defeitos é revelar defeitos latentes nos 
programas.
l Um teste bem sucedido é aquele que revela a 
presença de um defeito (faz com que o 
programa se comporte de maneira anômala)
l Testes mostram a presença e não a ausência 
de defeitos.
Slide 6
l A única maneira de mostrar que um programa está 
correto é o teste exaustivoteste exaustivo. Contudo, teste exaustivo é 
impraticávelimpraticável.
l Testes devem ser baseados em um subconjuntosubconjunto de 
possíveis casos de teste.
l Políticas devem ser utilizadas para escolher esse 
conjunto.
• Ex: todas as declarações do programa devem ser testadas pelo 
menos uma vez
• Todas as funções de sistema acessados por meio de menus devem 
ser testadas, etc.
Prioridades do teste
Slide 7
ll Dados de testeDados de teste entradas criadas para testar o 
sistema.
ll Casos de testeCasos de teste Entradas para testar o sistema 
e saídas esperadas para essas entradas ( 
quando o sistema opera de acordo com suas 
especificações) . 
Dados de teste e Casos de teste
Slide 8
Processo de teste para a detecção 
de defeitos
Design test
cases
Prepare test
data
Run program
with test data
Compare r esults
to test cases
Test
cases
Test
data
Test
results
Test
reportsCasos
de teste
Casos
de teste
Dados
de teste
Dados
de teste
Resultados
de teste
Resultados
de teste
Relatórios
de teste
Relatórios
de teste
Projetar casos
de teste
Projetar casos
de teste
Preparar dados
de teste
Preparar dados
de teste
Executar programa
com dados de teste
Executar programa
com dados de teste
Comparar resultados 
com os casos de teste
Comparar resultados 
com os casos de teste
Slide 9
Teste de caixa preta
l Uma abordagem de teste onde o programa é 
considerado como uma “caixa-preta”.
l Os casos de teste para testar o programa são 
baseados na especificação do sistema.
l O planejamento dos testes podem começar nos 
primeiros estágios do processo de software. 
Slide 10
Teste Caixa preta
Ie
Entrada de 
Dados de teste 
Saída dos resultados de 
teste
Oe
SISTEMA
SISTEMA
Entradas que provocam
comportamento anômalo
Saídas que revelam a
presença de defeitos
Problema: selecionar 
entradas ÎIe
Slide 11
Particionamento de equivalência
(abordagem sistemática para seleção de dados de teste)
l Dados de entrada e resultados de saída caem 
em diferentes classes onde todos os membros 
de uma classe são relacionados
l Cada uma dessas classes é uma partição de 
equivalência onde o programa se comporta de 
uma maneira equivalente para cada membro da 
classe
l Casos de teste devem ser escolhidos de cada 
partição.
Slide 12
(abordagem sistemática para seleção de dados de teste)
Particição de Equivalência
S y stem
Ou tput s
Inva li d in pu ts Va li d in pu ts
Slide 13
l Entradas e saídas do sistema são particionadas
em “conjuntos de equivalência” 
• Se a entrada é um inteiro de 5 dígitos entre 10.000 e 99.999, 
partições de equivalência são números < 10.000, números 
entre 10.000 e 99. 999 e números > 99. 999
l Escolher casos de teste nos limites das 
partições:
• 00000, 09.999, 10.000, 50.0000, 99.999, 100.000
(abordagem sistemática para seleção de dados de teste)
Particionamento de equivalência
Slide 14
(abordagem sistemática para seleção de dados de teste)
Partições de equivalência
Betw een 10 00 0 an d 99 99 9Less th an 1 00 00 M o re than 99 99 9
9 99 9
1 00 00 5 00 00
1 00 00 0
9 99 99
Inp ut valu es
Betw een 4 an d 10Less th an 4 M o re than 10
3
4 7
1 1
1 0
Nu m ber of inp ut v alu es
O programa aceita entre 4 a 
10 entradas, que são números 
inteiros de cinco dígitos, 
maiores do que 10.000 e 
menores que 99.999
Slide 15
Especificação de uma rotina de 
busca
procedure Search (Key : ELEM ; T: ELEM_ARRAY;
Found : in out BOOLEAN; L: in out ELEM_INDEX) ;
Pré-condição
-- a seqüência tem pelo menos um elemento
T’FIRST <= T’LAST 
Pós-condição
-- O elemento é encontrado e é referenciado por L
( Found and T (L) = Key) 
ou
-- O elemento não está na seqüência
( not Found and
not (exists i, T’FIRST >= i <= T’LAST, T (i) = Key ))
Slide 16
l Entradas que estão de acordo com a pré 
condição: seqüência com no mínimo um 
elemento.
l Entradas onde a pré condição não vale.
l Entradas onde o elemento chave é um 
elemento da seqüência.
l Entradas onde o elemento chave não é um 
membro da seqüência.
Rotina de busca - partições de 
entrada
Slide 17
Diretrizes de testes (no caso do 
exemplo usado)
l Teste o software com seqüências que possuem 
somente um único valor.
l Use diferentes seqüências, de diferentes 
tamanhos, em diferentes testes.
l Derive testes de maneira que o primeiro, o 
médio e o último elemento da seqüência sejam 
acessados.
l Teste com seqüências de comprimento zero.
Slide 18
Rotina de busca - partições de 
equivalência
Vetor Elemento 
Valor único Está na seqüência 
Valor único Não está na seqüência 
Mais que 1 valor Pr imeiro e lemento está na seqüência 
Mais que 1 valor Úl t imo elemento es tá na seqüência 
Mais que 1 valor Elemento médio es tá na seqüência 
Mais que 1 valor Não es tá na seqüênc ia 
 
 
Seqüência de entradas (T) Chave (key) Saídas (Found, L)
17 17 Verdadeiro, 1
17 0 Falso, ??
17, 29, 21, 23 17 Verdadeiro, 1
41, 18, 9, 31, 30, 16, 45 45 Verdadeiro, 7
17, 18, 21, 23, 29, 41, 38 23 Verdadeiro, 4
21, 23, 29, 33, 38 25 Falso, ??
Slide 19
l Algumas vezes chamado testes de “caixa 
branca”.
l Derivação de casos de teste de acordo com a 
estrutura do programa. O conhecimento do 
programa é usado para identificar casos de 
testes adicionais.
• Exemplo: exercitar todas as declarações do programa.
Teste Estrutural
Slide 20
Testes caixa branca
Component
code
Test
outputs
Test data
DerivesTests
Component
code
Test
outputs
Test data
DerivesTests
Dados
de teste
Dados
de teste
Código de
componente
Código de
componente Saídas
do teste
Saídas
do teste
Testa Deriva
Slide 21
Testes de Caminho
l O objetivo dos testes de caminho é garantir que 
o conjunto de casos de teste é tal que cada 
caminho do programa é executado no mínimo 
uma vez. 
l Para o teste de caminho, elabora-se um grafo 
de fluxo de programa, onde os nós, 
representam os pontos de decisão do 
programa, e os arcos representam o fluxo de 
controle.
Slide 22
l Modelo em esqueleto de todos os caminhos do 
programa.
l Consiste em nós que representam decisões e 
em ramos que mostram o fluxo de controle.
l É construídoatravés do código fonte, onde 
substitui-se os comandos por nósnós e desvios 
pelos arcosarcos (ou ramos) do grafo.
l Declarações seqüenciais são ignoradas na 
construção do grafo de fluxo. 
Grafos de fluxo de programa
Slide 23
l Em um comando condicional, cada ramo é 
mostrado como um caminho separado, e laços 
são indicados por uma seta fazendo o loop de 
volta para o nó de condição do laço.
l Usado como base para calcular o número de 
caminhos independentes no programa.
l Caminho independente - caminho que 
atravessa pelo menos um novo ramo no grafo 
de fluxo.
Grafos de fluxo de programa
Slide 24
l O número de caminhos independentes no 
código é igual à complexidade complexidade ciclomáticaciclomática.
l Cálculo da Complexidade ciclomática: 
CC = Número de ramos - Número de nós + 2.
l Complexidade ciclomática determina o número 
de casos de teste mínimo para testar 
adequadamente todos os caminhos 
independentes do programa.
Complexidade Ciclomática
Busca binária (Java) 
class BinSearch { 
 
// Esse é um encapsulamento de uma função de busca 
// binária que considera um vetor de objetos ordenados e uma chave 
// e retorna um objeto com 2 atributos, chamados 
// index – o valor do índice de vetor 
// found – um booleano que indica se uma chave está ou não no vetor 
// A chave será –1 se o elemento não for encontrado 
 
 public static void search ( int key, int [] elemArray, Result r ) 
 { 
 int bottom = 0 ; 
 int top = elemArray.length - 1 ; 
 int mid ; 
 r.found = false ; r.index = -1 ; 
 while ( bottom <= top ) 
 { 
 mid = (top + bottom) / 2 ; 
 if (elemArray [mid] == key) 
 { 
 r.index = mid ; 
 r.found = true ; 
 return ; 
 } // if part 
 else 
 { 
 if (elemArray [mid] < key) 
 bottom = mid + 1 ; 
 else 
 top = mid - 1 ; 
 } 
 } //while loop 
 } // search 
} //BinSearch 
Grafo de fluxo para Busca 
Binária
1
2
3
4
65
7
w hile bo ttom < = to p
if (elem A rray [m id] == k ey
(i f (elemA rray [mi d]< key8
9
b otto m > top
Slide 27
l 1, 2, 3, 8, 9
l 1, 2, 3, 4, 6, 7, 2
l 1, 2, 3, 4, 5, 7, 2
l 1, 2, 3, 4, 6, 7, 2, 8, 9
l Casos de teste devem ser projetados para 
executar todos esses caminhos.
Exercício: elaborar um conjunto de dados que execute os caminhos 
independentes acima.
Caminhos independentes
Slide 28
l Útil se usado com cuidado. 
l Não implica que o programa foi 
adequadamente testado - embora todos os 
caminhos independentes são executados, 
todas as combinações possíveis de caminhos 
não são executadas.
Teste de Caminhos
Slide 29
Testes de integração
l Testes feitos em sistemas completos ou 
subsistemas, compostos de componentes 
integrados.
l Testes de integração devem ser desenvolvidos 
a partir da especificação do sistema.
l A maior dificuldade é a localização de erros.
l Integração incremental reduz esse problema.
Slide 30
Testes de integração incremental
T3
T2
T1
T4
T5
A
B
C
D
T2
T1
T3
T4
A
B
C
T1
T2
T3
A
B
Test s equ ence
1
Test s equ ence
2
Test s equ ence
3
Seqüência 
de teste 1
Seqüência 
de teste 2
Seqüência 
de teste 3
Slide 31
Abordagens para o teste de 
integração
l Teste de integração top-down
• Começa com os componentes de alto nível de um sistema, e 
a integração se dá de cima para baixo em uma hierarquia de 
componentes. Componentes individuais em um nível mais 
baixo na hierarquia são representados por stubs.
l Teste de integração bottom-up
• Envolve integrar e testar os módulos de nível inferior na 
hierarquia e, então, subir na hierarquia de módulos, até que o 
módulo final seja testado.
l Na prática, a maioria das integrações envolve a 
combinação dessas estratégias.
Slide 32
Testes de integração Top-down
Level 2Le vel 2Level 2Level 2
Level 1 Level 1
Testin g
seq uen ce
Le vel 2
s tu bs
Le vel 3
s tubs
. . .Seqüência 
de testes
Stubs do 
nível 2
Stubs do 
nível 3
Slide 33
Testes de integração bottom-up
Level NLevel NLe vel NLevel NLevel N
Level N–1 Level N–1Level N–1
Test in g
s equence
Test
d rivers
Test
d rivers
Seqüência 
de testes
Drivers
de teste
Drivers
de teste
Slide 34
Vantagens e desvantagens das 
abordagens de teste
l Validação da arquitetura
• Os testes top-down oferecem maior probabilidade de 
descobrir erros na arquitetura de sistema, em um estágio 
inicial do processo de desenvolvimento.
l Demonstração do sistema
• Os testes de integração top-down permite a demonstração de 
um sistema de trabalho limitado em uma fase inicial do 
desenvolvimento.
l Implementação de teste
• Testes top-down são mais difíceis de implementar pois é 
necessário a produção de stubs (programas que simulam 
níveis inferiores)
l Observação de teste
• Problemas com ambas as abordagens. Código extra são 
necessários para poder observar os testes.
Slide 35
l Ocorrem quando módulos ou subsistemas são 
integrados para criar sistemas maiores.
l Objetivo é detectar erros devido a erros ou 
suposições inválidas sobre interfaces.
l Particularmente importante para o 
desenvolvimento orientado a objeto, uma vez 
que os objetos são definidos por suas 
interfaces
Testes de interface
Slide 36
Testes de Interface
Test
cases
BA
C
Slide 37
Diretrizes para os testes de 
interface
l Projete conjunto de testes em que o valor dos 
parâmetros para os componentes externos esteja nos 
limites extremos.
l Sempre teste parâmetros ponteiros com ponteiros 
nulos.
l Em sistemas de passagem de mensagem, projete 
testes que gerem muito mais mensagens que é 
provável ocorrer na prática (teste de estresse)estresse).
l Em um sistemas de memória compartilhada, varie a 
ordem na qual os componentes são ativados.
Slide 38
Testes de estresse
l Exercitam o sistema além de sua carga máxima 
de projeto, até o sistema falhe. 
l Testa o comportamento de falha do sistema. É 
importante que a falha não cause a corrupção 
de dados ou a perda inesperada de serviços do 
usuário.
l Particularmente relevantes para sistemas 
distribuídos, que podem exibir uma degradação 
severa quando a rede se torna sobrecarregada.
Slide 39
l Os componentes a serem testados são classes 
de objetos que são instanciadas como objetos.
l Diferentes de teste funcional, pois: 
• Objetos individuais são, muitas vezes, maiores do que 
funções isoladas. Abordagens de teste de caixa-branca 
devem ser estendidas.
• Testadores podem não ter acesso ao código fonte do 
componente para análise, no caso de reuso de objetos
• Não existe um nível superior óbvio para integração e teste 
top-down.
Testes orientados a objetos
Slide 40
4 Níveis de teste
l Testar as operações associadas com os 
objetos.
l Testar classes de objetos individuais.
l Testar agrupamentos de objetos que cooperam 
entre si.
l Testar o sistema orientado a objeto completo.
Slide 41
Testes de classes de objetos
l A cobertura completa de testes deve incluir
• Testar todas as operações associadas com um objeto
• Estabelecimento e a interrogação de todos os atributos 
associados com o objeto
• Exercitar o objeto em todos os estados possíveis (simular 
todos os eventos que provoquem mudança de estado no 
objeto)
l Herança dificulta o projeto de testes de classe 
de objetos. Quando uma superclasse fornece 
operações herdadas por subclasses, todas 
essas subclasses devem ser testadas com 
todas as operações herdadas.
Slide 42
Integração de objetos
l Níveis de integração são menos distintos em 
sistemas orientados a objetos.
l Testes de clusters se ocupam com a integraçãoe teste de objetos que cooperam entre si.
l Clusters devem ser identificados utilizando-se o 
conhecimento de suas operações e as 
características do sistema implementadas por 
esses clusters.
Slide 43
Pontos chave
l É mais importante testar as partes do sistema 
mais comumente utilizadas do que as partes que 
são exercitadas raramente.
ll Partição de equivalênciaPartição de equivalência é uma maneira de 
derivar casos de teste. Partições são conjuntos 
de dados onde o programa deve se comportar 
de maneira equivalente.
ll Teste de caixa pretaTeste de caixa preta é baseado na especificação 
do sistema. Não precisa analisar o código fonte.
ll Teste estruturalTeste estrutural baseia-se na análise do 
programa para determinar os caminhos a serem 
executados e a seleção de casos de teste.
Slide 44
Pontos chave
l Os testes de integraçãotestes de integração se concentram no 
teste das interações entre os componentes.
l Os testes de interfacetestes de interface procuram descobrir 
defeitos nas interfaces ou nos módulos. 
l Para testar as classes de objetostestar as classes de objetos, deve-se 
testar todas as operações, atributos e 
estados.
l Sistemas orientados à objetos devem ser 
integradosintegrados em torno de clustersclusters de objetos.