ガイドライン:
|
シナリオ 1 | 基本フロー | |||
シナリオ 2 | 基本フロー | 代替フロー 1 | ||
シナリオ 3 | 基本フロー | 代替フロー 1 | 代替フロー 2 | |
シナリオ 4 | 基本フロー | 代替フロー 3 | ||
シナリオ 5 | 基本フロー | 代替フロー 3 | 代替フロー 1 | |
シナリオ 6 | 基本フロー | 代替フロー 3 | 代替フロー 1 | 代替フロー 2 |
シナリオ 7 | 基本フロー | 代替フロー 4 | ||
シナリオ 8 | 基本フロー | 代替フロー 3 | 代替フロー 4 |
注: 単純化を図るために、シナリオ 5、6、8 では、代替フロー 3 によって示されるループを 1 回だけ実行するように描いています。
各シナリオからテスト ケースを導出するためには、その具体的なユース ケース シナリオを実行する引き金となる具体的な条件を識別します。
たとえば、上のダイアグラムに描かれているユース ケースの代替フロー 3 の記述が次のようであると仮定します。
上の「ステップ 2 引き出し額の入力」で入力された金額が、現在の口座残高よりも大きい場合に、このイベント フローが発生します。システムは警告メッセージを表示し、その後で上の「ステップ 2 引き出し額の入力」の所で基本フローに合流します。そこで、顧客は引き出し額を入力し直すことができます。
この情報を用いて、代替フロー 3 を実行するのに必要なテスト ケースの検討を開始できます。
テスト ケース ID | シナリオ | 条件 | 期待される結果 |
TC x | シナリオ 4 | ステップ 2: 引き出し額 > 口座残高 | ステップ 2 で基本フローに合流 |
TC y | シナリオ 4 | ステップ 2: 引き出し額 < 口座残高 | 代替フロー 3 を取らず、基本フローに従う |
TC z | シナリオ 4 | ステップ 2: 引き出し額 = 口座残高 | 代替フロー 3 を取らず、基本フローに従う |
メモ: 上に示したテスト ケースは、ほかに情報がなく、非常に単純です。実際のテスト ケースがこのように単純なことはまれです。
ユース ケースからテスト ケースを導出するもっと現実的な例を次に示します。
例
ATM マシン内のアクターとユース ケース
上のダイアグラムの現金引き出しユース ケースに関する基本フローといくつかの代替フローを下の表にまとめます。
基本フロー | ATM が待機している状態でこのユース ケースは開始される。
ATM が待機状態に戻り、ユース ケースは終了する。 |
代替フロー 1: 無効なカード | 基本フローの「ステップ 2: キャッシュ カードの照合」で、カードが有効でない場合は適切なメッセージを表示し、キャッシュ カードを排出する。 |
代替フロー 2: ATM の現金切れ | 基本フローの「ステップ 5:ATM オプション」で、ATM の現金がない場合、「現金引き出し」オプションは使用できない。 |
代替フロー 3: ATM の現金不足 | 基本フローの「ステップ 6: 金額の入力」で、ATM に残っている現金が要求された金額に足りない場合、適切なメッセージが表示され、このフローは基本フローの「ステップ 6: 金額の入力」に戻る。 |
代替フロー 4: 暗証番号の誤り | 基本フローの「ステップ 4: 口座番号と暗証番号の照合」で、顧客は正しい暗証番号の入力を 3 回まで行える。 入力された暗証番号が正しくないと、適切なメッセージが表示され、まだ入力回数が残っていれば、このフローは「ステップ 3: 暗証番号の入力」に戻る。 3 回目でも、入力された暗証番号が正しくないと、キャッシュ カードは排出されず、ATM は待機状態に戻り、このユース ケースは終了する。 |
代替フロー 5: 口座なし | 基本フローの「ステップ 4: 口座番号と暗証番号の照合」で、口座が見つからないか、または口座から引き出しが認められていないことを示すコードが銀行システムから返された場合、適切なメッセージが表示され、このフローは「ステップ 9: カードの返却」で基本フローに合流する。 |
代替フロー 6: 口座残高の不足 | 基本フローの「ステップ 7: 承認」で、基本フローの「ステップ 6: 金額の入力」で入力された金額よりも口座の残高が少ないことを示すコードが銀行システムから返された場合、適切なメッセージが表示され、このフローは「ステップ 6: 金額の入力」に戻る。 |
代替フロー 7:1 日の引き出し限度に到達 | 基本フローの「ステップ 7: 承認」で、この引き出し取り引きを含めて顧客が 24 時間以内に認められる引き出し限度額を既に超過しているか超過することになることを示すコードが銀行システムから返された場合、適切なメッセージが表示され、このフローは「ステップ 6: 金額の入力」に戻る。 |
代替フロー x: ログのエラー | 基本フローの「ステップ 10: 明細」で、ログを更新できなかった場合、ATM は「安全モード」に入り、すべての機能が一時停止する。ATM が運転を一時停止したことを示すために、適切な警報が銀行システムに送られる。 |
代替フロー y: 終了 | 顧客は任意の時点でトランザクションを中止 (終了) することができる。すると、トランザクション処理は停止し、キャッシュ カードが排出される。 |
代替フロー z: 一時停止 | ATM には、電力、ドアや入り口にかかる圧力を測定するなどの種々の監視機能を果たす多数のセンサーと動作検知器が備えられている。 任意の時点でセンサーが異常を感知すると、警報が警察に送られ、ATM は「安全モード」に入り、すべての機能が一時停止する。適切な再起動 / 再初期化アクションが取られるまで、ATM は動かない。 |
|
このユース ケースから下記のシナリオを導出できます。
シナリオ 1: 正常な現金引き出し | 基本フロー | |
シナリオ 2:ATM の現金切れ | 基本フロー | 代替フロー 2 |
シナリオ 3:ATM の現金不足 | 基本フロー | 代替フロー 3 |
シナリオ 4: 暗証別番号の誤り (再入力の余地あり) | 基本フロー | 代替フロー 4 |
シナリオ 5: 暗証番号の誤り (再入力の余地なし) | 基本フロー | 代替フロー 4 |
シナリオ 6: 口座なし / 不適切な口座タイプ | 基本フロー | 代替フロー 5 |
シナリオ 7: 口座残高の不足 | 基本フロー | 代替フロー 6 |
メモ: 単純化を図るために、代替フロー 3 と 6 (シナリオ 3 と 7) 中のループとループの組み合わせは上の表に含めていません。
これらの 7 つの各シナリオに関して、テスト ケースを設定する必要があります。テスト ケースの設定と管理にはメトリクスまたは決定テーブルが使用できます。その一般的なフォーマットを次に示します。各行は個々のテスト ケースを表します。各欄はテスト ケースに関する情報を示します。この例では、各テスト ケースにテスト ケース ID、条件 (または摘要)、テスト ケースに関係するすべてのデータ要素 (入力としてまたはデータベースに既存)、期待される結果があります。
メトリクスの作成は、ユース ケース シナリオを実行するのに必要なデータ要素を挙げることから始めます。そして、各シナリオを実行するのに適切な条件を持つテスト ケースを、最低限 1 つ設定します。たとえば、下のメトリクスにおいて、基本フローを実行するためには該当の条件が有効でなければならないことを示す場合は V (有効) を使用し、代替フローを起動する条件を示す場合は I (無効) を使用します。該当の条件が該当のテスト ケースに適用されないことを示す場合は、"n/a" を使用しています。
テスト ケース ID# | シナリオ / 条件 | 暗証番号
|
口座番号
|
入力 (選択) 金額
金額
|
口座残高
|
ATM 残高
|
期待される結果 |
CW1. | シナリオ 1: 正常な現金の引き出し | V | V | V | V | V | 現金を正常に引き出せる。 |
CW2. | シナリオ 2: ATM の現金切れ | V | V | V | V | I | 現金引き出しオプションが利用できず、ユース ケースを終了。 |
CW3. | シナリオ 3: ATM の現金不足 | V | V | V | V | I | 警告メッセージが表示され、基本フローの「ステップ 6: 金額の入力」に戻る。 |
CW4. | シナリオ 4: 暗証別番号の誤り (再入力の余地あり) | I
|
V | 該当なし | V | V | 警告メッセージが表示され、基本フローの「ステップ 4: 暗証番号の入力」に戻る。 |
CW5. | シナリオ 4: 暗証番号の誤り (再入力可能回数: 残り 1 回) | I
|
V | 該当なし | V | V | 警告メッセージが表示され、基本フローの「ステップ 4: 暗証番号の入力」に戻る。 |
CW6. | シナリオ 4: 暗証番号の誤り (再入力可能回数: 残り 0 回) | I
|
V | 該当なし | V | V | 警告メッセージが表示され、カードは排出されず、ユース ケースを終了。 |
上のメトリクスに、4 つのシナリオに関するテスト ケースが 6 つ挙げられています。基本フローに関するテスト ケース CW1 はいわゆる肯定的なテスト ケースです。このテスト ケースでは、基本フローから外れることなく、ユース ケース内の処理の流れが貫徹します。基本フローを総合的にテストするためには、否定的なテスト ケースを含めて、条件が正しい場合にのみ基本フローに沿って処理が行われることを確認する必要があります。そのような否定的なテスト ケースは、テスト ケース CW2 ~ 6 で取り上げられています (メトリクス内の網掛けされたセルは代替フローに進むために必要な条件を示します)。CW2 ~ 6 は基本フローに対しては否定的なテスト ケースですが、代替フロー 2 ~ 4 に対しては肯定的なテスト ケースです。それらの代替フローのそれぞれに関して、少なくとも 1 つの否定的なテスト ケース (CW1 - 基本フロー) があります。
シナリオ 4 は肯定的、否定的なテスト ケースをシナリオあたり 1 つだけ用意するのでは不十分な例です。「シナリオ 4: 暗証番号の誤り」を徹底的にテストするためには、(シナリオ 4 を起動するために) 肯定的なテスト ケースが少なくとも 3 つ必要です。
上のメトリクスにおいて、条件 (データ) に実際の値が示されていないことに注意してください。テスト ケースのメトリクスをこのような形で作成することの利点は、どの条件がテストされているのかを見分けやすいことです。また、十分なテスト ケースが設定されたかどうかを判定するのも非常に容易になり ます。V と I (または網掛けされたセル) だけに注目するだけでよいからです。上の表を見ると、セルに網掛けされていない条件がいくつかあります。したがって、テスト ケースが欠けていることがわかります。具体的には、「シナリオ 6: 口座なし、または不適切な口座タイプ」と「シナリオ 7: 口座残高の不足」が挙げられます。
すべてのテスト ケースの設定が済んだら、それらをレビュー、検証して正確性と適切性を確認し、重複または同等のテスト ケースがあれば削除します。「テスト ケースのためのテスト データの定義」の追加情報も参照してください。
テスト ケース ID# | シナリオ / 条件 | 暗証番号
|
口座番号
|
入力 (選択) 金額
金額
|
口座残高
|
ATM 残高
|
期待される結果 |
CW1. | シナリオ 1: 正常な現金の引き出し | 4987 | 809 - 498 | 50.00 | 500.00 | 2,000 | 現金を正常に引き出せる。口座残高が 450.00 に更新される。 |
CW2. | シナリオ 2: ATM の現金切れ | 4987 | 809 - 498 | 100.00 | 500.00 | 0.00 | 現金引き出しオプションが利用できず、ユース ケースを終了。 |
CW3. | シナリオ 3: ATM の現金不足 | 4987 | 809 - 498 | 100.00 | 500.00 | 70.00 | 警告メッセージが表示され、基本フローの「ステップ 6: 金額の入力」に戻る。 |
CW4. | シナリオ 4: 暗証別番号の誤り (再入力の余地あり) | 4978
|
809 - 498 | 該当なし | 500.00 | 2,000 | 警告メッセージが表示され、基本フローの「ステップ 4: 暗証番号の入力」に戻る。 |
CW5. | シナリオ 4: 暗証番号の誤り (再入力可能回数: 残り 1 回) | 4978
|
809 - 498 | 該当なし | 500.00 | 2,000 | 警告メッセージが表示され、基本フローの「ステップ 4: 暗証番号の入力」に戻る。 |
CW6. | シナリオ 4: 暗証番号の誤り (再入力可能回数: 残り 0 回) | 4978
|
809 - 498 | 該当なし | 500.00 | 2,000 | 警告メッセージが表示され、カードは排出されず、ユース ケースを終了。 |
上に示したテスト ケースは、この反復での現金引き出しユース ケースを検証するために必要なテスト ケースの一部にすぎません。ほかにも、次のようなテスト ケースが必要です。
将来の反復において、ほかのフローが実装されると、下記のためのテスト ケースも必要になります。
機能テスト ケースを設定するときに、次の点を確実に行うようにします。
「テスト ケースのためのテスト データの定義」の追加情報も参照してください。
テスト対象に対する要求がすべて、ユース ケース仕様などの機能要求に反映されるとは限りません。性能、セキュリティとアクセス、構成要求のような機能外要求は、テスト対象に追加の振る舞いまたは特性を指定し、多くの場合、機能要求とは別に文書化されます。それらの追加的な要求に関するテスト ケースを導出するための主な情報源となるのが補足仕様書です。
追加のテスト ケースを導出するための下記のガイドラインを以降に説明します。
性能用のテスト ケースの主要な入力源となるのは補足仕様書です。これには機能外要求が記載されています (「成果物: 補足仕様書」参照)。性能テストのためのテスト ケースを導出するときは、次のガイドラインに従います。
機能テストのためのテスト ケースと同様に、使用シナリオまたは要求につき少なくとも 2 つのテスト ケースを用意するのが普通です。性能の管理限界値を下回る場合 (平均トランザクション率)、重なる場合 (高トランザクション率)、ちょうど上回る場合 (ピーク トランザクション率) のそれぞれに 1 つずつテスト ケースを用意するのがもっと一般的な方法です。
上記の性能基準に加えて、応答時間に影響を与える特殊な条件を明らかにするようにします。
機能テストのために使用したのと同様のメトリクスを使用して、性能テストに関するテスト ケースをまとめます。
「テスト ケースのためのテスト データの定義」の追加情報も参照してください。
さまざまなタイプの性能テストの例を下に示します。
負荷テスト:
テスト ケース ID# | 作業量 | 条件 | 期待される結果 |
PCW1. |
1 (1 台の ATM) |
引き出しトランザクションの完了 |
20 秒未満でトランザクションを完了 (アクターに依存しない処理の時間) |
PCW2. |
2 (1,000 台の ATM が同時に稼働) |
引き出しトランザクションの完了 |
30 秒未満でトランザクションを完了 (アクターに依存しない処理の時間) |
PCW3. |
3 (10,000 台の ATM が同時に稼働) |
引き出しトランザクションの完了 |
50 秒未満でトランザクションを完了 (アクターに依存しない処理の時間) |
ストレス テスト:
テスト ケース ID# | 作業量 | 条件 | 期待される結果 |
SCW1. |
2 (1,000 台の ATM が同時に稼働) |
データベースのロック: 2 台の ATM で同じ口座を要求 |
ATM からの要求が待ち行列に入れられる |
SCW2. |
2 (1,000 台の ATM が同時に稼働) |
銀行システムとの通信が不能 |
トランザクションは待ち行列に入れられるかタイムアウトとなる |
SCW3. |
2 (1,000 台の ATM が同時に稼働) |
トランザクションを処理中に銀行システムとの通信が切断される |
警告メッセージが表示される |
アクターとユース ケースは、システムの外部ユーザーと特定のアクターに与える値を生成するためにシステム アクションとの間の相互作用を説明します。複雑なシステムには多くのアクターが参加します。したがって、ユース ケースを実行するように指定されたアクターだけが実行できるようなテスト ケースを開発することが、きわめて重要になります。アクターのタイプによってユース ケースのイベント フローに違いがある場合は特に重要です。
たとえば、ATM のユース ケースにおいて、アクターが ATM を所有する銀行に口座を持つ顧客、他行に口座を持つ顧客、さらには銀行以外のカードを使用しようとする顧客である場合は、ユース ケースのイベント フローは異なって実行されることがあります。
機能テスト用のテスト ケースとして上に示したのと同じガイドラインに従います。
「テスト ケースのためのテスト データの定義」の追加情報も参照してください。
セキュリティとアクセスのためのテスト ケースの例を下に示します。
テスト ケース ID# | 条件 | カード
(V は有効なカードを示す) |
カード リーダー
(V はリーダーが適切に作動することを示す) |
銀行ネットワーク | 期待される結果 |
ACW1. | 銀行内のネットワーク | V | V | V | すべてのユース ケースを利用可能 |
ACW2. | 銀行外のネットワーク | V | V | I | 現金引き出しユース ケースのみ |
ACW3. | カードを読めない | I | V | V | 警告メッセージ、カードは排出される |
ACW4. | カードの盗難届あり | I | V | V | 警告メッセージ、カードは排出されない |
ACW5. | カードは失効 | I | V | V | 警告メッセージ、カードは排出されない |
典型的な分散システムにおいては、サポートの対象として認められているハードウェアとソフトウェアの組み合わせは多数になることがあります。したがって、種々の構成においてテスト対象の機能または性能が十分であることを検証するためのテストを実施する必要があります。それらの異なる構成の要素としては、オペレーティング システム、ブラウザ、CPU 速度などが挙げられます。さらに、種々のコンポーネントの相互作用から生ずる欠陥を見つけ出すために、コンポーネントの組み合わせをテストする必要もあります。たとえば、あるアプリケーションによってインストールされた DLL のバージョンが、ほかのアプリケーションによって期待されている同じ DLL の別のバージョンと矛盾しないことを確認する必要があります。
構成テストのためのテスト ケースを導出するには、次のガイドラインに従います。
インストール テストでは、可能なすべてのシナリオのもとでテスト対象がインストール可能であることを検証する必要があります。インストール シナリオには、テスト対象を初めてインストールする場合、あるいはテスト対象の新しいバージョンまたはビルドの (古いバージョンがインストールされているマシンに) インストールなどが含まれます。インストール テストではまた、ディスク容量が足りないといった異常な条件に遭遇したときに、テスト対象の実行結果が受け入れられることを確認する必要があります。
テスト ケースでは次のようなソフトウェアのインストール シナリオをカバーする必要があります。
クライアント / サーバー ソフトウェア用のインストール プログラムには、特殊化された一連のテスト ケースがあります。ホストベースのシステムとは異なり、インストール プログラムは通常はサーバーとクライアント用に分割されています。したがって、インストール テストでは、クライアント、ミドルウェア、サーバーを含むテスト対象のすべてのコンポーネントのインストールを実行することが重要です。
理想的には、ユース ケース モデル、設計モデル、補足仕様書の各成果物の中からテスト ケースを導出するために必要なすべての入力情報を見つけ出すべきです。しかし、この時点で後から見つかったことを捕捉する必要に迫られることは珍しくありません。
その例を次に示します。
ほとんどの場合、前に挙げたケースから導出されたテスト ケースを変形または集成することによって、これらのテスト ケースを見つけ出すことができます。
製品受け入れテストはソフトウェアを導入する前の最後のテスト アクションです。受け入れテストの目的は、ソフトウェアの準備が整い、その設計目的の機能とタスクを遂行するためにエンドユーザーが使用できるようになったことを検証することです。製品の受け入れテストには、多くの場合、ソフトウェアを実行して準備状況を見る以上のことが含まれます。トレーニング、文書、パッケージングのような、すべての成果物を顧客に納入することも含まれます。
ソフトウェア成果物のためのテスト ケースを導出することは、これまで上で述べた方法で行います。製品受け入れテストの公式性の度合いに応じて、テスト ケースは上で示したものと同じまたは類似したものとするか (公式)、あるいはそのサブセット (非公式) とします。テスト ケースの深さとは関係なく、テスト ケースと製品検収基準について合意に達してから、製品受け入れテストの実装と実行を行うべきです。
ソフトウェア外成果物に関するテスト ケースは、評価対象の成果物に応じて、大幅に異なります。ソフトウェア外成果物の評価とその方法については、それぞれのソフトウェア外成果物のガイドラインとチェックリストを参照してください。
回帰テストでは、同じテスト対象の 2 つのビルドまたはバージョンを比較して、潜在的な欠陥としての差異を洗い出します。つまり、新しいバージョンは前のバージョンと同様に動作すべきであると想定して、変更の結果に欠陥が入り込まないようにします。
ある反復で使用したすべてのテスト ケースを後の反復で使用できると理想的です。回帰テストと再利用の値を最大化しながら、メンテナンスを最少に保つようなテスト ケースを設定、設計、実装するためには、次のガイドラインに従います。
テスト ケースの検討を行い、一般的な合意または承認が得られると、実際のデータ値をより詳細に示すことができ (テスト ケースの実装マトリクス)、テスト データ成果物が作成されます。
テスト データの定義と管理については、「ガイドライン: テスト データ」を参照してください。
Rational Unified Process
|