SlideShare a Scribd company logo
1 of 36
Download to read offline
Automated Oracle Creation Support,
    or: How I Learned to Stop Worrying
    about Fault Propagation and Love
    Mutation Testing (ICSE2012)
    輪講用資料


        対象: コンピュータ科学専攻の修士・博士学生
             (ソフトウェア工学専攻とは限らない)
1
        発表時間: 25分


                             2012年 6月 28日
発表論文
“Automated Oracle Creation Support, or: How I Learned
to Stop Worrying about Fault Propagation and Love
Mutation Testing”
 - テストオラクル(後述)の選択を自動化する
By. Matt Staats (Korea Advanced Institute of Science & Technology)
    Gregory Gay, Mats P. E. Heimdahl (University of Minnesota)

34th International Conference on Software Engineering
(ICSE 2012, Acceptance ratio: 21%)

                                                                     2
テストとは
テスト:実装の正しさを,実行して確かめること

         // x2 + |x| + 5を求める
X=3とする   int calc(int x) {
           int val = x * x;
           if (x > 0) {
             val += x;
           } else {
             val -= x;
           }
           return val + 5;
         }
         正しいかわからないプログラム
                               3
テストオラクルとは
                                       オラクル
オラクル:正しい振舞いを決めるもの
                                     期待値オラクル
         // x2 + |x| + 5を求める
X=3とする   int calc(int x) {        ここでのvalは9である
           int val = x * x;
           if (x > 0) {               ↑本研究の対象
             val += x;
           } else {
                                  この分岐は実行されない
             val -= x;
           }
           return val + 5;        出力は5以上である
         }

出力変数だけでなく,内部変数もオラクルに利用することで,                      4

テストの結果が改善できる (Staats, 2011)
論文概要
問題:
 オラクルの選択は重要だが,現状は出力変数のみ着目

 全ての内部変数に期待値を設定するのはコスト大



目的: テストオラクルの選択を自動化したい

解法: ミューテーションテストを応用して,各変数をランク付け,
    ランク上位の変数をテストオラクルとして利用

結果: 4つの実アプリケーションに適用
   標準的なやり方と比べ最高145.8%の性能向上        5
提案手法の使われ方
             提案手法

     プログラム              ミュータント
              (1)ミュータ
              ント生成
                            (2)テストを実行
     テスト入力                  変数の有効性を調べる

                        変数の有効性
既存研究が                    ランキング
多く存在                        (3)ランキングの上位から,
                               - 少ない変数
                            必要そうな変数を選択
                             - 欠陥発見に役立つ
                    オラクルの変数集合
                                 {x, y,…}

 テスト実行者 入力に応じて,                        6

        変数に期待する値を設定 期待値オラクルの集合 {x=3, y=5,…}
前提知識:ミューテーションテスト(1/2)
テストの欠陥発見能力を知りたい
テストの例) 2乗差を求めるメソッドdoubledDiff(a, b)のテスト
テスト1
 assertEqual(
    1, doubledDiff(1, 0));
                               成功
テスト2                                int doubledDiff(int a, int b) {
 assertEqual(                 成功       int c = a + b;
    12, doubledDiff(4, 2));            int d = a – b;
                                       return c * d; }
テスト3
                               成功
 assertEqual(
    5, doubledDiff(3, 2));
                                                                      7

                              どのテストが「良い」だろうか?
前提知識:ミューテーションテスト(2/2)
ミュータント:プログラムの一部を変換して欠陥を埋め込んだもの

テスト1
                                        ミュータント1                 欠陥
 assertEqual(                            int doubledDiff(int a, int b) {
                                   成功
    1, doubledDiff(1, 0));                  int c = a - b;
                              成功            int d = a – b;
テスト2                                        return c * d; }
 assertEqual(                 失敗
                                        ミュータント2
    12, doubledDiff(4, 2));   失敗
                                         int doubledDiff(int a, int b) {
テスト3                                        int c = a + b;
                              失敗            int d = a – b;
 assertEqual(                      成功       return c / d; }
    5, doubledDiff(3, 2));
                                                           欠陥
                                                                           8
