A Mahalanobis Distance-Based Integration of
Suspicious Scores For Bug Localization
Masanao Asato∗ , Hirohisa Aman† , Sousuke Amasaki‡ , Tomoyuki Yokogawa‡ and Minoru Kawahara†∗ Graduate School of Sc. & Eng., Ehime University, Matsuyama, Japan† Center for Information Technology, Ehime University, Matsuyama, Japan‡ Faculty of Computer Sc. & Systems Eng., Okayama Prefectural University, Soja, Japan

Abstract—Once a software bug is reported, it is crucial to locate
the source ﬁle causing the bug and ﬁx it as soon as possible. To
this end, there have been various studies for locating bugs withthe version control system and the bug reports. AmaLgam+ is
one of the most promising methods for localizing bugs. Thismethod quantiﬁes the degree to which a source ﬁle causes the
bug from different ﬁve perspectives (metrics), and combines
those values (suspicious scores) into a single integrated score of
the source ﬁle. However, the method has a challenge regarding
the computation time because it uses the genetic algorithm(GA) to combine the above ﬁve metrics. This paper proposes
an application of the Mahalanobis distance to the suspicious
score integration to overcome the above challenge. The proposed
method considers the above ﬁve metrics to be a ﬁve-dimensional
vector. It computes the Mahalanobis distance of the vector fromthe origin as an alternative integrated suspicious score. The
empirical study using six open source software projects provesthat the proposed method has almost the same bug localization
accuracy as AmaLgam+ and can reduce the computation timeby up to 98%: e.g., while AmaLgam+ took about 3.5 hours, theproposed method did it about 4 minutes.
Index Terms—Bug localization, mining software repositories,
Mahalanobis distance, computation time

I. I NTRODUCTION
When a bug is reported to the software development organization, the developers need to localize the faulty (buggy)source ﬁle that causes the reported bug. However, it may not
be easy because the bug report may not always present an
informative clue to detect the buggy ﬁle. Furthermore, largescale and complex software products tend to be plagued bya lot of bug reports [1], [2]. A quick resolution of a newlyreported bug is a crucial challenge in software maintenance.
The detection of buggy ﬁles is referred to as “bug localization,” and various approaches have been studied [3]. In recent
years, many studies focused on information retrieval (IR)techniques, and proposed IR-based bug localization methods
that apply IR methods to the bug reports and the software
repositories [4]–[12]. For instance, some methods analyzed thesimilarity among bug reports using the natural language processing techniques such as tf-idf method and picked alreadyresolved bug reports similar to the new (unresolved) bug report[4], [9], [10]. They then considered the source ﬁles that had
been ﬁxed to resolve those old bugs to be bug-prone ones.
Other methods also focused on various data such as the bugﬁxing history recorded in the code repository, the stack trace
data given in the bug report, the bug report reporter.

Recently, Wang and Lo [7] proposed a promising bug
localization method, AmaLgam+. For a newly-reported bug,
this method evaluates the suspiciousness of a source ﬁle fromﬁve different points of view, i.e., it measures the source ﬁleusing ﬁve different metrics quantifying the degree to which
the source ﬁle causes the reported bug. Then, AmaLgam+
combines these ﬁve evaluation values of a source ﬁle into
an integrated suspicious score by the genetic algorithm (GA).
Wang and Lo empirically proved that AmaLgam+ could
outperform the conventional bug localization methods [7].
Although AmaLgam+ is one of the most promising bug
localization methods, it has a challenge regarding the computational cost. Because AmaLgam+ uses GA to tune theweight coefﬁcients to combine different metric values, it may
require a long tuning time. Moreover, it would be better torerun the tuning whenever the metric data set is updated. To
perform a better bug localization as quickly as possible, weneed to overcome that problem of computation time. Thus, we
propose another way of integrating different metric values inthis paper. Our proposal applies the Mahalanobis distance [13]notion, which is commonly used in anomaly detection studies.
Because it can reasonably integrate different-scale metrics witha low computational cost, we consider the proposed method
can be a lightweight alternative to AmaLgam+.
The remainder of this paper is organized as follows. Section
II describes AmaLgam+, and Section III presents our proposal,
the Mahalanobis distance-based method. Then, Section IV
reports the empirical study that we conducted to examine theusefulness of the proposed method. Finally, Section V gives
the conclusion of this paper and our future work.
II. C ONVENTIONAL M ETHOD : A MA L GAM +In this section, we brieﬂy describe the bug localization by
a conventional method, AmaLgam+ [7]. Once a bug report isgiven, it computes a suspicious score for each source ﬁle; thesuspicious score is computed by combining ﬁve metric values.
A. Metric(1): Version History-Based MetricA version control system (VCS) records the source codechange history made during development and maintenance.
Such a change history may be beneﬁcial to an efﬁcient
bug localization because a prior bug ﬁx may cause anotherbug (fault) [14]. Rahman et al. [15] proposed a lightweight
method for predicting faulty ﬁles by focusing on the bug-ﬁxing

