l. debugging

29
L. Debugging 前前前前 前前前 前前前 前前 前 西一 前前前 前 、一 § 前前 § NII 前前前前前前前前前 12/08/30 1

Upload: carlow

Post on 18-Jan-2016

64 views

Category:

Documents


2 download

DESCRIPTION

L. Debugging. 前澤悠太 † 、清水遼 ‡ 、小林努 † 、 西浦一貴 † 、星敬一郎 § † 東大 § NII 本位田研、 ‡ 早大深澤研. An Empirical Study about the Effectiveness of Debugging When Random Test Cases Are Used. Ceccato , M., Marchetto , A., Mariani , L. Nguyen, C.D., and Tonella , P. Proc . ICSE’12, pp.452-462, 2012. - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: L. Debugging

L. Debugging

前澤悠太†、清水遼‡、小林努†、西浦一貴†、星敬一郎 §

†東大 §NII本位田研、‡早大深澤研

12/08/30 1

Page 2: L. Debugging

An Empirical Study about the Effectiveness of Debugging When Random Test Cases Are Used

Ceccato, M., Marchetto, A., Mariani, L. Nguyen, C.D., and Tonella, P.Proc. ICSE’12, pp.452-462, 2012.

東京大学 本位田研 前澤悠太12/08/30 2

Page 3: L. Debugging

概要• 問題– 自動生成されたテストケースは可読性が低い– デバッグ作業に与える影響の根拠はない

• アプローチ– 手動記述 (manual) or 自動生成 (autogen)のテストケース– デバッグにおける正確性と効率性についてユーザ実験

• 貢献– 定性的/定量的な評価実験による知見獲得

12/08/30 3

Page 4: L. Debugging

実験の設定• 被験者

• 対象アプリ( Java)– manualを入手可能

@SIR

• 実験手順– プレテスト

• プログラミング能力、開発経験、大学での成績等を測定

– 訓練セッション• 対象アプリを理解• デバッグ作業の練習

– 実験• 被験者は欠陥を修正• 作業時間を測定

– 事後アンケート12/08/30 4

実験1 実験2N/A 学部生 2:8人

修士学生 1:7人 修士学生 3:14人

1 University of Trento, “Software analysis and testing”を履修2 University of Milano Bicocca, “Software analysis and testing”を履修3 University of Milano Bicocca, “Software quality control”を履修

Jtopas XML-security

機能 トークナイザ

XMLの署名検証

スケール 15クラス2,171 MeLOC

228クラス14,754 MeLOCSIR: Software-artifact Infrastructure Repository, http://sir.unl.edu

MeLOC: Method Lines of Code

Page 5: L. Debugging

実験で収集したデータの分析• 正確性–正しく修正 (*)できた欠陥 (**)数

12/08/30 5

(論文より抜粋)manualと autogenで正確性に違いがあることは確からしい

(*) 正しく修正:著者らがあらかじめ用意した         テストケースが成功

(**) 欠陥:次の 4つを満たすもの1. アプリの異なる部分に起因2. manualと autogenで発見可能3. 別々のテストケースで発見可能4. SIRで manualを入手可能

(Wilcoxon検定:有意度 95%)

Page 6: L. Debugging

• 効率性:

実験で収集したデータの分析

12/08/30 6

(論文より抜粋)manualと autogenで効率性に違いがあることは確からしい

正しく修正できた欠陥数

デバッグ作業にかけた時間 (min)

(Wilcoxon検定:有意度 95%)

Page 7: L. Debugging

実験結果の分析を元に獲得した知見• デバッグの正確性と効率性

– テストケースの無意味な識別子• 影響なし

– テストケースの複雑さ• 影響あり、簡単な方がよい

– テスト・デバッグ作業の能力と経験• 影響あり、能力が高く、経験豊富な方がよい

• 複雑なテストシナリオ– デバッグ能力を向上– デバッガツールの有効活用

12/08/30 7

TestCase1…ExecOnlyLogined…

( Eclipse debugger)

意味無し

意味あり

ログイン成功

管理者権限あり

管理者機能を表示

logined == true

複雑) 簡単)

結論として提案するテストプロセス1. autogenを利用してデバッグ2. manualを用意

autogenの方が manualより効率的manualの複雑さは autogenでは補えない

Page 8: L. Debugging

Reducing Confounding Bias in Predicate-Level

Statistical Debugging Metrics

