社団法人 電子情報通信学会
THE INSTITUTE OF ELECTRONICS,
INFORMATION AND COMMUNICATION ENGINEERS

信学技報
TECHNICAL REPORT OF IEICE.

R 言語に対する欠陥データセット構築の試み—dplyr プロジェクトを題材として—
石野 太一†

柗本 真佑†真二†

楠本† 大阪大学大学院情報科学研究科
E-mail: †{t-ishino,shinsuke,kusumoto}@ist.osaka-u.ac.jp
あらまし ソフトウェア開発中に発生した様々な欠陥を再現可能な形で収集した欠陥データセットが公開されている．
欠陥データセットは欠陥研究を支える 1 つの重要な要素となっており，欠陥箇所の自動特定や欠陥の自動修正などの研究で利用されている．特に Java や C 言語などのプログラミング言語では複数の欠陥データセットが公開されており，その言語における欠陥研究を大きく促進している．一方で，R 言語には再現可能な欠陥データセットが存在せず，

R 言語における欠陥研究が全く行われていない．そこで，本研究では GitHub 上の R プロジェクトから開発過程で発生した欠陥を収集し，欠陥データセットの構築を試みる．その結果，dplyr プロジェクトから欠陥の規模が多様な 176
個の欠陥を収集した．
キーワード R 言語，欠陥データセット

1. は じ め に

1 つであり，現在でも頻繁に使用されている．
R 言語は一定の需要を持つ言語であるにもかかわらず，ソフ

ソフトウェア開発におけるデバッグコストの削減を目的としトウェア工学の観点で十分に研究されているとはいえない [14]．

て，プログラム中に存在する欠陥を対象とした研究が盛んに行

R 言語における研究課題の 1 つとして，再現可能な欠陥データ

われている．具体的には，欠陥の傾向の分析 [1] や，欠陥箇所

セットの構築が挙げられる．Java や C 言語などのプログラミンの自動特定 [2] [3] [4]，欠陥の自動修正 [5] [6] などが挙げられ

グ言語では多数の欠陥データセットが提案されている一方，Rる．これらの欠陥研究を支える土台として，欠陥データセット

言語においては再現可能な欠陥データセットが存在しない．そ[7] [8] [9] [10] [11] が存在する．欠陥データセットとは，ソフトのため，R 言語を対象とした欠陥研究が全く行われていない．

ウェア開発中に発生した様々な欠陥を再現可能な形で収集した他の言語と同様に，R 言語の開発プロジェクトでは issue 管理

データセットである．欠陥データセットには欠陥を含むソースや単体テストが行われており，過去に発生した欠陥を収集可能

コード，欠陥を検出できるテストケース，テスト実行環境の定である．しかし，我々の知る限りでは R 言語の再現可能な欠陥

義情報が含まれており，欠陥を動的に再現可能である．広く用

データセットは存在しない．

いられる欠陥データセットとして Defects4J [7] が挙げられる．

本研究の目的は，R 言語における欠陥研究の促進である．そDefects4J は Java の有名な 17 プロジェクトから 835 個の欠陥をのために，GitHub 上の R プロジェクトから開発過程で発生し収集した研究であり，欠陥箇所の自動特定 [2] [3] [4] や欠陥箇た欠陥を収集し，欠陥データセットの構築を試みる．欠陥収集所の自動修正 [5] [6] などの研究で幅広く使用されている．2023

過程においてテストを実行し，テストケースによって欠陥の再年 9 月時点で Defects4J の被引用数は 1,100 を超えており，Java

現性が保証されている欠陥を収集する．また，欠陥収集の工程における欠陥研究を大きく促進している．Java 以外のプログラをすべて自動化したため，将来的な欠陥データの拡充にも対応

ミング言語においても欠陥データセットは公開されており，C可能である．本研究では実際に R プロジェクトから欠陥が収集

言語では ManyBugs [8]，Python では BugsInPy [9]，JavaScript で可能であることを確認するため，dplyr1 プロジェクトから欠陥は BugsJS [10] などが挙げられる．

の収集を試みた．その結果，欠陥の規模が多様な 176 個の欠陥

上記以外のプログラミング言語として，主に統計解析で使用される R 言語が存在する．R 言語は統計学，生態学，地理情報
学，経済学など様々な分野で使用されている．特に生態学の分を収集した．

2. 準

備野においては R 言語の使用頻度が高く，R 言語は生態学分野に

2. 1 R

