モデルベースのテストとは何ですか?
トーマス・ハミルトン
⚡ スマートサマリー
モデルベーステストは、ソフトウェアの実行時動作を、絶対値モデルによる予測と比較して検証します。tracシステムのモデルを作成し、手作業ではなく、有限状態機械、状態遷移図、またはUML表記からテストケースを自動的に生成します。
モデルベースのテストとは何ですか?
モデルベーステスト これは、テスト対象ソフトウェアの実行時動作をモデルによる予測と照合するソフトウェアテスト手法です。モデルとは、入力シーケンス、アクション、条件、出力、および入力から出力へのデータフローによって表現される、システムの動作記述です。実用的なモデルは、実際に理解しやすく、再利用可能で、共有可能であり、テスト対象システムを正確に記述する必要があります。
利用可能なモデルは数多くあり、それぞれがシステム動作の異なる側面を記述しています。一般的な例としては、以下のようなものがあります。
モデルベーステストとは、モデルによって決定されたアクションに対してシステムがどのように動作するかを検証するテストです。アクションを与え、システムがモデルの予測どおりに動作するかどうかを確認します。両者の間に差異が生じた場合は、ソフトウェアの欠陥かモデルのエラーのいずれかであり、どちらも発見する価値があります。
これはシステムを検証するための軽量な形式手法であり、ソフトウェアテストと同様にハードウェアテストにも容易に適用できます。テストはコードからではなく動作仕様から生成されるため、この手法は ブラックボックステスト の家族 ソフトウェアテスト手法.
モデルベースのテストの例
行動モデルを理解する最も簡単な方法は、そのモデルを実際に辿ってみることです。下の図は、簡単なテキスト編集タスクをモデル化したもので、各ボックスはアプリケーションが取り得る状態を表し、各矢印はユーザーが実行できるアクションを表しています。
このモデルは、メモ帳で詩を書くための簡略化されたアプローチと、各ステップに関連する可能なアクションを説明しています。アプリケーションの起動、詩の入力、ファイルの保存などのすべてのアクションに対して、 テストケース 生成して出力を検証することができます。例えば、同じ図を異なる経路でたどる（保存せずに開始して終了するなど）と、追加の設計コストをかけずに異なるテストケースが生成されます。これが、この手法全体の経済的な利点です。
MBTの種類
モデルベーステストフレームワークには2種類あり、その違いはテストステップが生成されるタイミングにあります。
- オフライン / 事前情報: テストスイートは実行前に生成されます。テストスイートはテストケースの集合であり、このモードでは他のテストと同様にスイートが保存、レビュー、再実行されます。 自動化テスト 資産。
- オンライン／即時対応： テスト実行中にテストスイートを生成する。次のステップは、システムが前のステップに実際にどのように反応したかに基づいて選択される。
オフライン生成は、検証可能で再現性のあるスイートを必要とする規制環境に適しています。オンライン生成は、ステートフルシステムに対する長時間の探索セッションに適しています。これは、ジェネレーターが予測された応答ではなく、実際の応答に反応できるためです。
モデルベーステストの仕組み
どのフレームワークを使用する場合でも、この手法は同じ5つの段階に従います。各段階では、次の段階で使用される成果物が生成されます。そのため、テストスクリプトではなく、モデルがチームが保守する対象となります。
- ステップ1：モデルを構築する。 要件または仕様を絶対的なtrac期待される動作のモデルであり、状態、状態間の遷移、および各遷移を引き起こす入力を定義します。
- ステップ2：テストの選択基準を選択する。 生成器が停止するタイミングは、基準によって決まります。一般的な基準としては、すべての状態を少なくとも一度は訪れる全状態カバレッジ、すべての矢印を少なくとも一度は実行する全遷移カバレッジ、そしてより詳細な探索のためのパスカバレッジまたはデータフローカバレッジなどがあります。
- ステップ3：絶対値を生成するtract検定ケース。 このツールはモデルを走査し、一連の絶対値を出力する。trac選択された基準を満たすt個のステップと、各ステップで期待される結果。
- ステップ4：アブストラクトを具体化するtract検定。 アダプター レイヤーは各 abs をマッピングしますtracシステムに対する実際のアクション、例えば UI 操作、 API 呼び出しまたはプロトコルメッセージ。このマップping 一度記述すれば、生成されるすべてのテストで再利用されます。
- ステップ5：判決を実行し、割り当てる。 具体的なテストはテスト対象システムに対して実行され、観測された各応答はモデル予測と比較され、合格または不合格の判定が記録されます。 tracそれを生成したモデル要素に遡って。
その tracステップ5で作成された柔軟性が、実質的なメリットとなります。要件が変更されるとモデルも変更され、影響を受けるテストは書き直されるのではなく再生成されるため、頻繁にテストを実施するチームは、 回帰試験 安定した仕様に対して最も恩恵を受ける。
テスト中のさまざまなモデル
MBTを理解するためには、以下に説明するいくつかのモデルを理解する必要があります。それぞれのモデルは表現力と労力のトレードオフの関係にあるため、どのモデルを選択するかは、テスト対象となる行動が実際にどれほど複雑かによって異なります。
有限状態機械
このモデルは、選択された入力に応じてテスターが結果を評価するのに役立ちます。入力のさまざまな組み合わせによって、システムの状態が変化する可能性があります。
システムには特定の状態と現在の状態があり、これらはテスターから与えられる一連の入力によって制御されます。
以下の例を考えてみましょう。あるシステムでは、従業員がアプリケーションにログインできます。従業員の現在の状態は「ログイン中」ですが、システムにサインインすると「ログイン中」になります。「ログイン中」の状態では、従業員はシステム内の文書の閲覧、印刷、スキャンを行うことができます。
その例における状態遷移図を以下に示します。各矢印には、遷移を引き起こす入力がラベル付けされています。
状態図
ステートチャートは有限状態機械の拡張であり、複雑なリアルタイムシステムにも使用できます。ステートチャートはシステムの様々な動作を記述し、状態数は確定しており、各状態におけるシステムの動作はイベントの形で分析・表現されます。実務上重要な拡張は階層構造です。ステートチャートはネストされた状態や並列状態を許容するため、数十個のフラットな状態を必要とする機械でも、コンパクトに描画できます。
例えば、欠陥管理ツールでは、欠陥は「新規」ステータスで報告されます。開発者が欠陥を修正すると、ステータスは「修正済み」に変更されます。欠陥が修正されない場合は、ステータスは「再開」に変更されます。ステートチャートは、各状態に対してイベントが呼び出されるように設計する必要があります。
欠陥のライフサイクルは以下に図示されており、各ステータスは状態として、各ワークフローアクションは欠陥をそれらの間を移動させるイベントとして示されています。
統一モデリング言語（UML）
統一モデリング言語（UML） UMLは、標準化された汎用モデリング言語です。UMLには、非常に複雑なシステム動作を記述できる視覚的なモデルを作成するために使用される一連のグラフィック表記法が含まれています。
UML には次のような表記法があります。
- アクティビティ
- 役者
- ビジネスプロセス
- コンポーネント
- プログラミング言語
アクティビティ図とステートマシン図は、テスト生成者が最も頻繁に参照する図であり、以下のUMLモデルの例がそれを示している。
モデルベーステストツール
紙上のモデルはそれ自体では何も生成しない。モデルを走査してテストパスを出力するジェネレーターが必要であり、ツール市場はオープンソースのジェネレーターと商用のテスト設計プラットフォームに分かれる。
- グラフウォーカー — 有向グラフの形式で構成されたモデルを読み込み、選択可能なジェネレーターと停止条件を備えたテストパスを生成するオープンソースツール。
- fMBT — インテルが提供するオープンソースのモデルベーステストツールセットで、状態モデルに対するテスト生成と実行をサポートする。
- コンフォーミク — グラフィカルな振る舞いモデルからテストケースとスクリプトを生成する、市販の自動テスト設計製品。
- MateLoとMBTsuite ―統計的な利用モデルの構築や、既存の自動化フレームワークへのテスト生成を目的とした商用プラットフォーム。
- Spec Explorer - MicrosoftVisual Studio 用のモデルベーステスト拡張機能であり、プロトコルテストに関する文献で広く引用されている。
選定は機能一覧よりも、チームが実際にどの表記法を使えるか、そしてそのツールが既に利用されている自動化フレームワークにテストを出力できるかどうかという2つの点に大きく左右される。誰も実行できないテストスイートを生成するジェネレーターは、プロセスから手順を削除するどころか、むしろ手順を追加することになる。
モデルベーステストと従来型テスト設計の比較
手書きのテスト設計との対比を明確にしておくことは重要である。なぜなら、この2つのアプローチはどちらか一方が単純に優れているというのではなく、それぞれ異なる点で失敗するからである。
| 側面 | モデルベーステスト | 従来のテスト設計 |
|---|---|---|
| テストケースのソース | 行動モデルから自動的に生成されます | 要件に基づいてテスターが個別に作成した |
| 要件変更の影響 | モデルを更新し、影響を受けるテストを再生成します。 | 影響を受ける各テストケースを手動で特定して編集します。 |
| カバレッジ | 全状態または全遷移などのモデル基準に基づいて測定 | 要件に照らして評価され、テスターの判断に依存する。 |
| 先行投資コスト | 高レベル：モデリングスキル、ツール設定、アダプターレイヤー | 低：テスターはすぐに書き始めることができます |
| 最適 | 状態を保持し、長期間稼働する、安定した仕様を持つシステム | 短期プロジェクト、単発の特集記事、そして実験的な作品 |
| 主な故障モード | 間違った、あるいは古いモデルは、知らず知らずのうちに間違ったテストを生成する。 | 大規模なスイート全体で、欠落や重複が蓄積されます。 |
以下の進化は、この技術を文脈に沿って説明するものである。手動によるテスト実行は自動化された実行に取って代わられ、モデルベースのアプローチは自動化をさらに一段階進め、テスト設計そのものへと移行させた。
モデルベースのテストの課題
組織内でMBTを導入するには、かなりの資金と労力の投資が必要です。MBTの欠点は以下のとおりです。 ソフトウェア工学:
- テスターには、従来のテスト設計では求められないモデリングスキルが必要となる。
- 習得には時間がかかり、最初のプロジェクトは通常、節約できる金額よりも費用の方が高くなる。
- モデル自体は、特に規模が大きくなると、理解や検証が難しくなる場合がある。
- 仕様から逸脱したモデルは、自信過剰で誤ったテスト結果を生成する。
- アダプター層がtrac具体的な行動に移すための手順は、別途記述し、維持管理する必要がある。
- モデルのサイズは急速に増大するため、制約のない状態モデルでは、どのチームも実行できる以上のパスが生成される可能性があります。
これらはいずれもこの手法を避ける理由にはならないが、MBTが通常、システム全体ではなく、まず1つの安定したサブシステムに導入される理由を説明している。 ソフトウェアテストのライフサイクル 一度に。
モデルベーステストの利点
これらのコストに対して、MBTの利点は以下のとおりです。
- モデルを編集するだけで個々のテストを編集する必要がないため、テストケースとテストスイートのメンテナンスが容易です。
- 長期にわたるプロジェクトのライフサイクル全体を通してコストを削減する。
- 改善されました テストカバレッジなぜなら、ジェネレーターは人が見過ごしてしまうような経路を探索するからである。
- 生成された異なるテストスイートは、任意の数のマシン上で並列実行できる。
- 早期の欠陥検出は、コードが実行される前に、モデル構築中に曖昧さが明らかになるため重要です。
- 同じ検査作業量で発見される欠陥の数が増加すること。
- モデルとアダプタが既に存在する場合、テスト設計にかかる時間を節約できます。
- 反復的なスクリプト作成からモデリングや分析へと業務内容が移行することで、テスターの仕事に対する満足度が向上する。
テスターは作業中にいずれにせよメンタルモデルを構築しますが、MBTはそれらのメンタルモデルを紙に書き出して、レビュー、バージョン管理、再利用できるようにするだけです。この手法が他の利用可能なアプローチとどのように関連しているかは、以下に記載されています。 ソフトウェアテストの種類.
