日本ソフトウェア科学会第 41 回大会 (2024 年度) 講演論文集

メソッドレベル IR-based Bug Localization での模範
クエリの発見と性能評価
猪俣 良輔

小林 隆志

IR-based Bug Localization(IRBL) は，バグレポート内の文書を入力としそのバグの原因箇所を情報検索技術を用いて推定する手法である．バグレポートからどのように検索クエリを構成するかが重要となる．特にメソッドレベル
での IRBL は精度が十分でないことが知られているが，検索クエリを改良することでどの程度精度が向上できるかは議論がなされていない．本論文では，これまでファイルレベルの IRBL 向けに調査がなされていた手法をメソッドレベルでの IRBL に適用し模範クエリを構成する．この模範クエリの内容での IRBL の精度を調査することで，メソッドレベルでの IRBL の改善可能性を議論する．32 プロジェクトから取得した合計 2782 バグレポートを対象に実験を行い，メソッドレベルにおいても既存の IRBL 手法の精度を上回る模範クエリが構成でき，検索クエリ改
良の潜在的有効性が高いことを示した．

手法 [1] が提案されており，デバッグ作業の初期段

1 はじめに階でバグ箇所を静的に絞り込むことが出来る利点がソフトウェア開発において, バグを発生させずに開ある．

発することは困難である．大きなソフトウェアプロ

IRBL 手法では検索精度向上のために様々な提案がジェクトでは，バグを再現させ，その原因箇所を特定なされてきた [1]．これらの手法は，バグレポートにし修正するデバッグ作業に多くの時間を要する [16]．

出現する語彙とソースコード中の関数名や変数名など

バグ箇所局所化 (Bug Localization) 技術はバグの原の識別子の語彙に同じものが含まれるという前提に因となるソースコード要素を特定するために使用さ基づいている．バグレポートが入力として与えられるれ, バグ修正活動の労力やコストを削減するための重と，そのバグレポートに含まれる語彙を元に検索クエ

要な支援手法である．

リを構成し，ソースコードとの類似度を計算すること

バグ箇所局所化技術には, 動的な手法と静的な手法

で，バグの原因である可能性の高いソースコード要素が存在し, これまで様々な提案がなされてきた [14]．

を出力する．出力結果として表示されるソースコード

動的な手法にはテストの成否と各テストケースで実要素にはファイルやメソッドなどの粒度が存在する．

行された箇所などの特徴量を Spectrum として記録・

これまでの IRBL 手法の多くはファイル単位での検解析する Spectrum-based fault localization(SBFL)

索を行っているが，バグに関連するファイルが出力さ手法 [8] などが存在するが，バグの挙動をテストケーれた時に修正すべきソースコードをファイル内からスとして再現した後でないと適用できない．一方で，特定するには依然として人の労力を必要としている．

静的な手法ではバグレポートをクエリ，ソースコード

近年，メソッドレベルでの IRBL 手法が注目されてファイルを文書として情報検索技術を適用する IRBL

おり，より細かな粒度での検索を行うことで人の労力∗ This is an unrefereed paper.

Copyrights belong to
the Author(s).
Ryosuke Inomata, Takashi Kobayashia, 東京工業大学
情報理工学院, School of Computing, Tokyo Instituteof Technology.

を削減することが期待されている．しかし，メソッド
単位での検索精度はファイル単位と比較して低いことが知られている [9]．
本研究の最終的な目的は，バグレポート中の単語をそのまま使用するのではなく，クエリ改良 [2] を適用に制限がかかっていることを示した．

することによって，メソッド単位の IRBL 手法の検索精度を向上させることである．IRBL 手法における2. 2 模範クエリ

クエリ改良の潜在的有効性は， Mills らの報告 [6] で

前述の IRBL 手法の有用性に関する懸念を受け，議論されている．彼らは，バグレポート中の単語のみ

Mills ら [6] は，バグレポート中の単語からバグ箇所を使用して最適に近い単語組み合わせを探索し，模範局所化に有効な単語を抽出し，ヒント情報との関係をクエリを構成し IRBL 手法の有用性の調査を行って調査している．彼らは，バグレポートの単語のみで構いる．調査を通して，バグレポートの単語のみで構成成される模範クエリが既存手法の精度を大幅に上回される模範クエリが既存手法の精度を大幅に上回るることを示し，クエリを適切に構成することができことを示し，クエリを適切に構成することができればれば IRBL 手法は有効であることを示した．さらにIRBL 手法は有効であることを示している．Mills らMills らは検索ヒントを取り除いた模範クエリも構成

