Deep Neural Network (DNN) testing has emerged as an effective way of uncovering erroneous behaviors in DNN models and further enhancing their performance. Research on test input generation has gained much attention from both researchers and practitioners, aiming to expose faults in models. The newly generated inputs subsequently serve as additional training instances for model refinement through retraining. Existing approaches generate test inputs by optimizing an objective function based on testing metrics such as neuron coverage and property-related metrics, and the gradient of the objective is used to perturb seed inputs. However, these approaches pay limited attention to the model’s decision logic, particularly the erroneous decision patterns learned during training. Furthermore, they primarily focus on detecting faults without considering the diversity of detected misbehaviors, which limits the models’ ability to learn diverse features through retraining. To address these limitations, this article introduces SUNTest, a novel test input generation approach designed to detect diverse faults and enhance the robustness of DNN models. SUNTest focuses on erroneous decision-making by localizing suspicious neurons responsible for misbehaviors through the execution spectrum analysis of neurons. To guide input mutations toward inducing diverse faults, SUNTest designs a hybrid fitness function that incorporates two types of feedback derived from neuron behaviors, including the fault-revealing capability of test inputs guided by suspicious neurons and the diversity of test inputs. Additionally, SUNTest adopts an adaptive selection strategy for mutation operators to prioritize operators likely to induce new fault types and improve the fitness value in each iteration. Experiments conducted on eight DNN models demonstrate the effectiveness of SUNTest in fault localization and test input generation. It outperforms existing test input generators in the number of detected faults, uncovering up to 80.9 more distinct fault types. In terms of model enhancement, SUNTest increases the average accuracy improvement by up to 8.04% compared to baseline approaches.

Online programming platforms that offer various programming tasks play a crucial role in helping programmers enhance their coding skills. Programming tasks posted for different application scenarios may follow the same or similar programming patterns in their solutions. This leads programmers to repeatedly write not just the core code of problem-solving, but also the same basic framework and some peripheral code (such as variable declarations and input/output handling) that are needed to make their solutions executable. Repeatedly writing boilerplate or well-mastered algorithmic frameworks wastes time and adds little value for programmers focused on skill-specific practice.Toward this, we propose to develop AdaptGen, a problemadaptive code template generation method for online programming platforms. AdaptGen analyzes and extracts solution patterns from various programming problem solutions (i.e., code accepted by online programming platforms) and generates templates tailored to each problem. More specifically, AdaptGen is built on genetic programming and uses a linear hashing sequence encoding strategy to represent solutions. It incorporates selection, crossover, and de-duplication operators to maintain diversity in the evolution process, and a fitness function tailored to generate solution templates. These templates are then abstracted and structured with a flexible core-code-hiding mechanism, enabling programmers of different experience levels to practice efficiently.We evaluated AdaptGen using two datasets from LeetCode and NowCoder, containing a total of 997 tasks and over 3,200 solution categories. Results show that AdaptGen successfully generates usable templates for 77%-84% of solution categories, with 80% of the templates performing well in manual evaluations. It also outperforms seven advanced representative large language models (LLMs), achieving the best overall performance in template quality, consistency, and generation efficiency. To validate Adapt- Gen’s effectiveness in real-world programming environments, we further conduct a user study involving live coding practice by programmers in online programming platforms, which effectively demonstrated its utility in practical application scenarios.

Decompilation is one of the key techniques in software reverse engineering and is widely used in security-related tasks such as malware analysis and vulnerability detection. Software is typically released in binary form with symbol information stripped. Although decompilers are capable of reconstructing a lot of the information lost during compilation, they often fail to recover meaningful variable names. As a result, the readability of the decompiled code is significantly reduced, severely hindering the efficiency of reverse analysis. To address this problem, we propose a novel variable name recovery approach ReDevar for the decompiled code based on Multi-task Learning (MTL), which takes variable name recovery as the main task and introduces two additional tasks, including data source prediction and name complexity prediction, corresponding to two aspects of semantic understanding and semantic transformation of variables in the decompiled code. Data source prediction simulates the data flow relationship among variable instances, assisting ReDevar better understand the semantics of variables. The name complexity prediction task enables ReDevar to perceive the complexity of the expected variable name at a mask position, obtaining appropriate semantic transformation results. They are both jointly trained with the variable name recovery task to improve the understanding of ReDevar for variable semantics and name composition. We conducted a series of experiments to validate the effectiveness of ReDevar. Experimental results show that ReDevar achieves top- 1 accuracy of $54.44 \%$ on the VarCorpus benchmark dataset, 2.81% and 1.50% higher than the state-of-the-art approaches VarBERT and Resym respectively. In addition, we also evaluated the performance of ReDevar under various conditions, including different dataset splitting strategies, different decompilers, and different optimization levels. The results demonstrate that ReDevar generalizes well across all settings. Furthermore, the ablation study indicates that the two auxiliary tasks we introduced in ReDevar are both beneficial for the variable name recovery task.

