O documento discute a mineração de repositórios de defeitos durante o desenvolvimento de software. Apresenta os principais tópicos: 1) introdução sobre relatórios de defeitos em sistemas de acompanhamento; 2) criação de tíquetes; 3) mapeamento entre código e defeitos; 4) oportunidades e desafios da mineração de repositórios de defeitos, incluindo viés nos dados.

1. Mineração de
repositórios de defeitos
Oportunidades e Desafios
Rodrigo Souza, 20/12/2012, aula de Evolução de Software

2. Introdução

3. 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
4

5. 5

6. 6

7.    




  
7

8.    




  
FIXED / DUPLICATE / WONTFIX / WORKSFORME / INVALID
7

9. RESOLVED/FIXED
VERIFIED
REOPENED
8

10. Oportunidades e
Desafios

11. Repositório de defeitos
• Repositórios de defeitos têm informações...
• ... sobre o produto (defeitos)
• ... sobre o processo (atividades, interação
entre desenvolvedores)

12. Repositório de defeitos
• Oportunidade de estudar como
características do processo afetam a
qualidade do produto

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

14. 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/

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

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

17. Amostra representativa

18. Amostra representativa

19. Amostra enviesada

20. Outros trabalhos
• Triagem automática de tíquetes
• Detecção de tíquetes duplicados
(Yguaratã)
• Atribuição de tíquetes a desenvolvedores

21. Reabertura de defeitos
• Reabertura => retrabalho
• Trabalhos
• Causa de reabertura
• Predição de reabertura
• Custo da reabertura

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

23. Minha Pesquisa
21

24. Dados
• MSR Challenge 2011 - http://
2011.msrconf.org/msr-challenge.html
• Dump do MySQL do Bugzilla do Eclipse e do
NetBeans

25. Dados

26. Como aproveitar relatórios
de defeito para minerar o
processo de verificação?
Há ruído nos dados?
(Objetivo Específico 1)
24

27. há ruídos nos dados? (RQ1.4)
quando é feita a verificação? (RQ1.1)
quem faz a verificação? (RQ1.2)
como é feita a verificação? (RQ1.3)
25

28. há ruídos nos dados?
verificações em massa
26

29. há ruídos nos dados?
No Eclipse Modelling Framework,VERIFIED significa que o
patch está disponível em uma build.
27

30. quando é feita a verificação?
fase de verificação
28

31. quem faz a verificação?
time de
QA
10
29

32. 20% dos desenvolvedores quem faz a verificação?
time de
QA
10
29

33. 20% dos desenvolvedores quem faz a verificação?
time de
QA
80% das
verificações
10
29

34. como é feita a verificação?
A maioria dos comentários não traz informação sobre a
técnica empregada.
30

35. Resumo
Fase de
✓ ✗
verificação
Time de QA ✗ ✓
Comentários raramente mencionam técnica de verificação.
Cuidado com verificações em massa.
31

36. Será que determinadas
práticas de verificação são
mais eficazes do que outras
no sentido de evitar
reaberturas?
(em andamento)
32

37. 4 olhos
33

38. 4 olhos
• Hipótese: bugs verificados por outra pessoa
(4 olhos) estão menos sujeitos a serem
reabertos (depois da verificação)
33

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

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

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

42. Exemplo de tabela de
contingência
não
reabriu
reabriu
2 olhos 1985 108
4 olhos 11366 125

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

44. Misc
36

45. Mostrar
• SQuirreLSQL
• bugview (Ruby + Sinatra)
•R
• DAPSE ’13: Padrões para análise de bug
reports

46. Ferramentas úteis
• Análise de dados
• R. RStudio. KNIME. Weka. Orange.
• Extração de tíquetes
• http://metricsgrimoire.github.com/Bicho/