国際会議で学んだ
  “Mutation testing”
          takehikom
          2013年2月
このファイルは,大学院ゼミ向けに2012年10月に作成した
内容をWeb公開にあたり改変したものです.


                                1 /10
国際会議 JCKBSE 2012
• 2012年8月23~26日,
  ロドス(ギリシャ)にて
• Joint Conference on Knowledge-
  Based Software Engineering
     2年おきに欧州で開催
      前回はカウナス(リトアニア)
     日本人参加者が多い
     出席して初日に座長(session chair)を務め,2日目に
      発表し,guided tourは寝過ごして参加できず


                                     2
Mutation testing
• 関心を持った経緯
    座長を担当した,最初の質疑が噛み合わず
     • 「ソースを改変して,なぜ良くなるの?」
    2つの論文とWebの情報を通じて,面白さを理解
     • M. Papadakis and N. Malevris: Killing mutants effectively - a
       search based approach, Proc. JCKBSE 2012, pp.217-226,
       doi:10.3323/978-1-61499-094-9-217.
     • R. Lacanienta, S. Takada, H. Tanno, X. Zhang and T. Hoshino:
       A mutation test based approach to evaluating test suites for
       Web applications, Proc. JCKBSE 2012, pp.227-236,
       doi:10.3323/978-1-61499-094-9-227.


                                                                       3
ソフトウェアテスト
                         Test suite


Test case 1   Test case 2             ...   Test case n

【 ソースコード 】
…
y = x + 1;
…


Output 1      Output 2                ...   Output n


                         出力が期待したものと異なる
                         ⇒ソースコードを修正                       4
Mutation testing
                        Test suite


Test case 1    Test case 2           ...       Test case n

【 Original 】           1か所だけ          【Mutant】                Mutantは
…                     改変 (mutant      …                      多数作られる
                        operator)                            ランダムでは
y = x + 1;                            y = x – 1;               ない
…                                     …


Output 11
 Output        Output 22
                Output               ...       Output nn
                                                Output

                        出力が異なる
                        ⇒mutantはkilled                           5
killできないmutant
• (あるテストケースで)出力が異なる ⇒ killed
• では,出力が同じなら?

• Unkilled mutant
     テストスイートを充実させれば,killedになる.
• Equivalent mutant
                              【 Original 】   【Mutant】
     どんなにテストスイートを            …              …
      充実させても,killedに          x = y;         x = y;
      ならない.                   if (z < y)     if (z < x)
     例(Lacanienta et al.):   …              …
                                                          6
スコアの算出                   unkilledかequivalentか
                                              の識別は…
                                       “one of biggest obstacles”
• 4種類のmutantの関係                             (ムズい!)




                       #(killed)
• Mutation score =
                   #(non-equivalent)
     Mutation score = 1
      ⇒ non-equivalentならばkilled
      ⇒ テストはコード全体を網羅している
     Mutation score < 1
      ⇒ non-equivalentかつunkilledなmutantがある
      ⇒ テストスイートを充実させる必要あり
                                                            7
Mutation testingから学んだこと
 • ソフトウェアの品質を向上させたい.


 • テストスイートが,ソースコードの
   すべてを網羅するようにしたい.


 • ソースコードを改変してテストする
   ことで,網羅率が算出できる.
           Mutantは,テストスイートを
           より良くさせる手段となるが,
           直接ソースコードを改善しない.    8
関連情報
• http://en.wikipedia.org/wiki/Mutation_testing
• http://www.simple-talk.com/dotnet/.net-
  tools/mutation-testing/
• http://d.hatena.ne.jp/takehikom/20120829/134625
  2399

• 画像の出典
     http://www.mofa.go.jp/mofaj/area/greece/
     http://en.wikipedia.org/wiki/Mutation

                                                    9
おしまい!
  10

Mutation Testing (Aug 2012)

  • 1.
    国際会議で学んだ “Mutationtesting” takehikom 2013年2月 このファイルは,大学院ゼミ向けに2012年10月に作成した 内容をWeb公開にあたり改変したものです. 1 /10
  • 2.
    国際会議 JCKBSE 2012 •2012年8月23~26日, ロドス(ギリシャ)にて • Joint Conference on Knowledge- Based Software Engineering  2年おきに欧州で開催 前回はカウナス(リトアニア)  日本人参加者が多い  出席して初日に座長(session chair)を務め,2日目に 発表し,guided tourは寝過ごして参加できず 2
  • 3.
    Mutation testing • 関心を持った経緯  座長を担当した,最初の質疑が噛み合わず • 「ソースを改変して,なぜ良くなるの?」  2つの論文とWebの情報を通じて,面白さを理解 • M. Papadakis and N. Malevris: Killing mutants effectively - a search based approach, Proc. JCKBSE 2012, pp.217-226, doi:10.3323/978-1-61499-094-9-217. • R. Lacanienta, S. Takada, H. Tanno, X. Zhang and T. Hoshino: A mutation test based approach to evaluating test suites for Web applications, Proc. JCKBSE 2012, pp.227-236, doi:10.3323/978-1-61499-094-9-227. 3
  • 4.
    ソフトウェアテスト Test suite Test case 1 Test case 2 ... Test case n 【 ソースコード 】 … y = x + 1; … Output 1 Output 2 ... Output n 出力が期待したものと異なる ⇒ソースコードを修正 4
  • 5.
    Mutation testing Test suite Test case 1 Test case 2 ... Test case n 【 Original 】 1か所だけ 【Mutant】 Mutantは … 改変 (mutant … 多数作られる operator) ランダムでは y = x + 1; y = x – 1; ない … … Output 11 Output Output 22 Output ... Output nn Output 出力が異なる ⇒mutantはkilled 5
  • 6.
    killできないmutant • (あるテストケースで)出力が異なる ⇒killed • では,出力が同じなら? • Unkilled mutant  テストスイートを充実させれば,killedになる. • Equivalent mutant 【 Original 】 【Mutant】  どんなにテストスイートを … … 充実させても,killedに x = y; x = y; ならない. if (z < y) if (z < x)  例(Lacanienta et al.): … … 6
  • 7.
    スコアの算出 unkilledかequivalentか の識別は… “one of biggest obstacles” • 4種類のmutantの関係 (ムズい!) #(killed) • Mutation score = #(non-equivalent)  Mutation score = 1 ⇒ non-equivalentならばkilled ⇒ テストはコード全体を網羅している  Mutation score < 1 ⇒ non-equivalentかつunkilledなmutantがある ⇒ テストスイートを充実させる必要あり 7
  • 8.
    Mutation testingから学んだこと •ソフトウェアの品質を向上させたい. • テストスイートが,ソースコードの すべてを網羅するようにしたい. • ソースコードを改変してテストする ことで,網羅率が算出できる. Mutantは,テストスイートを より良くさせる手段となるが, 直接ソースコードを改善しない. 8
  • 9.
    関連情報 • http://en.wikipedia.org/wiki/Mutation_testing • http://www.simple-talk.com/dotnet/.net- tools/mutation-testing/ • http://d.hatena.ne.jp/takehikom/20120829/134625 2399 • 画像の出典  http://www.mofa.go.jp/mofaj/area/greece/  http://en.wikipedia.org/wiki/Mutation 9
  • 10.