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

Copyright © 2012 日本電信電話株式会社

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

Sai Zhang1, Cheng Zhang2, Michael D. Ernst1

1 University of Washington2 Shanghai Jiao Tong University

担当 : NTT サイバースペース研究所張暁晶


モチベーション

テストで失敗が出るとバグの可能性があるのだが、バグ改修の前に、失敗原因の究明が必要

なぜテストが失敗したか？コードのどのへんを先に解析すべきか？は自明ではない！

自動生成でも手書きでも、テストコードに対するドキュメンテーションは少ないので、テストコードやソースコートのどのへんが失敗に関連するのかは、推測に頼るしかない

失敗テストのためのドキュメンテーションを自動生成しよう！ 2

【例 1 】手書きのテストコード（ SUT はJDK ）Array.toArray メソッドが type-safe ではないエラー type-safe と関係ない Exception が出るだけなので判らない

【例 2 】自動生成されたテストコード（ SUT はJDK v1.6 ）自分自身に equal とならないオブジェクトを生成できてしまうエラースタックトレースも出ないしどこが悪いのか手がかりがない

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 より引用


貢献

提案手法

ツール： FailureDoc （ OSS として公開中： http://code.google.com/p/failuredoc）

評価（後述）4

必要なクラスのインスタンスをランダム生成し、ためておくテストコードの一部を生成した代替品に入れ替えてミュータントを作成

テストコードのミュータントを実行し、実行トレースを記録する※静的スライシングを用いて、実行トレースから、 assertion に無関係なステートメントを取り除く

既存の統計的アルゴリズム（※）を拡張して、①失敗と相関の高い「疑わしい」ステートメントを特定し、②失敗を修正するオブジェクトも特定する

「疑わしい」ステートメントのそれぞれに対し、失敗を修正するオブジェクトのプロパティを汎用化し、そこから文章を生成する

個々のミュータントの実行トレース：

i 行目のステートメント si とその行の出力オブジェクト vi

1

2

3

4

「失敗を修正するオブジェクト」を 1 つでも見つけられれば、その行は「疑わしいステートメント」である

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 より引用

※B Liblit, M Naik, A X. Zheng, A Aiken, and M I. Jordan. “Scalable statistical bug isolation”. In PLDI ’05, 2005.

http://code.google.com/p/failuredoc




評価 Q1.実案件の規模に対応できるか？妥当なドキュメンテーションを生成できるか？

5件の実プロジェクト（OSS）で評価– 12件の失敗テストのうち、10件に対しコメントを生成できた

オブジェクト値の置換により修正できないエラーには対応できない– 1件の失敗テストに対するコメント生成時間は約3分

ミュータントの生成と実行に時間がかかる– 評価用OSSの開発者にコンタクトし、フィードバックを得る：

「デバッガであれこれ調べなきゃいけないところを、どの変数に着目すべきかすぐ教えてくれるから有用」との声

Q2.生成されたドキュメンテーションは、テスト失敗原因の理解を助けるか？大学院生16人で被験者実験– ドキュメンテーションなし、と、FailureDocを使った場合、の比較

– 既存手法Delta Debuggingを使った場合、と、FailureDocを使った場合、の比較

　– 　

5

理解する為の時間を 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 より引用


Generating Program Inputs for Database Application Testing

Kai Pan, Xintao Wu （ノースカロライナ大学）Tao Xie （ノースカロライナ州立大学）

担当 : NTT サイバースペース研究所丹野治門

実運用 DB データを用いたテストデータ生成手法


void f(…) … if ( … ){ … } else{　 … }…}

目的と提案手法目的

– DB参照プログラムのパスカバレッジ向上を目指したテストデータ生成

うれしさ：実運用 DB データの特徴がある！

既存手法 (Emmi et al. ISSTA2007)ゼロから入力値， DB初期状態のペアを生成

入力値： name=“a”,age=0DB初期状態：

入力値： name=“b”,age=1DB初期状態：

提案手法（ Pex(Microsoft) の拡張）実運用 DB データとコードの動的，静的解析を用いて妥当な入力値を生成

問題点：実運用 DB データの特徴がない！

入力値： name=“Yamada”,age=20

入力値：name=“Tanaka”,age=40

実運用 DB データID Name Zipcode Age Preium

0 “a” 0 1 01 “a” 0 1 02 “a” 0 1 0

ID Name Zipcode Age Preium0 “a” 0 1 01 “a” 0 1 02 “a” 0 1 0




ID Name

Zipcode

Age

Preium

0 “b” 0 1 01 “b” 0 1 02 “b” 0 1 0



ID Name Zipcode

Age Preium

22 “Tanaka”

27695 40 0

34 “Sato” 25622 30 0… … … … …

222“Suzuki”

25846 45 1

void f(…) … if ( … ){ … } else{　 … }…}


bool ExistsCustomerByZipcode(int zip, bool isPremium) { 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;}

実運用 DB データを用いて入力値を生成手順（１）：入力変数に (Pex の ) デフォルト値を入れて実