commits in a VCS. Their method has been utilized in largescale software development projects [16]. AmaLgam+ uses
such a metric to quantify the suspicious level (fault-proneness)of a ﬁle. We describe the metric below.
Suppose we have a new (not resolved) bug report and let
R be the set of bug-ﬁxing commits that may relate to thereported bug. A related bug-ﬁxing commit c(∈ R) is a commit
satisfying the following two conditions 1) and 2).
1) The commit log of c includes “ﬁx” or “bug.”2) c was made within the last k days. Because an older
commit would be less likely to cause a newly-reported
bug, this metric focuses only on the recent bug-ﬁxing
commits. Wang and Lo [7] set k to 15 empirically.
Let tc be the elapsed days after commit c. Now the suspicious
score of a ﬁle f , score 1 (f ), is deﬁned as follows:
∑
1
.
(1)
score 1 (f ) =
k−tc
12(1−
k )
c∈R∧f ∈c 1 + e
B. Metric(2): Bug Report Similarity-Based Metric
When two bug reports have similar contents, they may be
associated with each other and require to ﬁx the same ﬁles
to resolve both of the bugs. We apply this notion to the bug
localization. Once we have a new bug report, we pick alreadyresolved bug reports similar to the new one and focus on theﬁles ﬁxed to resolve the above bugs. Those ﬁles may also be
related to the newly-reported bug.
AmaLgam+ quantiﬁes the similarity between bug reports
using the tf-idf method in the following three steps.
1) Pre-processing of bug reports: Extract all tokens froma bug report. If a token is a compound word written
in the camel-case style or the snake-case style, split itinto subwords following the compounding style; Then,
perform the stemming and the stop-word elimination.
2) Vectorization of bug reports: Compute the tf-idf value ofeach word. Then, express each bug report by the multidimensional vector whose elements are the tf-idf valuesof the words appearing in the report.
3) Computation of bug report similarity: Let rnew and roldbe the new bug report and a resolved one, respectively.
Obtain the similarity between them sim(rnew , rold ) as
the cosine similarity between the corresponding vectors.
Next, the suspicious score of a ﬁle is computed using theabove similarity. If rnew is more similar to rold and a ﬁle f
had been ﬁxed to resolve rold , f is more suspicious that it
may also cause the newly-reported bug. Hence, the suspicious
score of f is computed as follows1 :∑sim(rnew , ri )2,(2)
score 2 (f ) =|mod (ri )|ri ∈{r|f ∈mod(r)}where mod (r) is the set of ﬁles ﬁxed to resolve the bug reportr, and {r | f ∈ mod (r)} is the set of bug reports such that
1 Although the original AmaLgam+ [7] did not square the similarity, thispaper adopts the squared version because Rath et al. [10] reported its
superiority.