テスト2が良い(欠陥発見能力が高い)とわかる
提案手法の使われ方
           提案手法

   プログラム              ミュータント
            (1)ミュータ
            ント生成
                          (2)テストを実行
   テスト入力                  変数の有効性を調べる

                      変数の有効性
                       ランキング
                          (3)ランキングの上位から,
                          必要そうな変数を選択


                  オラクルの変数集合

テスト実行者                                     9
提案手法概観
           提案手法

   プログラム              ミュータント
            (1)ミュータ
            ント生成
                          (2)テストを実行
   テスト入力                  変数の有効性を調べる

                      変数の有効性
                       ランキング
                          (3)ランキングの上位から,
                          変数を選択


                  オラクルの変数集合

テスト実行者                                 10
1. ミュータントの生成
 一般的なミューテーションテスト[1]の手法通り

  演算子(+, -, *, /, !, ==, など)の置換
  Boolean値の反転

  定数の置換

 など                                                               演算子の置換

     int doubledDiff(int a, int b) {       int doubledDiff(int a, int b) {
        int c = a + b;                        int c = a - b;
        int d = a – b;                        int d = a – b;
        return c * d; }                       return c * d; }
            プログラム                                  ミュータント
                                                                             11
 [1] An analysis and survey of the development of mutation testing,
 Yue Jia, Mark Harman(2010, IEEE Software Engineering)
2. 変数へのランク付け(1/3)
 各ミュータントに対してテストを実行し,
 変数の値を毎ステップ監視

          プログラム     例)ある時点での変数の値
                                   x      y     ret

         ミュータント1   プログラム           5      10    30
 テスト               ミュータント1         -9     10    -27
 入力                ミュータント2         6      10    30
         ミュータント2
                   ミュータント3         5      -8    30
         ミュータント3   ミュータント4         -4     10    -20

         ミュータント4           3kill        1kill   2kill
                                                        12

元のプログラムと違った値を示す変数はバグ検出に役立ちそう
2. 変数へのランク付け(2/3)
killできるミュータント数順に変数を並べれば良いとも限らない
 ← 変数間に依存関係がある場合うまくいかない
 例) retでkill出来るミュータントは必ずxでkillできる


                                          x      y     ret
なるべく少ない個数の変数で,
                          プログラム           5      10    30
すべてのミュータントをkillしたい
                          ミュータント1         -9     10    -27
                          ミュータント2         6      10    30
                          ミュータント3         5      -8    30
集合被覆問題として解ける              ミュータント4         -4     10    -20
貪欲法による近似解法[2]が有名                                               13
                                  3kill        1kill   2kill
2. 変数へのランク付け(3/3)
貪欲法による変数へのランク付け
 アルゴリズム:
   1. RankedVariableを空集合で初期化
   2. UnkilledMutantsにすべてのミュータントを代入
   3. UnkilledMutants中のmutantを最も多くkillできる
   変数vを選択し,RankedVariableに加える
   4. UnkilledMutantsが空になるまで,3を繰り返す


 RankedVariableに追加された順に,ランクが高いとする.

                                            14
3. 適切なオラクル数の見積り(1/2)

何個の変数をオラクルに使うべきか?

多くの変数を使う
   ○ 欠陥発見に役立つ
   × 人間が期待値を設定するのが大変

最適な個数はわからない → 選択の基準を提供



                         15
3. 適切なオラクル数の見積り(2/2)
Fault finding effectiveness
        |その変数集合で 𝑘𝑖𝑙𝑙できるミュータントの数|
   :=
                 |すべてのミュータントの数|


オラクルに使う変数の数を1つ増やすと,effectivenessは上昇する
その上昇度合が閾値以下になると,十分なオラクル数だと言える

                     オラクルサイズとeffectivenessの関係(イメージ)
                   100
   effectiveness




                    80
                    60
                    40
                    20
                                                           16
                     0
                         0    5       10      15 オラクルサイズ
