突然変異検査

ミューテーション テスト(またはミューテーション分析、プログラム ミューテーション) は、新しいソフトウェア テストを設計し、既存のソフトウェア テストの品質を評価するために使用されます。ミューテーション テストでは、プログラムを少しずつ変更します。^{[1]ミューテーションされた各バージョンは}ミュータントと呼ばれ、テストでは、元のバージョンの動作がミュータントと異なるようにすることで、ミュータントを検出して拒否します。これをミュータントの削除と呼びます。テスト スイートは、削除したミュータントの割合で測定されます。新しいテストを設計して、追加のミュータントを削除することもできます。ミュータントは、一般的なプログラミング エラー (間違った演算子や変数名の使用など) を模倣するか、価値のあるテスト (各式をゼロで割るなど) の作成を強制する、明確に定義されたミューテーション演算子に基づいています。その目的は、テスターが効果的なテストを開発したり、プログラムに使用されるテスト データや、実行中にほとんどまたはまったくアクセスされないコード セクションの弱点を見つけたりするのを支援することです。ミューテーション テストは、ホワイト ボックス テストの一種です。^{[2] [3]}

この記事の大部分は、プログラムが変更される「プログラム変異」についてです。変異分析のより一般的な定義は、構文構造に定義された明確に定義されたルールを使用して、ソフトウェア成果物に体系的な変更を加えることです。^[4]変異分析は他の問題にも適用されていますが、通常はテストに適用されます。したがって、変異テストは、変異分析を使用して新しいソフトウェアテストを設計するか、既存のソフトウェアテストを評価することと定義されます。^[4]したがって、変異分析とテストは、設計モデル、仕様、データベース、テスト、XML、およびその他の種類のソフトウェア成果物に適用できますが、最も一般的なのはプログラム変異です。^[5]

テストを作成して、特定のソフトウェア システムの実装の正しさを検証することはできますが、テストの作成では、テストが正しく、実装の元となった要件を十分にカバーしているかどうかという疑問が残ります。^{[6] (この技術的な問題自体が、「誰}が警備員を守るのか?」というより深い哲学的問題の一例です。) ミューテーション テストの背後にある考え方は、ミュータントが導入されると、通常はプログラムの機能にバグが発生し、テストでそのバグを見つける必要があるというものです。このようにして、テストがテストされます。ミュータントがテスト スイートで検出されない場合、通常はテスト スイートがミュータントによって表される障害を特定できないことを示しますが、ミュータントが障害を導入していないこと、つまりミュータントが機能に影響しない有効な変更であることも示しています。ミュータントが有効になる (一般的な) 方法の 1 つは、変更されたコードが決して実行されない「デッド コード」である場合です。

ミューテーション テストを大規模に機能させるには、通常、多数のミュータントを導入し、非常に多くのプログラムのコピーをコンパイルして実行する必要があります。ミューテーション テストのコストの問題により、ソフトウェア テストの方法としてのミューテーション テストの実用性は低下していました。しかし、オブジェクト指向プログラミング言語とユニット テストフレームワークの使用が増えたことにより、アプリケーションの個々の部分をテストするミューテーション テスト ツールが開発されました。

突然変異テストの目的は複数あります。

• 十分にテストされていないコード部分（ミュータントが削除されないコード部分）を特定する^[1]
• 弱いテスト（突然変異体を殺さないテスト）を特定する^[7]
• 突然変異スコアを計算します。^[4]突然変異スコアは、殺された突然変異体の数 / 突然変異体の総数です。
• プログラムにおけるエラー伝播と状態感染について学ぶ

突然変異テストは、もともと1971年に学生だったリチャード・リプトンによって提案され、^[8]デミロ、リプトン、セイワードによって最初に開発され、公開されました。^[1]突然変異テストツールの最初の実装は、1980年にイェール大学のティモシー・バッドによる博士論文（「突然変異分析」と題された）の一部として行われました。^[9]

最近、膨大な計算能力が利用できるようになったことにより、コンピュータサイエンスコミュニティ内で突然変異分析が再び注目され、オブジェクト指向プログラミング言語やXML、SMV、有限状態マシンなどの非手続き型言語に突然変異テストを適用する方法を定義する作業が行われています。

2004 年、Certess Inc. (現在はSynopsysの一部) という会社が、多くの原則をハードウェア検証ドメインに拡張しました。突然変異解析では、生成された出力の違いを検出することだけが想定されていますが、Certess は、テストベンチのチェッカーが実際に違いを検出することを検証することでこれを拡張します。この拡張は、検証の 3 つの段階、つまりアクティベーション、伝播、検出がすべて評価されることを意味します。彼らはこれを機能認定と呼びました。

ファジングは、ミューテーション テストの特殊なケースと考えることができます。ファジングでは、通信インターフェイス内 (ソフトウェア インスタンス内とインスタンス間の両方) で交換されるメッセージまたはデータがミューテーションされ、データ処理の失敗や差異を検出します。Codenomicon ^[10] (2001) とMu Dynamics (2005)は、ファジングの概念を、プロトコル実装を徹底的にテストするためのモニターを備えた、完全にステートフルなミューテーション テスト プラットフォームへと進化させました。

