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 RiskDriven
Random併用
RiskDriven
TextDiversity
併用
略称 Rnd TD TC RDR RDD
手法概要ランダムな並び
替え
テストケースの
テキストの距離
を最大化
テストケースの
トピックに対す
る網羅率を最大
化
過去バージョン
でのバグ検出実
績多寡でテスト
ケースをクラス
タリング
クラスタ内はラ
ンダムでTCP
過去バージョン
でのバグ検出実
績多寡でテスト
ケースをクラス
タリング
クラスタ内は
TextDiversity
でTCP
TopicCoverageの手法概要
※対象論文のFig.1,Fig.2より引用

エンピリカル実験条件
• SUT：Mozilla Firefox, 計13バージョン
• Mozillaで使われる回帰テスト管理システムLitmusに対しWebク
ロールして，自然言語のテストケースと実行結果を取得
※対象論文のTable I.より引用
古典的開発
年1回リリース
RapidRelease開発
月1回リリース

種別ランダム ②多様性ベース ①網羅率ベース ③リスクベース
名称 Random TextDiversity TopicCoverage RiskDriven
Random併用
RiskDriven
TextDiversity
併用
古典的開発
(TR)
年1回リ
リース
RapidRelea
se開発(RR)
月1回リ
リース
手法間に顕著な差は見られない
③リスクベースが好成績
RQ1：古典的開発では①②③どれが最も効率的か？
→SUT依存，何とも言えない
RQ2：Rapid-Release開発では手法の優劣が異なるか？
→③リスクベースが効率良い
※APFDはTCP手法の評価で常
用される指標，100が最良
※対象論文のTable III. Table IV.より引用

所感
査読で評価されたと思われる点
• エンピリカル実験の題材が著名なプロジェクト
• テストケースやバグが全て実際のもの
• RapidReleaseかそうでないかで結果が大きく
変わる点が興味深い
• 結果を見てから魅力的なRQを設定したと思われる
論文は綿密に＆魅力的に
書きましょう

Using Fuzzy Logic & Symbolic Execution to
Prioritize 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.5
0.4
Fuzzy Logicを用いることで解に幅を持たせることができる

３．提案手法
ソースコ
ード
記号実行
生成された
テストケース
これをFuzzy Logicを
用いて優先度付する！

３．提案手法
入力
総テストケース数
→少ないほど優先度高
記号実行木の大きさ
（総記号数で評価）
→大きいほど優先度高
テストケースの長さ
（行数？）
→長いほど優先度高
外部と通信している
テストケース数の割合
→大きいほど優先度高
出力
テストケースの優先度

４．評価
 Symbolic state coverage（=とりうる記号の状態をどれだけ踏んだか）で評価
 ランダムにテストケースを抽出した場合と比較
提案手法
ランダム選択
Symbolicstatecoverage
選択したテストケース数の総テスト数との割合
 ランダム選択より少しではあるが優れた結果が出た。
 改善量が少なかった理由は、今回選択したモデルの記号実行木の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 A
failed!
Test case B
will fail!
(inferred)

1. 冗長なテストケースの推論はどれくらい有効
か？
テストケースの14～39％を冗長だと推論できた
2. 冗長なテストケースの推論はどれくらい正確
か？
不正なテスト結果が混入しない限り、正確であった
3. 冗長なテストケースとテスト経過時間の比率
は？
RQ

要約者の感想
テストケースの実施数を減らすことに対して、
机上の空論ではなく、実践的に向き合ってい
る
評価結果に対して率直に感想を述べている

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

More Related Content

What's hot (19)

Similar to ICST 2015 まるわかりDay! "Test Selection and Prioritization Track" (20)

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