は，正解が不明な実際の状況下でバグレポートから模し，検索ヒントが無い場合でも精度は低下するが模範

範クエリを構成する方法を明らかにはしていないが，クエリが有効であることも示した．

適切にクエリ改良 [2] を適用することで精度が改善する可能性を示唆している．

彼らの模範クエリ構成手法は，遺伝的アルゴリズ
ムを使用している．遺伝的アルゴリズムは進化計算

しかしながら，現状で十分な精度が達成できていの一種であり，生物の進化を模倣した最適化手法であないメソッドレベルでのバグ箇所局所化は，クエリ改る．クエリを個体として表現するために，バグレポー

良によりどの程度まで精度が向上する余地があるの

トの単語数 n に対して n ビットのバイナリベクトル

かは明らかでない．本稿では，メソッド単位の IRBLを使用する．ビットが 1 の場合，その単語がクエリ手法においてもクエリ改良の潜在的有効性を明らかに含まれ，ビットが 0 の場合は含まれないことを示にすることを目的とし，Mills らの調査手法をメソッ

す．そして，これらのクエリ（個体）を検索精度（適ドレベルでのバグ箇所局所化に適用してメソッド単位応度）に基づいて選択，交叉，突然変異を繰り返すこでの IRBL 向けの模範クエリを構成しその精度を調とで最適解を探索する．

査する．

Mills らは jmetal framework†1 を使用して遺伝的アルゴリズムを実装した．彼らは Lucene [5] を用い

2 関連研究て 3 種類の検索精度指標（Eﬀectiveness ，逆 Average

2. 1 IRBL 手法の有用性

Precision ，逆 Recall ）を計算し，個体を評価した。

情報検索を使用したバグ箇所局所化 (IRBL) 技術に

交叉には SinglePointCrossover，突然変異には Bit-

関して多くの研究がなされている中で，IRBL 手法の

FlipMutation，選択オペレータにはルーレットホイー

有用性を疑問視する研究も存在する [3, 11]. Kochhar

ルを使用し，各パラメータは， 集団サイズ : 100，最ら [3] は，バグ箇所局所化の研究はバイアスの制御が大世代数 : 30,000，交叉確率 : 0.9，各単語の突然変不十分であると指摘した．バグレポートに記述され異確率 : 1/n (n はバグレポートの単語数) を使用しる情報には観測された事象や期待される動作などのたと報告されている．

他にコードの一部であるクラス名やメソッド名が含

模範クエリは検索の正解情報を用いて探索的に構成まれる場合がある．クラス名やメソッド名などはバされるため，実際にバグ箇所局所化を行う支援には利グの原因箇所を明示的に示す可能性が高く，これらの用できない．この問題に対し，我々は模範クエリに近検索ヒントが存在する場合，バグ箇所局所化の精度いクエリを構成するために，ファイルレベルの IRBL

が本来の性能よりも過大評価されると示した．Wang

を対象に模範クエリに選ばれた単語の特徴分析 [20]ら [11] は，検索に必要な情報がバグレポートに記述されることが少ないことを指摘し，IRBL 手法の適用†1 https://jmetal.sourceforge.net

とそれらの特徴に基づくクエリ改良方法 [19] を提案

表1

対象プロジェクト

している．
Group
Commons

2. 3 FinerBench4BL
これまでの IRBL 手法研究の多くはファイル単位で行われており，メソッド単位での手法やデータセッ
トは多くない．積田ら [9] はソースコード，検索の正解セット，バグレポートを含むメソッド単位のデータ

JBoss

セットと 5 つの代表的な検索手法を提供する評価フSpring

レームワーク FinerBench4BL [10] を作成し，ファイ
ル単位とメソッド単位の IRBL 手法を検索精度とデバッグ効率の観点で比較した．積田らの分析によれ
ば，メソッド単位の IRBL 手法はファイル単位のものよりもデバッグ効率を向上させる一方で，検索精度は低下しており，メソッド単位の IRBL 手法には改善が必要であることが示されている．

FinerBench4BL は，ファイル単位の IRBL 手法評
価フレームワークである Bench4BL [4] をメソッド

Project
CODEC
COLLECTIONSCOMPRESSCONFIGURATIONCRYPTO
CSV
IO
LANG
MATH
WEAVERENTESBJBMETA
AMQP
ANDROID
DATACMNSDATAJPADATAMONGODATAREDISDATARESTMOBILEROO
SEC
SECOAUTH
SGF
SHDP
SHL
SOCIAL
SOCIALFBSOCIALLISOCIALTW
SPR
SWF