おける分析の重要な要素となっている [12]．2023 年 9 月現在，

R 言語はパッケージベースの言語であり，R リポジトリで

言語

プログラミング言語の人気指標の 1 つである PYPL 指数 [13] において R 言語は 7 位となっている．R 言語は人気の高い言語の（注 1）：https://github.com/tidyverse/dplyr—1—多数のパッケージが公開されている．最も主要な R リポジト
リは CRAN2 である．CRAN は R 言語の公式リポジトリであり，2023 年 9 月時点で 19,000 以上のパッケージが公開されて

R

R

GitHub PPPM

1. Cfix候補の抽出いる．CRAN の他には Bioconductor3 ，R-Forge4, GitHub などでパッケージが公開されている．
ユーザは R リポジトリからパッケージをインストールし，第3. 実行環境の構築

2. Cbug候補とのペア化

三者が開発した機能を利用できる．パッケージのインストール

複製

4. 検証

✔✔✔

には依存関係の解決が必要となるが，R 標準の機能や外部パッ
ケージにより自動で行われる．依存関係の解決において，標準では最新バージョンの依存パッケージがインストールされる．

実行環境

また，古いバージョンのパッケージ本体をインストールする場

ソースコードテスト

合においても最新バージョンの依存パッケージが自動でインス欠陥トールされる．しかし，依存パッケージの後方互換性のない変5. 実行環境の構築

対象リポジトリ R Rリポジトリ
コミット

6. 検証

✔×✔
各ペアの処理図 1: 欠陥収集の流れ

更により R パッケージが壊れてしまうことがある [15]．そのため，古いバージョンのパッケージ本体をインストールするためには適切なバージョンの依存パッケージを手動でインストールする必要がある．

2. 2 欠陥データセット
欠陥データセットとは，ソフトウェア開発中に発生した様々な欠陥を再現可能な形で収集したデータセットである．欠陥を再現するためには欠陥を含むソースコード，欠陥を検出できる
テストケース，テスト実行環境の定義情報が必要であり，欠陥
データセットにはこれらの情報が含まれている．さらに，欠陥に関するメタ情報として実際のコミットへのリンク，欠陥に関連する issue，テスト結果，コードメトリクスなどが含まれる．

3. 欠陥の収集方法
本研究では，欠陥研究で利用可能な欠陥データセットの構築を目的として，GitHub 上の R プロジェクトから開発過程で発生した欠陥を収集する．収集対象とする欠陥はドキュメントの不備などではなく，R のソースコードに含まれる欠陥である．
本研究で収集する欠陥データには欠陥を含むソースコード，欠陥が修正されたソースコード，テストが含まれる．欠陥を含む
ソースコードは 1 つ以上のテストケースに失敗する．このテス
トケースによって欠陥の再現性が保証される．
本研究では単体テストを用いて欠陥を自動的に収集する．基
本的な流れとしては Benton ら [11] の手法に従う．まず，GitHub
上の R プロジェクトから欠陥修正コミット（𝐶 𝑓 𝑖 𝑥 ）候補と欠陥
含有コミット（𝐶𝑏𝑢𝑔 ）候補のペアを抽出する．次に，単体テス
トを用いて欠陥の有無を自動的に検証する．図 1 に欠陥収集の流れを示す．欠陥収集は次の 6 つのステップから構成される．
ステップ 1: 𝑪 𝒇 𝒊 𝒙 候補の抽出
本ステップでは GitHub 上の大量のコミットから 𝐶 𝑓 𝑖 𝑥 候補を抽出する．以下の 2 つの条件をともに満たすコミットを 𝐶 𝑓 𝑖 𝑥
候補とする．1 つ目の条件は，「コミットメッセージに issue 番
号もしくはキーワードのいずれかが含まれる」である．大量のコミットから欠陥修正に関連するコミットのみに絞り込むためにこのフィルターを採用した．issue 番号は#数字で表される．
キーワードは error，issue，ﬁx，repair，solve，remove，problemの 7 語である．これらのキーワードは欠陥修正に関連するキー
ワードとして Benton ら [11] の手法で採用されたキーワードである．2 つ目の条件は，「R のソースコードに変更がある」である．本研究では R のソースコードに含まれる欠陥を収集対象としているため，このフィルターを採用した．
ステップ 2: 𝑪𝒃𝒖𝒈 候補と 𝑪 𝒇 𝒊 𝒙 候補のペア作成
それぞれの 𝐶 𝑓 𝑖𝑥 候補に対して，そのコミットで修正した欠陥を元々含んでいた 𝐶𝑏𝑢𝑔 候補を特定する必要がある．本ステッ
プではステップ 1 で抽出した 𝐶 𝑓 𝑖𝑥 候補から対応する 𝐶𝑏𝑢𝑔 候
補を特定し，𝐶𝑏𝑢𝑔 候補と 𝐶 𝑓 𝑖𝑥 候補のペアを作成する．本手法
では既存の欠陥データセット研究 [7] [10] [11] と同様に，𝐶 𝑓 𝑖 𝑥
候補の親コミットを 𝐶𝑏𝑢𝑔 候補とした．𝐶 𝑓 𝑖𝑥 候補で欠陥が修正された場合，𝐶 𝑓 𝑖𝑥 候補の親コミットである 𝐶𝑏𝑢𝑔 候補は欠陥を含んでいるはずである．ただし，𝐶𝑏𝑢𝑔 候補はそのコミットで欠陥が混入したとは限らない．マージコミットにより 𝐶 𝑓 𝑖 𝑥 候
補の親コミットが複数存在する場合は，1 つの 𝐶 𝑓 𝑖𝑥 候補から複数のペアを作成する．
ステップ 3: 𝑪 𝒇 𝒊 𝒙 候補の実行環境の構築