研究課題(RESEARCH QUESTION)
 RQ1:
   提案手法は,オラクルデータの選択に関して,
 標準のやり方と比べて実用上優れているだろうか?
 RQ2:
    ミューテーションベースの手法は潜在的にどれ
 だけの最大効率を持つだろうか.また,実用上の効率
 と最大効率はどの程度異なるだろうか?
 RQ3:
   テストに対する入力の違いはどの程度,提案手
 法の効率に影響するだろうか?


                          17
実験設定(1/2)
テスト対象:
航空機器の実アプリケーション
Simulink(組み込みシステム向けの,モデル駆動開発ツール)
で作られたモデルから自動生成されたLustreコード
 DWM1, 2: 商用コクピットシステムのウィンドウマネージャの一部
 Vertmax, Latctl: フライトガイダンスシステムの一部


テストの入力(RQ3):
カバレッジ基準を満たすテストケースを自動生成する既存手法[4]
を利用,以下の2つのカバレッジに対してそれぞれ10通りのテストス
イートを生成
ブランチカバレッジ                                  18
MC/DC(Modified Condition/DeCision)カバレッジ[3]
実験設定(2/2)
ミュータント:
250のミュータントを生成し,半分を訓練用,残りを評価用

オラクル生成方法(RQ1, RQ2):
Random: 出力変数および内部変数からランダムにn個選択
Output-base: 出力変数をまずオラクルに加え,
              その後,内部変数からランダムに選択
Mutation-based: 提案手法
Idealized Mutation-based:
   評価用のデータに提案手法を適用
   生じるバグをあらかじめ知っている場合に相当する        19
結果:4手法の性能比較




                                    |その変数集合で 𝑘𝑖𝑙𝑙できるミュータントの数|
縦軸: Fault finding effectiveness =
                                        |すべてのミュータントの数|          20
横軸: オラクル集合の変数の数
考察:   提案手法のOUTPUT-BASEに対する性能改善率

RQ1: 提案手法は,オラクルデータの選択に関して,標準のや
り方と比べて実用上すぐれているだろうか?
- 最大145.8%の性能向上,概して10-30%程度性能向上
- オラクルサイズ < 出力変数総数のとき,提案手法が優れており,
オラクルサイズ == 出力変数総数のとき同じような性能を示し,
その後提案手法が優位性を示す傾向




                                    21
      10%以上の性能向上
考察:   提案手法のOUTPUT-BASEに対する性能改善率

RQ1: 提案手法は,オラクルデータの選択に関して,標準のや
り方と比べて実用上すぐれているだろうか?
- 最大145.8%の性能向上,概して10-30%程度性能向上
- オラクルサイズ < 出力変数総数のとき,提案手法が優れており,
オラクルサイズ == 出力変数総数のとき同じような性能を示し,
その後提案手法が優位性を示す傾向
          → 変数に優先付けをすることは役立つだろう




                                    22
結果と考察: 理想的な場合の提案手法への性能改善率
 RQ2:ミューテーションベースの手法は潜在的にどれだけの最
 大効率を持つだろうか.また,実用上の効率と最大効率はどの
 程度異なるだろうか?
 理想的な場合のほうが高い欠陥発見能力
 しかし,性能差はさほどではない




                      すべて正の値
                               23
       多くの値が20%以下
考察:入力による違い
RQ3: テストに対する入力の違いはどの程度,提案手法の効率
に影響するだろうか? → 左右のグラフはどう違うか,ということ
80            100




MC/DCカバレッジの方が,欠陥発見能力が概ね高かった

一方で,グラフの形は概ね似ている              24
→入力による影響を受けない一般的な傾向と推測できる
まとめ
ミューテーションテストの考えを利用
テストオラクル,特に変数の期待値オラクルを対象に
有用な変数集合を自動で選択する手法を提案

実アプリケーション(欠陥は人工)に対して評価
提案手法は,ナイーブな選択の仕方に比べて
最大で145.8%,概して10-30%程度の性能向上



                             25
