Testes de Regressão
Criado: jun/2001
Atualizado: nov/2009
Eliane Martins - Instituto de Computação - UNICAMP
Tópicos
• Conceito
• Classificação
• Tipos de técnicas
• Características desejáveis das técnicas
• Ferramentas
Eliane Martins - Instituto de Computação - UNICAMP
2
Referências
R. Binder. “Testing OO Systems: Models, Patterns and Tools”. AddisonWesley, 1999, c.15.
G.Rothermel, M.J.Harrold. “A Framework for Evaluating Regression Test
Selection Techniques”, Proc. 16th. Int’l Conf on Sw Eng., Sorrento,
Itália, maio/1994, pg. 201-210.
M.J.Harrold. “Testing Evolving Software”. The Journal of Systems and
Sw, nº 47, 1999, pp173-181.
L.A Fondazzi Martimiano. “Estudo de Técnicas de Teste de Regressão
Baseado em Mutação Seletiva”. Dissertação de mestrado. Instituto de
Ciências Matemáticas e de Computação - USP/S.Carlos, 1999.
Eliane Martins - Instituto de Computação - UNICAMP
3
O que é
Testes realizados a cada vez que um sw é alterado
• Objetivo:
– validar modificações feitas
– mostrar que modificações realizadas não afetaram as partes que
não foram modificadas
isto é
 mostrar que o sw não regrediu
Eliane Martins - Instituto de Computação - UNICAMP
4
Teste de Regressão
• Objetivo: verificar Impacto de Mudanças
Eliane Martins - Instituto de Computação - UNICAMP
Alguns conceitos
• Linha básica (“baseline”)
– versão de um componente (ou sistema) já testada
• Delta
– modificação feita a um componente (ou sistema) e que ainda não foi
testada
• Configuração delta (“delta build”)
– configuração executável do sistema contendo deltas e linhas básicas
• Caso de teste de regressão
– caso de teste aplicado à linha de base com veredicto = passou
– se veredicto = não passou na config. delta  falha de regressão
Eliane Martins - Instituto de Computação - UNICAMP
6
Quando aplicar
• Para testar aplicações críticas que devem ser retestadas freqüentemente
• Para testar sw que é alterado constantemente durante o
desenvolvimento (ex.: Processo Incremental ou Evolutivo)
• Para testar componentes reutilizáveis para determinar se são adequados
para o novo sistema
• Durante os testes de integração
• Durante os testes, após correções
• Em fase de manutenção (corretiva, adaptativa, perfectiva ou
preventiva)
• Para identificar diferenças no comportamento do sistema quando há
mudanças de plataforma (uso de seqüências-padrão ou “benchmarks”)
Eliane Martins - Instituto de Computação - UNICAMP
7
Quando aplicar (OO)
•
•
•
•
Quando uma nova subclasse é criada
Quando uma super-classe é alterada
Quando uma classe servidora é alterada
Quando uma classe é reutilizada em um novo contexto
Eliane Martins - Instituto de Computação - UNICAMP
8
Limitações
 Uma seqüência de regressão NÃO contém testes para as
partes novas ou alteradas
 Uma seqüência de testes que pode ser usada como
seqüência de regressão deixa de ser útil como seqüência de
testes primária
 Uma seqüência de regressão não tem as mesmas metas de
cobertura de uma seqüência de testes primária
 O uso de seqüência de testes inadequada como seqüência
de regressão não melhora sua qualidade
Eliane Martins - Instituto de Computação - UNICAMP
9
Falhas de regressão - por quê?
• Falhas de regressão ocorrem quando há dependências entre
D (delta) e B (linha de base):
–
–
–
–
–
–
de fluxo de controle
de fluxo de dados
restrições de ativação
compartilhamento de dados
tempo
disputa por recursos
Eliane Martins - Instituto de Computação - UNICAMP
10
Modelos de falhas de regressão
• Dados D(delta) e B (linha de base):
– D aloca / muda o valor / desaloca: variável global, atributo de uma
classe, dado persistente usado por B, causando: (1) ativação de falha
dormente em B ou (2) violação do contrato (pré-condições e
invariantes) de B, gerando uma exceção ou (3) B viole contrato de
outra linha de base B’
– D é cliente de B e envia mensagem que viola contrato de B
– D é servidor de B e retorna valor que viola contrato de B
– D é incompatível com B
ex.: precisão de valores reais entre D e B
Eliane Martins - Instituto de Computação - UNICAMP
11
Modelos de falhas de regressão (OO)
garante
D
B
servidor E
cliente
requer
E servidor
requer
D
garante
B
cliente
Contrato entre B e E não muda,
mas comportamento de E muda
devido à mudança em D
Contrato entre B e E não muda.
D não é compatível com todos
os contratos de E, mas pode
substituí-la (polimorfismo)
Eliane Martins - Instituto de Computação - UNICAMP
12
Processo
Identificar modificações a P
Criar T’’
S
Modificar P  P’
 partes novas, modificadas