Compiler defects, especially optimization defects, pose significant threats to software systems.Diagnosing their root causes is crucial for efficient debugging and fixing but remains highly challenging due to complicated interactions of optimizations and ambiguity in root cause prediction.To address these challenges, in this paper, we propose a novel approach, which leverages a data-driven approach and the strengths of Large Language Models (LLMs) for automated root cause analysis and prediction.Specifically, we first extract and iteratively summarize the debugging information from historically fixed optimization defects, and ultimately construct a systematic taxonomy with eight root cause categories.Then, based on this taxonomy, we propose SRLRF, which leverages a domain-specific LLM (i.e., RTA) and a general-purpose LLM (i.e., Llama3.1) to achieve multiple root cause categories' prediction.Finally, SRLRF integrates stacking ensemble learning to train the prediction model to improve prediction performance.The experimental results on 5,573 GCC optimization defects show that SRLRF is able to accurately predict the root causes of 63.11 % optimization defects, and significantly outperforms four baselines with the average improvements ranging from 16.98 % to 179.99 %. CCS Concepts• Software and its

Vulnerabilities have become one of the most serious threats to software.In order to mitigate the impact of software vulnerabilities, researchers have continuously proposed vulnerability detection approaches.Although these investigations have achieved significant success, there is still room for improvement.Traditional approaches rely on code sequences or code graphs to extract the general characteristics of code, containing excessive information that is irrelevant to vulnerabilities.Meanwhile, traditional single-model approaches are hard to handle the multiangle vulnerability information, lacking the ability to effectively detect vulnerabilities.To address the above two problems, we proposed a new vulnerability detection approach, i.e., VDLS.It first selects the execution paths with the related entities of vulnerabilities from the constructed Control Flow Graph (CFG) of the source code.Then, it combines the code sequence and the execution paths as the intermediate representation, which can capture the features of the source code from the perspectives of structures and semantics.Next, we employ a dual model (TextCNN and Transformer) to learn the local and global features based on the intermediate representation.Finally, we design a fusion method to separately fuse the weights of local and global features, aiming to achieve more accurate vulnerability detection results.To evaluate VDLS, we conducted experiments on two widely used public datasets, including FFMPeg+Qemu and Reveal.The experimental results show that VDLS achieves 0.76% ∼ 15.97%, 3.07% ∼ 53.61% improvement on the FFMPeg + Qemu dataset and 0.61% ∼ 8.46%, 2.55% ∼ 39.13% improvement on the Reveal dataset compared to * Corresponding author.

During software maintenance and evolution, developers spend more than half of their time on code comprehension activities. In order to understand an unfamiliar code base, they would naturally ask different types of questions related to code snippets and try to find the answers. In this paper, we conduct an initial work to explore the possibility of automatic question generation for program comprehension. We construct a large-scale data set containing pairs of source code and questions that are automatically transformed from inline comments based on dependency analysis and semantic role labeling. We also build a comprehensive taxonomy of question types so as to generate questions concerning different aspects of code snippets, such as purpose, implementation details and so on. Then, we propose a deep learning-based prototype CodeQG to automatically generates multiple types of questions for code snippets. We evaluate CodeQG by using both typical performance metrics and manual evaluation. The results show that (1) we can achieve a value of 42.02 on BLEU4 and 60.81 on ROUGE-L for the generated questions; (2) overall, the questions are very correct in grammatical, semantic and format; (3) the questions are related to the corresponding code snippet and are helpful for developers in source code comprehension activities. Our work gives insights into automatically generating multiple types of questions for code comprehension. We expect this exploration will improve the applicability and generality of machine code comprehension.

