CInUFPE Seleo de Testes de Regresso para Reduo

CIn-UFPE Seleção de Testes de Regressão para Redução de Defeitos Escapados Juliana Mafra – jndm@cin. ufpe. br 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: – A Saída • 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 x x

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: – A Saída • 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 C 1 C 2 C 4 C C 3 Build C 3 C 7 C 1 C 5 C 8 M C 4 C 12

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 • V 1, V 2 … 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:

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 (T 1, T 2…T 22) e 9 componentes (C 1, C 2…C 9) 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 ?