行プログラムコード (C#)

zip=0 では 1 件もヒットしないのでここに到達しない

！

ID Name Zipcode

Age Preium

22 “Tanaka”

27695 40 0

34 “Sato” 25622 30 0

customer実運用 DB データ

実行zip = 27695 or

25622 として，検索でヒットするようにし

たい

zip = 0isPremium =

false

Kai Pan, Xintao Wu and Tao Xie 　“ Generating Program Inputs for Database Application Testing” 27th IEEE/ACM International Conference. 　 Automated Software Engineering (ASE 2011), 2011. 　　Figure 1 より引用（一部修正有り）



実運用 DB データを用いて入力値を生成手順（２）：実行時に補助クエリを作成しておく

プログラムコード (C#)

zip=0 では 1 件もヒットしないのでここに到達しない

！

ID Name Zipcode

Age Preium

22 “Tanaka”

27695 40 0

34 “Sato” 25622 30 0


実行

zip = 0isPremium =

false

補助クエリQa=SELECT ZipCode FROM customer WHERE Premium =１※ 動的解析，静的解析を併用




実運用 DB データを用いて入力値を生成手順（３）：補助クエリを利用して新しい入力値を設定，実行

プログラムコード (C#)

到達！パスカバレッジ向上！

ID Name Zipcode

Age Preium

22 “Tanaka”

27695 40 0

34 “Sato” 25622 30 0


実行

zip = 27695

isPremium = false

補助クエリQa=SELECT ZipCode FROM customer WHERE Premium =１※ 動的解析，静的解析を併用

Zipcode

27695

25622



評価評価用アプリ： RiskIt(120万レコード使用 )，比較対象ツール：

Pex

Pex に対してパスカバレッジは 25%向上

計算時間は Pex の約1/3

実運用 DB の特徴を持つ

DB参照アプリに対し短時間で高パスカバレッジのテストデータを生成

Kai Pan, Xintao Wu and Tao Xie 　“ Generating Program Inputs for Database Application Testing” 27th IEEE/ACM International Conference. 　 Automated Software Engineering (ASE 2011), 2011. 　　TableⅢ より引用


Prioritizing Tests for Fault Localization through Ambiguity Group ReductionAlberto Gonzalez-Sanchez1, Rui Abreu2,Hans-Gerhard Gross1 and Arjan J.C. van Gemund1

1 Delft University of Technology2 University of Porto

担当 : NTT サイバースペース研究所風戸広史


目的と貢献

目的– 回帰テストの失敗 (failure) から，原因となるバグ

(fault) がどこにあるのかを特定したい– 少ないテストケースで効率よく

貢献– Fault Localization のためのテスト優先順位付けア

ルゴリズム “ RAPTOR” を提案– 性能評価により，インスペクションのコストを既存手

法から 10%強〜 40%弱削減できることを示した• Siemens ベンチマークセット [22]• Software Infrastructure Repository [12]

13

Copyright © 2012 日本電信電話株式会社 14

例題 : テストの優先順位付けT

C Program: Character Counter t1 t2 t3 t4 t5 t6 t7 t8function count(char * s) { int let, dig, other, i;

c1 while(c = s[i++]) { 1 1 1 1 1 1 1 1

c2 if (’A’<=c && ’Z’>=c) { 1 1 1 1 1 1 0 1

c3 let += 2; // FAULT 1 1 1 1 1 1 0 0

c4 elsif (’a’<=c && ’z’>=c) 1 1 1 1 1 0 0 1

c5 let += 1; 1 1 0 0 1 0 0 0

c6 elsif (’0’<=c && ’9’>=c) 1 1 1 1 0 0 0 1

c7 dig += 1; 0 1 0 1 0 0 0 0

c8 elsif (isprint(c)) 1 0 1 0 0 0 0 1

c9 other += 1; 1 0 1 0 0 0 0 1

c10 printf("%d %d %d\n”, let, dig, other);}

1 1 1 1 1 1 1 1

Test case outcomes F F F F F F P PGonzalez-Sanchez et al. “Prioritizing Tests for Fault Localization through Ambiguity Group Reduction”, Proc. ASE 2011 (pp. 83-92). Table I より引用


RAPTOR アルゴリズムの概要

曖昧さ (Ambiguity)– 行ベクトルが同じ文はどれがバグの原因か区別で

きないのでグループ化する– 曖昧さを数値化

アルゴリズム– 空のテストケース集合から開始– 未選択のテストケースのうち，曖昧さの削減に最

も貢献するテストケースを追加

M: プログラム全体の文の数gi: Ambiguity グループ(1 ≦ i ≦ L)


効率性の評価

既存のテスト優先順位付け手法に対し顕著な削減効果を確認

Gonzalez-Sanchez et al. “Prioritizing Tests for Fault Localization through Ambiguity Group Reduction”, Proc. ASE 2011 (pp. 83-92). Table IV より引用

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

Documents

Transcript of テスト失敗原因を推測するための文章生成 Automated Documentation Inference to...