Context: Bug localization is a key step in bug fixing. Despite considerable progress, existing bug localization techniques still perform unsatisfactorily in situations where the complete fix to a bug involves touching multiple buggy code files. That is, for such bugs, those techniques tend to locate correctly only one or at least not all buggy code files, leaving other buggy code files undetected. Objective: This study aims to improve bug localization in cases where resolving a bug requires modifications to multiple buggy code files by proposing HitMore to rank more truly buggy files higher in the recommendation list. Method: The basic idea of HitMore is to attempt to retrieve a subset of truly buggy code files first, then use these files to retrieve other buggy code files based on code relation analysis. For the first part, we designed three kinds of domain-specific features to build a machine-learning model to identify the truly buggy code file subset. For the second part, we make use of three types of code relations between the code base and the buggy file subset to better retrieve the remaining truly buggy code files. Results: The experiments on six widely open-source projects show that: Our technique is effective in identifying the subset of truly buggy code files, with a weighted prediction F1-Score of 86.1%–92.1%. By leveraging the code relations to the retrieved subset and the code base, our HitMore could retrieve all truly buggy code files for 29.31%–69.56% of bugs across six projects. For multiple-buggy-code-file bugs, HitMore could completely localize such bugs by up to 15.38%, 19.36%, and 11.86% more than three representative IRBL baselines across six projects. Conclusion: The experimental results demonstrate the potential of HitMore in reducing developers’ burden of locating and further fixing relatively complex bugs such as those with multiple buggy code files in practice.

With the aim to help developers better localize bugs, Researchers propose a series of text retrieval bug localization (TRBL) techniques. Such techniques take bug localization as an information retrieval task with a bug report being a query, all code elements being the document corpus, and the retrieved recommended documents being potential buggy code elements. Like any textual retrieval-based recommendation system, the success of TRBL techniques also largely depends on the quality of queries, i.e., bug reports. Knowing in advance whether a query would lead to relevant results (buggy code) is important for developers so that they can for example decide whether they should reformulate the query before wasting limited resources in checking irrelevant results. To this end, we propose an automatic query quality prediction approach for text retrieval-based bug localization. We take it as a typical classification task, by first collecting six categories of features evolving different aspects of bug reports and code, and then applying classical machine learning algorithms to build models to predict whether a bug report query would retrieve relevant buggy code. Through experiments on six projects, our approach could obtain an average accuracy of 72-91%, and F1 score of 71-91% over different TRBL techniques, and outperform existing techniques on average by 6-10.6% in accuracy, and 5.3-11.1% in F1 scores. We further explore the importance of different feature subsets and find several common features that contribute most to prediction performance.

As a fundamental component of software documentation, code comments could help developers comprehend and maintain programs. Several datasets of method header comments have been proposed in previous studies for machine learning-based code comment generation. As part of code comments, inline code comments are also crucial for code understanding activities. However, unlike method header comments written in a standard format and describing the whole method code, inline comments are often written in arbitrary formats by developers due to timelines pressures and different aspects of code snippets in the method are described. Currently, there is no large-scale dataset used for inline comments generation considering these. Hence, this naturally inspires us to explore whether we can construct a dataset to foster machine learning research that not only performs fine-grained noise-cleaning but conducts a taxonomy of inline comments. To this end, we first collect inline comments and code snippets from 8000 Java projects on GitHub. Then, we conduct a manual review to obtain heuristic rules, which could be used to clean the data noise in a fine-grained manner. As a result, we construct a large-scale benchmark dataset named ICG with 5,740,770 pairs of inline comments and code snippets. We then build a comprehensive taxonomy and conduct a statistical and manual analysis to explore the performances of different categories of inline comments, such as helpfulness in code understanding. After that, we provide and compare several baseline models to automatically generate inline comments, such as CodeBERT, to enhance the usability of the benchmark for researchers. The availability of our benchmark and baselines can help develop and validate new inline comment generation methods, which would also further facilitate code understanding activities.

The ellipsis of the syntactic structure is a common phenomenon in ordinary textual documents. Existing studies have found that despite syntactic ellipsis could help avoid repetition of normative documents, it could also, for example, lead to ambiguity and hamper the understandability of document contents. As a fundamental component of software, code comments are generally written by developers in a non-structured way just like normative documents. This naturally inspires us to explore whether syntactic ellipsis is also a common phenomenon in code comments and what potential negative effects would such ellipsis have on software tasks such as code/comments comprehension activities. Such explorations, in our opinion, are expected to facilitate the research on code comments and comments-related software tasks. To this end, we conduct the first large-scale study to explore the syntactic structure ellipsis problem of code comments, with a focus on Java inline comments. Specifically, we construct a data set of 1,000 Java projects with 1,307,457 inline comments and associated codes. Based on this data set, we first study the prevalence of syntactic structure ellipsis in inline comments. We find that syntactic structure ellipsis is quite common in inline comments where 83.6% comments have structure ellipsis (such as subject/predicate omissions). Then, we investigate the effects of syntactic structure ellipsis on code/comment understanding activities. As a result, we find that there indeed exists a negative relationship between them, with a medium effect size. Based on these findings, we further propose neural network based approaches to complete the ellipsis parts for the inline comments. With our approach, we could achieve: 1) a medium improvement in assisting code/comment understanding activities, and 2) a substantial improvement of 11.3% in comment-assisted code abbreviation extension task.