𝐶 𝑓 𝑖 𝑥 候補のソースコードに対してテストを実行するために，
R 本体と依存パッケージをインストールする必要がある．2. 1
項で述べた通り，古いバージョンのパッケージ本体をインストールするためには適切なバージョンの依存パッケージをイン
ストールする必要がある．本ステップでは 𝐶 𝑓 𝑖 𝑥 候補開発時点
における最新バージョンの R 本体と依存パッケージをインストールし，𝐶 𝑓 𝑖𝑥 候補開発時点と同じ実行環境を構築する．依存パッケージのインストール元として複数の R リポジトリが存在するが，本手法ではインストール元が CRAN と GitHub の場
合に対応した．依存パッケージのインストール元が CRAN の場合，CRAN の代わりに Posit Public Package Manager（PPPM）5から依存パッケージをインストールする．PPPM は CRAN の（注 2）：https://cran.r-project.org/

ミラーサイトであり，日付ごとのアーカイブを保存している．

（注 3）：https://www.bioconductor.org/（注 4）：https://r-forge.r-project.org/（注 5）：https://packagemanager.posit.co/client/#/—2—

𝐶 𝑓 𝑖 𝑥 候補のコミット日時と同じ日付のアーカイブを参照し，開操作に特化した R パッケージであり，使用率の高いパッケージ

発時点における最新バージョンの依存パッケージをインストーの 1 つである．2023 年 9 月時点でスター数が 4,500，コミット

ルする．コミット日時と同じ日付のアーカイブが存在しなかっ数が 7,700，issue 数が 4,800 を超えており，人気があるプロジェ

た場合，開発日時に最も近い過去の日付のアーカイブから依存クトである．最新コミットではテストケース数が 3,400 を超え

パッケージをインストールする．依存パッケージのインストーており，テストを使用した欠陥の収集に適しているプロジェク

ル元が GitHub の場合，GitHub からリポジトリをクローンし，トである．収集対象とするコミットは 2023 年 6 月から過去 5

GitHub 上の依存関係をローカル上の依存関係に置き換えて依存年間の計 2,762 コミットである．

パッケージをインストールする．依存パッケージのバージョン

4. 2 欠陥収集過程の分析

は GitHub 上のコミット履歴からコミット日時を参照し，開発日

本手法を dplyr に適用した結果，176 ペアがすべてのステップ時における最新バージョンを選択した．依存関係を GitHub 上を通過し，欠陥データとして収集された．ステップごとのフィからローカル上に置き換えた理由は，インストール元が GitHub

ルター通過数を表 1 に示し，各ステップごとに分析する．

のパッケージは再帰的な依存関係の制御が難しいためである．

ステップ 1 ではコミットの件数が 2,762 コミットから 926 コ

一部の 𝐶 𝑓 𝑖 𝑥 候補については GitHub 上の依存関係をローカル上

ミットに減少しており，コミットの探索範囲を全体の約 34% にの依存関係に置き換えることができず，実行環境の構築に失敗削減できた．しかし，全コミットのうち約 34% が欠陥修正といした．R 本体のインストールやバージョン変更には rig6 を使用