突然変異テストは 2 つの仮説に基づいています。1 つ目は有能なプログラマー仮説です。この仮説は、有能なプログラマーはほぼ正しいプログラムを書くというものです。^[1]「ほぼ正しい」というのは、構文ではなく動作に基づくものです。2 つ目の仮説は結合効果と呼ばれます。結合効果は、単純な障害が連鎖したり結合したりして、他の新たな障害を形成する可能性があると主張しています。^{[11] [12]}

高次突然変異体では微妙かつ重要な欠陥も明らかになり、それがカップリング効果をさらに裏付けています。^{[13] [14] [7] [15] [16]}高次突然変異体は、複数の突然変異を持つ突然変異体を作成することによって可能になります。

ミューテーション テストは、ミューテーション演算子のセットを選択し、ソース コードの適用可能な部分ごとに 1 つずつソース プログラムに適用することによって行われます。プログラムに 1 つのミューテーション演算子を適用した結果は、ミュータントと呼ばれます。テスト スイートが変更を検出できる場合 (つまり、テストの 1 つが失敗する)、ミュータントは 強制終了 されたとみなされます。

たとえば、次の C++ コード フラグメントを考えてみましょう。

もしa && bならc = 1 ; }、そうでなければc = 0 ; }    
      
  
      

条件変異演算子は&&を に置き換え||、次の変異体を生成します。

もしa || bであればc = 1であり、そうでなければc = 0であり    
      
  
      

さて、この変異体を殺すためのテストでは、次の 3 つの条件を満たす必要があります。

1. テストは変更されたステートメントに到達する必要があります。
2. テスト入力データは、ミュータントと元のプログラムに異なるプログラム状態を引き起こすことによって、プログラム状態に影響を与える必要があります。たとえば、 と を使用したテストではa = 1、b = 0これが実行されます。
3. 不正なプログラム状態 (「c」の値) はプログラムの出力に伝播され、テストによってチェックされる必要があります。

これらの条件は総称してRIPモデルと呼ばれています。^[8]

弱いミューテーション テスト(または弱いミューテーション カバレッジ) では、最初の条件と 2 番目の条件のみが満たされている必要があります。強いミューテーション テストでは、 3 つの条件すべてが満たされている必要があります。強いミューテーションは、テスト スイートが実際に問題を検出できることを保証するため、より強力です。弱いミューテーションは、コード カバレッジメソッドと密接に関連しています。テスト スイートが弱いミューテーション テストを満たしていることを確認するために必要な計算能力は、強いミューテーション テストよりもはるかに少なくなります。

ただし、このミュータントを強制終了できるテスト ケースが見つからない場合もあります。結果のプログラムは、動作的には元のプログラムと同等です。このようなミュータントは、等価ミュータントと呼ばれます。

等価ミュータントの検出は、突然変異テストの実用化における最大の障害の1つです。ミュータントが等価かどうかを確認するために必要な労力は、小さなプログラムであっても非常に大きくなる可能性があります。^[17] 2014年に行われた等価ミュータント問題を克服するための幅広いアプローチに関する体系的な文献レビュー^{[18]では、} 17の関連技術（22の記事）と、検出（DEM）、提案（SEM）、および等価ミュータント生成の回避（AEMG）の3つのカテゴリが特定されました。実験では、高次突然変異全般、特にJudyDiffOp戦略が等価ミュータント問題に対する有望なアプローチであることが示されました。

同等のミュータントに加えて、別のミュータントと同じソース コードの場所に存在し、他のミュータントによって「包摂」されていると言われる、包摂されたミュータントがあります。包摂されたミュータントはミューテーション テスト ツールには表示されず、カバレッジ メトリックには寄与しません。たとえば、A と B という 2 つのミュータントがあり、どちらも同じ方法でコード行を変更するとします。ミュータント A が最初にテストされ、結果はコードが正しく動作していないというものです。次にミュータント B がテストされ、結果はミュータント A と同じになります。この場合、ミュータント B のテスト結果がミュータント A のテスト結果と同じであるため、ミュータント B はミュータント A に包摂されていると見なされます。したがって、ミュータント B はテストする必要はなく、結果はミュータント A と同じになります。

プログラムの構文を変更するには、突然変異演算子がソースコードの一部を置き換えるガイドラインとして機能します。突然変異はこれらの演算子に依存するため、研究者はJavaなどのさまざまなプログラミング言語に対応するために突然変異演算子のコレクションを作成しました。これらの突然変異演算子の有効性は、突然変異テストにおいて重要な役割を果たします。^[19]

研究者たちは多くの変異演算子を研究してきました。命令型言語の変異演算子の例をいくつか示します。

