An AST-based Approach To Automatically Classifying Defects

During software development,software will be influenced by many internal and external factors.Therefore,defects are inevitable.In a company,people are often concern about the discovery and fix of software defects and little attention is paid to the classification of software defects.However,it is very important to classify software defects in practice.Classifying software defects can help project managers to better understand the distribution of defect types.This helps to assess the security and stability of a software system and analyze the quality of the software.Furthermore,classifying software defects can also help check where the software being developed satisfies the specified requirements and hence control software quality.Most of the existing methods are manual classifications.A manual classification requires a lot of analysts and the classification result may be affected by the subjective factors of the analysts.In this paper,in order to deal with this challenge,we propose an AST-based approach to automatically classifying defects.We first convert the buggy version code and the fixed version code into two abstract syntax trees.Then,we extract the change features by comparing those two abstract syntax trees.Finally,based on these change features,we classify defects into one of the flowing four categories:data,computational,interface,and control/logic.We evaluated the proposed classification method on 1174 defects collected from the SVN/Jira repositories of three software systems:Mapreduce,Tomcat6,and Solr.We manually assigned defect types to those 1174 defects and use them as the ground truths to conduct the evaluation experiment.The results show that our proposed AST-based defect classification approach has a good classification performance for the defects of interface and control/logic types.In the experiment,the precision scores are in the ranges of 0.72-0.86 and 0.60-0.78,respectively.Furthermore,we analyze the characteristics of the defects fixing codes in MapReduce,Tomcat6,and Solr.The results show that most defects fixes involve the change of less than 3 modules,while only 7%-22%of defects involve the change of more than three modules.For more than 70%buggy modules,the first line of buggy code occurs in the front of the modules.In particular,it appears that there is a weak correlation between buggy code size and module size.