Identifiers play an important role in helping developers comprehend and maintain source code. In practice, developers usually employ two widely-used identifier styles, i.e., snake case and camel case, to format identifiers to make them understandable and informative. Despite researchers have empirically investigated the impacts of identifier styles on code comprehension activities, the usage and evolution of identifier styles, however, have not been fully explored. How are individual identifier styles formed in practice? How would identifier styles change and evolve? What are the potential impacts of identifier style-changes? Questions like these are important but have not been fully answered yet. In this paper, we conducted an empirical study on 9,792 GitHub projects to gain some insights into these problems. Specifically, we first analyzed how different identifier styles were formed in real software projects. Next, we explored the change patterns of identifier styles along with the project evolution. Finally, we investigated the potential impacts as well as categories of identifier style-changes. Our empirical results achieved some interesting findings. For example, we first reported some identifier style-change patterns (e.g., snake case →camel case → snake case), which could help developers resolve style-change problems in practice. Our study also provided some hints for researchers and developers when they use specific identifier styles in programs. For example, when researchers explore the impacts of identifier styles on code comprehension, they are suggested to consider the imbalanced distribution phenomenon of individual identifier styles. Besides, it is worthwhile for developers to build an identifier style-change prediction and propagation tool to reduce the style-change costs.

During the process of software development and maintenance, developers would regularly refactor existing source code to improve efficiency and maintainability. Among various code refactoring activities, method renaming often happens within the whole project evolution process. To perform method renaming, developers should first identify the exact methods that should be renamed, which is generally tedious and error-prone through manual analysis. Towards this end, researchers have proposed some approaches to automatically recommend candidate methods for renaming. To further improve the performance of existing techniques, in this paper, we propose a novel approach that fully leverages historical code changes and overlapping relationships among code entities to identify renaming opportunities for methods. Specifically, we first embed methods into vectors and incorporate overlapping relationships among code entities by using different attention heads in a deep learning network. Then, we apply these obtained vectors to train a classifier to predict potential renaming opportunities for methods. Finally, we utilize historical renaming activities of related code entities to further refine the predicted results. Experimental results on 114,398 methods from 10 open source Java projects show that our approach could outperform the state-of-the-art approach by achieving an average F-measure of 80.02%. To better validate the effectiveness of our approach, we also explore the performance of some major components of our approach. For example, we find that employing related code entities help to improve the performance of our approach by 40.40% in terms of the average F-measure.

Smart contract, a term which was originally coined to refer to the automation of legal contracts in general, has recently seen much interest due to the advent of blockchain technology. Recently, the term is popularly used to refer to low-level code scripts running on a blockchain platform. Our study focuses exclusively on this subset of smart contracts. Such smart contracts have increasingly been gaining ground, finding numerous important applications (e.g., crowdfunding) in the real world. Despite the increasing popularity, smart contract development still remains somewhat a mystery to many developers largely due to its special design and applications. Are there any differences between smart contract development and traditional software development? What kind of challenges are faced by developers during smart contract development? Questions like these are important but have not been explored by researchers yet. In this paper, we performed an exploratory study to understand the current state and potential challenges developers are facing in developing smart contracts on blockchains, with a focus on Ethereum (the most popular public blockchain platform for smart contracts). Toward this end, we conducted this study in two phases. In the first phase, we conducted semi-structured interviews with 20 developers from GitHub and industry professionals who are working on smart contracts. In the second phase, we performed a survey on 232 practitioners to validate the findings from the interviews. Our interview and survey results revealed several major challenges developers are facing during smart contract development: (1) there is no effective way to guarantee the security of smart contract code; (2) existing tools for development are still very basic; (3) the programming languages and the virtual machines still have a number of limitations; (4) performance problems are hard to handle under resource constrained running environment; and (5) online resources (including advanced/updated documents and community support) are still limited. Our study suggests several directions that researchers and practitioners can work on to help improve developers’ experience on developing high-quality smart contracts.

