skip to main content
research-article

An empirical study on the use of SZZ for identifying inducing changes of non-functional bugs

Published: 01 July 2021 Publication History

Abstract

Non-functional bugs, e.g., performance bugs and security bugs, bear a heavy cost on both software developers and end-users. For example, IBM estimates the cost of a single data breach to be millions of dollars. Tools to reduce the occurrence, impact, and repair time of non-functional bugs can therefore provide key assistance for software developers racing to fix these issues. Identifying bug-inducing changes is a critical step in software quality assurance. In particular, the SZZ approach is commonly used to identify bug-inducing commits. However, the fixes to non-functional bugs may be scattered and separate from their bug-inducing locations in the source code. The nature of non-functional bugs may therefore make the SZZ approach a sub-optimal approach for identifying bug-inducing changes. Yet, prior studies that leverage or evaluate the SZZ approach do not consider non-functional bugs, leading to potential bias on the results. In this paper, we conduct an empirical study on the results of the SZZ approach when used to identify the inducing changes of the non-functional bugs in the NFBugs dataset. We eliminate a majority of the bug-inducing commits as they are not in the same method or class level. We manually examine whether each identified bug-inducing change is indeed the correct bug-inducing change. Our manual study shows that a large portion of non-functional bugs cannot be properly identified by the SZZ approach. By manually identifying the root causes of the falsely detected bug-inducing changes, we uncover root causes for false detection that have not been found by previous studies. We evaluate the identified bug-inducing changes based on three criteria from prior research, i.e., the earliest bug appearance, the future impact of changes, and the realism of bug introduction. We find that prior criteria may be irrelevant for non-functional bugs. Our results may be used to assist in future research on non-functional bugs, and highlight the need to complement SZZ to accommodate the unique characteristics of non-functional bugs.

References