うのは割合として高いと思われる．これは dplyr が成熟したプ

した．

ロジェクトであり，保守に関するコミットが多いことが理由のステップ 4: 𝑪 𝒇 𝒊 𝒙 候補の検証

1 つであると考える．また，ステップ 1 ではコミットメッセー

本ステップではテストを実行し，𝐶 𝑓 𝑖 𝑥 候補のソースコードにジに issue 番号が含まれていれば 𝐶 𝑓 𝑖 𝑥 候補として抽出される欠陥が含まれていないことを確認する．テスト実行においてテが，issue の内容は考慮していない．そのため，欠陥修正以外にストが終了しない場合があるため，テスト実行時のタイムアウ

関する issue を扱うコミットが 𝐶 𝑓 𝑖 𝑥 候補に混入し，フィルター

トを 5 分とした．𝐶 𝑓 𝑖 𝑥 の必要条件は，「𝐶 𝑓 𝑖 𝑥 のソースコードが通過数が多くなった可能性がある．ステップ 1 におけるコミッ

𝐶 𝑓 𝑖 𝑥 のテストにすべて成功」である．𝐶 𝑓 𝑖 𝑥 候補のソースコー

トメッセージのフィルター内容と該当件数を表 2 に示す．スドが 1 つでもテストに失敗した場合は 𝐶 𝑓 𝑖 𝑥 候補から排除する．

テップ 1 を通過したコミットの中で issue 番号をコミットメッステップ 5: 𝑪𝒃𝒖𝒈 候補の実行環境の構築

セージに含むコミットは約 91% であり，大半を占めていた．こ本ステップではステップ 3 と同様に，𝐶𝑏𝑢𝑔 候補開発時点とれは dplyr の issue 管理が十分に行われているからだと考える．

同じバージョンの R 本体と依存パッケージをインストールし，

キーワードによるフィルターでは ﬁx，error，remove が順に多𝐶𝑏𝑢𝑔 候補開発時点の実行環境を構築する．
ステップ 6: 𝑪𝒃𝒖𝒈 候補の検証

かった．problem，solve，repair はコミットメッセージ中にほとんど現れなかった．

本ステップではテストを実行し，𝐶𝑏𝑢𝑔 候補のソースコードに欠陥が含まれていることを確認する．ステップ 4 と同じく，テ
スト実行時のタイムアウトは 5 分とした．𝐶𝑏𝑢𝑔 の必要条件は，「𝐶𝑏𝑢𝑔 のソースコードが 𝐶 𝑓 𝑖 𝑥 のテストに 1 つ以上失敗」である．開発者は欠陥を修正するときにその欠陥を検出できるテス

表 1: ステップごとのフィルター通過数
ステップ

件数

過去 5 年間の総コミット数

2,762 コミット

ステップ 1：𝐶 𝑓 𝑖 𝑥 候補の抽出

926 コミットトを追加する場合があるため，𝐶 𝑓 𝑖 𝑥 候補のテストを 𝐶𝑏𝑢𝑔 候補

ステップ 2：𝐶𝑏𝑢𝑔 候補と 𝐶 𝑓 𝑖 𝑥 候補のペア作成のソースコードに適用している．𝐶𝑏𝑢𝑔 候補のソースコードがステップ 3：𝐶 𝑓 𝑖 𝑥 候補の実行環境の構築

676 ペア

すべてのテストに成功した場合は 𝐶𝑏𝑢𝑔 候補から排除する．まステップ 4：𝐶 𝑓 𝑖 𝑥 候補の検証

383 ペアステップ 5：𝐶𝑏𝑢𝑔 候補の実行環境の構築

376 ペアステップ 6：𝐶𝑏𝑢𝑔 候補の検証

176 ペア

た，すべてのテストケースが実行完了せず，テストが実行途中で終了した場合も 𝐶𝑏𝑢𝑔 候補から排除する．
ステップ 6 まで通過した 𝐶𝑏𝑢𝑔 候補と 𝐶 𝑓 𝑖 𝑥 候補のペアは 𝐶𝑏𝑢𝑔と 𝐶 𝑓 𝑖 𝑥 のペアとなり，欠陥データとしてデータセットに保存される．𝐶𝑏𝑢𝑔 には欠陥を含むソースコードが含まれ，𝐶 𝑓 𝑖 𝑥 に

