ICST 2015 まるわかりDay! "Test Selection and Prioritization Track"

Copyright©2015 NTT corp. All Rights Reserved.

“Exploring Test Suite Diversification and Code Coverage in Multi-Objective Test Case Selection” の紹介著者： Debajyoti Mondal, Hadi Hemmati, Stephane Durocher( マニトバ大学，カナダ )

担当：チーム「えぬてーてー」NTT 研究所張暁晶

要約： Test Case Selection で，評価関数として「ソースコード網羅率」と「テストケース間距離」を組合せたら，よりバグ検出能力の高い手法になった

ICST 2015 まるわかり Day!Test Selection and Prioritization Track

2Copyright©2015 NTT corp. All Rights Reserved.

概要

• 背景• 既存の TestCase 群から「良い」部分集合を選ぶ

Test Case Selection は，コストや納期の制約がある際に有用な技術

• 「良さ」を測る尺度としては以下の２つある①ソースコード網羅率：古典的に用いられてきた尺度②多様性 (diversity) ：近年提案された尺度

• 目的下記リサーチクエスチョンに答えるためにエンピリカル実験RQ1 ：バグ検出能力の観点で，①と②はどちらが効率的か？RQ2 ：①と②は相補するものか？　　　（出力する部分集合はオーバーラップするものか）RQ3 ：①と②を組み合わせることで，　　　より良い尺度③を見い出せるか


背景知識

• TestCase Selection• 網羅率ベース：ソースコード網羅率を最大化

• ( 動的に ) テスト実行して通過したラインを数える• ( 静的に ) テストケースが呼び出す関数が全関数に占める割合を数える

• 多様性ベース：テストケース間の距離を最大化• 各関数を呼ぶか否かで 0 と 1 のベクトルで表現し，ベクトル間距離で計

算

• 最適化アルゴリズム• 単一目的最適化（例：網羅率最大化）

• Greedy ／ Additional-Greedy アルゴリズム，遺伝的アルゴリズム (GA) ，山登り法，焼き鈍し法，など

• 多目的最適化（例：網羅率最大化 & 実行時間最小化）

• パレートフロンティア／ α シェイプ• 既存ツール「 NSGA-II 」あり（ GA 使用）

TC1={1,1,0,1,0,0}TC2={1,0,1,1,0,1}例：ハミング距離 =3/6=0.5

※1: wikipedia より転載https://en.wikipedia.org/wiki/Pareto_efficiency

下線部は本研究で使用したものを指す

※1パレートフロンティア


エンピリカル実験　条件

• SUT ： OSS 5 種 , 計 16 バージョン• 埋め込みバグと本物のバグ両方含む• TestCase をメソッド呼出の列で表現

• 網羅率や多様性はメソッド呼出の粒度で定義• 実行時間は呼び出しているメソッドが全メソッド数に占める割合から見積る

• 実行時間のうちの最初の 1% ～ 20% までの結果を解析

※ 対象論文の Table II. より引用


エンピリカル実験　結果

RQ1 ：バグ検出能力の観点で，①と②はどちらが効率的か？⇒②がやや上だが， SUT にもよるRQ2 ：①と②は相補するものか？⇒①と②の解集合はほとんどオーバーラップしない　→組み合わせる価値あるかも？

① 網羅率最大化＆実行時間最小化（ 2 目的）

② 多様性最大化＆実行時間最小化（ 2 目的）

既存か新規か既存手法既存手法

利用する既存技術 Additional-Greedy アルゴリズム＆ NSGA-II併用

Additional-Greedy アルゴリズム＆ NSGA-II併用

解の集合を得る方法

パレートフロンティアを算出

α シェイプを算出

計算所要時間の例 10秒 2 分

バグ検出能力 16個中 3個のSUT では②より高い ( 最大 15%)

16個中 11個のSUT では①より高い ( 最大 28%)



① 網羅率最大化＆実行時間最小化（ 2 目的）

② 多様性最大化＆実行時間最小化（ 2 目的）

③ 網羅率最大化＆多様性最大化＆実行時間最小化（ 3 目的）

既存か新規か既存手法既存手法提案手法

利用する既存技術 Additional-Greedy アルゴリズム＆ NSGA-II併用

Additional-Greedy アルゴリズム＆ NSGA-II併用

NSGA-II

解の集合を得る方法

パレートフロンティアを算出

α シェイプを算出パレートフロンティアを算出

計算所要時間の例 10秒 2 分 5 分

バグ検出能力 16個中 3個のSUT では②より高い ( 最大 15%)