they had required to ﬁx f in the past. Intuitively, the bug reportsimilarity is the source of the suspicious score and is equallydistributed to the corresponding ﬁles.
C. Metric(3): Structured Information Retrieval-Based Metric
There have been studies that link a bug report to a ﬁleby focusing on their contents. BLUiR [17], one of the mostpromising methods, performs a structured information retrieval
for bug localization. It quantiﬁes the suspicious score of a ﬁleusing the textual similarity between the components of the
bug report and the ﬁle. We describe its computation procedure
below. Suppose we have a new bug report rnew and a ﬁle f .
1) Component extraction from bug report: Extract “summary” part and “description” one from rnew separately.
Let r1 and r2 be the summary part and the description
one of rnew , respectively.
2) Component extraction from source ﬁle: Pick out the classnames, the method names, the variable names, and thecomments appearing in f . Let f1 , f2 , f3 , and f4 be thesecomponents of the ﬁle, respectively.
3) Vectorization of components: Vectorize each of the above
six components (r1 , r2 , f1 , f2 , f3 , and f4 ) by the same
way as the above metric described in Sect. II-B.
4) Suspicious score computation: Compute the cosine similarity for each pair of a bug report’s component and aﬁle’s one, and obtain the suspicious score of f :score3 (f ) =

4
2 ∑
∑

sim(ri , fj ) .

(3)

i=1 j=1

D. Metric(4): Stack Trace-Based Metric
Schroter et al. [18] reported an empirical study that proved
the worth of stack trace in locating the corresponding bugs.
Therefore, when a bug report includes the stack trace, it
is beneﬁcial to pay attention to it. We describe the metricfor quantifying the suspiciousness of a ﬁle below. Although
the following description assumes the Java environment, we
can deﬁne similar metrics for other languages without losing
generality if their stack traces provide the ﬁle names.
1) Extraction of ﬁle names from bug report: Suppose thenew bug report rnew includes a stack trace. Extract all
ﬁle names appearing in it.
2) Ranking of source ﬁles: Rank the extracted ﬁles indescending order of appearance. The more times the ﬁleappears in the stack trace, the higher rank it gets.
3) Suspicious score computation: Compute the suspicious
score of a ﬁle f as:
1
, (f appears in rnew ),rank (f, rnew )score4 (f ) =0,(otherwise),(4)
where rank (f, rnew ) is the rank of ﬁle f , obtained in
the above process.