Ross Gore and Paul F. Reynolds, Jr.

8

東京大学 本位田研 前澤悠太 西浦一貴

Page 9: L. Debugging

背景・問題・貢献Predicate-level Statistical Debugging(後述 ) プログラム中に条件式 (x > 0など )を埋め込みテスト実行

 テストの成功 /失敗と条件の真偽から欠陥位置推定  (i.e., テスト失敗時に真となることの多い条件が怪しい)

9

それぞれに対する既存手法を拡張しバイアスを軽減した欠陥位置推定のための回帰モデル

背景

問題

貢献

2つのバイアスに影響される (後述 )• 制御フロー依存バイアス• 失敗フローバイアス

Page 10: L. Debugging

// 一次元距離を求めるint distance(int x, int y) { int diff = x – y; if (diff <= 1) { int dist = 0; dist = y – x; return dist; } int dist = 0; dist = x – y; return dist;}

5行目に欠陥を含むプログラム

123456789

10111213

Predicate-Level Statistical Debugging行 条件式 2,

25, 4

5,1

-4, -2

1, 0

従来法 提案法

5 diff == 0 T F F F F 4 3

5 diff > 0 F T F F T 1 1

5 diff < 0 F F T T F 4 3

6 dist == 0 T T T T T 3 36 dist > 0 F F F F F 4 3

6 dist < 0 F F F F F 4 3

7 dist == 0 T F F F F 4 3

7 dist > 0 F F T T F 4 3

7 dist < 0 F T F F T 1 2

テスト結果 S F S S F

10

欠陥:正しくは diff <= 0

Page 11: L. Debugging

// 一次元距離を求めるint distance(int x, int y) { int diff = x – y; if (diff <= 1) { int dist = 0; dist = y – x; return dist; } int dist = 0; dist = x – y; return dist;}

5行目に欠陥を含むプログラム

123456789

10111213

Predicate-Level Statistical Debugging行 条件式 2,

25, 4

5,1

-4, -2

1, 0

従来法 提案法

5 diff == 0 T F F F F 4 3

5 diff > 0 F T F F T 1 1

5 diff < 0 F F T T F 4 3

6 dist == 0 T T T T T 3 36 dist > 0 F F F F F 4 3

6 dist < 0 F F F F F 4 3

7 dist == 0 T F F F F 4 3

7 dist > 0 F F T T F 4 3

7 dist < 0 F T F F T 1 2

テスト結果 S F S S F

11

1. 文中の変数に対し

条件文生成

Page 12: L. Debugging

// 一次元距離を求めるint distance(int x, int y) { int diff = x – y; if (diff <= 1) { int dist = 0; dist = y – x; return dist; } int dist = 0; dist = x – y; return dist;}

5行目に欠陥を含むプログラム

123456789

10111213

Predicate-Level Statistical Debugging行 条件式 2,

25, 4

5,1

-4, -2

1, 0

従来法 提案法

5 diff == 0 T F F F F 4 3

5 diff > 0 F T F F T 1 1

5 diff < 0 F F T T F 4 3

6 dist == 0 T T T T T 3 36 dist > 0 F F F F F 4 3

6 dist < 0 F F F F F 4 3

7 dist == 0 T F F F F 4 3

7 dist > 0 F F T T F 4 3

7 dist < 0 F T F F T 1 2

テスト結果 S F S S F

12

1. 文中の変数に対し

条件文生成

x, yの値

2. テストを実行 ・条件真偽 ・テスト結果

Page 13: L. Debugging

// 一次元距離を求めるint distance(int x, int y) { int diff = x – y; if (diff <= 1) { int dist = 0; dist = y – x; return dist; } int dist = 0; dist = x – y; return dist;}

5行目に欠陥を含むプログラム

123456789

10111213

Predicate-Level Statistical Debugging行 条件式 2,

25, 4

5,1

-4, -2

1, 0

従来法 提案法

5 diff == 0 T F F F F 4 3

5 diff > 0 F T F F T 1 1

5 diff < 0 F F T T F 4 3

6 dist == 0 T T T T T 3 36 dist > 0 F F F F F 4 3

6 dist < 0 F F F F F 4 3

7 dist == 0 T F F F F 4 3

7 dist > 0 F F T T F 4 3

7 dist < 0 F T F F T 1 2

テスト結果 S F S S F

13

1. 文中の変数に対し

条件文生成2. テストを実行 ・条件真偽 ・テスト結果

