次の方法で共有

モデルからテストを開発する

  • [アーティクル]

システムとそのコンポーネントのテストを編成する際に、要件モデルとアーキテクチャ モデルを使用できます。 こうすることで、ユーザーやその他の利害関係者にとって重要な要求をテストしやすくなり、要求が変更された場合にすばやくテストを更新することができます。 Microsoft Test Manager を使用した場合、モデルとテストの間のリンクを維持することもできます。

これら機能をサポートする Visual Studio のバージョンを確認するには、「アーキテクチャ ツールとモデリング ツールのバージョン サポート」を参照してください。

システムとサブシステムのテスト

"システム テスト" は "受け入れテスト" とも呼ばれ、ユーザーのニーズが満たされているかどうかをテストするものです。 このようなテストでは内部の設計ではなく、外部から確認できるシステムの動作に焦点が当てられます。

システムの拡張またはシステムの再設計を行う場合、システム テストは非常に価値があります。 これらのテストにより、コードの変更時にバグの発生を回避することができます。

システムに対して変更や拡張を計画している場合、既存のシステム上で実行される一連のシステム テストから始めることをお勧めします。 次に新しい要求をテストするようにテストを拡張または調整して、コードの変更を行い、テストの完全セットを実行します。

新しいシステムを開発する場合、開発作業を開始してすぐに、テストの作成を開始することができます。 各機能を開発する前にテストを定義することで、非常に具体的な方法で、要求に関する検討項目を把握することができます。

サブシステムのテストでは、システムの主要コンポーネントに同じ原則が適用されます。 各コンポーネントは、他のコンポーネントとは別個にテストされます。 サブシステムのテストでは、コンポーネントのユーザー インターフェイスまたは API で確認できる動作を集中的にテストします。

要求モデルからシステム テストを派生させる

システム テストと要求モデル間の関係を作成して、それを維持することができます。 この関係を確立するには、要求モデルの主要な要素に対応するテストを作成します。 Visual Studio を使用すると、テストとモデルの部分間のリンクを作成することで、その関係を維持できます。 要求モデルの詳細については、「ユーザー要件のモデリング」を参照してください。

各ユース ケースのテストの作成

Microsoft Test Manager を使用している場合、要求モデル内で定義した各ユース ケースに対して、一連のテストを作成することができます。 たとえば、Create Order および Add Item to Order を含んでいる Order a Meal というユース ケースがある場合、全体に対するテストと、これらのユース ケースの細部に対する両方のテストを作成できます。

次のガイドラインが役立つ場合があります。

  • 各ユース ケースでは、主要パスと例外的な結果の両方に対して、複数のテストが必要です。

  • 要求モデルでユース ケースを記述する場合、重要な点は、目標を達成するためにユーザーが従う必要がある詳細な手順ではなく、事後条件 (つまり達成する目標) を記述することです。 たとえば、Order a Meal の事後条件は、レストランがお客様に対して食事を準備することや、お客様が支払いを済ませることになるでしょう。 事後条件とは、テストで確認する必要がある基準です。

  • 事後条件の個別の句に関して、別個のテストを作成します。 たとえば、レストランに注文を通知する場合と、お客様から支払いを受ける場合では、別のテストを作成します。 テストをこのように分離すると、次のメリットが得られます。

    • 要求のさまざまな側面に関する変更は、多くの場合、独立して発生します。 テストをこのようにさまざまな側面に切り離すことで、要求が変更された場合に、テストを更新することが簡単になります。

    • 開発計画により、別の側面を実装する前にユース ケースの 1 つの側面を実装した場合、開発の進捗に合わせて、テストを個別に有効にすることができます。

  • テストを設計するときに、事後条件が満たされたかどうかを判断するコードやスクリプトから、選択したテスト データを切り離してください。 たとえばシンプルな算術関数のテストの場合、Input 4; verify that the output is 2 などになります。 代わりに、Choose an input; multiply the output by itself, verify that the result is the original input などのスクリプトを設計します。 このスタイルを使うと、テストの本体を変更することなく、テストの入力を変更できます。

ユース ケースへのテストのリンク