E. Metric(5): Bug Reporter-Based Metric
A user sometimes pays attention to certain functionality.
When the same user reported two or more bug reports, thesebugs may be related to each other. They may be caused by thesame ﬁle or the ones in the same package. We can compute thesuspicious score of a ﬁle using the above tendency as follows.
1) Search of related bug reports: Suppose we have a new
bug report rnew that is submitted by a user. Search all
already-resolved bug reports that were also submitted by
the same user; Let Rsu be the set of these bug reports.
2) Detection of related packages: For each related bug
report r ∈ Rsu , pick all ﬁles that were ﬁxed to resolver, and let Pa (r) be the set of the packages to whichthese ﬁles belong.∪
Then, let Pall be the set of the related
packages: Pall = r∈Rsu Pa (r) .
3) Suspicious score computation: Compute the suspicious
score of a ﬁle f as follows.
{
1, (f is in Pall ),score5 (f ) =(5)0, (otherwise) .

Notice that different bug reports may have different AP
values. The mean AP (MAP) is obtained as:
1 ∑
APi ,
N i=1
N

MAP =

where N is the number of bug reports, and APi is AP
value of the i-th bug report (for i = 1, . . . , N ).
• Mean Reciprocal Rank (MRR): MRR focuses on thehighest rank among the buggy ﬁles and uses the reciprocal rank (MR) as an evaluation value. The higher rank abuggy ﬁle places, the higher the evaluation value is. The
mean MR (MRR) is obtained as follows.
1 ∑ 1
,
MRR =
N i=1 rank iNwhere wi is the weight coefﬁcient representing the degree towhich score i contributes to f ’s combined suspiciousness (fori = 1, . . . , 5); These weights have to be tuned well.
AmaLgam+ uses the genetic algorithm (GA) [19] to tune theabove weights w1 –w5 . GA is one of the most useful algorithms
to decide parameters to maximize the objective function. We
can perform it using the GA package2 of R.
GA needs the objective function that evaluates bug localization’s effectiveness to explore the optimal or suboptimal
solution. AmaLgam+ considers the following two criteria toorganize the objective function.
• Mean Average Precision (MAP): For a new bug report,
suppose we have n ﬁles ranked by the bug localization method, and m ﬁles are truly buggy. Let P(k) be
the precision at the top k ﬁles, i.e., P(k) = (number of buggy ﬁles ranked in top k)/k. The average
precision, AP, is deﬁned as follows.
1 ∑P(k) · I(k) ,
AP =
m
n

k=1

where I(k) = 1 when the ﬁle ranked at k is buggy;otherwise, I(k) = 0.
2 https://cran.r-project.org/web/packages/GA/(8)where rank i is the highest rank of buggy ﬁle for the i-th
bug report (for i = 1, . . . , N ).
Then, AmaLgam+ uses the following objective function:
ObjFunction = eMAP+MRR .

F. Metrics Integration in AmaLgam+
AmaLgam+ integrates the above ﬁve metrics to evaluate thesuspiciousness of a ﬁle f . It sorts all ﬁles in descending orderof the integrated score and suggests the highly-ranked ﬁles as
the ones most likely buggy. The integrated suspicious score ofa ﬁle f , susp(f ), is deﬁned as follows [7].
 5
∑



wi · score i (f ), (score 2 (f ) > 0
susp(f ) = i=1∨ score 3 (f ) > 0) (6)0,(otherwise) ,

(7)

(9)

III. P ROPOSED M ETHOD
AmaLgam+ uses the ﬁve metrics and integrates them using
GA. Although AmaLgam+ performs well, it has a challenge
regarding the computational cost. When we turned the weight
coefﬁcients of the metrics using an average personal computer,it took over three hours in the worst case. Such a long time
motivated us to propose another way of integrating metrics.
All of the above ﬁve metrics evaluate the suspicious degree
to which a ﬁle is buggy. Moreover, the higher value each of themetrics has, the more suspicious the ﬁle is. Now we express
a ﬁle as the ﬁve-dimensional vector whose elements are thecorresponding metric values, x = (score 1 , . . . , score 5 )T , andconsider its distance from the origin in the vector space.
Intuitively, the farther ﬁle is more suspicious. That is, thedistance can be yet another integrated suspicious score.
Although Euclidean distance is a common distance metric,
it is not reasonable in our scenario because it does not consider
the data dispersion and the correlations. Thus, we propose touse Mahalanobis distance [13] in this paper. To give an intuitive interpretation of it, let us consider a scholar data x whosemean value is 0, and the standard
deviation is σ. Mahalanobis√
distance between x and 0 is (x − 0)2 /σ. That is the distancenormalized by the data dispersion. By generalizing this notion
to multi-dimensional vectors, Mahalanobis distance between
x and 0, d(x), is computed as:√
d(x) = xT S −1 x ,(10)where S is the variance-covariance matrix, and S −1 is theinverse matrix of S.
The computation of Mahalanobis distance is just a matrix
calculation3 and does not require any parameter tuning. Hence,
we can perform it much faster than GA. Suppose the proposed
3 We can perform it using stats package of R.

(Mahalanobis distance-based) method can perform at almost
the same level of accuracy as GA-based AmaLgam+. In thatcase, it can play a lightweight alternative to AmaLgam+ andbe a solution to its challenge regarding the computational cost.
IV. E MPIRICAL S TUDY
In this section, we report the empirical study to examine our
proposal. We describe the aim and the dataset in Sect. IV-Aand explain the procedure in Sect. IV-B. Then, we present theresults and our discussions in Sect. IV-C. Finally, we describe
the threats to validity in Sect. IV-D.
A. Aim and Dataset
As we mentioned above, AmaLgam+ has a challenge regarding the computational cost, and we have proposed theMahalanobis distance-based method to overcome the problem.
In this study, we perform the bug localization by AmaLgam+
and the proposed method, comparing the results in terms of (1)accuracy and (2) computation time. If the proposed method canperform much faster than AmaLgam+ while having the bug
localization accuracy at almost the same level as AmaLgam+,the proposed method can be a useful alternative method.
We use a part of the datasets provided by Rath and Patrick4 :the bug reports (labeled as “bug” or “improvement”) submitted
to six open source software projects shown in Table I. Although the datasets do not include the source ﬁles, we obtained
them from their repositories available at GitHub.
We carried out all of our data processing and computations
on the personal computer whose CPU is Intel Core i5-9400,
memory size is 32GB, and OS is Windows 10.
B. Procedure
We performed the following procedure for each project.
1) Metrics computation: For each bug report and source
ﬁle, we compute the values of the above ﬁve metrics.
2) Suspicious score computation: We combine the metricvalues to get the integrated suspicious score for each ﬁleby AmaLgam+ and the proposed method independently.
We also measure the elapsed time to ﬁnish all computations. In AmaLgam+, to tune the weight coefﬁcients, we
randomly sampled 5% of the bug reports and run GA
with the parameters5 maxiter=200, popsize=50,