• ステートメントの削除
• 文の重複または挿入、例goto fail;^[20]
• ブール部分式のtrueとfalseへの置き換え
• いくつかの算術演算を他の演算に置き換える。例：+、*、-/
• いくつかのブール関係を他のブール関係に置き換える。例えば、、>および>===<=
• 同じスコープ内の他の変数との置換（変数の型は互換性がある必要があります）
• メソッド本体を削除します。^[21]

これらの突然変異演算子は、従来の突然変異演算子とも呼ばれます。オブジェクト指向言語用^[22] 、並行構造用^[23] 、コンテナのような複雑なオブジェクト用^[24]などの 突然変異演算子もあります。

コンテナの演算子はクラスレベルのミューテーション演算子と呼ばれます。クラスレベルの演算子は、検査対象の式を追加、削除、または変更することでプログラムの構造を変更します。変更のカテゴリごとに特定の演算子が確立されています。^[19]たとえば、muJavaツールは、アクセス修飾子の変更、型キャスト演算子の挿入、型キャスト演算子の削除など、さまざまなクラスレベルのミューテーション演算子を提供します。ミューテーション演算子は、プログラムのセキュリティ脆弱性テストを実行するためにも開発されています。^[25]

クラスレベルの演算子とは別に、MuJavaには、従来の演算子と呼ばれるメソッドレベルの変更演算子も含まれています。これらの従来の演算子は、手続き型言語で一般的に見られる機能に基づいて設計されています。プリミティブ演算子を追加、置換、または削除することで、ステートメントに変更を加えます。これらの演算子は、算術演算子、関係演算子、条件演算子、シフト演算子、論理演算子、および代入演算子の6つのカテゴリに分類されます。^[19]

変異検査には 3 つの種類があります。

ステートメントの変異とは、特定のステートメントを削除またはコピーすることで、コードブロックを意図的に変更するプロセスです。さらに、コードブロック内のステートメントの順序を変更して、さまざまなシーケンスを生成することもできます。^[26]この手法は、コードの潜在的な弱点やエラーを特定するのに役立つため、ソフトウェアテストでは非常に重要です。意図的にコードを変更し、その動作を観察することで、開発者は通常のテストでは気付かない可能性のある隠れたバグや欠陥を発見できます。^[27]ステートメントの変異は、コードの堅牢性と回復力に関する洞察を提供する診断ツールのようなもので、プログラマがソフトウェアの全体的な品質と信頼性を向上させるのに役立ちます。

たとえば、以下のコード スニペットでは、「else」セクション全体が削除されています。

関数checkCredentials (ユーザー名、パスワード) { if (ユーザー名=== "admin" &&パスワード=== "password" ) { return true ; } }   
          
     
   

値の変更は、コード内のパラメータや定数の値が変更されたときに発生します。通常は、1 を加算または減算して値を調整しますが、値に大幅な変更を加えることもあります。値の変更中に行われる具体的な変更には、主に次の 2 つのシナリオがあります。

まず、小さな値から大きな値への変換があります。これは、コード内の小さな値を大きな値に置き換えることを意味します。この変更の目的は、コードがより大きな入力に遭遇したときにどのように反応するかを評価することです。これにより、コードがエラーや予期しない問題に遭遇することなく、これらの大きな値を正確かつ効率的に処理できるようになります。^[26]

逆に、2番目のシナリオでは、高い値を低い値に変更します。この場合、コード内の高い値を低い値に置き換えます。このテストは、コードが小さい入力をどのように処理するかを評価することを目的としています。コードが小さい値で正しく動作することを確認することは、そのような入力データを処理する際に予期しない問題やエラーを防ぐために不可欠です。^[26]

例えば：

// 元のコード
function multiplyByTwo ( value ) { return value * 2 ; }  
     


// 値の変更: 小さい値から大きい値へ
function multiplyByTwoMutation1 ( value ) { return value * 10 ; }  
     


// 値の変更: 高い値から低い値へ
function multiplyByTwoMutation2 ( value ) { return value / 10 ; }  
     

決定変異テストは、コード内の設計エラーの特定に重点を置き、特にプログラムの意思決定ロジックの欠陥や弱点の検出に重点を置いています。この方法では、算術演算子と論理演算子を意図的に変更して、潜在的な問題を明らかにします。^[26]これらの演算子を操作することで、開発者はコードがさまざまな意思決定シナリオにどのように応答するかを体系的に評価できます。このプロセスは、プログラムの意思決定パスが堅牢で正確であることを保証し、誤ったロジックから発生する可能性のあるコストのかかるエラーを防ぐのに役立ちます。決定変異テストは、ソフトウェア開発における貴重なツールとして機能し、開発者が意思決定コードセグメントの信頼性と有効性を高めることを可能にします。

例えば：

// 元のコード
function isPositive ( number ) { return number > 0 ; }  
     


// 決定変異: 比較演算子の変更
function isPositiveMutation1 ( number ) { return number >= 0 ; }  
     


// 決定変異: 結果を否定する
function isPositiveMutation2 ( number ) { return ! ( number > 0 ); }  
     

• Pitest - Javaフレームワーク

• バグの発見（または障害の種まき）
• 健全性テスト
• フォールト注入