1

2013/5/23

Swarm Testing (ISSTA’12)

輪講用資料

対象：コンピュータ科学専攻の修士・博士学生

（ソフトウェア工学専攻とは限らない）

発表時間：20分

Swarm Testing

Alex Groce and Chaoqiang Zhang(オレゴン州立大学, アメリカ)

Eric Eide, Yang Chen and John Regehr (ユタ大学,アメリカ)

International Symposium in Software

Testing and Analysis (ISSTA 2012)

Acceptance rate: 28.7% (31/108)

2

発表論文

題目

著者

出典

群れ

ランダムテスト

(ランダムに実行列を生成し，異常がないことを確認)

カバレッジや欠陥発見能力を上げたい

実行列自動生成のときの最適な設定を求めよう！

いろんな設定でランダムテストを実行

ひとつの(良い)設定で実行するより性能向上?

3つのケーススタディで性能向上を確認

ある例では42%多く欠陥を発見 3

概要

背景

評価

例) どのAPIをテストするか

既存手法

Swarm Testing

4

背景: ランダムテスト

1. 設定の調節 (例)ある関数をテストする/しないを決定

3. 実行 プログラムが例外を投げたりしないか？

2. ランダムにテストケース(プログラム実行コード)を大量生成

テストケース 対象プログラム 開発者 テスト生成器

これまで：ひとつの設定を利用してテストケース生成

いろんな設定の下でテストケースを生成したら 多様性が生まれ，カバレッジ等向上するのでは？

スタックをテストしたい

バッファサイズが32を超えたときに起きるバグが存在

5

Toy example: スタックのオーバーフロー

Pushの呼び出し回数

Popの呼び出し回数

1/370,000の確率でエラー発生

従来法: {push, pop}をランダムに 組み合わせてテストを生成した場合

Popの呼び出し回数

Pushの呼び出し回数

• {push, pop}をランダムに組み合わせ

• {push}のみ

• {pop}のみ

でテスト生成 1/16の確率でエラー発生

Swarm Testing:

{push}

{push, pop} {pop}

スタックをテストしたい

バッファサイズが32を超えたときに起きるバグが存在

6

Toy example: スタックのオーバーフロー

Pushの呼び出し回数

Popの呼び出し回数

1/370,000の確率でエラー発生

従来法: {push, pop}をランダムに 組み合わせてテストを生成した場合

Popの呼び出し回数

Pushの呼び出し回数

• {push, pop}をランダムに組み合わせ

• {push}のみ

• {pop}のみ

でテスト生成 1/16の確率でエラー発生

Swarm Testing:

{push}

{push, pop} ある特徴がエラー発生を妨げることがあり その特徴を考慮しない場合を作ることで， 素早くエラーを発生することができる

以下の3つを対象にケーススタディを実施

7

ケーススタディ

1. ファイルシステム

2. Cのコンパイラ

3. 赤黒木(データ構造)の実装 時間の都合で省略

設定

組み込み向けファイルシステム

23の主要APIをそれぞれテストに含めるかどうか

APIをランダムに選びランダムな引数で呼び出し×200行

8

ケース1.1(準備): YAFFS フラッシュ・ファイルシステム

対象

テスト生成

Swarm

すべてのAPIをテスト対象に含める

各APIをそれぞれ利用するか確率1/2でそれぞれ決定

100個の設定を準備

比較対象

72時間かけてテストを実行

→ カバレッジ・ミューテーション解析による性能測定

ミュータント ミュータント 9

(補足)用語説明

カバレッジ

テストがプログラムを

どれだけカバーしたかの指標

ミューテーション解析

If a > 0

return a; return -a;

a = 10

分岐カバレッジ: 50%

機械的にプログラムに欠陥を注入

テストケースの欠陥発見能力を測定

プログラム ミュータント テスト

欠陥検出 できるか？

欠陥注入

10

ケース1.1(結果): カバレッジ・欠陥発見性能

従来 Swarm 両方

テストケース数 1747 1593 3340 ブロックカバレッジ 1161 1168 1173 ブランチカバレッジ 1247 1253 1261 Def-use pairカバレッジ 2487 2507 2525 Prime path カバレッジ 2834 2872 2964 Pathカバレッジ 14153 25484 35478 ミュータント検出数 94 97 97

従来 Swarm 両方

テストケース数 1747 1593 3340 ブロックカバレッジ 1161 1168 1173 ブランチカバレッジ 1247 1253 1261 Def-use pairカバレッジ 2487 2507 2525 Prime path カバレッジ 2834 2872 2964 Pathカバレッジ 14153 25484 35478 ミュータント検出数 94 97 97

11

ケース1.1(結果): カバレッジ・欠陥発見性能