表 2: ステップ 1 におけるコミットメッセージのフィルター内容と該当件数は欠陥が修正されたソースコードと欠陥を検出できるテストがフィルター内容

件数含まれる．

issue 番号

846

ﬁx

274

error

122

remove81

4. 1 dplyr

issue

24

本手法で欠陥が収集可能であることを確認するため，dplyr プ

problem8

ロジェクトから欠陥収集を試みる．dplyr はデータフレームの

solve

8

repair6

4. 欠陥収集手法の試行

1,048 ペア

（注 6）：https://github.com/r-lib/rig

—3—

70
欠陥数

60

欠陥候補数

50

件
数

40
30

20
10
0
10 11 12 1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6
2019年

2020年

2021年

2022年

2023年

Cfixのコミット日時

図 2: 期間ごとの欠陥数と欠陥候補数

ステップ 2 では 926 件のコミットから 1,048 件の 𝐶 𝑓 𝑖 𝑥 候補と98% の 𝐶𝑏𝑢𝑔 候補に対して開発当時の実行環境を構築できた．

𝐶𝑏𝑢𝑔 候補のペアを得た．マージコミットにより 1 つのコミッ

ステップ 3 とは異なり，非常に高い割合で開発当時の実行環境

トが複数の親コミットを持つ場合があるため，ステップ 2 ではの構築に成功した．これは，𝐶𝑏𝑢𝑔 候補は 𝐶 𝑓 𝑖 𝑥 候補の親コミッ

ステップ 1 より件数が多くなっている．

トであり，多くの場合開発日時は近いからだと考える．ステッステップ 3 では，ステップ 2 を通過したコミットのうち約プ 5 では 𝐶 𝑓 𝑖𝑥 候補の開発環境を構築できた 𝐶𝑏𝑢𝑔 候補のみを

65% の 𝐶 𝑓 𝑖 𝑥 候補に対して開発当時の実行環境を構築できた．

対象としているため，𝐶𝑏𝑢𝑔 候補の実行環境の構築に成功した

ステップ 3 で排除された理由としては R のクラッシュが最も割合は高くなったと予想される．

多かった．その他の理由としては依存パッケージのコンパイルステップ 6 では，ステップ 5 を通過したコミットのうち約

失敗，依存関係の解決の失敗が多かった．依存パッケージのイ

47% の 𝐶𝑏𝑢𝑔 候補に対してテストが 1 つ以上失敗した．ステッンストール時に R のクラッシュや依存パッケージのコンパイル

プ 6 で排除された理由としてはすべてのテスト成功が最も多失敗が発生した原因として，R の実行環境に問題があると考え

く，排除理由の約 7 割を占めていた．その他の理由としてはる．R 本体だけでなく，R を実行する環境も過去に戻すとこれ

dplyr パッケージのコンパイル失敗，テスト実行時間のタイム

らのエラーを解決できると予想する．依存パッケージのインスアウトが多かった．すべてのテストケースが実行完了せず，テトール時に依存関係の解決の失敗が発生した原因として，依存ストが実行途中で終了したケースが 2 件だけあった．排除理由

パッケージのインストール方法に問題があると考える．本手法のうちすべてのテスト成功が 7 割を占めたのは，ステップ 1 のでは開発日時を元に依存パッケージをインストールしたが，イフィルターの緩さが原因であると考える．ステップ 1 では欠陥

ンストールされた依存パッケージのバージョンが適切でなかっ修正以外に関する issue を扱うコミットも 𝐶 𝑓 𝑖 𝑥 候補に混入するた可能性がある．依存関係の解決に失敗した場合は，別の日付ため，実際には欠陥が含まれていない 𝐶𝑏𝑢𝑔 候補がステップ 6のアーカイブから依存パッケージをインストールすることで依でテストがすべて成功したと考える．また，ステップ 1 では R

存関係の解決に成功する可能性がある．

のテスト追加を条件にしていないため，欠陥を修正したがそのステップ 4 では，ステップ 3 を通過したコミットのうち約57% の 𝐶 𝑓 𝑖𝑥 候補に対してテストがすべて成功した．ステップ

欠陥を検出するテストを追加しなかった場合にテストがすべて成功した可能性がある．

4 で排除された理由としてはテスト実行時間のタイムアウトが

4. 3 期間ごとの欠陥数の分析

最も多く，排除理由の約半数を占めていた．その他の理由とし