min
#methods
439
5,967
788
1,449
488
360
452
2,661
1,906
469
3,210
4,477
1,476
1,901
835
559
1,992
2,525
574
182
1,967
4,359
2,253
368
1,259
409
804
962
830
890
34,7883,663

max#methods
1,310
6,997
2,591
6,073
488
405
2,608
6,336
15,695
469
3,210
4,813
3,729
1,926
4,043
1,970
5,125
8,490
2,108
780
7,803
8,500
2326
4,874
6,331
588
1,267
1,760
830
1,191
55,691
6,837#versions
6
5
15
11
1
3
12
15
15
1
1
3
32
2
30
32
40
15
23
3
15
41
6
19
8
2
4
4
1
5
10
19

#BR
27
59
105
107
4
6
70
158
175
1
4
15
86
8
104
107
209
44
89
8
568
422
61
83
37
6
10
11
2
6
89
101

単位に変換することで作成される．FinerBench4BL
は Bench4BL で提供されている 6 つの代表的な検索手法のうち，5 つ（BugLocator [17]，BLUiR [7]，3 手法: メソッド単位模範クエリの作成

BRTracer [13]，AmaLgam [12]，BLIA [15]）を提供

3. 1 概要

し，メソッド単位のデータセットを使用して検索精

本研究の目的は，メソッド単位の IRBL 手法にお度を評価することができる．BugLocator [17] は過いてクエリ改良が検索精度の向上にどの程度寄与しう去の類似バグレポートやファイルサイズを使用する．

るかを調査することである．そのために，我々は 2. 2

BLUiR [7] はソースコードの構文情報を使用する．

で紹介した Mills らの手法と，2. 3 で紹介したメソッ

BRTracer [13] はバグレポートに含まれるスタックト

ド単位の IRBL 評価フレームワークを組み合わせて，

レース情報を使用する．Amalgam [12] は履歴データ

メソッド単位の模範クエリを作成する．そして，そのを使用する．BLIA [15] はこれらの副次情報を統合す

模範クエリの検索精度をベースラインと比較して評る手法である．

価し，メソッド単位でのクエリ改良による改善可能性

FinerBench4BL のデータセットを構築する手順はを議論する．

以下の通りである．まず Bench4BL が提供する Git
リポジトリに対してリポジトリ変換ツール Histor-

3. 2 データセット

inc [18] を適用し，メソッド単位のリポジトリに変換

我々は模範クエリの作成に必要なソースコード，バ

する．その後，検索の正解として扱われるバグに関連

グレポートテキスト，およびバグレポートに紐づくするソースコード要素をメソッド単位に変換し，バグ

バグ関連メソッドを取得するために FinerBench4BL

レポートと修正ファイルの対応関係を取得する．そしのデータセット構築を再現した．FinerBench4BL のて最後に，ファイル単位の検索手法をメソッド単位に再現によって 46 プロジェクトのデータセットを取得

修正することで評価フレームワークを構築した．

した．
積田ら [9] は 46 プロジェクトのうち 37 プロジェ

クトを使用してメソッド単位の IRBL 手法の評価を

個体 2 つを選択する方法として BinaryTournament2

行っており，本研究でもその 37 プロジェクトに含まを使用し，交叉には SinglePointCrossover，突然変れない 9 プロジェクトは対象外とした．また，37 プ

異には BitFlipMutation を採用した．世代交代によロジェクトのうちメソッド単位への変換が不十分でる個体更新は親個体のうち適合度の高い個体をエリー

あった LDAP，DATAGRAPH，SWS の 3 プロジェ

ト個体として次世代に残すエリート保存戦略を採用

クトも本研究では対象外とした．さらに，BATCH はした．具体的には，親個体から 2 個体をエリート個再現したデータセットでバグレポートの数が異なるた体として選び，それ以外を子個体の生成によって置きめ除外し，BATCHADM はバグレポートに紐づく修換える．遺伝的アルゴリズムのパラメータは，Mills

正ファイルの数が少ないため本研究の対象から除外しらの実装を参考に，個体数 500，世代数 10，交叉確た．最終的に本研究では 32 プロジェクトを対象とし

率 0.9，各単語ビットの突然変異確率 1/n (n は単語て模範クエリの作成を行った．

数) として設定した．