ou não testadas em P’?
Testar P’ usando T’’
Criar T’’’ = T  T’’
Selecionar T’ T
Testar P’ usando T’
N
Fim
Eliane Martins - Instituto de Computação - UNICAMP
13
Processo
Identificar modificações a P
Criar T’’
S
Testar P’ usando T’’
Modificar P  P’
Selecionar T’ T
 partes novas, modificadas
Testar P’ usando T’
Pb da seleção da seqüência de regressão:
ou não testadas em P’?
• se t T obsoleto  não incluir t em T’
• se t T’/ t exercita a modificação e T’ aplicado
no mesmo contexto que T  T’ é segura (“safe”)
Criar T’’’ = T  T’’
N
Fim
Eliane Martins - Instituto de Computação - UNICAMP
14
Processo
Identificar modificações a P
Criar T’’
S
Modificar P  P’
 partes novas, modificadas
ou não testadas em P’?
Selecionar T’ T
Testar P’ usando T’
Testar P’ usando T’’
N
Pb da cobertura:
identificar partes de P’ (ou S’) que
não foram cobertos
Criar T’’’ = T  T’’
Fim
Eliane Martins - Instituto de Computação - UNICAMP
15
Processo
Identificar modificações a P
Criar T’’
S
Modificar P  P’
Selecionar T’ T
Pb da manutenção e minimização dos testes:
 partes
novas,Tmodificadas
• atualizar
T’’’
Testar P’ usando T’
ou •não
testadas
em
P’?
minimizar T’’’: eliminar casos de teste
redundantes e obsoletos
Testar P’ usando T’’
Criar T’’’ = T  T’’
N
Fim
Eliane Martins - Instituto de Computação - UNICAMP
16
Abordagens
• Abordagens:
– retesta tudo: T’ = T
– seletiva: T’ T
qual abordagem usar?
Eliane Martins - Instituto de Computação - UNICAMP
17
Modelo custo x benefício
• Sejam:
| T | e | T’ | cardinalidades de T e T’
s custo médio de seleção/caso de teste
r custo médio de execução/caso de teste
se
s  | T’ | < r  ( | T | - | T’ | )  regressão seletiva
mas
se potencial detecção falhas T’ < T  retesta tudo
Eliane Martins - Instituto de Computação - UNICAMP
18
Considerações para a seleção
• Problema: segurança (safety)
– como obter T’ contendo casos de teste t  T que exercitem código
de P que foi modificado em P’?
 Problema indecidível
 O uso de uma seqüência de regressão segura
 todos os casos de teste que podem revelar a presença de falhas
foram aplicados
 ausência de falhas de regressão ou de qualquer outro tipo de falha