すべての指標でカバレッジ増大

欠陥発見性能も増加

従来法で検出可な欠陥はすべてSwarmでも発見

設定

5つのコンパイラ，17のバージョン

CsmithというランダムCプログラム生成ツールを利用

構造体を含めるか

配列を含めるか

etc…

12

ケース2(準備): C言語コンパイラ

対象

テスト生成

Swarm

デフォルト設定(すべての要素を利用)

各要素をそれぞれ利用するか確率1/2でそれぞれ決定

比較対象

一週間かけてテストを実行

→ コンパイラをクラッシュさせるパターンがいくつ見つかるか？

13

ケース2(結果1): クラッシュ発生性能

コンパイラ デフォルト Swarm 両方

LLVM/Clang 2.6 10 12 14

LLVM/Clang 2.7 5 6 7

LLVM/Clang 2.9 0 1 1

GCC 3.2.0 5 10 11

GCC 3.3.0 3 4 5

GCC 4.0.0 8 8 10

GCC 4.3.0 7 8 9

CGG 4.5.0 0 1 1

GCC 4.6.0 0 1 1

Open64 4.2.4 13 18 20

Sun CC 5.11 5 14 14

Intel CC 12.0.5 4 2 5

Total 73 104 120

発生させたクラッシュの数(クラッシュ箇所が同じものは除く)(抜粋)

14

ケース2(結果1): クラッシュ発生性能

コンパイラ デフォルト Swarm 両方

LLVM/Clang 2.6 10 12 14

LLVM/Clang 2.7 5 6 7

LLVM/Clang 2.9 0 1 1

GCC 3.2.0 5 10 11

GCC 3.3.0 3 4 5

GCC 4.0.0 8 8 10

GCC 4.3.0 7 8 9

CGG 4.5.0 0 1 1

GCC 4.6.0 0 1 1

Open64 4.2.4 13 18 20

Sun CC 5.11 5 14 14

Intel CC 12.0.5 4 2 5

Total 73 104 120

42%の性能向上

発生させたクラッシュの数(クラッシュ箇所が同じものは除く)(抜粋)

15

ケース2(結果2): あるクラッシュと，関連する性質

あるクラッシュ(395回発生)を引き起こすプログラムが 各性質を含んでいる割合(信頼区間95%)

trigger

suppressor

16

ケース2(結果3): クラッシュのtriggerとsuppressor

Triggers

Pointers 33%

Arrays 31%

Structs 29%

Volatiles 21%

Bitfields 15%

Embedded Assignment 15%

Consts 13%

Comma Operator 11%

Jumps 11%

Unions 11%

Suppressor

Pointers 41%

Embedded Assignments 24%

Jumps 21%

Arrays 17%

++ and -- 16%

Volatiles 15%

Unions 13%

Comma Operator 11%

Long Long Ints 11%

Compound Assignments 11%

ある特徴を含むテストケースによってStatically likelyに クラッシュが引き起こされ/抑制される割合

17

ケース2(結果3): クラッシュのtriggerとsuppressor

Triggers

Pointers 33%

Arrays 31%

Structs 29%

Volatiles 21%

Bitfields 15%

Embedded Assignment 15%

Consts 13%

Comma Operator 11%

Jumps 11%

Unions 11%

Suppressor

Pointers 41%

Embedded Assignments 24%

Jumps 21%

Arrays 17%

++ and -- 16%

Volatiles 15%

Unions 13%

Comma Operator 11%

Long Long Ints 11%

Compound Assignments 11%

ある特徴を含むテストケースによってStatically likelyに クラッシュが引き起こされ/抑制される割合

ある特徴がtriggerにもsuppressorにもなりうる

過去400件のコンパイラバグを見つけた著者らでも，どの特徴がtriggerになるかは直観的に予測不可

提案法の有用性

Swarm Verification: いろんな設定でモデル検査を実行

Configurationテスト: いろんな「設定」のもとでソフトウェアをテスト

→提案法はテスト生成器の設定を変化させる

18

関連研究

テストの多様性に関する既存手法

Partitionテスト 入力空間をPartitionに分割 各Partitionから入力値を生成

組み合わせテスト 入力の組み合わせを網羅するテストケース集合

Adaptive ランダムテスト ランダムテストの修正版．過去に実行されたテストたちから最も「距離」の遠いテストを実行

提案法はテスト生成器の設定を変更したSwarmを作る 他のテスト手法と直交的に組み合わせ可能な 軽量かつ効果的な手法

Swarm Testing:

「テストケースに対する制約を複数作り

それぞれで自動テスト」を提案した

現実のアプリケーションに適用し

カバレッジ向上

ミュータントの検出性能向上

実際の欠陥の検出性能向上