表 1 に本研究で使用するバグレポート数を含むプ
ロジェクトの情報を示す. メソッド数は検索で対象と4 評価なるソースコード要素の数であり, 数が多いほど検索

4. 1 実験方法・手順で正解を見つける難易度が高くなる. データセットに

FinerBench4BL を使用して作成した模範クエリ

はバグレポートの報告されたバージョン情報が記述の検索精度を評価するために，以下の手順で実験をされており, 対応するバージョンのソースコードを使行った．

用して検索を行う. バージョン毎にメソッド数は異な

1. FinerBench4BL で提供される 32 プロジェクト

り, 各プロジェクトにおけるバージョン数および最小のデータセットを使用して，メソッド単位の模範

メソッド数と最大メソッド数を表 1 に示す.

クエリを生成する．

2. 生成した模範クエリを使用して Lucene で検3. 3 実装
本研究では，FinerBench4BL を使用してメソッド

索を行い，検索精度 (MAP, HITS@K ) を計算する．

単位で模範クエリを生成するために，遺伝的アルゴリ

3. バグレポートの単語全てを使用する初期クエ

ズムを含む模範クエリ生成ツールを実装した．我々はリを Lucene での検索に使用し，模範クエリとMills らの実装を参考にし，検索には Lucene 2.9.1 をMAP, HITS@K を比較する．

使用し，Eﬀectiveness を適合度として用いた．Eﬀec-

4. FinerBench4BL で提供される 5 つの検索手法

tiveness は，正解メソッドのうち検索結果の最上位にをベースラインとして模範クエリと MAP を比ランク付けされたもののランクをスコアとし，値が較する．

小さいほど検索精度が高く，最も精度が高い場合は 1である．

初期クエリを使用した Lucene と FinerBench4BLで提供される検索手法はバグレポートの単語全てを

開発者はバグに関連するソースコードを修正する

使用して検索を行う手法である．Lucene ではバグレ

ために，検索結果の上位にランク付けされたソース

ポートとソースコードの類似度のみを使用してバグ

コード要素を参照する．そのため，Eﬀectiveness はに関連するソースコード要素を検索する．それに対し本研究において最も重要な検索精度指標であり，模範て，FinerBench4BL で提供される 5 つの検索手法はクエリを生成する遺伝的アルゴリズムの適合度とし

2. 3 で紹介した通り，バグレポートとソースコードのて使用した．

類似度だけでなく，副次情報を使用することで検索精遺伝的アルゴリズムの選択，交叉，突然変異のオペ
レーターや世代間の個体更新方法は Mills らの実装を参考にしている．次世代の子個体を作成するために親度の向上を図っている．

表2
project
CODEC
COLLECTIONSCOMPRESSCONFIGURATIONCRYPTO
CSV
IO
LANG
MATH
WEAVERENTESBJBMETA
AMQP
ANDROID
DATACMNSDATAJPADATAMONGODATAREDISDATARESTMOBILEROO
SEC
SECOAUTH
SGF
SHDP
SHL
SOCIAL
SOCIALFBSOCIALLISOCIALTW
SPR
SWF

#BR
27
59
105
107
4
6
70
158
175
1
4
15
86
8
104
107
209
44
89
8
568
422
61
83
37
6
10
11
2
6
89
101

平均正解
含有率

0.64 %
0.14 %
0.19 %
0.11 %
4.71 %
0.93 %
0.2 %0.08 %
0.12 %
1.71 %
0.32 %
0.09 %
0.31 %
0.94 %
0.25 %
0.41 %
0.21 %
0.16 %
0.63 %
0.64 %
0.28 %
0.07 %
0.19 %
0.6 %
0.14 %
0.84 %
0.34 %
0.26 %
0.18 %
0.13 %
0.02 %
0.12 %

初期クエリと模範クエリの検索精度

HITS@10.29630.40680.33330.23360.00000.16670.45710.41140.36000.00000.00000.13330.24420.50000.22120.28040.1531
0.27270.11240.25000.18490.35550.26230.33730.24320.33330.60000.27270.50000.33330.15730.2970

