CIn-UFPE

Seleção de Testes de Regressão para Redução de Defeitos Escapados

Juliana Mafra – jndm@cin.ufpe.br

Novembro 2008

2

• 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

Motivaçã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

• 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.

Conceitos

• 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?

Métricas para Seleção de Testes

• 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:

– A Saída• Ordem de relevância dos casos de teste, baseado no resultado do

cálculo para cada caso de teste.

considered be tosize minimum N and otherwise 50%,

size executionslist | where N | if ,100*bugs Nº |Τ|Τ%|Τ|T

ΗΗΗf

Primeira Métrica

• Test Case History– Exemplo

• Suponha que N = 5

x ok x bloqueado ok ok x x x

%5,62 %100*85

33 T.:T ff

Teste 3

considered be tosize minimum N and otherwise 50%,

size executionslist | where N | if ,100*bugs Nº |Τ|Τ%|Τ|T

ΗΗΗf

Primeira 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:

– A Saída• Ordem de relevância dos casos de teste, baseado no resultado

do cálculo para cada caso de teste.

%100*||||

MMC

Tf

Segunda Métrica

• Changed and New Components– Exemplo

Test 3

C M

C1

C2 C3C4 C8

C5 C12C7

C1

C3

C4

Build

%86,42 %100*73

33 T.:T ff

%100*||||

MMC

Tf

Segunda 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

Terceira 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

Quarta 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:

0 if , 2

0 if ,),(

1),(

21

212121

) ,Ccount(C

) ,Ccount(CCCcountCCdistance

getherchanged to have been and C times C number of) ,Ct(Cwhere coun 2121

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…)

Quinta Métrica

• 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

Exemplo

• 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

EngineeringAdrian 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.

Conclusões

• Realizar experimentos no Time de Execução da Motorola

• Introduzir os novos critérios para o Time de Execução

• Mecanizar tudo (grande desafio!)

Trabalhos Futuros

?

Dúvidas