On-Demand Test Suite Reduction

Size: px

Start display at page:

Download "On-Demand Test Suite Reduction"

いとはひきぎ
5 years ago
Views:

1 make test-zesti: A Symbolic Execution Solution for Improving Regression Testing NTT ソフトウェアイノベーションセンタ丹野治門

2 目的と貢献目的ソフトウェアにおけるより多くのバグを見つけたい現状の問題点開発者が作るテスト ( 意味あるテスト, 高コスト ) 機械的に作るテスト ( 低コスト, 無意味なものが多い ) ( 例 ) パスカバレッジ向上を目指した Symbolic Execution 提案開発者が作った ( 回帰テスト向け ) テストケースを種にして様々なバリエーションを生成主な貢献点 OSS でしっかり評価, 未知のバグを発見 2

3 着眼点 Sensitive Operations の周辺を徹底的にテストするようにする Sensitive Operation = バグ混入しやすい箇所具体例 : 配列へのアクセス int v[100]; void f(int x){ if(x > 99){ x = 99; } v[x] = 0; } 回帰テスト用テストケース ( 開発者が作成 ) TestCase01 x = 100 TestCase02 x = 50 この 2 つのテストケースでパスカバレッジ ( 分岐網羅 ) は 100% だが x = -1 のとき配列不正アクセスエラー Sensitive Operation 周辺はバグが存在する可能性が高い! 3

4 着眼点 Sensitive Operations の周辺を徹底的にテストするようにする Sensitive Operation = バグ混入しやすい箇所具体例 : 配列へのアクセス int v[100]; void f(int x){ if(x > 99){ x = 99; } v[x] = 0; } 4 回帰テスト用テストケース ( 開発者が作成 ) TestCase01 x = 100 TestCase02 x = 50 提案手法この 2 つのテストケースでパスカバレッジ ( 分岐網羅 ) は 100% だが x = -1 のとき配列不正アクセスエラー! TestCase03 x = -1

5 手法テスト実行と同時に Symbolic Execution を実施 Symbolic Execution 結果 + 追加条件で新規テスト生成 TestCase02 x = 50 提案手法によるテストケース生成の一例 int v[100]; void f(int x){ if(x > 99){ x = 99; } v[x] = 0; } Symbolic Execution 追加! 入力変数 : x = x0 パス条件 : not(x0 > 99) 境界値条件 x0 > 0 && x0 <100 テストケース生成 TestCase03 x = -1 5

6 評価評価に用いた OSS(3 つ ) GNU Coreutils,libdwarf,readelf 評価結果合計 58 件 ( うち,52 件は未知 ) のバグを検出 OSSコミュニティに報告, バグ改修も進んでいる提案手法で発見した Coreutils のバグ一覧 Min Depth バグに到達するまでの条件分岐の数 6 通常の Symbolic Execution では時間がかかりすぎて発見しにくいバグ Paul Dan Marinescu and Cristian Cadar make test-zesti: A Symbolic Execution Solution for Improving Regression Testing ICSE2012. Table1 より

7 BALLERINA: Automatic Generation and Clustering of Efficient Random Unit Tests for Multithreaded Code NTT ソフトウェアイノベーションセンタ張暁晶

8 背景目的貢献背景マルチスレッドを用いるソースコードの単体試験は手間がかかるテスト対象が持つオブジェクトを複数のスレッドで触るような試験であるこのような単体試験をランダム生成する従来手法では目的生成された単体試験の実行が遅い並行性バグをうまく見つけられないバグじゃないのにバグだという誤報 (false alarm) が出る並行性バグをうまく見つけられるような単体試験をランダム生成する貢献 1. 並行性バグをうまく見つけられるような単体試験をランダム生成する手法を提案 2. 生成された単体試験でのfailureを人手で点検する手間を軽減できるクラスタリング手法も提案 3. 評価 : 実際のバグ検出による効果確認 8

9 手法概要 1 単体試験のランダム生成 : 2 つのスレッドのみ用意するそれぞれがランダムに選ばれたテスト対象のメソッドを 1 つだけ実行する並行性バグにあたる確率を上げるために上記のようなシンプルな並行コードをより複雑なシーケンシャルなランダム生成コードの後ろに追記する BALLERINA が生成した単体試験シーケンシャルなランダム生成コード既存手法 Randoop algorithm[1] を改造並行実行する 2 つのスレッド Adrian Nistor et al. BALLERINA: Automatic Generation and Clustering of Efficient Random Unit Tests for Multithreaded Code, In Proc. of ICSE 2012, pp , Figure 2 より [1] C. Pacheco, S. K. Lahiri, M. D. Ernst, and T. Ball, Feedbackdirected random test generation, in ICSE,

