make test-zesti ： A Symbolic Execution Solution

for Improving Regression Testing

NTT ソフトウェアイノベーションセンタ　丹野 治門

目的と貢献 目的

ソフトウェアにおけるより多くのバグを見つけたい 現状の問題点

開発者が作るテスト (○ 意味あるテスト， 高コスト✕ ) 機械的に作るテスト (○ 低コスト , ✕ 無意味なものが多

い ) ( 例 ) パスカバレッジ向上を目指した Symbolic Execution

提案 開発者が作った ( 回帰テスト向け ) テストケースを種にし

て様々なバリエーションを生成 主な貢献点

OSS でしっかり評価，未知のバグを発見2012/8/30ICSE'12 勉強会2

着眼点 Sensitive Operations の周辺を徹底的にテスト

するようにする Sensitive Operation = バグ混入しやすい箇所 具体例：配列へのアクセス

2012/8/30ICSE'12 勉強会3

int v[100];void f(int x){ if(x > 99){ x = 99; } v[x] = 0;}

この 2 つのテストケースでパスカバレッジ（分岐網羅）は 100% だが・・・

x = -1 のとき配列不正アクセスエラーSensitive Operation 周辺はバグが存在する可能性が高い！

回帰テスト用テストケース（開発者が作成）TestCase01x = 100

TestCase02x = 50

着眼点 Sensitive Operations の周辺を徹底的にテスト

するようにする Sensitive Operation = バグ混入しやすい箇所 具体例：配列へのアクセス

2012/8/30ICSE'12 勉強会4

int v[100];void f(int x){ if(x > 99){ x = 99; } v[x] = 0;}

この 2 つのテストケースでパスカバレッジ（分岐網羅）は 100% だが・・・

x = -1 のとき配列不正アクセスエラー！

回帰テスト用テストケース（開発者が作成）TestCase01x = 100

TestCase02x = 50

TestCase03x = -1提案手法

手法 テスト実行と同時に Symbolic Execution を実施 「 Symbolic Execution 結果＋追加条件」で新規テスト生

成

2012/8/30ICSE'12 勉強会5

入力変数：　 x = x0パス条件：　 not(x0 > 99)

TestCase02x = 50

提案手法によるテストケース生成の一例

int v[100];void f(int x){ if(x > 99){ x = 99; } v[x] = 0;}

Symbolic

Execution 境界値条件

　 x0 > 0 && 　 x0 <100

追加！

テストケース生成

TestCase03x = -1

評価 評価に用いた OSS( ３つ )

GNU Coreutils ， libdwarf ， readelf 評価結果

合計 58 件 ( うち， 52 件は未知 ) のバグを検出 OSS コミュニティに報告，バグ改修も進んでいる

2012/8/30ICSE'12 勉強会6

提案手法で発見した Coreutils のバグ一覧Min Depth

バグに到達するまでの「条件分岐」の数

通常の Symbolic Execution では時間がかかりすぎて発見しにくいバグ

Paul Dan Marinescu and Cristian Cadar “make test-zesti ： A Symbolic Execution Solution for Improving Regression Testing” ICSE2012. 　 Table1 より引用

BALLERINA: Automatic Generation and Clustering of Efficient Random Unit

Testsfor Multithreaded Code

NTT ソフトウェアイノベーションセンタ　張 暁晶

背景・目的・貢献 背景

マルチスレッドを用いるソースコードの単体試験は、手間がかかる テスト対象が持つオブジェクトを、複数のスレッドで触るような試験である

このような単体試験を「ランダム生成」する従来手法では・・・ 生成された単体試験の実行が遅い 並行性バグをうまく見つけられない バグじゃないのにバグだという誤報（ false alarm ）が出る

目的 並行性バグをうまく見つけられるような単体試験をランダム生成する

貢献1. 並行性バグをうまく見つけられるような単体試験をランダム生成す

る手法を提案2. 生成された単体試験での failure を、人手で点検する手間を軽減で

きる「クラスタリング手法」も提案3. 評価：実際のバグ検出による効果確認

2012/8/30ICSE'12 勉強会8

手法概要 1 単体試験のランダム生成：

２つのスレッドのみ用意する それぞれが、ランダムに選ばれたテスト対象のメソッドを 1 つだけ実行する 並行性バグにあたる確率を上げるために、上記のような「シンプルな」並行コー

ドを、「より複雑な」シーケンシャルなランダム生成コードの後ろに追記する