私見(1/2)
○「内部変数も使えば欠陥発見能力を高く出来る」という,当たり
前っぽいけどあまり研究されてなかった(らしい)ところをちゃんと
実験してそれらしい結果をまとめているのはすごい

×比較対象(Output-base)が単純すぎる.内部変数の選択はラ
ンダムなので,提案手法が勝ちそうなのはあまりに明らか
開発者のヒューリスティクスによる選択との比較があると良かった

× RQ2の考察が乱暴

他のドメインに試すとどうなるのか気になる
                                26
私見(2/2)
 △著者らの述べる,提案手法の使われ方がいまいちわからな
 かった.すでに実装があるなら,変数の期待値は機械的に設
 定できるのでは.

 ×人間がオラクルを設定するならば,内部変数の値を設定す
 るのは,出力変数の値と比べて困難なのではないか.

 △実験の詳細が不明瞭,対象のコード例や,行数,変数の数
 などを示して欲しい
 △テストの集合に対してオラクルになる変数集合がある,
 という問題設定がよくわからない.テストメソッドに対してオラク
 ルが存在するのが普通な気がする.             27
以下,参考資料
28
集合被覆問題(SET COVER PROBLEM)
ある集合Uと,その部分集合の族 F = {Si} (i = 1, …, n)
U = S1∪…∪Snのもと,Fの部分集合Cで,
∀e∈U, e∈C
かつ|C|が最小となるようなものを求める問題

最適解を求める問題はNP困難
※族とは,集合を要素にもつ集合 ex. {{}, {1, 2}}

貪欲法による解法がよく知られている.
まだ覆われていない要素を一番多く含むSiを選ぶという
作業を繰り返せば良い.                              29
貪欲法の近似率はln|U| + 1
2. 変数へのランク付け(2/3)補足
各変数vに対して,vがkillできるミュータントの集合をMvとする
M = M1∪…∪Mnとする
M1,…Mnからなるべく少ない個数の集合を選び,
その和集合Msubが
∀m∈Mについて,m∈Msubとなってほしい
→集合被覆問題
   Mx = {m1, m2, m4}                x    y    ret
   My = {m3}              プログラム     5    10   30
   Mret = {m1, m4}        ミュータント1   -9   10   -27
                          ミュータント2   6    10   30
                                                    30
   M = {m1, m2, m3, m4}   ミュータント3   5    -8   30
                          ミュータント4   -4   10   -20
   Mx とMyを選ぶと良い
MC/DC カバレッジ
用語定義:
 if ( (a == b) && (c == d) || (e == f) ) then
                          condition      decision


MC/DCカバレッジを満たすとは,以下の1~3が成立すること
1. プログラムのすべてのentry/exit点が少なくとも一度は実行さ
   れている
2. すべてのconditionが取りうる値を少なくとも一度はとっている

3. それぞれのconditionが,自身を含むdecisionに独立に影響
   することを示されている

3を確かめることにより,decisionも網羅できるので,                       31

ブランチカバレッジ(すべての分岐先を実行)より強い制約
結果(1/2)




          32
結果(2/2)




          33
参考文献
ミューテーションテスト
[1] An analysis and survey of the development of mutation testing,
Yue Jia, Mark Harman(2010, IEEE Software Engineering)
がとても詳しい.2010出版で,既に120披引用
マシンパワーの増加もあって,最近流行っている?

集合被覆問題の貪欲法による解法
[2] A Greedy Heuristic for the Set-Covering Problem
V. CHVATAL(1979, Mathematics of Operations Research)
有名な解法なので,ぐぐると日本語資料もたくさんある                                   34
参考文献
MC/DCカバレッジ
[3] DO-178B, Software Considerations in Airborne Systems and
Equipment Certification
RTCA(Requirements and Technical Concepts for Aviation ), 1992
厳格なテストを必要とした航空業界の人々が提案