初期クエリ
HITS@5 HITS@10
0.37040.48150.54240.62710.45710.50480.43930.54210.50000.50000.50000.66670.64290.78570.6266
0.69620.56000.62290.00001.00000.00000.00000.46670.53330.48840.56980.50000.62500.34620.44230.41120.49530.34450.41630.47730.52270.33710.41570.25000.62500.34680.4454
0.55690.63270.50820.65570.49400.59040.35140.43240.83331.00000.70000.70000.54550.54550.50000.50000.66671.00000.28090.39330.47520.5545MAP
0.25000.35970.30000.25980.16020.28010.43200.43260.31940.06410.01050.17480.16550.44120.12850.18060.10090.16100.08640.30320.15610.31260.25680.18850.20250.26480.45850.24800.50820.50000.1416
0.2444

模範クエリ
HITS@5 HITS@10
0.77780.81480.88140.88140.92380.92380.88790.93460.50000.75001.00001.00000.9286
0.92860.86710.89870.90860.92571.00001.00000.50000.50000.60000.73330.87210.91860.75000.87500.7596
0.79810.82240.85050.77510.82780.8636
0.86360.74160.82020.87501.00000.77990.84510.87680.90050.88520.91800.95180.96390.86490.91891.00001.00001.00001.00000.81820.81821.00001.00001.00001.00000.79780.83150.81190.8812

HITS@10.74070.76270.80950.85050.50000.83330.90000.75320.82861.00000.25000.53330.80230.50000.65380.66360.62200.79550.60670.62500.65320.78910.72130.85540.78381.00001.00000.63641.00000.83330.60670.6733MAP
0.46210.51800.62840.61680.26680.69870.68080.61220.55650.28250.21480.39950.35140.43780.28280.34830.25660.31090.22590.59600.36670.51800.43730.34580.37270.57450.65630.43090.75000.84580.35340.43304. 2 評価指標

メソッド総数，n は検索結果の総数，rel(k) はランク

本研究ではプロジェクト毎の検索精度の指標としてk に位置したファイルが正解セットに含まれる場合はMean Average Precision (MAP) と HITS@K を使

1，それ以外は 0 を表す．P (k) は，検索結果の上位用する．MAP はバグレポート毎の検索精度として計

k 件までの中で正解メソッドが占める割合を示し，次算される Average Precision (AP) の平均であり，検のように定義される．

索の正解セットを全体としてどれだけ高精度に検索できるかを示す．具体的には，MAP は次のように定義される．

M AP =

1
|BR|

∑

7
7 件含まれている場合，P (10) = 10
となる．

|BR|

AP (b)

b=1

ここで，|BR| はプロジェクトに含まれるバグレ
ポートの総数，AP (b) はバグレポート b に対する APを表し，以下のように定義される．
n1 ∑AP (b) =P (k) · rel(k)Rbk=1

ランク k までの正解数
k
例えば，検索結果の上位 10 件のうち正解メソッドがP (k) =

ここで，Rb はバグレポート b に対する検索の正解

HITS@K は，プロジェクト毎の検索精度指標であり，検索結果の上位 K 件までの中で正解メソッドが含まれているバグレポートの割合を示す．HITS@K
は次のように定義される．

1 ∑hits(b, K)
|BR|
|BR|

HIT S@K =b=1

こ こ で ，|BR| は バ グ レ ポ ー ト の 総 数 を 示 す．

hits(b, K) はバグレポート b に対して検索結果の

上位 K 件の中に正解メソッドが含まれている場合
は 1，含まれていない場合は 0 を示す．例えば，ある

表3

初期クエリと模範クエリの AP の中央値とWilcoxon の符号付き順位検定の p 値

プロジェクトに対して 10 件のバグレポートがあり，

HITS@10 を計算する場合，全バグレポートのうち 7件が上位 10 件の検索結果に正解メソッドを含めることができると，HITS@K は 0.7 となる．本研究では，

K = 1, 5, 10 について HITS@K を計算した.
4. 3 実験結果と考察
4. 3. 1 初期クエリと模範クエリの精度比較
表 2 に初期クエリと模範クエリの検索精度 (MAP ，

HITS@K ) を示す．初期クエリの検索精度が模範クエリと同等の場合，両者に対応する箇所に下線が引かれている．また，初期クエリが模範クエリよりも高精度である場合は，対応する箇所が太字で示されている．

HITS@K を比較すると，すべてのプロジェクト
で模範クエリの方が初期クエリと同等またはそれより高精度である．初期クエリが模範クエリと同等の精度を示したのは HITS@10 における WEAVER，

SHL，SOCIALTW の 3 プロジェクトである．これらのプロジェクトはいずれも初期クエリと模範クエ
リの HITS@10 が最大値の 1 であり，バグレポート
数が 10 以下である．バグレポート数が少ないため，