[1]
Bryant RE, O’Hallaron DR (2015) Computer systems: a programmer’s perspective, 3rd edn. Pearson
[2]
Borg M, Svensson O, Berg K, Hansson D (2019) Szz unleashed: an open implementation of the szz algorithm—featuring example usage in a study of just-in-time bug prediction for the jenkins project. In: Proceedings of the 3rd ACM SIGSOFT international workshop on machine learning techniques for software quality evaluation, ser. MaLTeSQuE 2019. Association for Computing Machinery, New York, pp 7–12. [Online]. Available:
[3]
da Costa DA, McIntosh S, Shang W, Kulesza U, Coelho R, and Hassan AE A framework for evaluating the results of the szz approach for identifying bug-introducing changes IEEE Trans Softw Eng 2017 43 7 641-657
[4]
Davies S, Roper M, and Wood M mparing text-based and dependence-based approaches for determining the origins of bugs J Softw: Evol Process 2014 26 01
[5]
Fan Y, Xia X, Alencar da Costa D, Lo D, Hassan AE, Li S (2019) The impact of changes mislabeled by szz on just-in-time defect prediction. IEEE Trans Softw Eng 1–1
[6]
Glinz M (2007) On non-functional requirements. In: 15th IEEE international requirements engineering conference (RE 2007), pp 21–26
[7]
Grubb P, Takang A (2003) Software maintenance—concepts and practice (2nd edn). 01
[8]
Guindon C Swt: the standard widget toolkit. [Online]. Available: https://www.eclipse.org/swt/
[9]
Gyimothy T, Ferenc R, and Siket I Empirical validation of object-oriented metrics on open source software for fault prediction IEEE Trans Softw Eng 2005 31 10 897-910
[10]
Hamill M and Goseva-Popstojanova KExploring the missing link: an empirical study of software fixesSoftw Test Verif Reliab2014248684-705[Online]. Available: https://doi.org/10.1002/stvr.1518
[11]
Hassan AE (2009) Predicting faults using the complexity of code changes. In: 2009 IEEE 31st international conference on software engineering, pp 78–88
[12]
Jin G, Song L, Shi X, Scherpelz J, and Lu S Understanding and detecting real-world performance bugs SIGPLAN Not 2012 47 6 77-88
[13]
Jpace (2018) jpace/diffj. [Online]. Available: https://github.com/jpace/dij
[14]
Kamei Y, Shihab E, Adams B, Hassan AE, Mockus A, Sinha A, and Ubayashi N A large-scale empirical study of just-in-time quality assurance IEEE Trans Softw Eng 2013 39 6 757-773
[15]
Kim M, Lee E (2018) Are information retrieval-based bug localization techniques trustworthy?. In: Proceedings of the 40th international conference on software engineering: companion proceedings, ser. ICSE ’18. Association for Computing Machinery, New York, pp 248–249. [Online]. Available:
[16]
Kim S, Whitehead EJ Jr (2006) How long did it take to fix bugs?. In: Proceedings of the 2006 international workshop on mining software repositories, ser. MSR ’06. ACM, New York, pp 173–174
[17]
Kim S, Zimmermann T, Pan K, Whitehead EJ Jr (2006) Automatic identification of bug-introducing changes. In: 21st IEEE/ACM international conference on automated software engineering (ASE’06), pp 81–90
[18]
Kotonya G, Sommerville I (1998) Requirements engineering: processes and techniques, 1st edn, Wiley Publishing
[19]
LaToza TD, Venolia G, DeLine R (2006) Maintaining mental models: a study of developer work habits. In: Proceedings of the 28th international conference on software engineering, ser. ICSE ’06. ACM, New York, pp 492–501
[20]
Mahrous H, Malhotra B (2018) Managing publicly known security vulnerabilities in software systems. In: 2018 16th Annual conference on privacy, security and trust (PST), pp 1–10
[21]
McHugh M Interrater reliability: the kappa statistic Biochemia medica: časopis Hrvatskoga društva medicinskih biokemičara / HDMB 2012 22 276-82, 10
[22]
McIntosh S and Kamei Y Are fix-inducing changes a moving target? A longitudinal case study of just-in-time defect prediction IEEE Trans Softw Eng 2018 44 5 412-428
[23]
Molyneaux I (2009) The art of application performance testing: help for programmers and quality assurance, 1st edn. O’Reilly Media, Inc.
[24]
Neto C, Barbalho E (2018) Enhancing the szz algorithm to deal with refactoring changes
[25]
Neto E, Costa D, Kulesza U (2018) The impact of refactoring changes on the szz algorithm: an empirical study. 03
[26]
Nistor A, Jiang T, Tan L (2013) Discovering, reporting, and fixing performance bugs. In: 2013 10th Working conference on mining software repositories (MSR), pp 237–246
[27]
Nugroho YS, Hata H, and Matsumoto KHow different are different diff algorithms in git?Empir Softw Eng2019251790-823[Online]. Available: https://doi.org/10.1007/s10664-019-09772-z
[28]
Ohira M, Kashiwa Y, Yamatani Y, Yoshiyuki H, Maeda Y, Limsettho N, Fujino K, Hata H, Ihara A, Matsumoto K (2015) A dataset of high impact bugs: manually-classified issue reports. In: Proceedings of the 12th working conference on mining software repositories, ser. MSR ’15. IEEE Press, Piscataway, pp 518–521
[29]
Pan K, Kim S, and Whitehead EJJr Toward an understanding of bug fix patterns Empir Softw Eng 2009 14 3 286-315
[30]
Ping L, Jin S, Xinfeng Y (2011) Research on software security vulnerability detection technology. In: Proceedings of 2011 international conference on computer science and network technology, vol 3, pp 1873–1876
[31]
Radu A, Nadi S (2019) A dataset of non-functional bugs. In: Proceedings of the 16th international conference on mining software repositories, ser. MSR ’19. IEEE Press, Piscataway, pp 399–403
[32]
Rosen C, Grawi B, Shihab E (2015) Commit guru: analytics and risk prediction of software commits. In: Proceedings of the 2015 10th joint meeting on foundations of software engineering, ser. ESEC/FSE 2015. Association for Computing Machinery, New York, pp 966–969. [Online]. Available:
[33]
Śliwerski J, Zimmermann T, and Zeller A When do changes induce fixes? SIGSOFT Softw Eng Notes 2005 30 4 1-5
[34]
Steidl D, Hummel B, Juergens E (2014) Incremental origin analysis of source code files. In: Proceedings of the 11th working conference on mining software repositories, ser. MSR 2014. Association for Computing Machinery, New York, pp 42–51. [Online]. Available:
[35]
Team J. Eclipse java development tools (jdt). [Online]. Available: https://www.eclipse.org/jdt/
[36]
Williams C, Spacco J (2008) Szz revisited: verifying when changes induce fixes. In: Proceedings of the 2008 workshop on defects in large software systems, ser. DEFECTS ’08. ACM, New York, pp 32–36
[37]
Williams L, McGraw G, and Migues S Engineering security vulnerability prevention, detection, and response IEEE Softw 2018 35 5 76-80
[38]
Zaman S, Adams B, Hassan AE (2011) Security versus performance bugs: a case study on firefox. In: Proceedings of the 8th working conference on mining software repositories, ser. MSR ’11. ACM, New York, pp 93–102

Cited By

View all

Recommendations

Comments

Information & Contributors

Information

Published In

cover image Empirical Software Engineering
Empirical Software Engineering  Volume 26, Issue 4
Jul 2021
1061 pages

Publisher

Kluwer Academic Publishers

United States

Publication History

Published: 01 July 2021
Accepted: 14 April 2021

Author Tags

  1. Bug inducing changes SZZ
  2. Non-functional bugs
  3. Mining software repositories

Qualifiers

  • Research-article

Contributors

Other Metrics

Bibliometrics & Citations

Bibliometrics

Article Metrics

  • Downloads (Last 12 months)0
  • Downloads (Last 6 weeks)0
Reflects downloads up to 27 Dec 2024

Other Metrics

Citations

Cited By

View all

View Options

View options

Media

Figures

Other

Tables

Share

Share

Share this Publication link

Share on social media