CIn-UFPE
Seleção de Testes de Regressão
para Redução de Defeitos Escapados
Juliana Mafra – [email protected]
Novembro 2008
2
Motivação
• Mercado de desenvolvimento de software bastante
competitivo.
• Necessidade de um processo de teste cuidadoso e
bem planejado.
• Mas o que é Teste de Software?
– “Any activity aimed at evaluating an attribute or
capability of a program or system and
determining that it meets its required results” (W.
Hetzel)
Motivação
• Este trabalho faz parte do projeto de pesquisa do
CIn/UFPE em cooperação com a Motorola no contexto
do Brazil Test Center (BTC).
• Propósito do Trabalho
– Resolver alguns problemas do Time de Execução de
testes da Motorola relacionados a escaped defects.
• Escaped defects
- Um escaped defect é um defeito que não foi descoberto
pelo BTC.
Motivação
• Escaped Defects – Os problemas
– Como evitar?
– Quais são as causas?
Motivação
• Escaped Defects – A solução
Agenda
• Conceitos
– Testes de Regressão
– Seleção de Testes de Regressão
– Depuração
• Métricas para Seleção de Testes
• Exemplo
• Conclusões
• Trabalhos Futuros
Conceitos
• Testes de Regressão
- Consiste na aplicação de testes em versões
modificadas do software, para garantir que as mudanças
realizadas estão corretas e que não surgiram novos
defeitos em componentes já testados do sistema.
• Seleção de Testes de Regressão
- Re-execução de alguns casos de teste selecionados a
partir de uma suíte para realizar o teste de regressão.
Conceitos
• Depuração
– “The process of diagnosing the precise nature of a
known error and then correcting it” (G. J. Myers)
– Algumas pesquisas e estudos em depuração
analisam técnicas de como prever defeitos.
- A idéia básica é encontrar localizações onde focar o
esforço do teste.
Métricas para Seleção de Testes
• Primeira tentativa: pesquisa em Seleção de Teste de
Regressão
– Não funcionou. Somente white box…
• Então, realizamos um pesquisa em depuração
– Essencialmente na idéia de predição de defeitos
• Cinco métricas foram definidas, baseadas em:
– Entrevistas
– Soluções de Predição de Defeitos
• Dado o histórico de CRs, onde ocorrerá o próximo
defeito?
Primeira Métrica
• Test Case History
– A Entrada
• Para cada caso de teste, existe um histórico de execuções
passadas (passou, falhou, bloqueado)
– A Solução
• Para cada caso de teste da suite, calcular:
 Nº bugs
*100% , if | ΗΤ |  N

T   |ΗΤ|
50%,
otherwise

f
– A Saída
where | ΗΤ |  list executionssize
and N  minimumsize to be considered
• Ordem de relevância dos casos de teste, baseado no resultado
do cálculo para cada caso de teste.
Primeira Métrica
• Test Case History
– Exemplo
• Suponha que N = 5
Teste 3
x ok x bloqueado ok ok x
 Nº bugs
*100% , if | ΗΤ |  N

T   |ΗΤ|
50%,
otherwise