Eliane Martins - Instituto de Computação - UNICAMP
19
Técnicas
• As técnicas de seleção de
testes de regressão podem ser
baseadas:
– No código
+ seguras
• Grafo de fluxo de controle
– Na arquitetura
• firewall
– Na especificação
• Casos de uso
Eliane Martins - Instituto de Computação - UNICAMP
- seguras
Seleção baseada no código
• Exemplo de técnica:
– Seleção baseada em segmento modificado
• As técnicas se baseiam na construção do Grafo de
Fluxo de Controle (GFC) do programa
– Passeio síncrono no grafo original e no grafo
modificado para identificar as modificações
Eliane Martins - Instituto de Computação - UNICAMP
Exemplo
G
A
V
B
P
if A then B
else C;
if D then
if E then F;
G;
if H then I;
X;
F
C
D
V
V
E
F
F
F
T
testes caminho
t1
ABDEFGHIX
t2
ABDEGHIX
t3
ABDHIX
t4
ACDHX
G
H
V
I
F
X
Eliane Martins - Instituto de Computação - UNICAMP
24
Seleção baseada no segmento modificado
G’
G
A
V
P
if A then B
else C;
if D then
if E then F;
G;
if H then I;
X;
F
B
C
D
V
V
E
F
F
F
G
H
V
I
F
V
P’
if A then B
else C’;
if D then
if E then F
else J;
G;
if H1 then K
else L;
else if H2 then I;
X;
X
Eliane Martins - Instituto de Computação - UNICAMP
A
F
C’
B
D
V
V
F
E
H2
F
V
J
F
G
I
H1
V
F
K
L
X
25
F
Exemplo
G’
T’
Modificação
seq. segura mínima
C  C’
t4 (ACDHX)
+J
t2 (ABDEGHIX)
H  H1 + H2 t1 (ABDEFGHIX),
t2 (ABDEGHIX),
t3 (ABDHX),
t4 (ACDHX)
V
P’
if A then B
else C’;
if D then
if E then F
else J;
G;
if H1 then K
else L;
else if H2 then I;
X;
A
F
C’
B
D
V
V
F
E
H2
F
V
J
F
G
I
H1
V
F
K
L
X
Eliane Martins - Instituto de Computação - UNICAMP
26
F
Seleção baseada na arquitetura
• Uso de firewall
– O conceito de firewall foi introduzido por Leung e White
(1989) para separar os módulos que podem ser afetados
pelas modificações dos outros.
– Uma vez identificado o firewall,é selecionado um
subconjunto de testes que exercitem os módulos dentro
do firewall.
– A determinação do firewall se dá através da análise de
dependências feita sobre o Grafo de Chamadas (GC)
representando a hierarquia de uso de módulos de um
sistema funcional.
Eliane Martins - Instituto de Computação - UNICAMP
Uso de firewall em software OO
• Firewall:
– Conjunto de componentes (classes, programas, módulos, ...) que
devem ser incluídos nos testes de regressão
– Obtido através da análise de cada componente modificado e suas
dependências com outros componentes
– Dependências entre A (delta) e B (linha de base):
•
•
•
•
B usa A (B é cliente de A)
B é servidor de A
B é subclasse de A
B sobrecarrega A (polimorfismo)
[Binder99, c.15]
Eliane Martins - Instituto de Computação - UNICAMP
33
Exemplo - Reteste no firewall
Tem único 
Tem 
0 .. *
NroConta
Conta
2 .. *
 Aplicada a
ServiçodeFinanças
0 .. * Transação
Oferecido através de 
0 .. *
Usa
Usa
Dinheiro
Aplicada a 
Taxas
Eliane Martins - Instituto de Computação - UNICAMP
34
Exemplo - Reteste no firewall
Dependências entre os componentes
ServiçodeFinanças
Transação
Taxas
Conta
Dinheiro
NroConta
: depende de
Eliane Martins - Instituto de Computação - UNICAMP
35
Exemplo - Reteste no firewall
Seleção de Testes no Firewall
ServiçodeFinanças
Testes
Transação
Transação
Taxas
firewall
Conta
Dinheiro
—: inalterado
—: modificado
Eliane Martins - Instituto de Computação - UNICAMP
Testes
Conta
NroConta
Testes
Dinheiro
36
Técnicas baseadas na especificação
• A seleção baseia-se na análise do modelo de
especificação. No caso, utilizaremos técnicas
baseadas nos casos de uso [Binder99, c.15] :
– Casos de uso de maior risco
– Casos de uso mais freqüentes
Eliane Martins - Instituto de Computação - UNICAMP
Seleção baseada nos casos de uso de maior risco
• Faz-se uma análise de risco para identificar:
– Casos de uso críticos
• Aqueles que são cruciais para o bom funcionamento do
sistema
– Casos de uso suspeitos
• Aqueles que dependem de recursos (componentes, hardware,
software) pouco confiávis, ou seja, instáveis, pouco testados,
mais complexos
• Selecionam-se os casos de teste para esses casos
de uso
Eliane Martins - Instituto de Computação - UNICAMP
Matriz de rastreabilidade
Caso de uso 1
t1
t2


Caso de uso 2
...
tM