過去 5 年間のコミットから欠陥収集を試みた結果として，期てはテストが 1 つ以上失敗，dplyr パッケージのコンパイル失間ごとに収集した欠陥数を分析する．図 2 に期間ごとの欠陥

敗が多かった．テスト実行時のタイムアウトは 5 分としたが，数と欠陥候補数を示す．欠陥数は全ステップを通過した 𝐶𝑏𝑢𝑔

時間が短すぎた可能性がある．タイムアウトによって排除されと 𝐶 𝑓 𝑖 𝑥 のペア数であり，欠陥候補数はステップ 2 を通過した

たコミットに対しては，タイムアウトの時間を調整したうえで

𝐶𝑏𝑢𝑔 候補と 𝐶 𝑓 𝑖𝑥 候補のペア数である．期間は 𝐶 𝑓 𝑖 𝑥 のコミッ

再度テストを行う必要があると考える．テストが 1 つ以上失敗

ト日時で分類した．2019 年 12 月から 2023 年 5 月までの約 3

したコミットもあるが，テストが失敗した原因として依存パッ

年半にかけて欠陥を収集できたが，収集した欠陥数は月によっ

ケージのバージョンが適切でない，テストに不備があるなどてばらつきがある．日付が古いほどその月の欠陥候補数に対し様々な可能性がある．

て収集できた欠陥数が少ない傾向にある．特に 2020 年 6 月以

ステップ 5 では，ステップ 4 を通過したコミットのうち約前は欠陥候補数と比較して収集した欠陥数は非常に少なくなっ

—4—

60

70

50

60
50

40

欠 40
陥
数 30

欠
陥 30
数

20

20

10

10

0

0
1

2～5

6～10

11～20

21～30

1

31～

2～5

6～10

修正行数

11～15

16～20

21～

ハンク数

図 3: 修正行数ごとの欠陥数

図 5: ハンク数ごとの欠陥数

120

50
45

100

40
35

80

30
欠
陥 25
数
20

欠
陥 60
数

40

15
10

20

5
0

0
1

2

3

4

5

1

6～

2

修正ファイル数

図 4: 修正ファイル数ごとの欠陥数ており，コミット日時が古いほど欠陥の収集が難しいとわかる．

4. 4 欠陥データの分析収集した欠陥データの分析を行う．分析内容は修正の大きさ，修正箇所の数，欠陥の複雑さの 3 つである．

3～5

6～10

11～15

16～

失敗したテストケース数

図 6: 失敗したテストケース数ごとの欠陥数ない欠陥であるとわかる．
最後に，欠陥の複雑さを分析する．図 6 に失敗したテスト
ケース数ごとの欠陥数を示す．失敗したテストケース数は 𝐶𝑏𝑢𝑔
が 𝐶 𝑓 𝑖𝑥 のテストに失敗したテストケース数である．失敗した

まず，修正の大きさを分析する．図 3 に修正行数ごとの欠陥

テストケース数が多いほどその欠陥は複雑だと考えられる．失数を示す．修正行数は R の各ソースファイルの変更行数を合計敗したテストケース数が 1 つの欠陥数は 47 件，失敗したテスト

した値であり，空行やコメント行は除外して計算した．修正行

ケース数が 2 つの欠陥数は 33 であり，約半数の欠陥は 2 つ以

数が 1 行の欠陥は 17 件，修正行数が 2 行以上 5 行以下の欠陥

下のテストケースで欠陥を検出しているとわかる．失敗したテは 31 件であり，これらの欠陥は修正の大きさが小さい欠陥でストケース数が 11 以上の欠陥は少数であった．欠陥を検出すある．また，修正行数が 31 行以上の欠陥は 55 件であり，これるためのテストケースが少ない欠陥が多いため，本データセッらの欠陥は修正に大きな変更を要する．本データセットに含まトに含まれる欠陥は単純な欠陥が多いと予想される．

れる欠陥は修正の大きさが多様であるとわかる．
次に，修正箇所の数を分析する．図 4 に修正ファイル数ごと

5. 制

約

の欠陥数を示す．修正ファイル数は R のソースフォルダの中

5. 1 手法に関する制約で変更されているファイル数である．修正ファイル数が 1 つの𝐶 𝑓 𝑖𝑥 候補と 𝐶𝑏𝑢𝑔 候補を決定するにあたり，簡易的な方法を

欠陥は 102 件であり，半数以上を占める．修正ファイル数が 1採用している．𝐶 𝑓 𝑖 𝑥 候補は issue 番号とキーワードを用いて抽

