テストオラクル

ソフトウェアテストにおいて、テストオラクル（または単にオラクル）は、テストケースの入力に基づいて正しい出力を記述する情報を提供するものです。オラクルを使用したテストでは、テスト対象システム（SUT）の実際の結果とオラクルによって提供される期待される結果を比較します。^[1]

「テストオラクル」という用語は、ウィリアム・E・ハウデンの論文で初めて導入されました。^[2]さまざまな種類のオラクルに関する追加の研究は、エレイン・ワイユカーによって研究されました。^[3]

オラクルはSUTとは別に動作し、テスト実行時にアクセスすることも、テストロジックにエンコードされた期待される結果を使用してテストを実行する前に使用することもできます。^[4]

しかし、メソッドの事後条件は、契約モデルによる設計における自動化されたオラクルとしてSUTの一部です。^[5]

与えられた入力（およびプログラムまたはシステムの状態のセット）に対する正しい出力を決定することは、オラクル問題またはテストオラクル問題として知られています。^{[6] : 507}これは比較的難しい問題であると考える人もおり、制御可能性と観測可能性に関連する問題を扱う必要があります。^[7]

1978年から2012年までを対象とした研究文献調査^[6]では、テストオラクルの潜在的なカテゴリーがいくつか見つかりました。

指定されたオラクルとは、典型的にはソフトウェアモデリングやソフトウェアコード構築に対する形式化されたアプローチと関連している。これは、形式仕様^[8] 、テストオラクルを生成するために使用できるモデルベース設計^{[9] 、}モデルベーステスト^[10]やプロトコル適合性テストを支援するためにオラクルを導出できる状態遷移仕様^[11]、および同等のテストオラクルがアサーションである契約による設計と関連している。

仕様化されたテストオラクルには多くの課題があります。形式仕様は抽象化に依存しており、すべてのモデルがすべての動作を捉えることはできないため、当然ながら不正確な要素が含まれる可能性があります。^{[6] : 514}

派生テストオラクルは、システムの成果物から派生した情報を使用して、正しい動作と間違った動作を区別します。これらには、ドキュメント、システム実行結果、SUTのバージョンの特性が含まれます。^{[6] ：514}回帰テストスイート（またはレポート）は、派生テストオラクルの一例です。これらは、以前のシステムバージョンの結果を将来のシステムバージョンの補助（オラクル）として使用できるという前提で構築されています。以前に測定されたパフォーマンス特性は、将来のシステムバージョンのオラクルとして使用して、たとえば、観察された潜在的なパフォーマンス低下に関する質問をトリガーできます。以前のシステムバージョンのテキストドキュメントは、将来のシステムバージョンでの期待を導くための基礎として使用できます。

擬似オラクル^{[6] : 515は}派生テストオラクルのカテゴリに分類されます。Weyuker ^[12]によって定義された擬似オラクルは、プログラムまたはSUTと同じ入力を受け取り、それらの出力を比較して調査する問題があるかどうかを把握できる、別途記述されたプログラムです。

部分オラクル^{[6] :515}は、指定されたテストオラクルと派生テストオラクルのハイブリッドです。これは、SUTの重要な（ただし完全ではない）プロパティを指定します。たとえば、メタモーフィックテストでは、システムの複数の実行にわたって、メタモーフィック関係と呼ばれるそのようなプロパティを活用します。

暗黙のテストオラクルは、暗黙の情報と仮定に依存します。^{[6] : 518}たとえば、プログラムクラッシュから暗黙の結論、つまり望ましくない動作がある場合があります。これは、問題がある可能性があることを判断するためのオラクルです。望ましくない動作を検索してテストする方法はいくつかあり、ネガティブテストと呼ばれるものもあれば、ファジングなどの特殊なサブセットもあります。

暗黙的なテストオラクルには、暗黙的な結論と仮定に依存するため、制限があります。たとえば、システムがフォールトトレラントシステムであり、自己修復/自己管理の形式で動作している場合、プログラムまたはプロセスのクラッシュは優先度の高い問題ではない可能性があります。暗黙的なテストオラクルは、環境依存性のために誤検知の影響を受けやすい場合があります。プロパティベースのテストは暗黙的なオラクルに依存します。

人間はテストオラクルとして行動することができます。^[7]このアプローチは、定量的または定性的に分類できます。^{[6] : 519–520}定量的アプローチは、利害関係者がソフトウェアの目的適合性やリリースを決定できるように、SUT（テスト結果など）で収集する適切な情報量を見つけることを目的としています。定性的アプローチは、入力テストデータの代表性と適合性、およびSUTからの出力のコンテキストを見つけることを目的としています。例としては、現実的で代表的なテストデータを使用し、結果（現実的な場合）を理解することが挙げられます。これらは、直感、経験則、チェックリスト補助、経験などのヒューリスティックアプローチによって導かれ、SUTに選択された特定の組み合わせを調整するのに役立ちます。

テストオラクルは、仕様とドキュメントに基づいていることが最も一般的です。^{[13] [14]}モデルベース設計とモデルベーステストへの入力として使用される正式な仕様は、指定されたテストオラクルの一例です。モデルベースオラクルは、同じモデルを使用してシステムの動作を生成および検証します。^[15]使用方法やインストールガイド、ソフトウェアのパフォーマンス特性や最小マシン要件の記録など、製品の完全な仕様ではないドキュメントは、通常、派生テストオラクルになります。

一貫性オラクルは、1つのテスト実行の結果を別のテスト実行の結果と比較して類似性を調べます。^[16]これは派生テストオラクルの別の例です。

ソフトウェアプログラムのオラクルは、テスト対象製品と同じ数式を異なるアルゴリズムで評価する2番目のプログラムである可能性があります。これは、派生テストオラクルである疑似オラクルの例です。^{[12] : 466}

Google検索では、返された結果の数が正しいかどうかを確認するための完全なオラクルはありません。メタモルフィック関係^[17]を定義して、後続の絞り込み検索で結果が少なくなるようにすることができます。これは、指定されたテストオラクルと派生テストオラクルのハイブリッドである部分オラクルの例です。

統計的オラクルは確率的特性^[18]を使用します。例えば、画像解析では、テストオラクルが一致または不一致を判定するための確実性と不確実性の範囲が定義されます。これは、人間のテストオラクルにおける定量的アプローチの例です。

ヒューリスティックオラクルは、テスト入力のクラスに対して代表的な結果または近似結果を提供します。^[19]これは、ヒューマンテストオラクルにおける定性的なアプローチの例です。

• Binder, Robert V. (1999)。「第 18 章 - Oracles」『オブジェクト指向システムのテスト: モデル、パターン、およびツール』、Addison-Wesley Professional、1999 年 11 月 7 日、ISBN 978-0-201-80938-1