...
Caso de uso N
Eliane Martins - Instituto de Computação - UNICAMP


Seleção de acordo com o perfil operacional do
caso de uso
• Contexto:
– Recursos (equipamento, pessoal, conhecimento, tempo)
para realização de testes de regressão são curtos
– o que fazer para selecionar subconjunto de testes da
melhor maneira possível para os recursos disponíveis?

Alocar testes de acordo com a freqüência com que um
caso de uso é realizado
Eliane Martins - Instituto de Computação - UNICAMP
43
Exemplo
• Supor que se dispõe de 100h (6000 min) para os testes de
regressão de um ATM, dos quais:
– a execução de um caso de teste leva em média 5 min
– uma falha é revelada 0,5% do tempo
– a correção da falha requer em média 4h (240 min)
• Supor ainda que o conjunto de testes da linha básica
contém 20.000 casos de testes
 Quantos casos de testes devem ser selecionados?
Eliane Martins - Instituto de Computação - UNICAMP
44
Exemplo - Reteste de acordo com perfil
• Seja T o total de testes que se quer realizar:
5T + (0,005T  240) = 6000  T  1000
Caso de Uso Freqüência
Saque
50%
Depósito
25%
Transferência
12%
Pede Saldo
8%
Pede Extrato
3%
Pede Talão 2%
Nº de testes
500
250
120
60
30
20
Eliane Martins - Instituto de Computação - UNICAMP
45
Características de uma técnica de seleção
• Inclusão
– o quanto a técnica inclui em T’ os casos de testes que fazem com
que saída(P’)  saída(P) , revelando assim as falhas de regressão?
Ex.:
• se | T | = 50 e 8 fazem com que saída(P’)  saída(P)
• se a técnica seleciona 2 destes 8 testes

a técnica tem uma inclusão de 25% com relação a P, P’ e T.
 para P, P’ e T quaisquer  pb indecidível
Eliane Martins - Instituto de Computação - UNICAMP
46
Características de uma técnica de seleção
• Inclusão
• Precisão
– o quanto a técnica evita incluir em T’ os casos de teste que não
farão com que saída(P’)  saída(P) ?
Ex.:
• se | T | = 50 e 44 não fazem com que saída(P’)  saída(P)
• se a técnica não seleciona 33 destes 44 testes

a técnica tem uma precisão de 75% com relação a P, P’ e T.
 para P, P’ e T quaisquer  pb indecidível
Eliane Martins - Instituto de Computação - UNICAMP
47
Características de uma técnica de seleção
• Inclusão
• Precisão
• Eficiência
– qual o custo computacional da técnica ?
• Espaço: quanto de informação o algoritmo necessita?
• Tempo: qual a complexidade do algoritmo de seleção?
Eliane Martins - Instituto de Computação - UNICAMP
48
Características de uma técnica de seleção
•
•
•
•
Inclusão
Precisão
Eficiência
Generalidade
– o quanto a técnica é genérica ?
• A técnica permite tratar qualquer tipo de modificação?
• A técnica pode tratar diferentes linguagens e tipos de programas?
• A técnica funciona tanto para unidade quanto para integração?
Eliane Martins - Instituto de Computação - UNICAMP
49
Características de uma técnica de seleção
•
•
•
•
•
Inclusão
Precisão
Eficiência
Generalidade
Suporte à cobertura
– o quanto a técnica permite que se obtenha cobertura com relação a
algum critério ?
• Os critérios de cobertura usados para gerar T continuam sendo
satisfeitos?
• A técnica permite que seja obtido T’’’ que cubra os acréscimos ou as
modificações?
Eliane Martins - Instituto de Computação - UNICAMP
50
Ferramentas
• Testes manuais:
– não recomendável pois número de testes e nº de falhas 
• Ferramentas que podem auxiliar:
– Capture/playback: permitem armazenar e re-aplicar conjuntos de
testes
– Controle de versões: controlar o sistema e seu histórico de testes
– Comparador de saídas: comparação entre resultados do delta e da
linha básica
– Embaralhador de casos de teste: permitem revelar falhas de
seqüência de entradas
– Testes embutidos: assertivas permitem revelar falhas de contrato.
Drivers embutidos permitem reduzir custos com manutenção dos
testes.
Eliane Martins - Instituto de Computação - UNICAMP
51