Upload
nkazuki
View
336
Download
4
Embed Size (px)
DESCRIPTION
研究室輪講用資料です. 発表論文は「Puzzle-Based Automatic Testing: Bringing Humans into the Loop by Solving Puzzles」で,ASE2012に採択されています.
Citation preview
1
対象:コンピュータ科学専攻の修士・博士学生
(ソフトウェア工学専攻とは限らない)
発表時間:25分
2012/11/1
Puzzle-Based Automatic Testing: Bringing Humans into the Loop by Solving Puzzles (ASE 2012) 輪講用資料
Puzzle-Based Automatic Testing: Bringing Humans into the Loop by Solving Puzzles
Ning Chen and Sunghun Kim(香港科技大学)
Automated Software Testing (ASE) 2012
Acceptance rate: 15.2% (21/138)
2
発表論文
テストケースの自動生成をしたい!
最先端の手法でもカバレッジに限界
→機械的に解くのが難しい問題(後述)
Puzzle-based Automated Testing (PAT):
「自動で解けない問題をパズルとして人間に提示,
その結果を利用してテストケースを生成」
カバレッジの向上
手動でテストを書くより効率大 3
概要
目的
実験結果
問題
提案手法
テストケース自動生成の研究が盛ん[1][2]
→ しかし,複雑なオブジェクト指向の
プログラムに対してカバレッジが不十分
4
問題:既存手法はカバレッジ低
対象 カバレッジ
Commons Math 61.6% Commons Collections 53.0%
対象 カバレッジ
SvnBridge 56.2% xUnit 15.5% Math.Net 62.8% QuickGraph 53.2%
[1]を用いた実験(著者たちによる) [2]を用いた実験 [3]
[1] C.Pacheso et al. Feedback-directed random test generation. ICSE 2007 [2] N. Tillmann and J. de Halleux. Pex-white box test generation for .NET. TAP 2008 [3] X.Xiao et al. Precise identification of problems for structural test generation. ICSE 2011
制約解決の困難さ
オブジェクト変更の困難さ
5
自動テスト生成を困難にする原因2つ
ある分岐先を通るために変数が満たすべき条件を,
うまく解くことが出来ない
6
原因1: 制約解決の困難さ
void method(int x, int y, int n) {
int value = x << n;
if (value < y && n > 2) {
// この分岐先をテストしたい
}
}
void method(int x, int y, int n) {
int value = x << n;
if (value < y && n > 2) {
// この分岐先をテストしたい
}
}
ある分岐先を通るために変数が満たすべき条件を,
うまく解くことが出来ない
7
原因1: 制約解決の困難さ
(x << n) < y かつ n > 2 を満たす具体的なx, y, n ?
長さ可変のシフト演算は苦手…
ある分岐先を通るために満たされているべき
オブジェクトの状態を設定できない
8
原因2: オブジェクト生成・変更の困難さ
void method2(Container container) {
if (container.getSize() >= 10) {
// この分岐先をテストしたい
}
}
void method2(Container container) {
if (container.getSize() >= 10) {
// この分岐先をテストしたい
}
}
containerの内部変数size==10にすれば良い
ある分岐先を通るために満たされているべき
オブジェクトの状態を設定できない
9
原因2: オブジェクト生成・変更の困難さ
Container.setSize()メソッドは無い… どうやってcontainer.getSize()==10 にすればいいんだ…?
制約解決の困難さ (x << n) < y かつ n > 2 を満たす具体的なx, y, n ?
オブジェクト変更の困難さ container.size() == 10となるcontainerの生成?
10
自動テスト生成を困難にする原因2つ
人間にとってはそんなに困難じゃない問題もありそう
提案手法
「Puzzle-based Automated Testing」
機械的に解決できない問題の一部を
小さなパズルとして人間に解いてもらおう!
11
提案手法: Puzzle-based Automated Testing
プログラム
テストケース
テストケース生成
カバレッジ情報
制約を
満たす値
値
既存手法で テストケース 生成・実行
・実行時インスタンス
・メソッド呼出履歴
(1)
未到達分岐へ至る パス・値の計算
制約解決 パズル 生成
オブジェクト 変更パズル 生成
(2)
(3) (4)
SMTソルバエラー
Randoop[1]という既存のツールを利用して
テストケースの生成・実行
既存ツールでカバー出来るパスをカバー
後に利用するため実行時情報を記録
生成されたインスタンス
メソッド呼び出し履歴
12
1. 既存手法でテストケース生成
[1] C.Pacheso et al. Feedback-directed random test generation. ICSE 2007
カバーしたい分岐から逆向きに
満たすべき制約条件を収集 (記号的実行[4])
13
2. 未到達分岐へ至るパス・値を計算
private pri(int n) {
if (n * 3 < 20) { // カバーしたい場所
}
}
public pub(int x) {
if (x > 0) {
pri(x + 5)
……
x > 0
n == x + 5
n * 3 < 20
解けない 解ける
SMTソルバ[5]で
制約を満たす
値を求める
③制約解決パズル
④オブジェクト変更パズル
x = 1
[4] L. A. Clarke. A system to generate test data and symbolically execute programs. TSE, 1976
[5] B. Dutertre and L. de Moura. System description: Yices 1.0. In Proc. SMT-COMP, 2006.
pub(x)
SMTソルバで解決できなかった制約のうち,
ソルバが出したエラーに関係するものを抽出
14
3. 制約解決パズルの生成(1/2)
this != null
sums != null
sums.length * sums.length <= 4096
sums.length > 0
this.n > 1
エラー: 非線形不等式はサポートされていません
sums.length * sums.length <= 4096
sums.length > 0
変数名以外に違いのない制約はまとめる
15
3. 制約解決パズルの生成(1/2)
sums.length * sums.length <= 4096
sums.length > 0
num * num <= 4096
num > 0
obj.mem * obj.mem <= 4096
obj.mem > 0
A * A <= 4096
A > 0
3回出現
16
3. 制約解決パズルの解決
何度も出現する制約から順に人間に解いてもらう
パズル…?
17
4. オブジェクト変更パズル(1/2)
input != null
input.readInt() == 1
this.currentState == null
依存するオブジェクトによって
条件集合をさらに分割する
input != null
input.readInt() == 1 this.currentState == null
どうやって この条件を満たす inputとthisを
作ればいいんだ?
18
4. オブジェクト変更パズル(2/2)
何度も出てくる条件集合を優先的に人間に解いてもらう
19
4. オブジェクト変更パズル(2/2)
メソッドに適当な引数を渡して実行
ステップ1で収集した インスタンスを
メソッド引数として利用
オブジェクトの 状態を変化させて 目標に近づける
何度も出てくる条件集合を優先的に人間に解いてもらう
20
テストケース生成
(2)から 「網羅したい分岐を通るにはどのパスを通るべきか」 (2)(3)から 「thisオブジェクト・引数の満たすべき値」 (4)から 「オブジェクトを望む状態にするためのメソッドの列」
以上を繋げることで 網羅したい分岐を通る テストケース (Javaの命令列) が得られる
1. 人間が解くことの出来るパズルは何割程度か
2. どれだけの人が進んでパズルを解いてくれるか (今回は説明を省略)
3. 提案法によってカバレッジはどれだけ向上するか
4. 手動でテストを書く労力はどれだけ削減できるか
21
実験による評価
研究課題
22
実験設定
名前 # of lines # of branches
Apache Commons Math (ACM) 20,605 7707
Apache Commons Collections (ACC) 14,261 5242
対象 Randoop +記号的実行&SMTソルバ
ACM 61.6% 64.4%
ACC 53.0% 56.8%
比較対象
提案法のステップ1, 2が既存手法に対応
(1)Randoop + (2)記号的実行&SMTソルバ
対象アプリケーション
23
研究課題1: 人間が解けるパズルはどの程度あるか?
被験者 コンピュータ科学専攻の大学院生8人
対象 Apache Commons Mathに対して
生成されたパズルの上位100件づつ
総数 解けたパズルの数(重複除く) 平均所要時間
オブジェクト変更 100 51 1分 制約充足 100 72 1分
結果
51%, 72%のパズルを平均1分で解けた
→実際にパズルを解いてもらう実験を行った
24
研究課題3: カバレッジはどれだけ向上するか?
最先端の手法で得られたカバレッジより,
それぞれさらに5.8%, 7% 向上した.
61.6 53
2.8
3.7
7
5.8
40
45
50
55
60
65
70
75
Commons Math Commons Collection
分岐カバレッジ
(%)
+提案法
+記号的実行
Randoop
25
研究課題4: テストを書く労力は削減できるか?
対象: Java歴6年のある大学院生
方法: 未網羅の分岐をランダムに10個選択,
その分岐を網羅するテストを書いてもらう
所要時間(平均): ACMでは9分 ACCでは8分
提案法
1パズル平均1分で解けてた
ドメイン知識ない人でも解けてた
1パズル解けばいくつかの分岐を網羅できる場合も
手動テストに関する実験
提案法は,手動でテストを書くよりも
効率的にカバレッジを増やせる
Test-based Automated Testingという枠組みを提案
機械的に解けない問題の一部をパズルとして人間に出題
26
結論
提案法の良さ
制約解決パズル
オブジェクト変更パズル
最先端ツールよりカバレッジが数%上昇
手動でテストを書くよりも効率大
ドメイン知識無くても実施可能
機械的に解けないので人の力を借りようというアイディアが面白い
結果の見せ方がうまい
さりげなくグラフの目盛りが40%から
最先端手法といいつつ,半分は「最先端手法でも使われてる古典テクニックの自分実装」
著者たちによる発表スライドが公開されている.見やすい
http://www.slideshare.net/hunkim/puzzlebased-automatic-testing-bringing-humans-into-the-loop-by-solving-puzzles-ase-2012
27
私見
28
研究課題2: 任意の参加者はどの程度いるか?
実験 Commons Collectionsに関するパズルを
Web上に公開,Twitterで参加者を募った
総数 解けたパズルの数(重複除く) 平均所要時間
オブジェクト変更 100 24 1分 制約充足 100 84 1分
結果
ゲーム感覚(?)で参加してくる人は居る
彼ら(ドメイン知識無い?)は,CS専攻の学生と比べても同等程度のパズル正解力
120人の参加者