という提案法の有用性を示した

19

結論

アイディアはシンプルだけど面白い

評価対象が現実的

「同時に編集すべき設定」というのがありそう

「 既存研究は良い設定を見つけることに腐心している」といいつつ，実験での比較対象が「全ての命令を含むような設定」というのはやや乱暴

20

私見

○

×

△

○

21

ケース1.2: Swarmの数を増やす + ミューテーション解析をオフライン化

従来 Swarm 両方

テストケース数 5665 5888 11553 ブロックカバレッジ 1173 1172 1178 ブランチカバレッジ 1261 1259 1268 DefUse-pairカバレッジ 2525 2538 2552 Prime path カバレッジ 2907 2967 3018 Pathカバレッジ 35432 64845 91280 ミュータント検出数 95 97 97

• Swarmの数を500に • ミューテーション解析を後で行うように

ミューテーション解析を後で行うようにしたので，同じテスト時間でも3倍のテストが実行

できている

カバレッジは減った部分もあるが，概ね

向上

ミュータント検出に関しては1.1と同じく良い結果

22

ケース1.1(補足): Swarmの選び方について1

1.1で扱ったSwarmの選び方をコイントス法と命名

(各APIについて確率1/2で使う/使わないを決定)

他のSwarmの作り方として，Covering-Array-baseのアプローチを試す

N-covering-array-based: 任意のN要素に着目した時，N要素のすべての値の組み合わせが考慮されている ※注目しているN要素以外の要素について，含む/含まないの自由度があるので，Covering-array(included)と(excluded）を共に実験

Path coverage Block coverage, Branch coverage

デフォルト 4 (他の3つと大きな差) 2

コイントス 2 1

5-covering-array(included) 1 3 or 4(ややデフォルトに劣る)

5-covering-array(excluded) 3 3 or 4(ややデフォルトに劣る)

ランダム(コイントス)そんなに悪くないかも また，ランダムでも数増やせばどうせn-covergeに近くなる

23

ケース1.1(補足): Swarmの選び方について2

ランダムを推し進めて，毎回ランダムに設定を作ったらどうなるのか？

設定生成のコストが低い時は毎回設定つくるのも良いかも

デフォルト Swarm

ブロックカバレッジ 1446 1459

ブランチカバレッジ 1626 1641

パスカバレッジ 70587 112944

PCTカバレッジ 61380 61864

ミュータント検出数 113 123

実行時間(秒) 158 136

5000テストケース，毎回設定生成の結果

あらゆる面で 性能向上

Swarm(群れ)テストという新手法を提案する．これは，ランダムテストにお

いて生成されるテストケースの多様性を低コストで増やすものである．

Swarmテストは，従来のランダムテストがもっている，「すべてのテスト

ケースに対してすべての性質・設定を考慮する」という慣習を捨て去り，そ

の代わりに，ランダムに生成された設定のSwarmを利用し，様々な設定のも

とでテストケースを生成する．それぞれの設定はある性質を考慮していたり，

いなかったりする．ある性質を考慮しないことがシステムの状態空間探索に

おいてよく働く理由を２つ述べる．まず，ある特徴によって，システムが興

味深い状態になりにくい，ということがあり得る．例えば，スタックにおい

てpopを考慮することで，スタックオーバーフローを起こしにくくするだろ

う．また，直接阻害することが無くても，多くの性質を同時に考慮するとい

うことは，限られたテストケースのサイズやテスト実行時間のもとで，ある

特定の性質(複数かもしれない)がより深く状態を探索することを阻害するだ

ろう．実験の結果から，Swarmテストはカバレッジを増大させ，欠陥発見能

力を劇的に改善させることを示す．例えば，一週間におよぶ自動テストにお

いて，SwarmテストはCコンパイラをクラッシュさせる独立した方法を見つ

けるタスクにおいて，手動でチューニングされたデフォルトの設定を利用し

た時とくらべ，42%の性能向上を見せた．

24

アブスト和訳

25

用語説明1

ブロック カバレッジ

コードブロック(分岐を含まないコードのまとまり)

のどれだけがカバーされたか

Def-use pair 変数の定義と，その参照箇所の組

Simple path 途中に同じノードが複数回登場しないパス

(ただし，始点と終点が同じことは許す)

Prime path Simple pathかつ他のSimple pathに完全に含まれない

Path ここでは，プログラムの実行経路

26

用語説明2

Predicate 真偽値を返す式 (例: x > 0)

PCT カバレッジ

Predicate complete Test カバレッジ

分岐・アサーションなどのプログラム中のすべてのPredicateのすべての組み合わせを

網羅すると最大になるカバレッジ指標

http://www.flickr.com/photos/filthysize/171132217/lightbox/

画像出典