HITS@10 の精度を比較するのは難しいが，HITS@1

project
CODEC
COLLECTIONSCOMPRESSCONFIGURATIONCRYPTO
CSV
IO
LANG
MATH
WEAVERENTESBJBMETA
AMQP
ANDROID
DATACMNSDATAJPADATAMONGODATAREDISDATARESTMOBILEROO
SEC
SECOAUTH
SGF
SHDP
SHL
SOCIAL
SOCIALFBSOCIALLISOCIALTW
SPR
SWF

初期クエリ
中央値

模範クエリ
中央値

0.02280.04550.04550.06450.13010.10000.18840.12740.0656
0.06410.01870.10000.04950.15560.01710.01940.01350.02860.02340.07320.02760.05000.06550.04910.02460.22160.20300.20720.01650.16670.00790.04170.19610.35000.50000.50150.14020.50000.59170.47110.41360.28250.33130.50000.22080.22620.24260.20010.16670.21600.13010.27990.18370.33330.27910.17470.24400.50820.50710.35620.50000.85000.15780.3239p値
0.00040.00000.00000.00000.25000.06250.00000.00000.00001.00000.25000.00390.00000.29690.00000.00000.00000.00000.00000.03120.00000.00000.00000.00000.00000.09380.31250.08401.00000.12500.00000.0000や HITS@5 では模範クエリがより高精度であるため，
模範クエリは初期クエリの検索精度を改善している．

CRYPTO と WEAVER でも HITS@10 の値はそれ

HITS@K は検索結果上位 K 件までに正解を 1 つ

ぞれ 0.75 と 1.0 と高く，CRYPTO では HITS@1,でも出力できるかどうかを評価するため，検索問題10 で，WEAVER では HITS@1, 5 で精度が改善しの難しさはソースコードのメソッド数に対する正解ていることから，模範クエリの貢献が確認できる．

メソッド数に依存する．各プロジェクトの正解メソッ

表 2 で 初 期 ク エ リ と 模 範 ク エ リ の MAP を 比

ド含有率の平均値を表 2 の 3 列目に示す．CRYPTO較 す る と ANDROID を 除 く す べ て の プ ロ ジェクと WEAVER を除くすべてのプロジェクトで平均正

ト で 模 範 ク エ リ が 高 精 度 を 示 し た ．表 3 に 各 プ

解含有率は 1% 未満である．正解含有率 1% の場

ロジェクトの AP について Wilcoxon の符号付き

合，ランダムに 10 個のメソッドを選んで正解メソッ

順 位 検 定 の p 値 を 示 す．p 値 0.05 を 基 準 と す る

ドが 1 つでも含まれる確率は 0.096 となる. ランダと ，初 期 ク エ リ に 対 し て 統 計 的 に 有 意 に 精 度 がムに選ぶ時の確率 0.096 と比較して，模範クエリの改 善 し た の は CRYPTO，CSV，WEAVER，EN-

HITS@10 は ENTESB を除く全てのプロジェクト

TESB，ANDROID，SHL，SOCIAL，SOCIALFB，

で 0.7 を超えており，ENTESB でも 0.5 である．こSOCIALLI，SOCIALTW の 10 プロジェクト を除れにより，模範クエリは検索精度の向上に貢献してく 22 プロジェクトであった．MAP が悪化した AN-いることがわかる．平均正解含有率が 1% を超えた

DROID と統計的な有意差を確認できなかった 9 プ

ロジェクトは，すべてバグレポート数が 11 以下と少は，バグレポート数が少ないため，統計的有意性を確ないプロジェクトである．逆に，バグレポート数が多保するのが難しい場合がある．そのため，これらの結いプロジェクトでは模範クエリの精度が初期クエリよ

果を一般化する際には慎重さが求められ，妥当性に対りも有意に高いことが確認された．

する懸念が残る．今後，FinerBench4BL のデータ構

4. 3. 2 既存 IRBL 手法と模範クエリの精度比較

築手法を他のファイル単位データセットに適用し，バ

表 4 に初期クエリ，FinerBench4BL が提供する

グレポート数が多いプロジェクトのメソッド単位デー

5 つの検索手法，および模範クエリの MAP を示

タセットを構築することで，それらに対して本研究をす．FinerBench4BL の 5 つの手法の MAP は，論適用したい．

文中 [9] に記載されたものである．7 つの MAP のう
ち最も高精度なものが太字で示され，次に高精度なも5 おわりにのが下線で示されている．模範クエリは ENTESB，

