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

３回出現

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人の参加者