2012/8/30ICSE'12 勉強会9

シーケンシャルなランダム生成コード

→ 既存手法 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.727-737, Figure 2 より

BALLERINA が生成した単体試験

[1] C. Pacheco, S. K. Lahiri, M. D. Ernst, and T. Ball, “Feedbackdirected random test generation,” in ICSE, 2007.

手法概要 2 点検すべき failure を絞り込むクラスタリング手

法： Test Oracle として既存手法 linearizability[2] を採用して

いるので誤報が出る可能性がある 「似たような」バグレポートはたぶん、

全部誤報か全部本物のバグかだろう→バグレポートを下記２点によりクラスタリングする Failure 発生時に実行していたメソッド Failure の種類

評価では、 1 個の本物のバグに対して、数百個の誤報が出る→非実用的

クラスタリングの導入後では誤報は 3 ～ 4 個にまで減った

2012/8/30ICSE'12 勉強会10

[2] S. Burckhardt, C. Dern, M. Musuvathi, and R. Tan, “Line-Up: A complete and automatic linearizability checker,” in PLDI, 2010.

評価 6 件の OSS に含まれる 14 個の本物のバグで評

価 Groovy, JDK, JFreeChart, Apache Log4j,

Apache Lucene, Apache Pool

提案手法は、既存ランダム生成手法より、2 ～ 10 倍速くバグを見つけた

クラスタリング手法により、点検すべき failureの数を 4 ～ 8 倍減らした

未知のバグをさらに 3 件検出できた Apache Log4j, Apache Pool から

2012/8/30ICSE'12 勉強会11

On-Demand Test Suite ReductionDan Hao@Peking University

（株） NTT データ 技術開発本部　朱峰 錦司

背景（１／２） 従来のテストケース削減手法は、コードカバ

レッジを一定に保てれば減らしてよい、というものが多い

2012/8/30ICSE'12 勉強会13

裁判長！コードカバレッジを保っていても・・・バグ発見能力には疑いの余地があります！

ﾁ ｮ ｼ ｬ

異議あり！

背景（２／２）

2012/8/30ICSE'12 勉強会14

※元論文 P.2 から抜粋

20%以上の確率でバグ発見能力 6割減 20%以上の確率で

バグ発見能力 4割減

2 つの既存手法を試してみると…

目的 バグ発見能力を一定に保ちながらテストケース

を削減する手法の提案

2012/8/30ICSE'12 勉強会15

全てのテストケースの集合

以下を満たす最小のテストケースの集合・バグ発見能力の低下は l% 以下・（統計学に頼るので）信頼度は c%

テストケース削減によるバグ発見能力低下の実績データをもとに、この集合を線形計画法で発見す

る！

※元論文 P.4 から抜粋

手法概要（１／２）

2012/8/30ICSE'12 勉強会16

テストケース数を 4 から 2に減らすと、 99% の確率

でバグ発見能力は（最高で）

83.3% 減少してしまう

実績データの作成 既存のソフトウェアをもとに、テストケースの削減と

バグ発見能力の低下との相関を分析 信頼度は 90%,95%,99% の 3 パターンに決め打ち

手法概要（２／２）

2012/8/30ICSE'12 勉強会17

線形計画法の適用 2 種類のモデル式を提案

local constraints に基づく式

global constraints に基づく式

モデル式の簡易化（省略）

過去の実績では、テストケースを p_j 個から q 個に減らすとこ

れぐらい能力が落ちる

あるテストケースの部分集合において、 q 行目のソースコードをカバーするケースがもともと p_j 個あった状態から q 個に減少した際に…

全ての行個別で不等式が成り立たたないといけない

ソースコード全体で成り立

てばよい※元論文 P.5 から抜粋

※元論文 P.5 から抜粋

評価 3 つのシナリオで手法を評価

他手法との比較 テストケース削減効果は少ないが、バグ発見能力を維

持したい場合は非常に効果的

2012/8/30ICSE'12 勉強会18

対象 実績データ 適用対象 結果

1 8 つの C プログラム

1 つのプログラムの半分

プログラムの残り半分

全てのプログラムにおいて、 2つのモデル式の場合ともに、結果は妥当であった

2 1 つの Java プログラムの 3 リビジョン

前バージョン 後バージョン バージョン番号が近いほうがより結果は妥当であった

3 7 つの C プログラム

6 プログラム 残り 1 プログラム

global の場合のほうが削減効果は大きいが、 local の場合のほうがバグ発見能力が高い