構造カバレッジメトリクスを満たすための,
モデル検査器を用いたテストケース自動生成
[4] Coverage Based Test-Case Generation using Model Checkers
Sanjai Rayaduragam, Mats P.E. Heimdahl, 2001,
                                                          35
IEEE Int’l Conf. on Engineering of Computer Based Systems
著者(MATT STAATS)による関連研究

[5] “Programs, tests, and oracles: the foundations of
testing revisited” Matt Staats, Michael W. Whalen,
Mats P. E. Heimdahl (ICSE 2011, Distinguished Paper)
- テストオラクルも含めてテスティングの枠組みを再考しよう!
[6] “Better testing through oracle selection” Matt
Staats, Michael W. Whalen, Mats P. E. Heimdahl
(ICSE 2011(New Ideas and Emerging Results Track))
 - テストオラクルの選択でテストの欠陥発見能力が変わること
を調べたよ!

                                                       36
発表論文は,上記2つの論文を元にしたもの

More Related Content

Similar to 「Automated Oracle Creation Support, or: How I Learned to Stop Worrying about Fault Propagation and Love Mutation Testing」 slide for lab seminor (Japanese)

Tokyor14 - R言語でユニットテスト
Tokyor14 - R言語でユニットテストTokyor14 - R言語でユニットテスト
Tokyor14 - R言語でユニットテスト
Yohei Sato
 
Effective java 勉強会
Effective java 勉強会Effective java 勉強会
Effective java 勉強会
Takinami Kei
 
Source monitorと複雑度のはなし
Source monitorと複雑度のはなしSource monitorと複雑度のはなし
Source monitorと複雑度のはなし
aomori ringo
 

Similar to 「Automated Oracle Creation Support, or: How I Learned to Stop Worrying about Fault Propagation and Love Mutation Testing」 slide for lab seminor (Japanese) (20)

Junit4
Junit4Junit4
Junit4
 
Tokyor14 - R言語でユニットテスト
Tokyor14 - R言語でユニットテストTokyor14 - R言語でユニットテスト
Tokyor14 - R言語でユニットテスト
 
第2回DARM勉強会
第2回DARM勉強会第2回DARM勉強会
第2回DARM勉強会
 
Mutation Testing (Aug 2012)
Mutation Testing (Aug 2012)Mutation Testing (Aug 2012)
Mutation Testing (Aug 2012)
 
C# から java へのプログラム移植で体験したtddの効果は?
C# から java へのプログラム移植で体験したtddの効果は?C# から java へのプログラム移植で体験したtddの効果は?
C# から java へのプログラム移植で体験したtddの効果は?
 
Enshu8
Enshu8Enshu8
Enshu8
 
ソフトウェア工学2023 11 テスト
ソフトウェア工学2023 11 テストソフトウェア工学2023 11 テスト
ソフトウェア工学2023 11 テスト
 
Gura プログラミング言語の紹介
Gura プログラミング言語の紹介Gura プログラミング言語の紹介
Gura プログラミング言語の紹介
 
エクストリームエンジニア4
エクストリームエンジニア4エクストリームエンジニア4
エクストリームエンジニア4
 
深層学習①
深層学習①深層学習①
深層学習①
 
Code complete ch22_developper_test
Code complete ch22_developper_testCode complete ch22_developper_test
Code complete ch22_developper_test
 
タダで始めるテストファースト入門 ~ C# Express + NUnit
タダで始めるテストファースト入門 ~ C# Express + NUnitタダで始めるテストファースト入門 ~ C# Express + NUnit
タダで始めるテストファースト入門 ~ C# Express + NUnit
 
Akka Unit Testing
Akka Unit TestingAkka Unit Testing
Akka Unit Testing
 
Effective java 勉強会
Effective java 勉強会Effective java 勉強会
Effective java 勉強会
 
wankuma #28
wankuma #28wankuma #28
wankuma #28
 
レポート1
レポート1レポート1
レポート1
 
