研究室輪講用資料です． 発表論文は「Puzzle-Based Automatic Testing: Bringing Humans into the Loop by Solving Puzzles」で，ASE2012に採択されています．

1. Puzzle-Based Automatic Testing:
Bringing Humans into the Loop
by Solving Puzzles (ASE 2012)
輪講用資料
対象：コンピュータ科学専攻の修士・博士学生
1 （ソフトウェア工学専攻とは限らない）
発表時間：25分
2012/11/1

2. 発表論文
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

3. 概要
目的 テストケースの自動生成をしたい！
問題 最先端の手法でもカバレッジに限界
→機械的に解くのが難しい問題(後述)
提案 Puzzle-based Automated Testing (PAT):
手法 「自動で解けない問題をパズルとして人間に提示，
その結果を利用してテストケースを生成」
実験  カバレッジの向上
結果  手動でテストを書くより効率大
3

4. 問題：既存手法はカバレッジ低
テストケース自動生成の研究が盛ん[1][2]
→ しかし，複雑なオブジェクト指向の
プログラムに対してカバレッジが不十分
対象 カバレッジ
SvnBridge
56.2%
対象 カバレッジ xUnit
15.5%
Commons Math
61.6% Math.Net
62.8%
Commons Collections
53.0% QuickGraph
53.2%
[1]を用いた実験(著者たちによる) [2]を用いた実験 [3]
4
[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つ
 制約解決の困難さ
 オブジェクト変更の困難さ
5

6. 原因1: 制約解決の困難さ
ある分岐先を通るために変数が満たすべき条件を，
うまく解くことが出来ない
void method(int x, int y, int n) {
int value = x << n;
if (value < y && n > 2) {
// この分岐先をテストしたい
}
}
6

7. 原因1: 制約解決の困難さ
ある分岐先を通るために変数が満たすべき条件を，
うまく解くことが出来ない
void method(int x, int y, int n) {
int value = x << n;
if (value < y && n > 2) {
// この分岐先をテストしたい
}
(x << n) < y かつ n > 2 を満たす具体的なx, y, n ?
}
長さ可変のシフト演算は苦手…
7

8. 原因2: オブジェクト生成・変更の困難さ
ある分岐先を通るために満たされているべき
オブジェクトの状態を設定できない
void method2(Container container) {
if (container.getSize() >= 10) {
// この分岐先をテストしたい
}
}
8

9. 原因2: オブジェクト生成・変更の困難さ
ある分岐先を通るために満たされているべき
オブジェクトの状態を設定できない
void method2(Container container) {
if (container.getSize() >= 10) {
// この分岐先をテストしたい
} containerの内部変数size==10にすれば良い
}
Container.setSize()メソッドは無い…
どうやってcontainer.getSize()==10
にすればいいんだ…？
9

10. 自動テスト生成を困難にする原因2つ
 制約解決の困難さ
 (x << n) < y かつ n > 2 を満たす具体的なx, y, n ?
 オブジェクト変更の困難さ
 container.size() == 10となるcontainerの生成?
人間にとってはそんなに困難じゃない問題もありそう
提案 「Puzzle-based Automated Testing」
手法 機械的に解決できない問題の一部を
小さなパズルとして人間に解いてもらおう！
10

11. 提案手法: Puzzle-based Automated Testing
(1) 既存手法で
テストケース
生成・実行
プログラム
・実行時インスタンス
カバレッジ情報 ・メソッド呼出履歴
(2) 未到達分岐へ至る
パス・値の計算
SMTソルバエラー
値
(3) 制約解決 (4) オブジェクト
パズル 変更パズル テストケース
制約を
生成 満たす値 生成
11
テストケース生成

12. 1. 既存手法でテストケース生成
Randoop[1]という既存のツールを利用して
テストケースの生成・実行
 既存ツールでカバー出来るパスをカバー
 後に利用するため実行時情報を記録
 生成されたインスタンス
 メソッド呼び出し履歴
12
[1] C.Pacheso et al. Feedback-directed random test generation. ICSE 2007

13. 2. 未到達分岐へ至るパス・値を計算
カバーしたい分岐から逆向きに SMTソルバ[5]で
満たすべき制約条件を収集 (記号的実行[4]) 制約を満たす
private pri(int n) { 値を求める
if (n * 3 < 20) {
// カバーしたい場所 pub(x)
} x> 0
} n == x + 5
n * 3 < 20
public pub(int x) {
if (x > 0) { x=1
解けない
pri(x + 5) 解ける
…… ③制約解決パズル
④オブジェクト変更パズル 13
[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.

14. 3. 制約解決パズルの生成(1/2)
SMTソルバで解決できなかった制約のうち，
ソルバが出したエラーに関係するものを抽出
this != null エラー：
sums != null 非線形不等式は
sums.length * sums.length <= 4096 サポートされて
sums.length > 0 いません
this.n > 1
sums.length * sums.length <= 4096
14
sums.length > 0

15. 3. 制約解決パズルの生成(1/2)
変数名以外に違いのない制約はまとめる
sums.length * sums.length <= 4096
sums.length > 0
num * num <= 4096
A * A <= 4096
num > 0
A>0
obj.mem * obj.mem <= 4096
３回出現
obj.mem > 0
15

16. 3. 制約解決パズルの解決
何度も出現する制約から順に人間に解いてもらう
パズル…？
16

17. 4. オブジェクト変更パズル(1/2)
依存するオブジェクトによって
条件集合をさらに分割する
どうやって
input != null この条件を満たす
input.readInt() == 1 inputとthisを
作ればいいんだ？
this.currentState == null
input != null
this.currentState == null
input.readInt() == 1
17

18. 4. オブジェクト変更パズル(2/2)
何度も出てくる条件集合を優先的に人間に解いてもらう
18

19. 4. オブジェクト変更パズル(2/2)
何度も出てくる条件集合を優先的に人間に解いてもらう
ステップ1で収集した
インスタンスを
メソッド引数として利用
オブジェクトの
状態を変化させて
目標に近づける
メソッドに適当な
引数を渡して実行
19

20. テストケース生成
(2)から
「網羅したい分岐を通るにはどのパスを通るべきか」
(2)(3)から
「thisオブジェクト・引数の満たすべき値」
(4)から
「オブジェクトを望む状態にするためのメソッドの列」
以上を繋げることで
網羅したい分岐を通る
テストケース
(Javaの命令列) 20
が得られる

21. 実験による評価
研究課題
1. 人間が解くことの出来るパズルは何割程度か
2. どれだけの人が進んでパズルを解いてくれるか (今回は説明を省略)
3. 提案法によってカバレッジはどれだけ向上するか
4. 手動でテストを書く労力はどれだけ削減できるか
21

22. 実験設定
対象アプリケーション
名前 # of lines # of branches
Apache Commons Math (ACM) 20,605 7707
Apache Commons Collections (ACC) 14,261 5242
比較対象
提案法のステップ1, 2が既存手法に対応
(1)Randoop + (2)記号的実行&SMTソルバ
対象 Randoop +記号的実行&SMTソルバ
ACM 61.6% 64.4%
22
ACC 53.0% 56.8%

23. 研究課題1: 人間が解けるパズルはどの程度あるか？
→実際にパズルを解いてもらう実験を行った
被験者 コンピュータ科学専攻の大学院生8人
対象 Apache Commons Mathに対して
生成されたパズルの上位100件づつ
結果
総数 解けたパズルの数(重複除く) 平均所要時間
オブジェクト変更 100 51 1分
制約充足 100 72 1分
23
51%, 72%のパズルを平均1分で解けた

24. 研究課題3: カバレッジはどれだけ向上するか？
75
70
7
分岐カバレッジ(%)
65
2.8
60 5.8 +提案法
+記号的実行
55 3.7
Randoop
50 61.6
53
45
40
Commons Math Commons Collection
最先端の手法で得られたカバレッジより，
24
それぞれさらに5.8%, 7% 向上した．

25. 研究課題4: テストを書く労力は削減できるか？
手動テストに関する実験
対象: Java歴6年のある大学院生
方法: 未網羅の分岐をランダムに10個選択，
その分岐を網羅するテストを書いてもらう
所要時間(平均): ACMでは9分 ACCでは8分
提案法
 1パズル平均1分で解けてた
 ドメイン知識ない人でも解けてた
 1パズル解けばいくつかの分岐を網羅できる場合も
提案法は，手動でテストを書くよりも 25
効率的にカバレッジを増やせる

26. 結論
Test-based Automated Testingという枠組みを提案
機械的に解けない問題の一部をパズルとして人間に出題
 制約解決パズル
 オブジェクト変更パズル
提案法の良さ
 最先端ツールよりカバレッジが数%上昇
 手動でテストを書くよりも効率大
 ドメイン知識無くても実施可能 26

27. 私見
 機械的に解けないので人の力を借りようというアイディアが面白い
 結果の見せ方がうまい
 さりげなくグラフの目盛りが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で参加者を募った
結果 120人の参加者
総数 解けたパズルの数(重複除く) 平均所要時間
オブジェクト変更 100 24 1分
制約充足 100 84 1分
ゲーム感覚(?)で参加してくる人は居る
彼ら(ドメイン知識無い？)は，CS専攻の学生
と比べても同等程度のパズル正解力
28