Test Manager を使ってテストの設計と実行を行っている場合、要求、ユース ケース、またはユーザー ストーリーの作業項目の下でテストを編成することができます。 モデル内のユース ケースを、このような作業項目にリンクできます。 これにより、要求の変更を迅速に追跡してテストすることができます。また、各ユース ケースの進捗も追跡しやすくなります。

  1. Test Manager で要求を作成し、その要求に対してテスト スイートを作成します。

    作成した要求は、Team Foundation Server の作業項目になります。 これは、Team Foundation でプロジェクトが使用するプロセス テンプレートに応じて、ユーザー ストーリー、要求、ユース ケースの作業項目などになります。 詳細については、アジャイル ツールとアジャイル プロジェクト管理に関するページを参照してください。

  2. モデル内の 1 つまたは複数のユース ケースに対して、要求の作業項目をリンクします。

    ユース ケース図でユース ケースを右クリックし、 [作業項目へリンク] をクリックします。

  3. テスト スイートに追加して、ユース ケースを確認するケースをテストします。

    通常、各ユーザー ストーリーまたは要求の作業項目は、モデル内の複数のユース ケースにリンクされます。また、各ユース ケースは複数のユーザー ストーリーや要求にリンクされます。 これは、各ユーザー ストーリーや要求が複数のユース ケースを開発する、一連のタスクを対象としているためです。 たとえば、プロジェクトの初期のイテレーションで、お客様がカタログから商品を選択し、配送を依頼することができる基本的なユーザー ストーリーを開発することができます。 後期のイテレーションでは、注文の終了時にお客様が支払いをして、商品が出荷された後、業者がお金を受け取るというストーリーになっていることがあります。 ストーリーごとに、Order Goods ユース ケースの事後条件に句が追加されます。

    ユース ケース図で個別のコメントに句を書き込むことで、事後条件の句に要件から個別のリンクを作成することができます。 要求の作業項目に対して各コメントをリンクしたり、図のユース ケースに対してコメントをリンクしたりすることができます。

要求型に関する基本テスト

型 (要求モデルの句、インターフェイス、列挙) では、ユーザーがビジネスについてどのように考え、やり取りするかという点について、概念と関係を記述します。 この場合、システムの内部設計にのみ関連する型は除外されます。

このような要求の種類に応じて、テストを設計してください。 このようにすることで、要求に対する変更を検討する場合、テストの中で、変更点を必要な変更に関連付けることが簡単にできます。 これにより、テストや想定される結果を、エンドユーザーおよびその他の利害関係者と直接検討することが可能になります。 つまり、開発プロセスの外部でユーザーのニーズを維持し、設計内の潜在的な欠点に関して、不注意でテストを設計することを回避できるということです。

手動テストの場合、この方法には、テスト スクリプト内の要求モデルのボキャブラリに準拠することが含まれます。 自動テストの場合、この方法には、テスト コードのベースとして要件クラス図を使用すること、および要件モデルをコードにリンクするため、評価機能と更新機能を作成することが含まれます。

たとえば、要求モデルに、Menu、Menu Item、Order などの型と、その型の間の関連付けが含まれていることがあります。 このモデルは、食事注文システムによって格納され処理される情報を表していますが、その実装の複雑さを表わしてはいません。 作業システムでは、データベース、ユーザー インターフェイス、API などに、各型が複数の異なる形で存在していることがあります。 分散システムでは、システムのさまざまな部分に保存された各インスタンスのバリエーションが、複数同時に存在することがあります。

Add Item to Order などのユース ケースをテストするため、テスト メソッドに次のようなコードが含まれていることがあります。

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 を介して使用できる状態になります。 しかし、テストを有効にするには、追加機能を作成することが必要になる場合があります。 これらの追加のアクセサーとアップデーターは、「テスト インストルメンテーション」と呼ばれることもあります。 これらの機能はシステムの内部設計に依存しているため、それらを提供するのはシステム開発者の役割です。一方テスト担当者は、要求モデルに関するテスト コードを作成します。

自動テストを作成する場合、汎用テストを使ってアクセサーとアップデーターをラップすることができます。

ビジネス ルールのテスト

要求の中には、特定のユース ケースに直接は関連していないものがあります。 たとえば、DinnerNow では、お客様は多くのメニューから選択できますが、1 回の注文では、1 つのメニューからすべての項目を選択する必要があります。 このビジネス ルールは、要求クラス モデル内の Orders、Menus、Items 間の関連付けについてのインバリアントとして表現することができます。

このようなインバリアント ルールは、現在定義されているすべてのユース ケースだけでなく、今後定義される予定の他のすべてのユース ケースも制御します。 このため、このようなルールはユース ケースとは別に作成し、ユース ケースとは別にテストすると有効です。

モデルからサブシステム テストを派生させる