f
fT 3  85 * 100%
.:
x
x
where | ΗΤ |  list executionssize
and N  minimumsize to be considered
fT 3  62,5%
Segunda Métrica
• Changed and New Components
– As Entradas
• Para cada caso de teste
– C: o conjunto de componentes visitados pelo caso de teste
– M: o conjunto de componentes novos e modificados na versão corrente
– A Solução
• Para cada caso de teste da suite, calcular:
|C  M |
T 
* 100%
|M |
– A Saída
f
• Ordem de relevância dos casos de teste, baseado no resultado
do cálculo para cada caso de teste.
Segunda Métrica
• Changed and New Components
– Exemplo
Test 3
C1
C2
C3
C3
C4
C
Build
C7
|C  M |
T 
* 100%
|M |
f
C1
C5
C8
M
C4
C12
fT 3  73 * 100%
.:
fT 3  42,86%
Terceira Métrica
• Recent failures
– As Entradas
• Os componente que falharam na versão anterior
• Para cada um desses componente, a porcetagem de CRs
abertas na versão anterior
• Para cada um desses componentes, o conjunto de casos de
teste associados
– A Solução
• Para cada caso de teste:
– Calcular a soma de todas as porcentagens associadas ao caso de
teste
– A Saída
• Ordem de relevância dos casos de teste, baseado no resultado
do cálculo para cada caso de teste.
Terceira Métrica
• Recent failures
– Exemplo
Quarta Métrica
• Escaped Defects
– As Entradas
• Os componentes que apresentaram defeitos escapados em um
período específico de tempo
• Para cada um desses componentes, a porcentagem de CRs
que escaparam do BTC (Brazil Test Center)
• Para cada um desses componentes, o conjunto de casos de
teste associados, que não foram executados naquele período
específico de tempo.
– A Solução
• Para cada caso de teste que não foi executado naquele
período específico:
– Calcular a soma de todas as porcentagens associadas ao caso de
teste
– A Saída
• Ordem de relevância dos casos de teste, baseado no resultado
do cálculo para cada caso de teste.
Quarta Métrica
• Escaped Defects
– Exemplo
Quinta Métrica
• Spatial Locality
– As Entradas
• V1, V2 … Vn: Todo conjunto de componentes que foram
modificados em todas as versões existentes
• C´: o conjunto de componentes que falharam na versão anterior
• C´´: os componentes restantes
• Todo conjunto de casos de teste associados a cada C´´
– A Solução
• Calcular a distância entre todo C´ e C´´ utilizando a equação:
 count (1C1,C 2 ) , if count(C1,C 2 )  0
distance ( C 1, C 2 )  
, if count(C1 ,C 2 )  0
2
where count(C1,C2 )  number of times C1 and C2 have been changed together
Quinta Métrica
• Spatial Locality
• Calcular a distância média relacionada a todo C´´
• Calcular a porcentagem relacionada a todo C’’, associando o
valor “2 - média” e então, normalizar para 100%
• Para cada caso de teste na suíte:
– Calcular a soma de todas as porcentagens associadas aquele
caso de teste
– A Saída
• Ordem de relevância dos casos de teste, baseado no
resultado do cálculo para cada caso de teste.
Quinta Métrica
• Spatial Locality
– Exemplo
Quinta Métrica
• Spatial Locality
– Exemplo (Continuação…)
Quinta Métrica
• Spatial Locality
– Exemplo (Continuação…)
Quinta Métrica
• Spatial Locality
– Exemplo (Continuação…)
Exemplo
• Um pequeno sistema foi criado e analisado com cada
métrica
– Um sistema composto por uma suíte de teste com 22
casos de teste (T1, T2…T22) e 9 componentes (C1,
C2…C9) foi considerado
• Dados hipotéticos foram criados para serem utilizados
como entrada para as cinco métricas
• Os resultados são apresentados ordenados de forma
decrescente de acordo com sua relevância
Exemplo
 Resultado
 Somente os dez casos de teste mais relevantes de cada métrica são
mostrados
Conclusões
• Cinco métricas foram definidas para serem utilizadas
separadamente na seleção de testes de regressão.
• Os resultados de cada métrica podem ser analisados
cuidadosamente
– Baseado nas necessidades e prioridades da versão
corrente, os melhores casos de teste podem ser
selecionados
• Algumas das métricas sugeridas já são utilizadas
intuitivamente por alguns membros do Time de
Execução da Motorola
Conclusões
• Outras métricas vieram de pesquisas em depuração
– Where Do Bugs Come From? A Challenge for Empirical Software
Engineering
Adrian Schröter, Thomas Zimmermann, Rahul Premraj, and Andreas
Zeller
– Predicting Faults from Cached History
Sunghun Kim, Thomas Zimmermann, E. James Whitehead, Jr., and
Andreas Zeller
• A maior contribuição
– O uso de técnicas de depuração para aumentar a
confiabilidade do teste de software.
Trabalhos Futuros
• Realizar experimentos no Time de Execução da
Motorola
• Introduzir os novos critérios para o Time de
Execução
• Mecanizar tudo (grande desafio!)
Dúvidas
?