TABLE IDATASETS USED IN THIS STUDY
Project
Railo
IzpackLog4j2Weld
Hornetq
Seam2

Number of reports
529
402
676
657
481
784

KLOC
241
89
72
63
171
106

Data collection period
2008-11 — 2013-12
2009-01 — 2016-01
2008-12 — 2017-04
2009-01 — 2017-03
2006-05 — 2015-06
2005-08 — 2014-03

4 https://dataverse.harvard.edu/dataset.xhtml?persistentId=doi:10.7910/DVN/PDDZ4Q
5 The values of maxiter and popsize are the same as the ones used in[7]; We set the value of run based on the tutorial of the package.

and run=100. We include the parameter tuning timein the computation time mentioned above.
3) Accuracy evaluation: For each bug report, we evaluate
the bug localization accuracy by AmaLgam+ and the
proposed method, respectively. We adopt Top@k measures [20] and use Top1, Top5, and Top10 accuracy.
C. Results and Discussions
Table II shows the bug localization accuracy. Although theproposed method does not outperform AmaLgam+, it shows
almost the same accuracy: While AmaLgam+ outperformed
the proposed method in 12 cases (e.g., Top1 in Log4j2), theproposed method did in 5 cases (e.g., Top5 in Ralio); theremaining one case (Top10 in Hornetq) was a tie.
Table III presents the comparison of the computation times
between AmaLgam+ and the proposed method. While AmaLgam+ took 12, 782 seconds (about 3.55 hours) in the worst
case (Ralio project), the proposed ﬁnished within 246 seconds(about 4 minutes). That is, the proposed method reduced
the computation time by about 98%. The average rate oftime reduction is about 97%. Hence, the proposed method
successfully performs the bug localization much faster than
AmaLgam+ while not seriously losing the accuracy.
AmaLgam+ tunes the weight coefﬁcients of the ﬁve suspicious metric values to maximize the predeﬁned objective function. On the other hand, the proposed method simply computes
the distance from the origin as the combined suspicious score
while considering the metric data dispersion and the correlations between metrics. In this sense, GA-based AmaLgam+ is
a supervised learning method, and the Mahalanobis distancebased method is an unsupervised learning one. Because theproposed method does not perform any parameter tuning, it
has a risk of producing a useless integrated score if one of themetrics does not work well for locating bugs. In other words,
GA can minimize such a risk by giving a smaller weight tothe useless metric through tuning. Such a difference might

TABLE II
T OP 1, T OP 5, AND T OP 10 ACCURACY (%)
Project
Railo
IzpackLog4j2Weld
Hornetq
Seam2

Top1
17.61
29.03
30.18
16.44
18.26
12.75

AmaLgam+
Top5 Top10
35.98
45.45
52.85
61.54
56.95
65.38
35.46
44.44
33.82
36.93
26.10
32.84

Proposed method
Top1
Top5 Top10
16.48 39.39
48.67
24.07 48.64
59.31
27.37 58.28
67.90
16.74 31.51
40.79
15.15 31.95
36.93
10.54 22.06
27.21

TABLE IIIC OMPARISON OF COMPUTING TIMES
Project
Railo
IzpackLog4j2Weld
Hornetq
Seam2

elapsed time (sec)(a) AmaLgam+(b) proposed method
12, 782
246
1, 09024
2, 70968
1, 02431920
36
1, 724109(a)−(b)(a)98.08%
97.80%
97.49%
96.97%
96.09%
93.68%

