---
# System prepended metadata

title: B4濱本：研究打ち合わせ

---

# 8/2 個別ミーティング
## 研究内容：SBFL-SuitabilityとAutorepairabilityの変遷調査

### 先行研究
- SBFL-Suitability : https://ipsj.ixsq.nii.ac.jp/ej/?action=pages_view_main&active_action=repository_view_main_item_detail&item_id=210658&item_no=1&page_id=13&block_id=8
- Autorepairability : https://sdl.ist.osaka-u.ac.jp/pman/pman3.cgi?DOWNLOAD=621

### 研究手法
- 対象プログラムのSBFLスコアやAPRスコアを,コミットを遡って測定する
- 測定は先行研究の手法を導入して行う
- スコアがどのように変化しているかを調べ,大きく変化した時にプログラムにおいてどのような変更がなされているかを確かめる.

### これまでの進捗
- 先行研究の熟読
- SBFLスコア測定ツールの導入, 簡単なアルゴリズム(順列,進数変換,経路問題)のプログラムに対するSBFLスコアの測定
- 一つ一つ手作業でプログラムを取ってきて測定するのは面倒？
→ JGitを用いて全部とってくるツール

### 研究方針
- ++JGitでのツール作成++
どこまでツールに組み込む? → プログラムを取ってくるまで？ スコアを測定するまで？
スコアの測定まで組み込むのは難しそうなので, プログラムを全部とってくるところまでをJGitで行い,測定は1つずつ手作業で
ツールを作成してしまえばスコアの測定は効率的に進むので, 第一優先で
- ++対象プログラムの適切な選定++
今絞っている条件：スター数20000以上, Javaプログラム, テストが存在.
それに加えて**一般的な(実用的な)システム**であることが望ましい
テストが複雑なプログラムだとうまく測定できない可能性も
- ++APRツールの導入++
SBFLツールは使えるがAPRツールはまだ手をつけていない
astor(Java用のプログラム自動修復ライブラリ)を楠本研の久保さんに教えていただいたので, それを用いて実装する.

できるだけ早く準備段階を終了させてスコア測定したい...

### フィードバック
- FinerGit(メソッド単位の追跡?)について調べる
- 測定対象はプログラムというより++メソッド++. 対応するテストが明確に存在するメソッドを選定する.


# 5/22

* Autorepairabilityについては自分でツール作れそうだから作る
* SBFLツールは教えてもらう
* 全てのプログラムが測定できるわけではない？（コンパイルを通さないといけないため）
* Githubでスター数の多いリポジトリの中から愚直に調査
* 変遷の原因を探る

# 5/15

第1希望：SBFL-SuitabilityやAutorepairabilityの変遷調査
第2希望：テスト自動生成ツールによって生成されたテストは本当にバグ発見に役立つのか？(テスト，欠陥限局，自動プログラム修正)
第3希望：バグ・脆弱性の重要性診断

SBFL-Suitability
https://ipsj.ixsq.nii.ac.jp/ej/?action=pages_view_main&active_action=repository_view_main_item_detail&item_id=210658&item_no=1&page_id=13&block_id=8

Autorepairability
https://sdl.ist.osaka-u.ac.jp/pman/pman3.cgi?DOWNLOAD=621

1.↑の論文を読む．
2.実際にツールを動かしてみる．
3.Gitのリポジトリの各コミットに対してSBFL/Autoを計測し，その変遷を調査する．

https://github.com/eclipse-jgit/jgit
https://github.com/kusumotolab/FinerGit

---
[SBFL-Suitability]
==参考論文「プログラムに対する欠陥限局の適合性計測」==

**用語説明**
++SBFL++
テストケースごとの成否と,プログラム中で実行される文の情報を用いて,欠陥を含む文を推測する技術.

++疑惑値++
プログラムの各文に対して欠陥を含む可能性を数値化したもの.
欠陥を含む文の疑惑値がほかより高ければSBFL結果がより正確である.
0≦susp≦1 であり,1が最も疑惑が強い.

++ミュータント++
変更が加えられたプログラム.

**研究内容**
プログラムに対してミューテーションテストを用いて意図的に欠陥を発生,SBFLを実行してどの程度正確に欠陥を特定できたかを計測.
→ 条件分岐先で実行される文の数が少ないほどSBFLスコアが向上

* 全てのテストケースを通過するプログラムを対象としている.
(→テストに失敗するプログラムに対するSBFL結果の信頼度を
事前に把握できない)
* 他のリファクタリングパターンで検証することで違う傾向を見られるかも
しれない.
* テストスイートやミュータント生成器を改変することでSBFLに
どのような変化が見られるのか?
* SBFL適合性と他の品質特性(保守性など)の関係性を明らかにすることも必要.


[Autorepairability]
==参考論文「大規模データセットと多種ミュータント演算子を利用した
自動修正適合性の再計測」==

**用語説明**
++自動修正適合性++
対象プログラムでバグが発生した場合に,そのバグをAPR技術が修正できる可能性を
表す指標.

**研究内容**
先行研究より多くのプログラム(AtCoder Beginner Contestの問題など)に対してより多くのミューテーション演算子を利用して変異プログラムを生成する.それらの変異プログラムに対して自動修正適合性の数値を計算し,どのようなプログラム構造がAPRと親和性が高いのかを明らかにする.
→ プログラムが複雑になるほど自動修正適合性が低くなる.APRツールによって自動修正適合性に差が出る.

* 限られたAPRツールで検証しているので,異なるAPRツールを用いることで違った結果が得られるかも.
* APRツールの実験設定である最大実行時間や個体数に制限を設けているので,設定を変更すると違う結果が得られるかも.







