View
279
Download
0
Category
Preview:
DESCRIPTION
Apresentado na disciplina MATE08 - Evolução de Software, da UFBA, em 2012.2
Citation preview
Mineração de repositórios de defeitos
Oportunidades e Desafios
Rodrigo Souza, 20/12/2012, aula de Evolução de Software
Introdução
Durante o desenvolvimento de software, defeitos* são relatados em sistemas de acompanhamento de defeitos(aka, repositórios de defeitos)
Artefato: relatório de defeito ou tíquete
* e, às vezes, requisições de funcionalidade
3
4
Criação de Tíquete
5
6
7
7
FIXED / DUPLICATE / WONTFIX / WORKSFORME / INVALID
RESOLVED/FIXED
VERIFIED
REOPENED
8
Oportunidades e Desafios
• Repositórios de defeitos têm informações...
• ... sobre o produto (defeitos)
• ... sobre o processo (atividades, interação entre desenvolvedores)
Repositório de defeitos
Repositório de defeitos
• Oportunidade de estudar como características do processo afetam a qualidade do produto
Código e Defeitos
• Algumas pesquisas cruzam dados de relatórios de defeitos e código-fonte
• Mapeamento entre commit e bug, ex.: “Resolve o bug #1437.”
• O código original que foi alterado é o código defeituoso.
• O commit que criou o código original é uma mudança que induziu o defeito
Código e Defeitos
• Data sets (para cada componente do código-fonte, contagem de defeitos):
• http://www.st.cs.uni-saarland.de/ibugs/
• http://www.st.cs.uni-saarland.de/softevo/bug-data/eclipse/
• http://bug.inf.usi.ch/
Trabalhos (código e defeitos)
• code ownership => defeitos
• convenções de código => defeitos
• code churn => defeitos
• predição de defeitos
• predição do tempo de correção
Desafios
• Identificação de desenvolvedores com múltiplas contas no sistema de controle de versão (VCS) ou no sistema de acompanhamento de defeitos (BTS)
• Mapeamento de contas entre VCS e BTS
• Viés no mapeamento de bugs para código
• Nem todos os bugs são mapeados
Amostra representativa
Amostra representativa
Amostra enviesada
Outros trabalhos
• Triagem automática de tíquetes
• Detecção de tíquetes duplicados (Yguaratã)
• Atribuição de tíquetes a desenvolvedores
Reabertura de defeitos
• Reabertura => retrabalho
• Trabalhos
• Causa de reabertura
• Predição de reabertura
• Custo da reabertura
Reabertura
• Oportunidade de estudar a eficácia do processo de verificação usando apenas dados do repositório de defeitos
• Ideia básica: se o tíquete foi verificado e depois reaberto, a verificação não foi efetiva
Minha Pesquisa
21
Dados
• MSR Challenge 2011 - http://2011.msrconf.org/msr-challenge.html
• Dump do MySQL do Bugzilla do Eclipse e do NetBeans
Dados
Como aproveitar relatórios de defeito para minerar o
processo de verificação? Há ruído nos dados?
24
(Objetivo Específico 1)
25
há ruídos nos dados?
quando é feita a verificação?
quem faz a verificação?
como é feita a verificação?
(RQ1.4)
(RQ1.1)
(RQ1.2)
(RQ1.3)
verificações em massa
há ruídos nos dados?
26
há ruídos nos dados?
No Eclipse Modelling Framework, VERIFIED significa que o patch está disponível em uma build.
27
fase de verificação
quando é feita a verificação?
28
quem faz a verificação?
29
time deQA
10
quem faz a verificação?
29
20% dos desenvolvedores
time deQA
10
quem faz a verificação?
29
20% dos desenvolvedores
time deQA
80% das verificações
10
como é feita a verificação?
30
A maioria dos comentários não traz informação sobre a técnica empregada.
Resumo
31
Fase de verificação ✓ ✗
Time de QA ✗ ✓
Comentários raramente mencionam técnica de verificação.⚠ Cuidado com verificações em massa.
Será que determinadas práticas de verificação são
mais eficazes do que outras no sentido de evitar
reaberturas?(em andamento)
32
4 olhos
33
4 olhos
• Hipótese: bugs verificados por outra pessoa (4 olhos) estão menos sujeitos a serem reabertos (depois da verificação)
33
4 olhos
• Hipótese: bugs verificados por outra pessoa (4 olhos) estão menos sujeitos a serem reabertos (depois da verificação)
• Dados: 34 subprojetos do Eclipse
33
4 olhos
• Hipótese: bugs verificados por outra pessoa (4 olhos) estão menos sujeitos a serem reabertos (depois da verificação)
• Dados: 34 subprojetos do Eclipse
• Método: teste exato de Fisher
33
4 olhos
• Hipótese: bugs verificados por outra pessoa (4 olhos) estão menos sujeitos a serem reabertos (depois da verificação)
• Dados: 34 subprojetos do Eclipse
• Método: teste exato de Fisher
• Resultado: inconclusivo
33
Exemplo de tabela de contingência
não reabriu
reabriu
2 olhos 1985 108
4 olhos 11366 125
• A chance de o bug ser reaberto após a verificação é menor quando...
• ... a verificação é feita pelo time de QA?inconclusivo
• ... a verificação é feita durante a fase de verificação?sim (em 2/4 dos projetos)
• ... uma determinada técnica de verificação é empregada (testes, inspeção etc.)?sim, no caso de inspeção de código no Eclipse/Platform
35
Misc
36
Mostrar
• SQuirreLSQL
• bugview (Ruby + Sinatra)
• R
• DAPSE ’13: Padrões para análise de bug reports
Ferramentas úteis
• Análise de dados
• R. RStudio. KNIME. Weka. Orange.
• Extração de tíquetes
• http://metricsgrimoire.github.com/Bicho/
Recommended