大規模システムのハイレベル設計では、コンポーネントまたはサブシステムを特定できます。 これらは、個別に設計可能なパーツ、別のコンピューターに配置できるパーツ、さまざまな方法で再結合できる再利用可能モジュールなどを表しています。

システム全体に対して使用した原則と同じ原則が、各主要コンポーネントに対しても適用できます。 大規模なプロジェクトでは、各コンポーネントは、独自の要求モデルを持つことができます。 小さいプロジェクトでは、アーキテクチャ モデルやハイレベル設計を作成して、主要コンポーネントとその相互作用を表わすことができます。 詳細については、「アプリのアーキテクチャをモデル化する」を参照してください。

いずれの場合でも、要求モデルとシステム テスト間と同じ方法で、モデル要素とサブシステム テスト間の関係を確立することができます。

提供されたインターフェイスと要求インターフェイスを使ったコンポーネントの分離

システムの他の部分や外部サービスにおける、特定のコンポーネントのすべての依存関係を特定し、それを要求インターフェイスとして表すことが役立ちます。 この方法により、通常はいくらかの再設計を行うことになります。これにより、コンポーネントは非常に分離しやすくなり、設計の他の部分から簡単に切り離すことができます。

このような分離の利点は、コンポーネントが通常使用しているサービスをモック オブジェクトに置き換えることで、コンポーネントのテストが実行できることです。 これらは、テスト目的で設定されているコンポーネントです。 モック コンポーネントは、シミュレートされたデータによる照会に反応して、コンポーネントで必要になるインターフェイスを提供します。 モック コンポーネントは、コンポーネントのすべてのインターフェイスに接続できる、完全なテスト ハーネスの一部を形成します。

モック テストの利点は、そのコンポーネントで使われるサービスの他のコンポーネントが開発中の場合でも、コンポーネントを開発できることです。

テストとモデル間の関係の維持

数週間ごとにイテレーションが発生する一般的なプロジェクトでは、毎回イテレーションの開始が近くなると、要求の見直しが実行されます。 ミーティングでは、次回のイテレーションで提供予定の機能について検討されます。 要求モデルを使うと、開発予定の概念、シナリオ、操作シーケンスを検討しやすくなります。 ビジネスの利害関係者が優先順位を設定し、開発者が見積もりを行い、テスト担当者が各機能の想定される動作が適切に捕捉されていることを確認します。

要求を定義するには、テストを作成することが最も効果的な方法です。また、何が求められているかについて各自が明確に理解しているか、確認することも有効な方法です。 ただしテストの作成は時間がかかりすぎて、仕様ワークショップ中に実行することはできませんが、モデルの作成はそれよりもはるかに短時間で実行できます。

テストの観点から見た場合、要求モデルは簡略化されたテストと見なすことができます。 そのため、プロジェクト中は常に、テストとモデル間の関係を維持することが重要です。

テスト ケースをモデル要素へアタッチする

プロジェクトで Test Manager を使用している場合、テストをモデル内の要素にリンクすることができます。 これにより、要求内の変更によって影響を受けるテストを迅速に見つけることができ、要求が実現される範囲を追跡しやすくなります。

すべての種類の要素に、テストをリンクできます。 次に例をいくつか示します。

  • ユース ケースを、それを実行するテストにリンクします。

  • ユース ケースの事後条件または目的を、ユース ケースにリンクされているコメントに記述します。次に、テストを各コメントにリンクします。

  • クラス図またはアクティビティ図のコメントにインバリアント ルールを記述し、それをテストにリンクします。

  • テストをアクティビティ図、または個々のアクティビティにリンクします。

  • テスト スイートを、テスト対象のコンポーネントまたはサブシステムにリンクします。

  1. Test Manager で要求を作成し、その要求に対してテスト スイートを作成します。

    作成した要求は、Team Foundation Server の作業項目になります。 これは、Team Foundation でプロジェクトが使用するプロセス テンプレートに応じて、ユーザー ストーリー、要求、ユース ケースの作業項目などになります。 詳細については、アジャイル ツールとアジャイル プロジェクト管理に関するページを参照してください。

  2. モデル内の 1 つまたは複数の要素に対して、要求の作業項目をリンクします。

    モデリング図で、要素、コメント、または関係を右クリックし、 [作業項目へリンク] をクリックします。

  3. テスト スイーツに追加し、モデル要素内で表された要求を検証するケースをテストします。

関連するコンテンツ