x, yの値

欠陥に関連する文・条件に高い優先度

3. 欠陥に関連しそうな文・条件推定

Page 14: L. Debugging

行 条件式 2, 2

5, 4

5,1

-4, -2

1, 0

従来法 提案法

5 diff == 0 T F F F F 4 3

5 diff > 0 F T F F T 1 1

5 diff < 0 F F T T F 4 3

6 dist == 0 T T T T T 3 36 dist > 0 F F F F F 4 3

6 dist < 0 F F F F F 4 3

7 dist == 0 T F F F F 4 3

7 dist > 0 F F T T F 4 3

7 dist < 0 F T F F T 1 2

テスト結果 S F S S F

2つのバイアス// 一次元距離を求めるint distance(int x, int y) { int diff = x – y; if (diff <= 1) { int dist = 0; dist = y – x; return dist; } int dist = 0; dist = x – y; return dist;}

5行目に欠陥を含むプログラム

123456789

10111213

14

1. 制御フロー依存バイアス 対象 : 欠陥を含む文と依存関係を持つ文 (e.g., 5行目で diff > 0 なら 7行目で dist < 0)

2. 失敗フローバイアス 対象 : 欠陥の発現後に実行される文

欠陥に関連する文・条件に高い優先度

Page 15: L. Debugging

制御フロー依存バイアスの検出

15

ステートメントレベルでの既存手法 * 制御フローを解析して直前の分岐文を判別

     → 制御フロー依存する文 If (diff <= 1)

int dist = 0;dist = y – x;return dist;

int diff = x – y;

diff <= 1

!(diff <= 1)

貢献:条件式レベルに拡張

直前の分岐文の条件式と,その否定を考える e.g., (diff <= 1), (!(diff <= 1))注目する式に到達するために成立すべきものが,制御フロー依存する条件式

制御フロー依存

*本論文参考文献 [10, 11]

Page 16: L. Debugging

失敗フローバイアスへの対応

16

既存手法 (本論文参考文献 [1, 2]) ヒューリスティックに基づく式で,バイアスの影響を軽減

貢献:バックドア基準を満たすような回帰モデル

TestResult = αp + τpTp + βpCp + ωpDp+ εp

TestResult: テスト失敗なら 1, 成功なら 0, αp, τp, βp, ωp: 係数 , εp: 誤差Tp: テスト時に条件式 pが真なら 1 ,それ以外は 0Cp: pの制御フロー依存条件式が真なら 1, それ以外は 0Dp: 条件式 pが評価された時 1, それ以外は 0

制御フロー依存バイアスの考慮

失敗フローバイアスの考慮

Page 17: L. Debugging

実験:欠陥に関連する条件文発見効率

17

最小二乗法で求めた τpを利用して,既存のメトリクスを書き換え

2 種類の predicate-level statistical debugger( 赤,白 ) それぞれ利用時の「欠陥に関連する条件文へのランク付け」の相対的性能向上

従来法 vs. 制御フロー依存バイアスのみ考慮 制御フロー依存バイアスのみ考慮 vs. 失敗フローバイアスも考慮

180プログラム中性能向上 : 94横ばい : 84性能低下 : 2

180プログラム中性能向上 : 68横ばい : 112性能低下 : 0

Page 18: L. Debugging

BugRedux: Reproducing Field Failures for In-House Debugging

Wei Jin and Alessandro Orso

18

国立情報学研究所 本位田研 星 敬一郎       東京大学 本位田研 西浦 一貴

Page 19: L. Debugging

目的と問題目的:出荷後に報告された欠陥を,社内で再現すること

19

問い 2: クラッシュレポートはどんな実行時情報を含むべきか?

多くの情報 (e.g., 実行トレースすべて ) - 実行時オーバーヘッド大 - プライベートな情報を含んでしまう恐れ

少ない情報 (e.g., 発生した例外の種類のみ ) - 報告された欠陥が再現できない

トレードオフ

問い 1: どうすれば報告された欠陥を再現できるか?

Page 20: L. Debugging

提案ツールと貢献

20

• 実行時情報を収集し,それを利用して 欠陥を再現するツール BugReduxの開発• 収集する情報を変化させて,費用対効果を調

欠陥を再現するテストケース生成

提案ツール動作図 発表論文より引用( 日本語は発表者 )

ログ関数埋め込み

Page 21: L. Debugging

報告された欠陥の再現