本研究では，Mills らが提案した模範クエリの作

ANDROID，MOBILE を除く 29 プロジェクトで最成方法をメソッド単位のデータセットを含む Finer-

も高精度を示した．残りの 3 プロジェクトでは 2 番

Bench4BL に適応することでメソッド単位の模範ク

目に高い精度を示し，これらはバグレポート数が 10

エリを作成した．作成された模範クエリは多くのプロ

以下のプロジェクトであった．

ジェクトで既存の手法の精度を上回る高い精度を示

模範クエリは MAP において初期クエリと既存のした．特に，バグレポート中の単語のみを使用した模5 つの IRBL 手法よりも高い精度を示し，HITS@K

範クエリの精度が高いことは，メソッド単位の IRBL

では問題の難しさに対して高い数値を示した．これ手法において，クエリ作成戦略が精度改善に重要な役

はバグレポートの単語のみという限定的な情報でも，割を果たすことを示している．

IRBL 手法を改善できることを示す．また，クエリを今後の研究では，ファイル単位とメソッド単位の模適切に構成することで精度が改善することが示され

範クエリの違いを分析し，どのようにして効果的な模たことは，メソッド単位の IRBL 手法においてクエ範クエリを構築できるかを調査する．この分析によ

リ作成戦略が精度向上に寄与することを示している．

り，模範クエリに近いクエリを構成するクエリ改良手法を検討し，メソッド単位のバグ箇所局所化において

4. 4 妥当性への脅威

バグレポートの情報を効率的に活用する IRBL 手法

本研究では遺伝的アルゴリズムの適合度としての提案を目指す．

Eﬀectiveness を使用したが，逆 AP や 逆 Recall を適合度として使用することを試していない．MAP と謝辞： 本研究の一部は科研費（#22H03567）の助成を受けた．

いう検索精度指標において，逆 AP を使用した方が高精度となる可能性があるためこの点についての検参 考 文 献証が必要である．

[ 1 ] Akbar, S. and Kak, A.: A Large-Scale Comparative Evaluation of IR-Based Tools for Bug Localization, Proc. MSR, 2020, pp. 21–31.
[ 2 ] Huang, J. and Efthimiadis, E. N.: Analyzing andevaluating query reformulation strategies in web
search logs, Proc. CIKM, 2009, pp. 77–86.
[ 3 ] Kochhar, P. S., Tian, Y., and Lo, D.: Potential
Biases in Bug Localization: Do They Matter?, Proc.
ASE, 2014, pp. 803–814.
[ 4 ] Lee, J., Kim, D., Bissyandé, T. F., Jung, W.,
and Le Traon, Y.: Bench4BL: reproducibility study
on the performance of ir-based bug localization,
Proc. ISSTA, 2018, pp. 61–72.
[ 5 ] McCandless, M., Hatcher, E., and Gospodnetić,

我々は初期クエリと模範クエリの AP についてWilcoxon の符号付き順位検定を行っているが，デー
タ入手の問題から FinerBench4BL の手法と模範ク
エリに対する統計検定を実施できなかった．MAP は平均値であるため，バグレポートごとに精度が実際に向上しているかを確認するには FinerBench4BL の手法に関するデータを入手し，統計検定を行う必要がある．

FinerBench4BL に含まれる一部のプロジェクトでproject
CODEC
COLLECTIONSCOMPRESSCONFIGURATIONCRYPTO
CSV
IO
LANG
MATH
WEAVERENTESBJBMETA
AMQP
ANDROID
DATACMNSDATAJPADATAMONGODATAREDISDATARESTMOBILEROO
SEC
SECOAUTH
SGF
SHDP
SHL
SOCIAL
SOCIALFBSOCIALLISOCIALTW
SPR
SWF

表4

初期クエリと 5 つのベースラインと模範クエリの MAP

#BR
27
59
105
107
4
6
70
158
175
1
4
15
86
8
104
107
209
44
89
8
568
422
61
83
37
6
10
11
2
6
89
101

初期クエリ

0.25000.35970.30000.25980.16020.28010.43200.43260.31940.06410.01050.17480.16550.44120.12850.18060.10090.16100.08640.30320.15610.31260.25680.18850.20250.26480.45850.24800.50820.50000.1416
0.2444

