1 / 16

テスト失敗原因を推測するための文章生成 Automated Documentation Inference to Explain Failed Tests

テスト失敗原因を推測するための文章生成 Automated Documentation Inference to Explain Failed Tests. Sai Zhang 1 , Cheng Zhang 2 , Michael D. Ernst 1 1 University of Washington 2 Shanghai Jiao Tong University 担当 : NTT サイバースペース研究所 張暁晶. モチベーション. テストで失敗が出るとバグの可能性があるのだが、バグ改修の前に、 失敗原因の究明が必要

marsden-lopez
Télécharger la présentation

テスト失敗原因を推測するための文章生成 Automated Documentation Inference to Explain Failed Tests

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. テスト失敗原因を推測するための文章生成Automated Documentation Inference to Explain Failed Tests Sai Zhang1, Cheng Zhang2, Michael D. Ernst1 1 University of Washington 2 Shanghai Jiao Tong University 担当:NTTサイバースペース研究所 張暁晶

  2. モチベーション • テストで失敗が出るとバグの可能性があるのだが、バグ改修の前に、失敗原因の究明が必要 • なぜテストが失敗したか？コードのどのへんを先に解析すべきか？は自明ではない！ • 自動生成でも手書きでも、テストコードに対するドキュメンテーションは少ないので、テストコードやソースコートのどのへんが失敗に関連するのかは、推測に頼るしかない • 失敗テストのためのドキュメンテーションを自動生成しよう！ 【例2】自動生成されたテストコード（SUTはJDK v1.6）自分自身にequalとならないオブジェクトを生成できてしまうエラースタックトレースも出ないしどこが悪いのか手がかりがない 【例1】手書きのテストコード（SUTはJDK）Array.toArrayメソッドがtype-safeではないエラーtype-safeと関係ないExceptionが出るだけなので判らない Sai Zhang, Cheng Zhang, Michael D. Ernst“Automated Documentation Inference to Explain Failed Tests” 27th IEEE/ACM International Conference.Automated Software Engineering (ASE 2011), 2011.Fig.1, Fig.2 より引用

  3. 目的 • 失敗テストのためのドキュメンテーションを自動生成 • テストコードをどう変更したら「テスト成功」となるかを提示なぜ「テスト失敗」となったかの理解を助ける • 出力例（下線コメントの形で挿入） 【例1】Array.toArrayメソッドがtype-safeではないエラーｌの型をLong型ではなくInteger型に変えれば、もしくは、lをnumsに追加しなければ、テスト成功となる型が合わないｌをリストに加え、後にIntegerにキャストしていた 【例2】自分自身にequalとならないオブジェクトを生成できてしまうエラーオブジェクトoがComparableを実装していれば、テスト成功となるoが使われた箇所が怪しいTreeSetのコンストラクタでComparableでないオブジェクトも受容していた Sai Zhang, Cheng Zhang, Michael D. Ernst“Automated Documentation Inference to Explain Failed Tests” 27th IEEE/ACM International Conference.Automated Software Engineering (ASE 2011), 2011.Fig.3, Fig.4 より引用

  4. 貢献 既存の統計的アルゴリズム（※）を拡張して、①失敗と相関の高い「疑わしい」ステートメントを特定し、②失敗を修正するオブジェクトも特定する 3 • 提案手法 • ツール：FailureDoc（OSSとして公開中：http://code.google.com/p/failuredoc） • 評価（後述） 「失敗を修正するオブジェクト」を1つでも見つけられれば、その行は「疑わしいステートメント」である 必要なクラスのインスタンスをランダム生成し、ためておくテストコードの一部を生成した代替品に入れ替えてミュータントを作成 1 ※B Liblit, M Naik, A X. Zheng, A Aiken, and M I. Jordan. “Scalable statistical bug isolation”. In PLDI ’05, 2005. テストコードのミュータントを実行し、実行トレースを記録する※静的スライシングを用いて、実行トレースから、assertionに無関係なステートメントを取り除く 個々のミュータントの実行トレース： i行目のステートメントsiとその行の出力オブジェクトvi 「疑わしい」ステートメントのそれぞれに対し、失敗を修正するオブジェクトのプロパティを汎用化し、そこから文章を生成する 2 4 Sai Zhang, Cheng Zhang, Michael D. Ernst“Automated Documentation Inference to Explain Failed Tests” 27th IEEE/ACM International Conference.Automated Software Engineering (ASE 2011), 2011.Fig.5 より引用

  5. 評価 • Q1.実案件の規模に対応できるか？妥当なドキュメンテーションを生成できるか？5件の実プロジェクト（OSS）で評価 • 12件の失敗テストのうち、10件に対しコメントを生成できたオブジェクト値の置換により修正できないエラーには対応できない • 1件の失敗テストに対するコメント生成時間は約3分ミュータントの生成と実行に時間がかかる • 評価用OSSの開発者にコンタクトし、フィードバックを得る：「デバッガであれこれ調べなきゃいけないところを、どの変数に着目すべきかすぐ教えてくれるから有用」との声 • Q2.生成されたドキュメンテーションは、テスト失敗原因の理解を助けるか？大学院生16人で被験者実験 • ドキュメンテーションなし、と、FailureDocを使った場合、の比較 • 既存手法Delta Debuggingを使った場合、と、FailureDocを使った場合、の比較 理解する為の時間を14％削減 理解・改修の成功率が向上 Sai Zhang, Cheng Zhang, Michael D. Ernst“Automated Documentation Inference to Explain Failed Tests” 27th IEEE/ACM International Conference.Automated Software Engineering (ASE 2011), 2011.Fig.9 より引用

  6. Generating Program Inputs for Database Application Testing 実運用DBデータを用いたテストデータ生成手法 Kai Pan, Xintao Wu （ノースカロライナ大学） Tao Xie （ノースカロライナ州立大学） 担当:NTTサイバースペース研究所 丹野 治門

  7. 目的と提案手法 提案手法（Pex(Microsoft)の拡張）実運用DBデータとコードの動的，静的解析を用いて妥当な入力値を生成 既存手法(Emmiet al. ISSTA2007)ゼロから入力値，DB初期状態のペアを生成 入力値：name=“a”,age=0DB初期状態： 入力値：name=“Yamada”,age=20 void f(…)… if ( … ){… } else{… }…} void f(…)… if ( … ){… } else{… }…} 実運用DBデータ 入力値：name=“b”,age=1DB初期状態： 入力値：name=“Tanaka”,age=40 うれしさ：実運用DBデータの特徴がある！ 問題点：実運用DBデータの特徴がない！ • 目的 • DB参照プログラムのパスカバレッジ向上を目指したテストデータ生成

  8. 実運用DBデータを用いて入力値を生成 zip = 0 isPremium = false プログラムコード (C#) 実運用DBデータ customer boolExistsCustomerByZipcode(intzip, boolisPremium) {int premium=0; if(isPremium)premium = １; String q=“SELECT ID FROM customer ” + “WHERE Zipcode = ” + zip + “AND” + “Premium = ” premium; …SqlReader results = cmd.ExecuteReader(…); count=results.Count; if(count == 0) return false; else return true;} zip = 27695 or 25622として，検索でヒットするようにしたい 実行 zip=0では1件もヒットしないのでここに到達しない！ Kai Pan, XintaoWu and Tao Xie“Generating Program Inputs for Database Application Testing”27th IEEE/ACM International Conference.Automated Software Engineering (ASE 2011), 2011.Figure 1 より引用（一部修正有り） 手順（１）：入力変数に(Pexの)デフォルト値を入れて実行

  9. 実運用DBデータを用いて入力値を生成 zip = 0 isPremium = false プログラムコード (C#) 実運用DBデータ customer boolExistsCustomerByZipcode(intzip, boolisPremium) {int premium=0; if(isPremium)premium = １; String q=“SELECT ID FROM customer ” + “WHERE Zipcode = ” + zip + “AND” + “Premium = ” premium; …SqlReader results = cmd.ExecuteReader(…); count=results.Count; if(count == 0) return false; else return true;} 実行 補助クエリQa=SELECTZipCodeFROM customerWHERE Premium =１ zip=0では1件もヒットしないのでここに到達しない！ ※動的解析，静的解析を併用 Kai Pan, XintaoWu and Tao Xie“Generating Program Inputs for Database Application Testing”27th IEEE/ACM International Conference.Automated Software Engineering (ASE 2011), 2011.Figure 1 より引用（一部修正有り） 手順（２）：実行時に補助クエリを作成しておく

  10. 実運用DBデータを用いて入力値を生成 zip = 27695 isPremium = false プログラムコード (C#) 実運用DBデータ customer boolExistsCustomerByZipcode(intzip, boolisPremium) {int premium=0; if(isPremium)premium = １; String q=“SELECT ID FROM customer ” + “WHERE Zipcode = ” + zip + “AND” + “Premium = ” premium; …SqlReader results = cmd.ExecuteReader(…); count=results.Count; if(count == 0) return false; else return true;} 実行 補助クエリQa=SELECTZipCodeFROM customerWHERE Premium =１ 到達！パスカバレッジ向上！ ※動的解析，静的解析を併用 Kai Pan, XintaoWu and Tao Xie“Generating Program Inputs for Database Application Testing”27th IEEE/ACM International Conference.Automated Software Engineering (ASE 2011), 2011.Figure 1 より引用（一部修正有り） 手順（３）：補助クエリを利用して新しい入力値を設定，実行

  11. 評価 Pexに対してパスカバレッジは25%向上 計算時間はPexの約1/3 DB参照アプリに対し短時間で高パスカバレッジのテストデータを生成 実運用DBの特徴を持つ Kai Pan, XintaoWu and Tao Xie“Generating Program Inputs for Database Application Testing”27th IEEE/ACM International Conference.Automated Software Engineering (ASE 2011), 2011.TableⅢより引用 評価用アプリ：RiskIt(120万レコード使用)，比較対象ツール：Pex

  12. Prioritizing Tests for Fault Localization through Ambiguity Group Reduction Alberto Gonzalez-Sanchez1, Rui Abreu2, Hans-Gerhard Gross1 and Arjan J.C. van Gemund1 1 Delft University of Technology 2 University of Porto 担当:NTTサイバースペース研究所 風戸広史

  13. 目的と貢献 • 目的 • 回帰テストの失敗 (failure) から，原因となるバグ (fault) がどこにあるのかを特定したい • 少ないテストケースで効率よく • 貢献 • Fault Localization のためのテスト優先順位付けアルゴリズム “RAPTOR” を提案 • 性能評価により，インスペクションのコストを既存手法から 10%強〜40%弱削減できることを示した • Siemens ベンチマークセット [22] • Software Infrastructure Repository [12]

  14. 例題: テストの優先順位付け Gonzalez-Sanchez et al. “Prioritizing Tests for Fault Localization through Ambiguity Group Reduction”, Proc. ASE 2011 (pp. 83-92). Table I より引用

  15. RAPTOR アルゴリズムの概要 • 曖昧さ (Ambiguity) • 行ベクトルが同じ文はどれがバグの原因か区別できないのでグループ化する • 曖昧さを数値化 • アルゴリズム • 空のテストケース集合から開始 • 未選択のテストケースのうち，曖昧さの削減に最も貢献するテストケースを追加 M: プログラム全体の文の数 gi: Ambiguity グループ(1 ≦ i≦L)

  16. 効率性の評価 • 既存のテスト優先順位付け手法に対し顕著な削減効果を確認 Gonzalez-Sanchez et al. “Prioritizing Tests for Fault Localization through Ambiguity Group Reduction”, Proc. ASE 2011 (pp. 83-92). Table IV より引用

More Related