16個中 11個のSUT では①より高い ( 最大 28%)

① より高い ( 最大 50%)② より高い ( 最大 16%)

RQ3 ：①と②を組み合わせることで，より良い尺度③を見い出せるか⇒ YES．より高いバグ検出能力を達成できている．③ が①②両方に劣るケースはなかった．③ が②単独に劣るケースは SUT3 件で見られた．


所感

査読で評価されたと思われる点• Abstract がとても良く書けている

• 全体像が把握でき，読む気にさせられる• 前提知識や従来手法に対する丁寧な説明

• 分野外の人でも読みやすい• エンピリカル実験の有効性

• 妥当性の高い実験条件であることアピール• 結果の有意性もしっかり統計検定で評価


“Prioritizing Manual Test Cases in Traditional and Rapid Release Environments” の紹介著者： Hadi Hemmati, Zhihan Fang, Mika Mäntylä( マニトバ大学，カナダ／同済大学，中国／オウル大学，フィンランド )

要約：手動で実施されるシステムテストに対して複数の Test Case Prioritization 手法を適用し比較した結果， Rapid-Release開発では，過去バグ検出実績に基づくリスクベースの手法が最も効率良かった

ICST 2015 まるわかり Day!Test Selection and Prioritization Track

担当：チーム「えぬてーてー」NTT 研究所張暁晶


概要

• 背景• 効果高い順にテストを並び替える Test Case Prioritization(TCP)

は，時間制約がある場合に有用な技術．Agile や CI では変更のたびに全件テスト実行を推奨しているが，大規模システムでは 1日1回だとしても時間かかるため困難

• 従来のソースコード網羅率に基づく手法は，ブラックボックス的に手動実施されるシステムテストに不向き．網羅率を記録するためのcode Instrumentation も課題多し．

• 既存のヒューリスティクスをシステムテストに適用①網羅率ベース　②多様性ベース　③リスクベース

• 目的下記リサーチクエスチョンに答えるためにエンピリカル実験RQ1 ：古典的開発では①②③どれが最も効率的か？RQ2 ： Rapid-Release開発では手法の優劣が異なるか？


比較するヒューリスティクス

種別ランダム ② 多様性ベース

① 網羅率ベース

③ リスクベース

名称 Random TextDiversity TopicCoverage

RiskDrivenRandom 併用

RiskDrivenTextDiversity併用

略称 Rnd TD TC RDR RDD

手法概要ランダムな並び替え

テストケースのテキストの距離を最大化

テストケースのトピックに対する網羅率を最大化

過去バージョンでのバグ検出実績多寡でテストケースをクラスタリングクラスタ内はランダムでTCP

過去バージョンでのバグ検出実績多寡でテストケースをクラスタリングクラスタ内はTextDiversityで TCPTopicCoverage の手法概要

※ 対象論文の Fig.1,Fig.2 より引用


エンピリカル実験　条件

• SUT ： Mozilla Firefox, 計 13 バージョン• Mozilla で使われる回帰テスト管理システム Litmus に対し Web

クロールして，自然言語のテストケースと実行結果を取得

※ 対象論文の Table I. より引用

古典的開発年 1回リリース

RapidRelease開発

月 1回リリース



種別ランダム ② 多様性ベース

① 網羅率ベース

③ リスクベース

名称 Random TextDiversity TopicCoverage

RiskDrivenRandom 併用

RiskDrivenTextDiversity併用

古典的開発(TR)

年 1回リリース

RapidRelease開発(RR)

月 1回リリース

手法間に顕著な差は見られない

③ リスクベースが好成績

RQ1 ：古典的開発では①②③どれが最も効率的か？→SUT依存，何とも言えないRQ2 ： Rapid-Release開発では手法の優劣が異なるか？→③ リスクベースが効率良い

※APFD は TCP 手法の評価で常用される指標， 100 が最良

※ 対象論文の Table III. Table IV. より引用


所感

査読で評価されたと思われる点• エンピリカル実験の題材が著名なプロジェクト

• テストケースやバグが全て実際のもの• RapidRelease かそうでないかで結果が大きく変わる点が興味深い• 結果を見てから魅力的な RQ を設定したと思われる

論文は綿密に＆魅力的に書きましょう


Using Fuzzy Logic & Symbolic Execution toPrioritize UML-RT Test Cases

NTT　ソフトウェアイノベーションセンタ倉林　利行


１．序論

背景モデルベースのテストケース生成が多く行われている。

問題生成するテストケースが多すぎる！

