1 / 29

L. Debugging

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.

carlow
Download Presentation

L. Debugging

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. L. Debugging 前澤悠太†、清水遼‡、小林努†、 西浦一貴†、星敬一郎§ †東大§NII本位田研、‡早大深澤研

  2. 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. 東京大学　本位田研　前澤悠太

  3. 概要 • 問題 • 自動生成されたテストケースは可読性が低い • デバッグ作業に与える影響の根拠はない • アプローチ • 手動記述(manual) or 自動生成(autogen)のテストケース • デバッグにおける正確性と効率性についてユーザ実験 • 貢献 • 定性的／定量的な評価実験による知見獲得

  4. 実験の設定 • 被験者 • 対象アプリ（Java） • manualを入手可能@SIR • 実験手順 • プレテスト • プログラミング能力、開発経験、大学での成績等を測定 • 訓練セッション • 対象アプリを理解 • デバッグ作業の練習 • 実験 • 被験者は欠陥を修正 • 作業時間を測定 • 事後アンケート 1 University of Trento, “Software analysis and testing”を履修 2 University of Milano Bicocca, “Software analysis and testing”を履修 3University of Milano Bicocca, “Software quality control”を履修 SIR: Software-artifact Infrastructure Repository, http://sir.unl.edu MeLOC: Method Lines of Code

  5. 実験で収集したデータの分析 • 正確性 • 正しく修正(*)できた欠陥(**)数 (*)正しく修正：著者らがあらかじめ用意した テストケースが成功 (**)欠陥：次の4つを満たすもの アプリの異なる部分に起因 manualとautogenで発見可能 別々のテストケースで発見可能 SIRでmanualを入手可能 （論文より抜粋） manualとautogenで正確性に違いがあることは確からしい （Wilcoxon検定：有意度95%）

  6. 実験で収集したデータの分析 • 効率性： 正しく修正できた欠陥数 デバッグ作業にかけた時間(min) （論文より抜粋） manualとautogenで効率性に違いがあることは確からしい （Wilcoxon検定：有意度95%）

  7. 実験結果の分析を元に獲得した知見 意味無し • デバッグの正確性と効率性 • テストケースの無意味な識別子 • 影響なし • テストケースの複雑さ • 影響あり、簡単な方がよい • テスト・デバッグ作業の能力と経験 • 影響あり、能力が高く、経験豊富な方がよい • 複雑なテストシナリオ • デバッグ能力を向上 • デバッガツールの有効活用 TestCase1… ExecOnlyLogined… 意味あり 複雑） 簡単） ログイン 成功 logined == true 管理者 権限あり 管理者機能 を表示 （Eclipse debugger） 結論として提案するテストプロセス autogenを利用してデバッグ manualを用意 autogenの方がmanualより効率的 manualの複雑さはautogenでは補えない

  8. Reducing Confounding Bias in Predicate-Level Statistical Debugging Metrics Ross Gore and Paul F. Reynolds, Jr. 前澤悠太 西浦一貴 東京大学本位田研

  9. 背景・問題・貢献 Predicate-level Statistical Debugging(後述) プログラム中に条件式(x > 0など)を埋め込みテスト実行 テストの成功/失敗と条件の真偽から欠陥位置推定 (i.e., テスト失敗時に真となることの多い条件が怪しい） 背景 ２つのバイアスに影響される(後述) • 制御フロー依存バイアス • 失敗フローバイアス 問題 それぞれに対する既存手法を拡張し バイアスを軽減した欠陥位置推定のための回帰モデル 貢献

  10. Predicate-Level Statistical Debugging 1 2 3 4 5 6 7 8 9 10 11 12 13 // 一次元距離を求める int distance(int x, int y) { int diff = x – y; if (diff <= 1) { intdist = 0; dist = y – x; return dist; } intdist = 0; dist = x – y; return dist; } 欠陥：正しくはdiff <= 0 5行目に欠陥を含むプログラム

  11. Predicate-Level Statistical Debugging 1 2 3 4 5 6 7 8 9 10 11 12 13 // 一次元距離を求める int distance(int x, int y) { int diff = x – y; if (diff <= 1) { intdist = 0; dist = y – x; return dist; } intdist = 0; dist = x – y; return dist; } 1. 文中の変数に対し 条件文生成 5行目に欠陥を含むプログラム

  12. Predicate-Level Statistical Debugging x, yの値 1 2 3 4 5 6 7 8 9 10 11 12 13 // 一次元距離を求める int distance(int x, int y) { int diff = x – y; if (diff <= 1) { intdist = 0; dist = y – x; return dist; } intdist = 0; dist = x – y; return dist; } 1. 文中の変数に対し 条件文生成 2. テストを実行 ・条件真偽 ・テスト結果 5行目に欠陥を含むプログラム

  13. Predicate-Level Statistical Debugging x, yの値 1 2 3 4 5 6 7 8 9 10 11 12 13 // 一次元距離を求める int distance(int x, int y) { int diff = x – y; if (diff <= 1) { intdist = 0; dist = y – x; return dist; } intdist = 0; dist = x – y; return dist; } 欠陥に関連する文・条件に高い優先度 1. 文中の変数に対し 条件文生成 2. テストを実行 ・条件真偽 ・テスト結果 3. 欠陥に 関連しそうな文・条件推定 5行目に欠陥を含むプログラム

  14. 2つのバイアス 1 2 3 4 5 6 7 8 9 10 11 12 13 // 一次元距離を求める int distance(int x, int y) { int diff = x – y; if (diff <= 1) { intdist = 0; dist = y – x; return dist; } intdist = 0; dist = x – y; return dist; } 欠陥に関連する文・条件に高い優先度 2. 失敗フローバイアス 対象: 欠陥の発現後に実行される文 1. 制御フロー依存バイアス 対象: 欠陥を含む文と依存関係を持つ文 (e.g., 5行目でdiff > 0 なら 7行目でdist < 0) 5行目に欠陥を含むプログラム

  15. 制御フロー依存バイアスの検出 ステートメントレベルでの既存手法* 制御フローを解析して直前の分岐文を判別 　　　 → 制御フロー依存する文 int diff = x – y; If (diff <= 1) !(diff <= 1) 貢献： 条件式レベルに拡張 diff <= 1 制御フロー依存 直前の分岐文の条件式と，その否定を考える e.g., (diff <= 1), (!(diff <= 1)) 注目する式に到達するために 成立すべきものが，制御フロー依存する条件式 intdist = 0; dist= y – x; return dist; *本論文参考文献[10, 11]

  16. 失敗フローバイアスへの対応 既存手法(本論文参考文献[1, 2]) ヒューリスティックに基づく式で，バイアスの影響を軽減 貢献： バックドア基準を満たすような回帰モデル 失敗フローバイアスの考慮 TestResult = αp + τpTp + βpCp + ωpDp+ εp 制御フロー依存バイアスの考慮 TestResult: テスト失敗なら1, 成功なら0, αp, τp, βp, ωp: 係数, εp:誤差 Tp: テスト時に条件式pが真なら1，それ以外は0 Cp: pの制御フロー依存条件式が真なら1, それ以外は0 Dp: 条件式pが評価された時1, それ以外は0

  17. 実験：欠陥に関連する条件文発見効率 最小二乗法で求めたτpを利用して，既存のメトリクスを書き換え 2種類のpredicate-level statistical debugger(赤，白)それぞれ利用時の 「欠陥に関連する条件文へのランク付け」の相対的性能向上 180プログラム中 性能向上: 68 横ばい: 112 性能低下: 0 180プログラム中 性能向上: 94 横ばい: 84 性能低下: 2 制御フロー依存バイアスのみ考慮 vs. 失敗フローバイアスも考慮 従来法 vs. 制御フロー依存バイアスのみ考慮

  18. BugRedux: Reproducing Field Failures for In-House Debugging Wei Jin and Alessandro Orso 国立情報学研究所　本位田研星 敬一郎 　　　　　　東京大学　本位田研　西浦 一貴

  19. 目的と問題 目的：出荷後に報告された欠陥を，社内で再現すること 問い1: どうすれば報告された欠陥を再現できるか？ 問い2: クラッシュレポートはどんな実行時情報を含むべきか？ 多くの情報 (e.g., 実行トレースすべて) - 実行時オーバーヘッド大 - プライベートな情報を含んでしまう恐れ トレードオフ 少ない情報 (e.g., 発生した例外の種類のみ) - 報告された欠陥が再現できない

  20. 提案ツールと貢献 ログ関数 埋め込み • 実行時情報を収集し，それを利用して 欠陥を再現するツールBugReduxの開発 • 収集する情報を変化させて，費用対効果を調査 提案ツール動作図 発表論文より引用 (日本語は発表者) 欠陥を再現する テストケース生成

  21. 報告された欠陥の再現 クラッシュレポート中の文をゴールの列とし， ゴールを同じ順番で通過する 欠陥の再現 := 1. プログラムを記号的に実行． 次に通過したい文に近づくように探索 2. 得られた条件を満たす入力を，制約ソルバで求める

  22. クラッシュレポートに含める情報 欠陥を再現するためには どんな情報を記録すべきか？ 以下の４種類を考慮し，実験的に評価 • 例外発生時の位置(POF) • 例外発生時のコールスタック(Call Stack) • 例外発生までの関数呼び出し履歴(Call Sequence) • 完全な実行トレース(Complete Trace)

  23. 実験結果1: オーバーヘッド • POFとCall Stackはクラッシュレポートに入っているのが一般的， • オーバーヘッドはほぼ無視できる程度 • Call Sequenceは時間・空間ともにオーバーヘッドがあるが， • 完全なトレースよりは桁違いに小さいオーバーヘッド 対象とした プログラム達 空間オーバーヘッド(kB) 時間オーバーヘッド(%)

  24. 実験結果2: 欠陥再現性能 • POF, Call Stack, Call Sequenceまでは，情報が増えるほど， • 　　欠陥再現の性能が高くなっている • 完全な実行トレースを再現しようとすると， • 　　制約が複雑になりすぎるためか，テストケース生成に失敗した 対象とした プログラム達 欠陥がただしく再現できたかどうか(Yes or No) テストケース生成にかかった時間

  25. ICSE2012勉強会“Object-Centric Debugging” Jorge Ressia (Univ. of Bern) AlexandreBergel (Univ. of Chile) Oscar Nierstrasz (Univ. of Bern) 早稲田大学 深澤研究室 清水遼 （kiyo07@fuka.info.waseda.ac.jp)

  26. 概要

  27. 背景 • デバッグ・ソフトウェア理解へのデバッガの利用 プログラマが持つ問い† プログラマが用いるツール このメソッドはいつ呼び出される？ このクラスのインスタンスは いつ生成される？ この変数／ データ構造は いつアクセス される？ ブレークポイント・条件付きブレークポイントを用いたスタックベースのデバッガ この引数の実行時の値は？ 本当に問いに答えることに適しているのか？ ブレークポイントを逐一決定する手間が大きいのでは？ †J. Sillito et al. “Questions programmers ask during software evolution tasks”, FSE 2006.

  28. 提案手法 • Object-centric Debugging • “オブジェクト毎”の状態に着目したデバッグの提案 • オブジェクトへの着目に適した操作を定義 これまでのデバッグ Object-centric ブレークポイントを設定し， 実行中のプログラムに割り込み ＆相互作用を実現 指定したオブジェクトがアクセス／変更された際に実行に割り込み State-related Operations Interaction Operations Halt on write: 特定のオブジェクトに変更が加えられた際に停止 Halt on read: 特定のオブジェクトが利用された際に停止 Halt on call: 特定のオブジェクトのメソッドが他のオブジェクトから呼ばれた際に停止 Halt on invoke:特定のオブジェクトがメソッドを呼び出した際に停止 Halt on object in invoke: 特定のオブジェクトがメソッド呼び出しの引数として使われた際に停止 etc…

  29. ケーススタディ • Pharo†の実装に対してデバッグを実施 • InstructionStreamクラスの変数pcの調査 ‡ 最初のアクセスまで18，次のアクセスまで30のステップイン操作を要した InstructionStreamクラスのインスタンスにhalt on callとhalt on writeの操作を指定するだけ • Object-Centric Debugginにより… • 簡潔な操作の指定 • 関連する実行部分のみの確認 • を実現 より効率よく開発者の要求に答えるデバッガの実現 †http://www.pharo-project.org/home ‡J. Ressia et al. “Object-Centric Debugging”, ICSE 2012.

More Related