つの欠陥は修正範囲が 1 ファイル内に限定されるため，欠陥研出した．この方法は多数の欠陥修正コミットをカバーできる半究で扱いやすい欠陥である．図 5 にハンク数ごとの欠陥数を示

面，欠陥修正以外のコミットも 𝐶 𝑓 𝑖𝑥 候補に混入してしまう．

す．ハンク数は連続したコード変更の数であり，修正ファイル

本研究では 𝐶 𝑓 𝑖 𝑥 候補を抽出する際に issue の内容は考慮してが複数ある場合は各ファイルのハンク数を合計した値である．

いないが，Gyimesi ら [10] の手法では issue に付与されている

ハンク数が 1 の欠陥は 36 件，ハンク数が 2 以上 5 以下の欠陥

ラベルを確認している．欠陥修正以外のコミットの混入を防は 59 件であり，これらの欠陥は修正箇所が少ない欠陥である．

ぐために，𝐶 𝑓 𝑖 𝑥 候補の抽出方法を改善する余地がある．また，

本データセットに含まれる欠陥は半数以上が修正箇所の数が少𝐶𝑏𝑢𝑔 候補として 𝐶 𝑓 𝑖𝑥 候補の親コミットを採用しており，これ—5—も簡易的な方法である．この方法は既存の欠陥データセット研

めに，これらの改善に取り組む予定である．2 つ目は欠陥デー

究 [7] [10] [11] でも採用されており，𝐶𝑏𝑢𝑔 と 𝐶 𝑓 𝑖 𝑥 の差分が小タの拡充である．多種多様な欠陥をデータセットに含めるため

さいという点では優れている．しかし，𝐶𝑏𝑢𝑔 は欠陥が混入しには様々なプロジェクトから欠陥を収集する必要があると考えたコミットとは限らず，完成した欠陥データセットは欠陥が混る．本手法を他のプロジェクトへ適用し，多種多様な欠陥の収入したコミットや欠陥の潜伏期間などを分析する研究には適し集を予定している．

ていないデータセットとなる．
本研究では dplyr から欠陥を収集したが，他のプロジェクトからは欠陥を十分に収集できない可能性がある．コミットメッ
セージや issue 管理が適切に行われており，テストが十分に行われているプロジェクトであれば本手法の適用は可能である．
しかし，他のプロジェクトの過去のコミットに対してテスト実
行環境の構築やテスト実行が問題なく行えるかについては不明
である．

5. 2 収集した欠陥データに関する制約本研究で収集した欠陥データは，欠陥がソースコードに含まれていない可能性がある．本研究では，テスト失敗の原因は
ソースコードに含まれる欠陥だと仮定している．しかし，実際にはテスト自体の欠陥やテスト実行環境の不備など，ソース
コードに含まれる欠陥以外の理由でテストが失敗する場合がある．ソースコードに含まれる欠陥のみを収集するためには手動検証のステップを追加し，テスト失敗の原因がソースコードに含まれる欠陥であることを確認する必要がある．既存の欠陥
データセット研究 [7] [9] [10] では手動検証を行い，欠陥がソースコードに含まれていることを確認している．また，R パッ
ケージは一部を C や C++ による実装が可能であるが，本研究ではそれらのソースファイルの変更を考慮していない．そのた
め，R のソースコードではなく C や C++ のソースコードに欠陥が含まれている可能性がある．実際，本研究で収集した 176
個の欠陥のうち 𝐶 𝑓 𝑖 𝑥 に C や C++ のソースコードの変更が含まれる欠陥は 15 件存在した．割合としては少ないが，これら 15件についてはさらなる検証が必要である．
本研究では収集した欠陥データに対して，ペアの差分が欠陥修正のみであると保証していない．収集したペアの差分は欠陥修正以外に，リファクタリングや機能追加などの欠陥修正とは無関係な変更を含んでいる可能性がある．欠陥研究への応用を考えると，欠陥データセットはペアの差分が欠陥修正のみである修正パッチを含んでいることが望ましい．Just ら [7] の研究
ではペアの差分から欠陥修正とは無関係な変更を取り除き，差分を最小化している．また，Widyasari ら [9] の研究では差分の最小化を行わず，ペアの差分に欠陥修正とは無関係な変更が含まれるペアは欠陥データセットから排除している．