Java Puzzlers JJUG CCC 2016
Java Puzzlers JJUG CCC 2016Java Puzzlers JJUG CCC 2016
Java Puzzlers JJUG CCC 2016
 
Source monitorと複雑度のはなし
Source monitorと複雑度のはなしSource monitorと複雑度のはなし
Source monitorと複雑度のはなし
 
debug_profile.pdf
debug_profile.pdfdebug_profile.pdf
debug_profile.pdf
 
ji-5. 繰り返し計算
ji-5. 繰り返し計算ji-5. 繰り返し計算
ji-5. 繰り返し計算
 

More from nkazuki

More from nkazuki (10)

AngularJSを浅めに紹介します
AngularJSを浅めに紹介しますAngularJSを浅めに紹介します
AngularJSを浅めに紹介します
 
X-PERT: Accurate Identification of Cross-Browser Issues in Web Applications (...
X-PERT: Accurate Identification of Cross-Browser Issues in Web Applications (...X-PERT: Accurate Identification of Cross-Browser Issues in Web Applications (...
X-PERT: Accurate Identification of Cross-Browser Issues in Web Applications (...
 
はじめてのAIプログラミング 5章: 知識表現
はじめてのAIプログラミング 5章: 知識表現はじめてのAIプログラミング 5章: 知識表現
はじめてのAIプログラミング 5章: 知識表現
 
Mutation Analysis for JavaScript Web Applicaiton Testing SEKE2013
Mutation Analysis for JavaScript Web Applicaiton Testing  SEKE2013Mutation Analysis for JavaScript Web Applicaiton Testing  SEKE2013
Mutation Analysis for JavaScript Web Applicaiton Testing SEKE2013
 
Swarm Testing (ISSTA 2012) 輪講会用資料
Swarm Testing (ISSTA 2012) 輪講会用資料Swarm Testing (ISSTA 2012) 輪講会用資料
Swarm Testing (ISSTA 2012) 輪講会用資料
 
B4からM1までの間にやってきた研究について
B4からM1までの間にやってきた研究についてB4からM1までの間にやってきた研究について
B4からM1までの間にやってきた研究について
 
A sequential recommendation approach for interactive personalized story gener...
A sequential recommendation approach for interactive personalized story gener...A sequential recommendation approach for interactive personalized story gener...
A sequential recommendation approach for interactive personalized story gener...
 
Reducing Confounding Bias in Predicate-Level Statistical Debugging Metrics 4分説明用
Reducing Confounding Bias in Predicate-Level Statistical Debugging Metrics 4分説明用Reducing Confounding Bias in Predicate-Level Statistical Debugging Metrics 4分説明用
Reducing Confounding Bias in Predicate-Level Statistical Debugging Metrics 4分説明用
 
Supporting View Transition Design of Smartphone Applications Using Web Templ...
Supporting View Transition Design of Smartphone Applications Using  Web Templ...Supporting View Transition Design of Smartphone Applications Using  Web Templ...
Supporting View Transition Design of Smartphone Applications Using Web Templ...
 
AIChallange発表資料
AIChallange発表資料AIChallange発表資料
AIChallange発表資料
 

Recently uploaded

Recently uploaded (7)

LoRaWANスマート距離検出センサー DS20L カタログ LiDARデバイス
LoRaWANスマート距離検出センサー  DS20L  カタログ  LiDARデバイスLoRaWANスマート距離検出センサー  DS20L  カタログ  LiDARデバイス
LoRaWANスマート距離検出センサー DS20L カタログ LiDARデバイス
 
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアルLoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
 
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
 
新人研修 後半 2024/04/26の勉強会で発表されたものです。
新人研修 後半        2024/04/26の勉強会で発表されたものです。新人研修 後半        2024/04/26の勉強会で発表されたものです。
新人研修 後半 2024/04/26の勉強会で発表されたものです。
 
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)
 
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
 
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
 

「Automated Oracle Creation Support, or: How I Learned to Stop Worrying about Fault Propagation and Love Mutation Testing」 slide for lab seminor (Japanese)