Loading article…
コンピューティング分野において、モデルベーステストとは、モデルベース設計を活用してテストを設計し、場合によっては実行するテスト手法です。右の図に示すように、モデルはテスト対象システム（SUT）の望ましい動作を表すことができます。あるいは、モデルはテスト戦略やテスト環境を表すこともできます。
SUT を記述するモデルは通常、SUT の望ましい動作を抽象的かつ部分的に表現したものです。 このようなモデルから派生したテスト ケースは、モデルと同じ抽象レベルの機能テストです。これらのテスト ケースはまとめて抽象テスト スイートと呼ばれます。抽象テスト スイートは抽象レベルが間違っているため、SUT に対して直接実行することはできません。実行可能なテスト スイートは、対応する抽象テスト スイートから派生させる必要があります。実行可能なテスト スイートは、テスト対象システムと直接通信できます。これは、抽象テスト ケースを実行に適した具体的なテスト ケースにマッピングすることによって実現されます。モデル ベースのテスト環境によっては、モデルに実行可能なテスト スイートを直接生成するのに十分な情報が含まれている場合があります。他の環境では、具体的なテスト スイートを作成するために、抽象テスト スイートの要素をソフトウェア内の特定のステートメントまたはメソッド呼び出しにマッピングする必要があります。これは「マッピング 問題」の解決と呼ばれます。[ 1 ] オンライン テストの場合 (下記参照)、抽象テスト スイートは概念的にのみ存在し、明示的な成果物としては存在しません。
モデルからテストを導出する方法は様々です。テストは通常、実験的で経験則に基づいて行われるため、テスト導出のための唯一の最適なアプローチは存在しません。テスト導出に関連するすべてのパラメータを、「テスト要件」、「テスト目的」、あるいは「ユースケース」などと呼ばれるパッケージにまとめるのが一般的です。このパッケージには、モデルのどの部分に焦点を当てるべきか、あるいはテストを終了するための条件（テスト停止基準）に関する情報を含めることができます。
テストスイートはソースコードではなくモデルから生成されるため、モデルベーステストは通常、ブラックボックステストの一形態と見なされます。
特にモデル駆動型エンジニアリングやモデル駆動型アーキテクチャでは、モデルは対応するシステムよりも前に、または並行して構築されます。モデルは完成したシステムから構築することもできます。テスト生成のための代表的なモデリング言語には、UML、SysML 、主流のプログラミング言語、有限機械記法、 Z、B（Event-B）、Alloy、Rocqなどの数学的形式化が含まれます。
モデルベーステストを展開する方法はいくつか知られており、オンラインテスト、実行可能なテストのオフライン生成、手動で展開可能なテストのオフライン生成などがある。[ 2 ]
オンラインテストとは、モデルベースのテストツールがテスト対象システム（SUT）に直接接続し、動的にテストを行うことを意味します。
オフラインで実行可能なテストを生成するとは、モデルベースのテストツールが、後で自動的に実行できるコンピュータ読み取り可能なアセットとしてテストケースを生成することを意味します。たとえば、生成されたテストロジックを具体化したPythonクラスの集合などが挙げられます。
オフラインで手動展開可能なテストを生成するということは、モデルベースのテストツールが、後で手動テストを支援できる人間が読みやすい形式のテストケースを生成することを意味します。例えば、生成されたテスト手順を人間が理解できる言語で記述したPDFドキュメントなどが挙げられます。
モデルベーステストの有効性は、主に自動化の可能性にある。モデルが機械可読であり、かつ明確な振る舞いの解釈を持つほど形式的であれば、原則としてテストケースを機械的に導出することができる。
多くの場合、モデルは有限状態オートマトンまたは状態遷移システムに変換または解釈されます。このオートマトンは、テスト対象システムの可能な構成を表します。テストケースを見つけるには、オートマトン内で実行可能なパスを検索します。実行可能なパスはテストケースとして使用できます。この方法は、モデルが決定論的であるか、決定論的なモデルに変換できる場合に有効です。これらのモデルにおける未指定の遷移を利用することで、有用な非定型テストケースが得られる場合があります。
テスト対象システムの複雑さと対応するモデルによっては、システムの可能な構成が膨大になるため、パスの数が非常に多くなる可能性があります。適切なが有限な数のパスをカバーできるテストケースを見つけるには、選択をガイドするテスト基準が必要です。この手法は、モデルベーステストを開始した論文でOffuttとAbdurazikによって最初に提案されました。[ 3 ]テストケース生成のための複数の手法が開発され、Rushbyによって調査されています。[ 4 ]テスト基準は、テストの教科書で一般的なグラフの観点から説明されています。[ 1 ]
定理証明はもともと論理式の自動証明に使用されていました。モデルベースのテスト手法では、システムはシステムの動作を指定する述語の集合によってモデル化されます。 [ 5 ]テストケースを導出するために、モデルはテスト対象システムを記述する述語の集合の有効な解釈に基づいて同値類に分割されます。各クラスは特定のシステム動作を記述するため、テストケースとして使用できます。最も単純な分割は、システムの動作を記述する論理式を選言標準形に変換する選言標準形アプローチです。
制約プログラミングは、一連の変数に対する一連の制約を解くことによって、特定の制約を満たすテストケースを選択するために使用できます。システムは制約によって記述されます。[ 6 ] 制約のセットを解くには、ブールソルバー（例えば、ブール充足可能性問題に基づくSATソルバー）またはガウス消去法などの数値解析を使用できます。制約式のセットを解くことによって得られた解は、対応するシステムのテストケースとして使用できます。
制約プログラミングは、シンボリック実行と組み合わせることができます。このアプローチでは、システムモデルがシンボリックに実行されます。つまり、さまざまな制御パスにわたるデータ制約を収集し、制約プログラミング手法を使用して制約を解決し、テストケースを生成します。[ 7 ]
Model checkers can also be used for test case generation.[8] Originally model checking was developed as a technique to check if a property of a specification is valid in a model. When used for testing, a model of the system under test, and a property to test is provided to the model checker. Within the procedure of proofing, if this property is valid in the model, the model checker detects witnesses and counterexamples. A witness is a path where the property is satisfied, whereas a counterexample is a path in the execution of the model where the property is violated. These paths can again be used as test cases.
Markov chains are an efficient way to handle Model-based Testing. Test models realized with Markov chains can be understood as a usage model: it is referred to as Usage/Statistical Model Based Testing. Usage models, so Markov chains, are mainly constructed of 2 artifacts : the finite-state machine (FSM) which represents all possible usage scenario of the tested system and the Operational Profiles (OP) which qualify the FSM to represent how the system is or will be used statistically. The first (FSM) helps to know what can be or has been tested and the second (OP) helps to derive operational test cases. Usage/Statistical Model-based Testing starts from the facts that is not possible to exhaustively test a system and that failure can appear with a very low rate.[9] This approach offers a pragmatic way to statically derive test cases which are focused on improving the reliability of the system under test. Usage/Statistical Model Based Testing was recently extended to be applicable to embedded software systems.[10][11]