cause the loss of bug localization accuracy shown in Table
II. Nonetheless, the empirical results did not show severe
deterioration in accuracy. That is, it successfully maintains
almost the same accuracy and reduces the computation time
dramatically (reduced by about 97% on average).
We used the notion of Mahalanobis distance to integratedifferent metrics for bug localization reasonably and overcomes AmaLgam+’s challenge regarding computational cost.
However, our method is not only for AmaLgam+; i.e., it canbe applied to other bug localization methods. There have beenvarious bug localization methods using IR, spectrum analysis,or program analysis techniques [4], [21]–[27]. Because manymethods utilize two or more metrics for bug localization, we
can apply our integration method to those bug localization
methods without any changes. A further comparative study is
our signiﬁcant future work.
D. Threats to Validity
Construct validity: The parameter setting of GA would
affect the computational results. If we run the GA computation
with a different parameter, we may obtain a different result.
Although we used the same parameter as the previous work[7], it would be better to tune the settings as well.
External validity: Because we used only six Java projects,
the proposed method may not work well for another project.
To mitigate this threat, we would also need to perform a further
study using various projects written in other than Java.
V. C ONCLUSION AND F UTURE W ORK
AmaLgam+ is a promising bug localization method, which
combines ﬁve metrics into a suspicious score of a sourceﬁle. However, because AmaLgam+ uses GA to decide theweight coefﬁcients of metrics, it tends to need a long time fortuning the weights. To reasonably integrate these metrics witha low cost, we proposed a Mahalanobis distance-based method.
Then, we empirically proved that the proposed method could
reduce the computation time by about 97% on average without
severe loss of the bug localization accuracy. Thus, it would bea lightweight alternative to AmaLgam+.
Our future work is to enhance the accuracy of the proposed
method, i.e., narrow the accuracy gap with AmaLgam+. We
plan to further study the contribution of each metric andincorporate the study results into the computation of Mahalanobis distance toward a better and fast bug localization. A
further comparative study using various methods other than
AmaLgam+ is also our signiﬁcant future work.
ACKNOWLEDGMENT
This work was supported by JSPS KAKENHI #18K11246
and #20H04184.
R EFERENCES[1] C. Sun, D. Lo, X. Wang, J. Jiang, and S.-C. Khoo, “A discriminativemodel approach for accurate duplicate bug report retrieval,” in Proc.
32nd ACM/IEEE Int. Conf. Softw. Eng., vol. 1, May 2010, pp. 45–54.
[2] N. Bettenburg, R. Premraj, T. Zimmermann, and S. Kim, “Duplicate bug
reports considered harmful ... really?” in In Proc. 24th IEEE Int. Conf.
Softw. Maintenance, Oct. 2008, pp. 337–345.