With the wide-spread use of Android applications in people's daily life, it becomes more and more important to timely identify the security problems of these applications. To enrich existing studies in guarding the security and privacy of Android applications, we attempted to predict the security risk levels of Android applications. Specifically, we proposed an approach that incorporated Android code smells into traditional Java code metrics to predict how secure an Android application is. With an evaluation of our technique on 3,680 Android applications, we found that: (1) Android code smells could help improve the performance of security risk prediction of Android applications; (2) By building a Random Forest model based on Android code smells and Java code metrics, we could achieve an Area Under Curve (AUC) of 0.97; (3) Android code smells such as member ignoring method (MIM) and leaking inner class (LIC) have a relatively-large influence on Android security risk prediction, to which developers should pay more attention during their application development.

Bug reports play an important role in the process of debugging and fixing bugs. To reduce the burden of bug report managers and facilitate the process of bug fixing, a great amount of software engineering research has been invested toward automated bug report management techniques. However, the verdict is still open whether such techniques are actually required and applicable outside the domain of theoretical research. To fill this gap, we conducted a survey among 327 practitioners to gain their insights into various categories of automated bug report management techniques. Specifically, we asked the respondents to rate the importance of such techniques and provide the rationale. To get deeper insights into practitioners' perspective, we conducted follow-up interviews with 25 interviewees selected from the survey respondents. Through the survey and the interviews, we gained a better understanding of the perceived usefulness (or its lack) of different categories of automated bug report management techniques. Based on our findings, we summarized some potential research directions in developing techniques to help developers better manage bug reports.

Branching is often used to help developers work in parallel during distributed software development. Previous studies have examined branch usage in practice. However, most studies perform branch analysis on industrial projects or only a small number of open source software (OSS) systems. There are no broad examinations of how branches are used across OSS communities. Due to the rapidly increasing popularity of collaboration in OSS projects, it is important to gain insights into the practice of branch usage in these communities. In this paper, we performed an empirical study on branch usage for 2,923 projects developed on GitHub. Our work mainly studies the way developers use branches and the effects of branching on the overall productivity of these projects. Our results show that: 1) Most projects use a few branches (<;5) during development; 2) Large scale projects tend to use more branches than small scale projects. 3) Branches are mainly used to implement new features, conduct version iteration, and fix bugs. 4) Almost all master branches have been requested by contributors to merge their contributions; 5) There always exists a branch playing a more important role in merging contributions than other branches; 6) Almost all commits of more than 75% branches are included in the master branches; 7) The number of branches used in a project has a positive effect on a project's productivity but the effect size is small, and there is no statistically significantly difference between personal projects and organizational projects.

Issue reports and Pull Requests (PRs) are two important kinds of artifacts of software projects in GitHub. It is common for developers to leave explicit links in issues/PRs that refer to the other issues/PRs during discussions. Existing studies have demonstrated the value of such links in identifying complex bugs and duplicate issue reports. However, there are no broad examinations of why developers leave links within issues/PRs and the potential impact of such links on software development. Without such knowledge, practitioners and researchers may miss various opportunities to develop practical techniques for better solving bug-fixing or feature implementation related tasks. To fill this gap, we conducted the first empirical study to explore the characteristics of a large number of links within 642,281 issues/PRs of 16,584 popular (>50 stars) Python projects in GitHub. Specifically, we first constructed an Issue Unit Network (IUN, we refer to issue reports or PRs as issue units) by making use of the links between issue units. Then, we manually checked a sample of 1,384 links in the IUN and concluded six major kinds of linking relationships between issue units. For each kind of linking relationships, we presented some common patterns that developers usually adopted while linking issue units. By further analyzing as many as 423,503 links that match these common patterns, we found several interesting findings which indicate potential research directions in the future, including detecting cross-project duplicate issue reports, using IUN to help better identify influential projects and core issue reports.