6. お わ り に本研究では R 言語における欠陥研究の促進を目的として，欠陥データセットの構築を試みた．その結果，dplyr プロジェク
トから欠陥の規模が多様な 176 個の欠陥を収集した．
今後の課題として以下の 2 つを挙げる．1 つ目は欠陥データ

謝辞

本 研 究 の 一 部 は ，JSPS 科 研 費（JP21H04877，

JP20H04166，JP21K18302，JP21K11829）による助成を受けた．
文

献[1] V. Sobreira, T. Durieux, F. Madeiral, M. Monperrus, and M.
deAlmeida Maia, “Dissection of a bug dataset: Anatomy of 395 patchesfrom defects4j,” Proc. International Conference on Software Analysis,
Evolution and Reengineering, pp.130–140, 2018.
[2] T.-D. B. Le, D. Lo, C. Le Goues, and L. Grunske, “A learning-to-rankbased fault localization approach using likely invariants,” Proc. International Symposium on Software Testing and Analysis, pp.177–188,
2016.
[3] G. Laghari, A. Murgia, and S. Demeyer, “Fine-tuning spectrum based
fault localisation with frequent method item sets,” Proc. International
Conference on Automated Software Engineering, pp.274–285, 2016.
[4] S. Pearson, J. Campos, R. Just, G. Fraser, R. Abreu, M.D. Ernst, D.
Pang, and B. Keller, “Evaluating and improving fault localization,”
Proc. International Conference on Software Engineering, pp.609–620,
2017.
[5] X.B.D. Le, D. Lo, and C. Le Goues, “History driven program repair,”Proc. International Conference on Software Analysis, Evolution, andReengineering, pp.213–224, 2016.
[6] Q. Xin and S.P. Reiss, “Leveraging syntax-related code for automatedprogram repair,” Proc. International Conference on Automated Software Engineering, pp.660–670, 2017.
[7] R. Just, D. Jalali, and M.D. Ernst, “Defects4j: A database of existingfaults to enable controlled testing studies for java programs,” Proc. International Symposium on Software Testing and Analysis, pp.437–440,
2014.
[8] C. Le Goues, N. Holtschulte, E.K. Smith, Y. Brun, P. Devanbu, S.
Forrest, and W. Weimer, “The manybugs and introclass benchmarks
for automated repair of c programs,” Transactions on Software Engineering, vol.41, no.12, pp.1236–1256, 2015.
[9] R. Widyasari, S.Q. Sim, C. Lok, H. Qi, J. Phan, Q. Tay, C. Tan, F. Wee,
J.E. Tan, Y. Yieh, B. Goh, F. Thung, H.J. Kang, T. Hoang, D. Lo, andE.L. Ouh, “Bugsinpy: A database of existing bugs in python programs
to enable controlled testing and debugging studies,” Proc. Joint Meeting on European Software Engineering Conference and Symposium on
the Foundations of Software Engineering, pp.1556–1560, 2020.
[10] P. Gyimesi, B. Vancsics, A. Stocco, D. Mazinanian, c. Beszédes, R.
Ferenc, and A. Mesbah, “Bugsjs: a benchmark of javascript bugs,”
Proc. International Conference on Software Testing, Validation andVeriﬁcation, pp.90–101, 2019.
[11] S. Benton, A. Ghanbari, and L. Zhang, “Defexts: A curated datasetof reproducible real-world bugs for modern JVM languages,” Proc.
International Conference on Software Engineering, pp.47–50, 2019.
[12] J. Lai, C.J. Lortie, R.A. Muenchen, J. Yang, and K. Ma, “Evaluating
the popularity of r in ecology,” Journal on Ecosphere, vol.10, no.1,
p.e02567, 2019.
[13] “PYPL PopularitY of Programming Language Index,” accessed 202309-07. https://pypl.github.io/PYPL.html.
[14] M. Vidoni, “Software engineering and r programming: A call for research,” Journal on R J., vol.13, no.2, p.600, 2021.
[15] A. Decan, T. Mens, M. Claes, and P. Grosjean, “When GitHub meets
CRAN: An analysis of inter-repository package dependency problems,”
Proc. International Conference on Software Analysis, Evolution, andReengineering, pp.493–504, 2016.

セット構築方法の改善である．𝐶 𝑓 𝑖 𝑥 候補と 𝐶𝑏𝑢𝑔 候補の決定方
法や収集した欠陥の検証方法など，欠陥収集過程において多くの改善点がある．欠陥データセットの信頼性と価値を高めるた—6—