10 手法概要 2 点検すべき failure を絞り込むクラスタリング手法 : Test Oracle として既存手法 linearizability[2] を採用しているので誤報が出る可能性がある似たようなバグレポートはたぶん全部誤報か全部本物のバグかだろうバグレポートを下記 2 点によりクラスタリングする Failure 発生時に実行していたメソッド Failure の種類評価では 1 個の本物のバグに対して数百個の誤報が出る非実用的クラスタリングの導入後では誤報は 3~4 個にまで減った [2] S. Burckhardt, C. Dern, M. Musuvathi, and R. Tan, Line-Up: A complete and automatic linearizability checker, in PLDI,

11 評価 6 件の OSS に含まれる 14 個の本物のバグで評価 Groovy, JDK, JFreeChart, Apache Log4j, Apache Lucene, Apache Pool 提案手法は既存ランダム生成手法より 2~10 倍速くバグを見つけたクラスタリング手法により点検すべき failure の数を 4~8 倍減らした未知のバグをさらに 3 件検出できた Apache Log4j, Apache Pool から 11

12 On-Demand Test Suite Reduction Dan University ( 株 )NTT データ技術開発本部朱峰錦司

13 背景 (1/2) 従来のテストケース削減手法はコードカバレッジを一定に保てれば減らしてよいというものが多いチョシャ裁判長! コードカバレッジを保っていてもバグ発見能力には疑いの余地があります! 13

14 背景 (2/2) 2 つの既存手法を試してみると 20% 以上の確率でバグ発見能力 6 割減 20% 以上の確率でバグ発見能力 4 割減 14 元論文 P.2 から抜粋

15 目的バグ発見能力を一定に保ちながらテストケースを削減する手法の提案全てのテストケースの集合以下を満たす最小のテストケースの集合バグ発見能力の低下は l% 以下 ( 統計学に頼るので ) 信頼度は c% テストケース削減によるバグ発見能力低下の実績データをもとにこの集合を線形計画法で発見する! 15

16 手法概要 (1/2) 実績データの作成既存のソフトウェアをもとにテストケースの削減とバグ発見能力の低下との相関を分析信頼度は 90%,95%,99% の 3 パターンに決め打ちテストケース数を 4 から 2 に減らすと 99% の確率でバグ発見能力は ( 最高で ) 83.3% 減少してしまう元論文 P.4 から抜粋 16

17 手法概要 (2/2) 線形計画法の適用 2 種類のモデル式を提案 local constraints に基づく式あるテストケースの部分集合において q 行目のソースコードをカバーするケースがもともと p_j 個あった状態から q 個に減少した際に全ての行個別で不等式が成り立たたないといけないソースコード全体で成り立てばよい global constraints に基づく式モデル式の簡易化 ( 省略 ) 元論文 P.5 から抜粋過去の実績ではテストケースを p_j 個から q 個に減らすとこれぐらい能力が落ちる元論文 P.5 から抜粋 17

18 評価 3 つのシナリオで手法を評価対象実績データ適用対象結果 1 8つのCプログラム 1つのプログラムの半分プログラムの残り半分全てのプログラムにおいて 2 つのモデル式の場合ともに結果は妥当であった 2 1 つの Java プログラムの 3 リビジョン前バージョン後バージョンバージョン番号が近いほうがより結果は妥当であった 3 7つのCプログラム 6プログラム残り1プログラム global の場合のほうが削減効果は大きいが local の場合のほうがバグ発見能力が高い他手法との比較テストケース削減効果は少ないがバグ発見能力を維持したい場合は非常に効果的 18

PowerPoint プレゼンテーション

PowerPoint プレゼンテーションソフトウェア品質シンポジウム 15 継続的システムテストについての理解を深めるための開発とバグのメトリクスの分析 15/9/18 荻野恒太郎 kotaro.ogino@mail.rakuten.com Test Engineering Team Service Support Section Group Core Service Department http://www.rakuten.co.jp/