BugLocator
0.19200.36600.28100.21000.10600.15500.40000.37400.26300.06800.03100.14600.15500.29800.12500.16900.11400.16300.10000.37200.20000.29900.30100.18200.20000.22700.31600.18400.51100.48800.20300.2120O.: Lucene in action, Vol. 2, Manning Greenwich,2010.
[ 6 ] Mills, C. et al.: On the relationship between
bug reports and queries for text retrieval-based
bug localization, Empir. Software Eng., Vol. 25,
No. 5(2020).
[ 7 ] Saha, R. K., Lease, M., Khurshid, S., and Perry,
D. E.: Improving bug localization using structured
information retrieval, Proc. ASE, 2013, pp. 345–
355.
[ 8 ] Sarhan, Q. I. and Beszédes, A.: A Survey ofChallenges in Spectrum-Based Software Fault Localization, IEEE Access, Vol. 10(2022), pp. 10618–
10639.
[ 9 ] Tsumita, S., Hayashi, S., and Amasaki, S.:
Large-Scale Evaluation of Method-Level Bug Localization with FinerBench4BL, Proc. SANER, 2023,
pp. 815–824.
[10] Tsumita, S., Hayashi, S., and Amasaki, S.:
Replication package of FinerBench4BL, https://github.com/salab/FinerBench4BL, 2023.
[11] Wang, Q. et al.: Evaluating the usefulness of
IR-based fault localization techniques, Proc. ISSTA,
2015, pp. 1–11.

BLUiR
0.35200.36900.31800.32900.06000.42300.50600.50300.35500.08300.16700.22600.16700.34300.20400.17300.14400.16000.12700.62700.19300.33400.27500.15900.16100.32700.49900.30000.51400.32000.16700.2430

BRTracer
0.09400.09400.17000.13800.26400.15400.22700.16700.12200.01500.35000.03500.10600.23700.12400.11500.09600.12300.07700.37600.08700.18600.17600.12300.16600.22600.40600.32800.50500.19300.14100.1910AmaLgam
0.34500.37700.30200.31300.06000.43700.49900.52500.35500.08300.16600.22600.16500.35300.20100.17500.14200.15200.12800.62700.20000.33900.28500.16800.16000.32700.49900.31800.51400.32000.22700.2290BLIA
0.38100.39400.34900.36300.05800.45300.49500.53600.37500.03800.21400.21400.18700.36700.21400.18300.16500.19000.12800.59500.22800.36200.31800.16900.21100.31400.50100.31800.51500.28200.25400.2710模範クエリ

0.46210.51800.62840.61680.26680.69870.68080.61220.55650.28250.21480.39950.35140.43780.28280.34830.25660.31090.22590.59600.36670.51800.43730.34580.37270.57450.65630.43090.75000.84580.35340.4330[12] Wang, S. and Lo, D.: Version history, similar report, and structure: putting them together
for improved bug localization, Proc. ICPC, 2014,
pp. 53–63.
[13] Wong, C.-P., Xiong, Y., Zhang, H., Hao, D.,
Zhang, L., and Mei, H.: Boosting Bug-ReportOriented Fault Localization with Segmentation andStack-Trace Analysis, Proc. ICSME, 2014, pp. 181–
190.
[14] Wong, W. E. et al.: A Survey on Software
Fault Localization, IEEE Trans. Soft. Eng., Vol. 42,
No. 8(2016), pp. 707–740.
[15] Youm, K. C., Ahn, J., Kim, J., and Lee, E.: Bug
Localization Based on Code Change Histories and
Bug Reports, Proc. APSEC, 2015, pp. 190–197.
[16] Zeller, A.: Why Programs Fail, 2nd ed., Morgan
Kaufmann, 2009.
[17] Zhou, J., Zhang, H., and Lo, D.: Where should
the bugs be ﬁxed? More accurate information
retrieval-based bug localization based on bug reports, Proc. ICSE, 2012, pp. 14–24.
[18] 柴駿太, 林晋平: Historinc: 細粒度履歴追跡のための増分的なリポジトリ変換ツール, コンピュータソフト
ウェア, Vol. 39, No. 4(2022), pp. 75–85.

[19] 猪俣良輔, 小林隆志: 情報検索に基づくバグ箇所局
所化でのクエリ改良の効果, 電子情報通信学会技術研究
報告 Vol.123, No.123, pp.37–42, 2023.

[20] 林和輝, 小林隆志: 欠陥箇所検索に有効なバグレポー
ト中のキーワード抽出, 電子情報通信学会技術研究報告
Vol.121, No.416, pp.84–89, 2022.