[3] W. Wong, R. Gao, Y. Li, R. Abreu, and F. Wotawa, “A survey on
software fault localization,” IEEE Trans. Softw. Eng., vol. 42, pp. 707–
740, Aug. 2016.
[4] J. Zhou, H. Zhang, and D. Lo, “Where should the bugs be ﬁxed?
more accurate information retrieval-based bug localization based on bug
reports,” in Proc. 34th Int. Conf. Softw. Eng., June 2012, pp. 14–24.
[5] S. Wang and D. Lo, “Version history, similar report, and structure:
Putting them together for improved bug localization,” in Proc. 22ndInt. Conf. Program Comprehension, May 2014, pp. 53–63.
[6] Q. Wang, C. Parnin, and A. Orso, “Evaluating the usefulness of
ir-based fault localization techniques,” in Proc. Int. Symp. Softw. Testing& Analysis, July 2015, pp. 1–11.
[7] S. Wang and D. Lo, “Amalgam+: Composing rich information sources
for accurate bug localization,” J. Softw.: Evol. & Process, vol. 28,
no. 10, pp. 921–942, Oct. 2016.
[8] S. K. Lukins, N. A. Kraft, and L. H. Etzkorn, “Bug localization using
latent dirichlet allocation,” Inf. & Softw. Tech., vol. 52, no. 9, pp.
972–990, Sept. 2010.
[9] X. Ye, R. Bunescu, and C. Liu, “Learning to rank relevant ﬁles for bug
reports using domain knowledge,” in Proc. 22nd ACM SIGSOFT Int.
Symp. Foundations of Softw. Eng., Nov. 2014, pp. 689–699.
[10] M. Rath, D. Lo, and P. Mader, “Analyzing requirements and traceability
information to improve bug localization,” in Proc. 15th IEEE/ACM
Working Conf. Mining Softw. Rep., May 2018, pp. 442–453.
[11] M. Rath and P. Mader, “Inﬂuence of structured information in bug report
descriptions on ir-based bug localization,” in Proc. 44th Euromicro Conf.
Softw. Eng. & Advanced App., Aug. 2018, pp. 26–32.
[12] M. Rath and P. Mader, “Structured information in bug report
descriptions—inﬂuence on IR-based bug localization and developers,”
Softw. Quality J., vol. 27, pp. 1315–1337, May 2019.
[13] G. Taguchi, S. Chowdhury, and Y. Wu, The Mahalanobis-Taguchi
System. New York: McGraw-Hill, 2001.
[14] S. Kim, T. Zimmermann, E. J. Whitehead Jr., and A. Zeller, “Predicting
faults from cached history,” in Proc. 29th Int. Conf. Softw. Eng., May
2007, pp. 489–498.
[15] F. Rahman, D. Posnett, A. Hindle, E. Barr, and P. Devanbu, “Bugcachefor inspections : Hit or miss?” in Proc. 19th ACM SIFSOFT Symp. &13th European Conf. Foundations Softw. Eng., Sept. 2011, pp. 322–331.
[16] C. Lewis and R. Ou, “Bug prediction at google,” http://googleengtools.blogspot.com/2011/12/bug-prediction-at-google.html.
[17] R. K. Saha, M. Lease, S. Khurshid, and D. E. Perry, “Improving
bug localization using structured information retrieval,” in Proc. 28th
IEEE/ACM Int. Conf. Automated Softw. Eng., Nov. 2013, pp. 345–355.
[18] A. Schroter, A. Schroter, N. Bettenburg, and R. Premraj, “Do stack traces
help developers ﬁx bugs?” in Proc. 7th IEEE Working Conf. Mining
Softw. Rep., May 2010, pp. 118–121.
[19] J. H. Holland, Adaptation in Natural and Artiﬁcial Systems: An Introductory Analysis with Applications to Biology, Control and Artiﬁcial
Intelligence. Cambridge, MA, USA: MIT Press, 1992.
[20] C. D. Manning, P. Raghavan, and H. Schütze, Introduction to Information Retrieval. Cambridge: Cambridge University Press, 2008.
[21] A. Rui, Z. Peter, G. Rob, and G. Arjan, “A practical evaluation ofspectrum-based fault localization,” Softw. Quality J., vol. 82, pp. 1780–
1792, Nov. 2009[22] A. Rui, Z. Peter, G. Arjan, and J.C.van, “Spectrum-Based Multiple Fault
Localization,” in Proc. 24th IEEE/ACM Int. Conf. Automated Softw.
Eng., Nov. 2009, pp. 88–99.
[23] X. Xie, W.E. Wong, T.Y. Chen and B. Xu, “Spectrum-Based Fault
Localization: Testing Oracles are No Longer Mandatory,” in Proc. 11th
Int. Conf. Quality Softw., July 2011, pp. 1–10.
[24] L. Yun, S. Jun, X. Yinxing, L. Yang and D. Jinsong, “Feedback-Based
Debugging,” in Proc. 39th Int. Conf. Softw. Eng., May 2017, pp. 393–
403.
[25] L. Yun, S. Jun, T. Lyly, B. Guangdong, W. Haijun and D. Jinsong,“Break the Dead End of Dynamic Slicing: Localizing Data and Control
Omission Bug,” in Proc. 33rd IEEE/ACM Int. Conf. Automated Softw.
Eng., Sept. 2018, pp. 509–519.
[26] W. Tao and R. Abhik, “Hierarchical Dynamic Slicing,” in Proc. Int.
Symp. Softw. Testing & Analysis, July 2007, pp. 228–238.
[27] M. Wen, R. Wu and S. Cheung, “Locus: Locating bugs from softwarechanges,” in Proc. 31st IEEE/ACM Int. Conf. Automated Softw. Eng.,
Sept. 2016, pp. 262–273.