21

クラッシュレポート中の文をゴールの列とし,ゴールを同じ順番で通過する

欠陥の再現 :=

1. プログラムを記号的に実行. 次に通過したい文に近づくように探索

2. 得られた条件を満たす入力を,制約ソルバで求める

Page 22: L. Debugging

クラッシュレポートに含める情報

22

以下の4種類を考慮し,実験的に評価

欠陥を再現するためにはどんな情報を記録すべき

か?

• 例外発生時の位置 (POF)• 例外発生時のコールスタック (Call Stack)• 例外発生までの関数呼び出し履歴 (Call Sequence)• 完全な実行トレース (Complete Trace)

Page 23: L. Debugging

実験結果 1: オーバーヘッド

23

• POF と Call Stackはクラッシュレポートに入っているのが一般的,  オーバーヘッドはほぼ無視できる程度• Call Sequence は時間・空間ともにオーバーヘッドがあるが,  完全なトレースよりは桁違いに小さいオーバーヘッド

時間オーバーヘッド (%) 空間オーバーヘッド (kB)

対象としたプログラム達

Page 24: L. Debugging

実験結果 2: 欠陥再現性能

24

• POF, Call Stack, Call Sequence までは,情報が増えるほど,  欠陥再現の性能が高くなっている• 完全な実行トレースを再現しようとすると,  制約が複雑になりすぎるためか,テストケース生成に失敗した

テストケース生成にかかった時間欠陥がただしく再現できたかどうか (Yes or No)

対象としたプログラム達

Page 25: L. Debugging

ICSE2012 勉強会“ Object-Centric Debugging”

Jorge Ressia (Univ. of Bern)Alexandre Bergel (Univ. of Chile)Oscar Nierstrasz (Univ. of Bern)

早稲田大学 深澤研究室 清水遼( [email protected])

Page 26: L. Debugging

概要

目的

• 開発者の持つ問いにより良く答えられるデバッガの実現

問題

• ブレークポイントを用いる場合,全体動作の把握,ブレークポイントの定義にコストがかかる

解法

• “ オブジェクト”毎の状態に着目したデバッグの提案• オブジェクトに着目した新たな停止操作の定義

結果

• ケーススタディを通し,全体動作を把握することなく,既存のデバッガよりも簡潔に停止操作の指定が可能なことを示した

Page 27: L. Debugging

背景 デバッグ・ソフトウェア理解へのデバッガの利用

このメソッド

はいつ呼び出される?

このクラスのインスタンスはいつ生成され

る?

プログラマが持つ問い†

† J. Sillito et al. “Questions programmers ask during software evolution tasks”, FSE 2006.

プログラマが用いるツール

ブレークポイント・条件付きブレークポイントを用いたスタックベースのデバッガ

この変数/データ構造

はいつアクセ

スされる?

この引数の実行時の値は?

本当に問いに答えることに適しているのか?ブレークポイントを逐一決定する手間が大きいので

は?

Page 28: L. Debugging

提案手法Object-centric Debugging

“ オブジェクト毎”の状態に着目したデバッグの提案

オブジェクトへの着目に適した操作を定義

ブレークポイントを設定し,実行中のプログラムに割り込み&相互作用を実現

これまでのデバッグ

指定したオブジェクトがアクセス/変更された際に実行に割り込み

Object-centric

Halt on write: 特定のオブジェクトに変更が加えられた際に停止Halt on read: 特定のオブジェクトが利用された際に停止

State-related Operations

Halt on call: 特定のオブジェクトのメソッドが他のオブジェクトから呼ばれた際に停止Halt on invoke: 特定のオブジェクトがメソッドを呼び出した際に停止Halt on object in invoke: 特定のオブジェクトがメソッド呼び出しの引数として使われた際に停止etc…

Interaction Operations

Page 29: L. Debugging

ケーススタディ Pharo† の実装に対してデバッグを実施

InstructionStream クラスの変数 pc の調査

† http://www.pharo-project.org/home ‡J. Ressia et al. “Object-Centric Debugging”, ICSE 2012.

最初のアクセスまで 18 ,次のアクセスまで 30 のステッ

プイン操作を要した

InstructionStream クラスのインスタンスに halt on callと halt on write の操作を指

定するだけ

Object-Centric Debuggin により… 簡潔な操作の指定 関連する実行部分のみの確認を実現 より効率よく開発者の要求に答えるデバッガの実現