モデルからのテストの作成
Microsoft Visual Studio Ultimate では、システムとそのコンポーネントのテストを編成する際に、要求モデルとアーキテクチャ モデルを使用できます。 こうすることで、ユーザーなどの関係者にとって重要な要求を確実にテストしたり、要求が変更されたときにすばやくテストを更新したりできます。 Microsoft テスト マネージャー を使用すると、モデルとテストの間のリンクを維持することもできます。
システムとサブシステムのテスト
システム テスト (承認テストとも呼ばれる) は、ユーザーのニーズを満たしているかどうかを確認するテストです。 このようなテストは、内部の設計ではなく、外部で参照できるシステムの動作を対象としています。
システム テストは、システムの拡張または再設計の際に非常に役立ちます。 これにより、コードを変更するときにバグが生じるのを防ぐことができます。
システムの変更または拡張を計画するとき、最初に既存のシステム上で一連のシステム テストを実行すると効果的です。 その後でテストを拡張または調整し、新しい要求をテストします。さらに、コードに変更を加え、テストの完全なセットを再実行します。
新しいシステムを開発するとき、開発作業の開始と同時にテストの生成を開始できます。 各機能を開発する前にテストを定義することで、要求に関して、きわめて具体的な話し合いを行うことができます。
サブシステム テストでは、システムの主要コンポーネントに同じ原則が適用されます。 各コンポーネントは、別々にテストされます。 サブシステム テストで重視されるのは、コンポーネントのユーザー インターフェイスまたは API で参照可能な動作です。
テストを実行する方法の詳細については、「アプリケーションのテスト」を参照してください。
要求モデルに基づくシステム テストの作成
システム テストと要求モデルの関係を設定し、維持できます。 この関係を確立するには、要求モデルの主要な要素に対応するテストを記述します。 Visual Studio Ultimate では、テストとモデルのパートの間のリンクを生成することにより、こうした関係を維持することができます。 要求モデルの詳細については、「ユーザー要求のモデリング」を参照してください。
ユース ケースごとのテストの記述
Microsoft テスト マネージャー を使用すると、要求モデルで定義されているユース ケースごとに一連のテストを生成できます。 たとえば、"注文の作成" と "注文への品目の追加" を含む "料理の注文" ユース ケースがある場合は、これらのユース ケース全体とその詳細の両方についてテストを作成できます。 ユース ケースの詳細については、「UML ユース ケース図: ガイドライン」を参照してください。
次のガイドラインを参考にしてください。
ユース ケースごとに複数のテスト (主要パス用と例外的な結果用) を作成する必要があります。
要求モデルにユース ケースを記述する際には、ユーザーが目的を達成するために従う手順を詳細に記述することよりも、事後条件 (達成される目的) を定義することの方が重要です。 たとえば、"料理の注文" の事後条件としては、"レストラン" が "顧客" の料理を準備しているという条件と、"顧客" による支払いが完了しているという条件が考えられます。 事後条件は、テストで検証する必要のある条件です。
各テストは、事後条件の異なる句に基づいて作成する必要があります。 たとえば、レストランへの注文の通知のテストと、顧客からの支払受領のテストは別個に作成します。 このようにテストを別個に作成することには、次のようなメリットがあります。
頻繁に、かつ別々に、要求のさまざまな側面が変更されます。 このようにテストを複数の異なる側面に分けておくことで、要求が変更されたときにテストをより簡単に更新できるようになります。
開発計画でユース ケースの特定の側面が優先的に実装される場合、開発作業の進行に合わせてテストを個別に有効化できます。
テストを設計する際に、事後条件が満たされているかどうかを確認するコードまたはスクリプトからテスト データの選択を切り離します。 たとえば、単純な算術関数のテストとして、入力が 4 のときに出力が 2 になることを検証するテストが考えられます。 この場合は、"入力を選択し、出力を 2 乗して、結果が元の入力と同じになることを検証する" というスクリプトを代わりに設計します。 このスタイルを採用すると、テストの主要部分を変更せずにテストの入力を変更できます。
ユース ケースへのテストのリンク
テストの設計と実行に テスト マネージャー を使用している場合は、要求、ユース ケース、またはユーザー ストーリーの各作業項目に基づいてテストを編成できます。 これらの作業項目は、モデル内のユース ケースにリンクできます。 これにより、要求の変更からテストに至るまでをすばやく確認でき、各ユース ケースの進行状況を追跡できます。
テストをユース ケースにリンクするには
テスト マネージャー で要求を作成し、それに基づいてテスト スイートを作成します。 その方法については、「要件またはユーザー ストーリーを使用したテスト計画の作成」を参照してください。
作成する要求は、Team Foundation Server の作業項目です。 プロジェクトが Team Foundation で使用するプロセス テンプレートに応じて、ユーザー ストーリー、要求、またはユース ケースのいずれかの作業項目を作成します。 詳細については、「プロジェクトの計画および追跡」を参照してください。
要求の作業項目をモデルの 1 つ以上のユース ケースにリンクします。
ユース ケース図で、ユース ケースを右クリックし、[作業項目へリンク] をクリックします。 詳細については、「方法: 作業項目をモデル要素にリンクする」を参照してください。
ユース ケースを検証するテスト ケースをテスト スイートに追加します。
通常、ユーザー ストーリーまたは要求の各作業項目はモデル内のいくつかのユース ケースにリンクし、各ユース ケースはいくつかのユーザー ストーリーまたは要求にリンクします。 これは、各ユーザー ストーリーまたは要求が、複数のユース ケースを生成する一連のタスクに対応しているためです。 たとえば、プロジェクトの初期のイテレーションでは、顧客がカタログから品目を選択して配送を依頼できる、基本的なユーザー ストーリーを生成できます。 その後のイテレーションでは、注文の完了時にユーザーが支払いを行い、サプライヤーが商品の配送後に代金を受け取るというストーリーが考えられます。 各ストーリーでは、"商品の注文" ユース ケースの事後条件に句が追加されます。
ユース ケース図の個別のコメントに事後条件の句を記述することで、要求からそれらの句への個別のリンクを設定できます。 そして、各コメントを要求の作業項目にリンクしたり、そのコメントを図上のユース ケースにリンクしたりできます。
要求のタイプに基づくテストの作成
要求モデルのタイプ (クラス、インターフェイス、および列挙体) は、ユーザーがビジネスについてどのように考え、どのように伝達するかという観点から概念と関係を示します。 これには、システムの内部設計だけに関係するタイプは含まれません。
これらの要求のタイプに基づいてテストを設計します。 これにより、要求の変更について、テストに加える必要のある変更と簡単に結び付けて話し合うことができます。 また、テストとその意図した結果について、エンド ユーザーなどの関係者と直接話し合うことができます。 これは、ユーザーのニーズを開発プロセスとは切り離して管理でき、不注意によって設計上の潜在的な問題を中心にテストをデザインすることを回避できることを意味します。
この手法によって手動テストを作成する場合は、テスト スクリプトにおいて要求モデルの語彙に準拠する必要があります。 自動テストの場合は、要求クラス図をテスト コードの基盤として使用し、アクセサー関数とアップデーター関数を作成して要求モデルをコードにリンクする必要があります。
たとえば、要求モデルには、"メニュー"、"メニュー品目"、"注文" などのタイプとこれらのタイプの間の関連付けを含めることができます。 このモデルが表すのは、実装の複雑な部分ではなく、料理注文システムによって格納および処理される情報です。 作業システムでは、各タイプが、データベース、ユーザー インターフェイス、API など、さまざまな場所で実現されることがあります。 分散システムでは、各インスタンスの複数の変種がシステムの異なる部分に同時に格納されることがあります。
"注文への品目の追加" などのユース ケースをテストする場合は、テスト メソッドに次のようなコードを含めることができます。
Order order = … ; // set up an order
// Store prior state:
int countBefore = order.MenuItems.Count;
// Perform use case:
MenuItem chosenItem = …; // choose an item
AddItemToOrder (chosenItem, order);
// Verify part of postcondition:
int countAfter = order.MenuItems.Count;
Assert (countAfter == countBefore = 1);
このテスト メソッドでは要求モデルのクラスが使用されていることに注目してください。 関連付けと属性は、.NET プロパティとして実現されています。
これを機能させるためには、クラスのプロパティを、システムにアクセスして現在の状態の情報を取得する読み取り専用の関数またはアクセサーとして定義する必要があります。 AddItemToOrder などのユース ケースをシミュレートするメソッドは、その API またはそのユーザー インターフェイスの下のレイヤーを介してシステムを動作させる必要があります。 Order や MenuItem などのテスト オブジェクトのコンストラクターも、システム内に対応する項目を作成するようにシステムを動作させる必要があります。
アクセサーとアップデーターの多くは、アプリケーションの通常の API を介して提供されています。 ただし、テストを有効にするには、追加の関数をいくつか記述しなければならない場合もあります。 これらの追加のアクセサーとアップデーターは、"テスト インストルメンテ―ション" とも呼ばれます。 これらはシステムの内部設計に依存するため、システムの開発者が用意する必要があります。一方、テスト担当者は、要求モデルの観点からテストのコードを記述します。
自動テストを記述する際には、汎用テストを使用してアクセサーとアップデーターをラップできます。 詳細については、「汎用テストを使用して実行可能ファイルを実行する、自動テストの作成」を参照してください。
ビジネス ルールのテスト
要求によっては、特定のユース ケースに直接関係しないものもあります。 たとえば、料理宅配ビジネスでは、顧客は多数の "メニュー" から選択できますが、どの "注文" でも、すべての "品目" を 1 つの "メニュー" から選択する必要があります。 このビジネス ルールは、要求クラス モデルで、"注文"、"メニュー"、および "品目" の間の関連付けに関する不変ルールとして表現できます。
この種の不変ルールは、現在定義されているすべてのユース ケースだけでなく、将来定義される他のすべてのユース ケースにも適用されます。 したがって、不変ルールの記述とテストはユース ケースとは別に行うことをお勧めします。
クラス図では、不変ビジネス ルールをコメントとして記述できます。 詳細については、「UML クラス図: ガイドライン」を参照してください。
コメントを要求の作業項目またはユーザー ストーリーの作業項目にリンクすることで、テストをビジネス ルールにリンクできます。これは、テスト マネージャー でテスト スイートにリンクできます。 詳細については、「モデル要素へのテスト ケースのアタッチ」を参照してください。
パフォーマンスなどのサービス品質要求は、ユース ケース図、アクティビティ図、またはシーケンス図でコメントとして記述できます。 これらも要求の作業項目とそのテスト スイートにリンクできます。
テスト用のシーケンス図とアクティビティ図
要求モデルまたはアーキテクチャ モデルにシーケンス図またはアクティビティ図が含まれている場合は、図に直接基づくテストを記述できます。
図で分岐またはループを使用することで、異なるパスを動的に選択するテストを設計すると効果的な場合もあります。
各メッセージまたはアクションの後のシステムの状態を確認するようにしてください。 そのためには、追加のインストルメンテ―ションが必要になる場合があります。
モデルに基づくサブシステム テストの生成
大規模なシステムの高度な設計では、コンポーネントまたはサブシステムを識別できます。 これらは、別々に設計できるパート、複数の異なるコンピューターに配置されているパート、またはさまざまな方法で再結合できる再利用可能なモジュールです。 詳細については、「UML コンポーネント図: ガイドライン」を参照してください。
主要な各コンポーネントには、完全なシステムで使用するものと同じ基本原則を適用できます。 大規模なプロジェクトでは、各コンポーネントに独自の要求モデルを設定できます。 小規模なプロジェクトでは、主要なコンポーネントとそれらの相互作用を示すアーキテクチャ モデルまたは高度な設計を生成できます。 詳細については、「ソフトウェア システムのアーキテクチャのモデリング」を参照してください。
どちらの場合も、要求モデルとシステム テストの関係を確立するときと同じ方法で、モデル要素とサブシステム テストの関係を確立できます。
提供インターフェイスおよび要求インターフェイスを使用したコンポーネントの分離
システムの他のパートまたは外部サービスに対するコンポーネントの依存関係をすべて特定し、これらの依存関係を要求インターフェイスとして表現することをお勧めします。 この作業の行った場合、通常、コンポーネントの分離度を格段に高め、設計の残りの部分から容易に分離できる状態を維持するための再設計が必要になります。
こうした分離の利点の 1 つに、コンポーネントが通常使用するサービスをモック オブジェクトに置き換えることにより、コンポーネントをテスト目的で実行できるという点があります。 これらは、テスト目的で設定されるコンポーネントです。 モック コンポーネントは、コンポーネントに必要なインターフェイスを提供し、ダミー データでクエリに応答します。 モック コンポーネントは、コンポーネントのすべてのインターフェイスに接続できる完全なテスト ハーネスの一部を構成します。
モック テストの利点の 1 つに、コンポーネントが使用するサービスを提供する他のコンポーネントの開発中にも、コンポーネントの開発を進めることができるという点があります。
テストとモデルの関係の維持
数週間おきにイテレーションを行う一般的なプロジェクトでは、要求のレビューは各イテレーションの開始直後に行われます。 このミーティングでは、次のイテレーションで提供予定の機能について話し合います。 要求モデルは、概念、シナリオ、および開発予定のアクションのシーケンスについて話し合う際に役立ちます。 ビジネス上の関係者が優先順位を決め、開発者が見積もりを行い、テスト担当者が各機能の動作が正しく実現されていることを確認します。
テストを記述することは、要求を定義するための最も効果的な方法です。また、何が必要かを関係者が明確に把握するための効果的な手段でもあります。 ただし、テストの記述には時間がかかるので、仕様ワークショップ中には実行できません。一方、モデルの生成ははるかに短時間で済みます。
テストの観点からすると、要求モデルはテストのための迅速な手段ととらえることができます。 したがって、プロジェクト全体にわたってテストとモデルの関係を維持することが重要です。
モデル要素へのテスト ケースのアタッチ
プロジェクトで テスト マネージャー を使用する場合は、テストをモデル内の要素にリンクできます。 こうすることで、要求の変更の影響を受けるテストをすばやく特定でき、要求が満たされている範囲を追跡できます。
テストのリンク先には、あらゆる種類の要素を指定できます。 次にいくつかの例を示します。
ユース ケースを、そのユース ケースを実行するテストにリンクできます。
ユース ケースの事後条件 (目的) の句を、そのユース ケースにリンクされたコメントに記述し、テストを各コメントにリンクできます。
クラス図またはアクティビティ図のコメントに不変ルールを記述し、それをテストにリンクできます。
アクティビティ図または個々のアクティビティにテストをリンクできます。
テスト スイートを、テスト対象のコンポーネントまたはサブシステムにリンクできます。
モデル要素または関係にテストをリンクするには
テスト マネージャー で要求を作成し、それに基づいてテスト スイートを作成します。 その方法については、「要件またはユーザー ストーリーを使用したテスト計画の作成」を参照してください。
作成する要求は、Team Foundation Server の作業項目です。 プロジェクトが Team Foundation で使用するプロセス テンプレートに応じて、ユーザー ストーリー、要求、またはユース ケースのいずれかの作業項目を作成します。 詳細については、「プロジェクトの計画および追跡」を参照してください。
要求の作業項目をモデルの 1 つ以上の要素にリンクします。
モデル図で、要素、コメント、または関係を右クリックし、[作業項目へリンク] をクリックします。 詳細については、「方法: 作業項目をモデル要素にリンクする」を参照してください。
モデル要素で表された要求を検証するテスト ケースをテスト スイートに追加します。