Recommandé
Contenu connexe
En vedette
Similaire à Swarm Testing (ISSTA 2012) 輪講会用資料
Similaire à Swarm Testing (ISSTA 2012) 輪講会用資料 (20)
Plus de nkazuki
Plus de nkazuki (11)
Dernier
Dernier (11)
Swarm Testing (ISSTA 2012) 輪講会用資料
- 2. Swarm Testing Alex Groce and ChaoqiangZhang(オレゴン州立大学, アメリカ) Eric Eide,YangChen and John Regehr (ユタ大学,アメリカ) International Symposium in Software Testing and Analysis (ISSTA 2012) Acceptance rate: 28.7% (31/108) 2 発表論文 題目 著者 出典 群れ
- 4. 4 背景: ランダムテスト 1. 設定の調節 (例)ある関数をテスト する/しないを決定 3. 実行 プログラムが例外を 投げたりしないか？ 2. ランダムにテスト ケース(プログラム実 行コード)を大量生成 テストケース 対象プログラム開発者 テスト生成器 これまで：ひとつの設定を利用してテストケース生成 いろんな設定の下でテストケースを生成したら 多様性が生まれ，カバレッジ等向上するのでは？
- 5. スタックをテストしたい バッファサイズが32を超えたときに起きるバグが存在 5 Toy example: スタックのオーバーフロー Pushの呼び出し回数 Popの呼び出し回数 1/370,000の確率で エラー発生 従来法: {push, pop}をランダムに 組み合わせてテストを生成した場合 Popの呼び出し回数 Pushの呼び出し回数 • {push, pop}をランダムに組み合わせ • {push}のみ • {pop}のみ でテスト生成 1/16の確率で エラー発生 SwarmTesting: {push} {push, pop} {pop}
- 6. スタックをテストしたい バッファサイズが32を超えたときに起きるバグが存在 6 Toy example: スタックのオーバーフロー Pushの呼び出し回数 Popの呼び出し回数 1/370,000の確率で エラー発生 従来法: {push, pop}をランダムに 組み合わせてテストを生成した場合 Popの呼び出し回数 Pushの呼び出し回数 • {push, pop}をランダムに組み合わせ • {push}のみ • {pop}のみ でテスト生成 1/16の確率で エラー発生 SwarmTesting: {push} {push, pop}ある特徴がエラー発生を妨げることがあり その特徴を考慮しない場合を作ることで， 素早くエラーを発生することができる
- 7. 以下の3つを対象にケーススタディを実施 7 ケーススタディ 1. ファイルシステム 2. Cのコンパイラ 3. 赤黒木(データ構造)の実装 時間の都合 で省略
- 9. ミュータントミュータント 9 (補足)用語説明 カバレッジ テストがプログラムを どれだけカバーしたかの指標 ミューテーション解析 If a > 0 return a; return -a; a = 10 分岐カバレッジ: 50% 機械的にプログラムに欠陥を注入 テストケースの欠陥発見能力を測定 プログラム ミュータント テスト 欠陥検出 できるか？ 欠陥注入
- 10. 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
- 11. 従来 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でも発見
- 12. 設定 5つのコンパイラ，17のバージョン CsmithというランダムCプログラム生成ツールを利用 構造体を含めるか 配列を含めるか etc… 12 ケース2(準備): C言語コンパイラ 対象 テスト 生成 Swarm デフォルト設定(すべての要素を利用) 各要素をそれぞれ利用するか確率1/2でそれぞれ決定 比較対象 一週間かけてテストを実行 → コンパイラをクラッシュさせるパターンがいくつ見つかるか？
- 13. 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. 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. 15 ケース2(結果2): あるクラッシュと，関連する性質 あるクラッシュ(395回発生)を引き起こすプログラムが 各性質を含んでいる割合(信頼区間95%) trigger suppressor
- 16. 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. 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になるかは直観的に予測不可 提案法の有用性
- 18. SwarmVerification: いろんな設定でモデル検査を実行 Configurationテスト: いろんな「設定」のもとでソフトウェアをテスト →提案法はテスト生成器の設定を変化させる 18 関連研究 テストの多様性に関する既存手法 Partitionテスト 入力空間をPartitionに分割 各Partitionから入力値を生成 組み合わせテスト 入力の組み合わせを網羅するテストケース集合 Adaptive ランダムテスト ランダムテストの修正版．過去に実行されたテ ストたちから最も「距離」の遠いテストを実行 提案法はテスト生成器の設定を変更したSwarmを作る 他のテスト手法と直交的に組み合わせ可能な 軽量かつ効果的な手法
- 19. SwarmTesting: 「テストケースに対する制約を複数作り それぞれで自動テスト」を提案した 現実のアプリケーションに適用し カバレッジ向上 ミュータントの検出性能向上 実際の欠陥の検出性能向上 という提案法の有用性を示した 19 結論
- 21. 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. 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. 23 ケース1.1(補足): Swarmの選び方について2 ランダムを推し進めて，毎回ランダムに設定を作ったらどうなるのか？ 設定生成のコストが低い時は毎回設定つくるのも良いかも デフォルト Swarm ブロックカバレッジ 1446 1459 ブランチカバレッジ 1626 1641 パスカバレッジ 70587 112944 PCTカバレッジ 61380 61864 ミュータント検出数 113 123 実行時間(秒) 158 136 5000テストケース，毎回設定生成の結果 あらゆる面で 性能向上
- 25. 25 用語説明1 ブロック カバレッジ コードブロック(分岐を含まないコードのまとまり) のどれだけがカバーされたか Def-use pair 変数の定義と，その参照箇所の組 Simple path 途中に同じノードが複数回登場しないパス (ただし，始点と終点が同じことは許す) Prime path Simple pathかつ他のSimple pathに完全に含まれない Path ここでは，プログラムの実行経路
- 26. 26 用語説明2 Predicate 真偽値を返す式 (例: x > 0) PCT カバレッジ Predicate completeTest カバレッジ 分岐・アサーションなどのプログラム中のすべての Predicateのすべての組み合わせを 網羅すると最大になるカバレッジ指標 http://www.flickr.com/photos/filthysize/171132217/lightbox/ 画像出典