GitHub is a widely used collaborative platform for global software development. A pull request plays an important role in bridging code changes with version controlling. Developers can freely and parallelly submit pull requests to base branches and wait for the merge of their contributions. However, several developers may submit pull requests to edit the same lines of code; such pull requests result in a latent collaborative conflict. We refer such pull requests that tend to change the same lines and remain open during an overlapping time period to as competing pull requests. In this paper, we conduct a study on 9,476 competing pull requests from 60 Java repositories in GitHub. The data are collected by mining pull requests that are submitted in 2017 from top Java projects with the most forks. We explore how multiple pull requests change the same code via answering four research questions, including the distribution of competing pull requests, the involved developers, the changed lines of code, and the impact on pull request integration. Our study shows that there indeed exist competing pull requests in GitHub: in 45 out of 60 repositories, over 31% of pull requests belong to competing pull requests; 20 repositories have more than 100 groups of competing pull requests, each of which is submitted by over five developers; 42 repositories have over 10% of competing pull requests with over 10 same lines of code. Meanwhile, we observe that attributes of competing pull requests do not have strong impacts on pull request integration, comparing with other types of pull requests. Our study provides a preliminary analysis for further research that aims to detect and eliminate conflicts among competing pull requests.

Bug fixing is one of the most important activities in software development and maintenance. A software project often employs an issue tracking system such as Bugzilla to store and manage their bugs. In the issue tracking system, many bugs are invalid but take unnecessary efforts to identify them. In this paper, we mainly focus on bug fixing rate, i.e., The proportion of the fixed bugs in the reported closed bugs. In particular, we study the characteristics of bug fixing rate and investigate the impact of a reporter's different contribution behaviors to the bug fixing rate. We perform an empirical study on all reported bugs of two large open source software communities Eclipse and Mozilla. We find (1) the bug fixing rates of both projects are not high, (2) there exhibits a negative correlation between a reporter's bug fixing rate and the average time cost to close the bugs he/she reports, (3) the amount of bugs a reporter ever fixed has a strong positive impact on his/her bug fixing rate, (4) reporters' bug fixing rates have no big difference, whether their contribution behaviors concentrate on a few products or across many products, (5) reporters' bug fixing rates tend to increase as time goes on, i.e., Developers become more experienced at reporting bugs.

Software companies spend over 45 percent of cost in dealing with software bugs. An inevitable step of fixing bugs is bug triage, which aims to correctly assign a developer to a new bug. To decrease the time cost in manual work, text classification techniques are applied to conduct automatic bug triage. In this paper, we address the problem of data reduction for bug triage, i.e., how to reduce the scale and improve the quality of bug data. We combine instance selection with feature selection to simultaneously reduce data scale on the bug dimension and the word dimension. To determine the order of applying instance selection and feature selection, we extract attributes from historical bug data sets and build a predictive model for a new bug data set. We empirically investigate the performance of data reduction on totally 600,000 bug reports of two large open source projects, namely Eclipse and Mozilla. The results show that our data reduction can effectively reduce the data scale and improve the accuracy of bug triage. Ourwork provides an approach to leveraging techniques on data processing to form reduced and high-quality bug data in software development and maintenance.

Developers build all the software artifacts in development. Existing work has studied the social behavior in software repositories. In one of the most important software repositories, a bug repository, developers create and update bug reports to support software development and maintenance. However, no prior work has considered the priorities of developers in bug repositories. In this paper, we address the problem of the developer prioritization, which aims to rank the contributions of developers. We mainly explore two aspects, namely modeling the developer prioritization in a bug repository and assisting predictive tasks with our model. First, we model how to assign the priorities of developers based on a social network technique. Three problems are investigated, including the developer rankings in products, the evolution over time, and the tolerance of noisy comments. Second, we consider leveraging the developer prioritization to improve three predicted tasks in bug repositories, i.e., bug triage, severity identification, and reopened bug prediction. We empirically investigate the performance of our model and its applications in bug repositories of Eclipse and Mozilla. The results indicate that the developer prioritization can provide the knowledge of developer priorities to assist software tasks, especially the task of bug triage.

Bug triage is an important step in the process of bug fixing. The goal of bug triage is to assign a new-coming bug to the correct potential developer. The existing bug triage approaches are based on machine learning algorithms, which build classifiers from the training sets of bug reports. In practice, these approaches suffer from the large-scale and low-quality training sets. In this paper, we propose the training set reduction with both feature selection and instance selection techniques for bug triage. We combine feature selection with instance selection to improve the accuracy of bug triage. The feature selection algorithm X2-test, instance selection algorithm Iterative Case Filter, and their combinations are studied in this paper. We evaluate the training set reduction on the bug data of Eclipse. For the training set, 70% words and 50% bug reports are removed after the training set reduction. The experimental results show that the new and small training sets can provide better accuracy than the original one.