提案Fuzzy Logic を用いたテストケース優先度付け手法


２． Fuzzy Logic とは何か？

例：結婚相手に求める条件

① 年収 1000万以上②身長 180cm 以上

「年収 1200万＆身長 175cm 」の男性は本当に結婚対象外なのか？

→Fuzzy Logic の登場


２． Fuzzy Logic とは何か

年収の度合い (万円 )0 1500750

身長の度合い (cm)150 200150

ルール１： IF ( 年収 is high) AND (身長 is high) THEN 結婚してもいい is highルール２： IF ( 年収 is middle) AND (身長 is middle) THEN 結婚してもいい is middleルール３： IF ( 年収 is low) AND (身長 is low) THEN 結婚してもいい is low

採点ルール１：年収 =0.6 high 　身長 =0.5 high → 　結婚してもいい =0.5 highルール２：年収 =0.4 middle 身長 =0.5 middle → 　結婚してもいい =0.4 middleルール３：年収 =0.0 low 　身長 =0.0 low → 　結婚してもいい =0.0 low→赤と緑の図形の重心を求める→ 「年収 1200万＆身長 175cm 」の男性と結婚してもいい度合いは 0.6ポイント

1.0 1.0

結婚してもいい度合い0 1.00.5

1.0

1200 175

0.50.4

Fuzzy Logic を用いることで解に幅を持たせることができる


３．提案手法

ソースコード

記号実行生成された

テストケース

これを Fuzzy Logic を用いて優先度付する！


３．提案手法

入力

総テストケース数→少ないほど優先度高

記号実行木の大きさ（総記号数で評価）→ 大きいほど優先度高

テストケースの長さ（行数？）→長いほど優先度高

外部と通信しているテストケース数の割合→ 大きいほど優先度高

出力

テストケースの優先度


４．評価

Symbolic state coverage （ = とりうる記号の状態をどれだけ踏んだか）で評価ランダムにテストケースを抽出した場合と比較

提案手法

ランダム選択

Sym

bolic state coverage

選択したテストケース数の総テスト数との割合

ランダム選択より少しではあるが優れた結果が出た。改善量が少なかった理由は、今回選択したモデルの記号実行木の symbolic state

の配置のバランスが良かった（＝ランダムでもある程度良い結果が得られる）ため。

現実のシステムはもっと複雑なためより良い結果が得られるのではないか。


５．所感

Fuzzy Logic を用いることで優先度付けという　あいまいな問題に対処する指針は面白いと感　じた。入力とルールを適切に調整すれば良い　結果が得られるかも。

ただし設定しなくてはいけない項目が多すぎ　る。入力のグラフ、入力と出力の関係性を決　めるルール…など。テスト対象によっても適　切な調整は変わってくると考えられるので、　入力とルールの調整方法の検討が今後の課題


“If A fails, can B still succeed?”Inferring dependency between test results in automotive system testing

要約者：ちーむえぬてーてー田端　啓一

要求仕様書の項目を構造化すれば、テストケースの実施削減が可能に！

1


背景

自動車のテストは大変

• テスト環境が大規模（ H/W, S/W ）• テストケースのセットアップが複雑で時間がかかる

無駄なテストケースを実施したくない

（例）「雨センサ」の単体テストに失敗した場合→ 「降雨時に天窓を閉める」テストも失敗する

論理的に結論が推論できるテストケースを見つけて実施を省きたい


この論文でやったこと

Vehicle Function

Sub Function

End Condition

Function Contribution

Trigger

Pre Condition

要求仕様を整理してテストケースの冗長性を推論

• 自然言語の要求仕様に親子関係と依存関係を付加した• テストケースと要求仕様が対応付け可能と仮定した• テストの経過から冗長なテストケースを推論した

Test case Afailed!

Test case Bwill fail!

(inferred)


1.冗長なテストケースの推論はどれくらい有効か？テストケースの 14 ～ 39％を冗長だと推論できた

2.冗長なテストケースの推論はどれくらい正確か？不正なテスト結果が混入しない限り、正確であった

3.冗長なテストケースとテスト経過時間の比率は？テストが進むほど、冗長なテストケースの数が増えたテストが進むほど、冗長なテストケースが得られにくくなったテストの初期に、未実施のテスト数が比較的大規模であるときに特に有効であると考えられる

RQ


要約者の感想

テストケースの実施数を減らすことに対して、机上の空論ではなく、実践的に向き合っている

評価結果に対して率直に感想を述べている

Technology

ICST 2015 まるわかりDay! "Test Selection and Prioritization Track"