トピック

説明 ページの先頭へ

プロジェクト チームが利害関係者のソフトウェアに対する要求を満たせるかどうかに最も影響するのは、利害関係者が何を期待するかを明確に仕様化できるかにあります。要求仕様が十分であるかどうかにせよ、テスト ケースは、利害関係者の期待を反映し、その期待を検証するための 1 成果物です。

十分な要求がある場合、テスト チームは、その要求を適宜検証するテストを計画する必要があります。要求に対するソフトウェアの検証は、要求のタイプに応じて異なる形で行えます。たとえば、機能と性能を検証するためにソフトウェアを実行する場合、テスト担当者は自動的なテスト技法を使用しますが、ホスト コンピュータ システムのシャットダウンのような構成要求の検証には、手作業によるテスト技法が必要とされます。

すべての要求を検証することは不可能な (または責任は負えない) ため、現在の作業の範囲内で最も適切な、または重要な要求に重点を置くことが大切です。検証のための技法は、コスト、リスク、要求を検証する必要性とのバランスを考慮して選択をし、通常は、現在の反復の範囲から制限されます。

要求は、テストの派生元となる重要なソースですが、これが唯一の情報源ではありません。実際に多くの場合、これだけではテストを作成するのに十分ではありません。テスト ケースについても、リスク、制約、技術、変更要求 (欠陥)、障害などの情報をもとに考慮する必要があります。テストの派生元となる情報については、「概念: テスト構想」を参照してください。

テスト ケースの識別は、次のような理由で役に立ちます。

  • テスト ケースは、実際のテストを設計し実装するための基盤となります。テスト ケースの検討に費やした時間は、設計と実装の要求を理解するための時間でもあり、設計と実装の作業における時間を節約する可能性もあります。
  • テストには、特に複雑、または詳細なものがあります。このようなテストは、テストの実装を始める前に慎重に検討を加えることでよい結果を得ることができ、テスト ケースやテスト設計の成果物は、こうした考慮事項を検討するためのよい手段となります。
  • テストの「深さ」は、一般的にテストの数に比例します。テスト ケースの数をもとにテストし得る「深さ」を予測できると、テスト プロセス自体への信頼が高まります。
  • テスト作業がどの程度完了したかを表す尺度の 1 つに、動機となる要素についてカバレッジを測定することによるものがあります。カバレッジの報告は、指示されたテスト ケースの数や、テスト ケースごとに実装または実行されたテストの数、各テスト ケースで行われた作業の量をもとに行えます。
  • テストに要する作業量の度合いと複雑さは、ある程度テスト ケースの数に比例します。テスト ケースを分解すると、より詳細な細分化レベルでテスト作業を予測できます。
  • 必要とされるテストの設計と開発、リソースの種類は、一部にテスト ケースの数と複雑さによって左右されます

ただし、テスト ケースについて考慮すべき点を次にあげます。

  • すべてのテスト ケースが、テスト ケースを作成してレビューと保守を必要とするほど複雑というわけではなく、簡略なテキスト記述により、要求内容を伝えることのできるテストがあります。実際に、多くのテスト ケースはこのカテゴリに属します。多数の単純なテスト ケースを文書化するために時間をかけることにより、より重要なテスト作業の時間が失われることがあります。
  • テストの初期構想には、後から何かしらの点で欠陥のあることが分かるものがあります。これは、当初その構想をもとに指示したテスト ケースが破棄されることを意味します。つまり、テスト ケースを詳細に文書化した作業が、後で破棄され、テスト ケースに基づくカバレッジのレポートはすべて、その状況を考慮する必要があるわけです。このため、テスト カバレッジのレポートは、テスト ケースよりも上位の考慮事項をもとに作成し、テスト ケースの扱いは、必要に応じて内部のテスト チーム成果物として使用することをお勧めします。

テスト ケースは、テストの種類または関連するテストへの要求によって区分ないし分類されることがよくあります。したがって、テスト ケースはいろいろに変化します。テスト ケースを識別する実際の方法としては、次の 2 つの点を考慮して開始します。

  • 要求が達成されたことを示す (通常、肯定的なテスト ケースと呼ばれる)
  • 要求が、望ましい状況のもとでのみ達成されたことを示す (否定的なテストとされる)。このテストケースは、受け入れられない、異常の、予期せぬ状況や、ソフトウェアでの管理対象とされるデータを反映したものです。

ユース ケースからのテスト ケースの導出 ページの先頭へ

機能的なテストのテスト ケースは、テスト対象のユース ケースから導出されます (「成果物: ユース ケース」参照)。テスト ケースは各ユース ケース シナリオごとに開発します。ユース ケースの始点から終点までに至る基本フローと代替フローのパスを記述することによって、ユース ケース シナリオが識別されます。

たとえば、次に示すダイアグラムでは、基本フローと代替フローを反映するユース ケース中のいろいろなパスが、それぞれ矢印で表されています。黒い直線で表される基本フローはユース ケースを貫く最も単純なパスです。各代替フローは基本フローと共に始まり、具体的な条件に応じて、代替フローが実行されます。代替フローは基本フローに合流する (代替フロー 1 と 3) こともあれば、ほかの代替フローから派生する (代替フロー 2) ことも、ほかのフローとは合流せずにユース ケースの終わりに至る (代替フロー 2 と 4) こともあります。

ユース ケースのイベント フローの例

上のダイアグラムの中のユース ケースを貫く各パスを追って、いくつかのユース ケース シナリオを組み立てることができます。基本フローから開始し、それから基本フローを代替フローと組み合わせることによって、次のようなユース ケース シナリオが得られます。

シナリオ 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 が待機している状態でこのユース ケースは開始される。
  1. 引き出しの開始: 顧客はキャッシュ カードを ATM マシンのカード読み取り口に挿入する
  2. キャッシュ カードの照合: ATM はキャッシュ カード上の磁気ストライプから口座番号を読み取って、そのカードを受け付けるかどうかをチェックする 
  3. 暗証番号の入力:ATM は顧客に暗証番号 (4 桁) の入力を求める
  4. 口座と暗証番号の照合: 口座番号と暗証番号が照合されて、口座番号が有効であるかどうか、入力された暗証番号がその口座にとって正しいものであるかどうかを判定する。このフローでは、口座番号は有効であり、正しい暗証番号である。
  5. ATM オプション: この ATM で取り扱っている取り引きをいくつか表示。  このフローでは、顧客は必ず「現金の引き出し」を選択する。
  6. 金額の入力:ATM からの引き出し額。このフローでは、顧客はあらかじめ設定されている金額 (10 ドル、20 ドル、50 ドル、100 ドル) の中から選択する。
  7. 承認: カード ID、暗証番号、金額、口座情報が ATM から銀行システムに送信されて、検証プロセスが開始する。  このフローでは、銀行システムはオンラインで稼働しており、現金の引き出しを正常に完了させる承認の応答を示し、口座の残高を引き出し額に応じて更新する。
  8. 払い出し: 現金が払い出される
  9. カードの返却: キャッシュ カードが返却される
  10. 明細: 取引明細が印刷されて排出される。  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 は動かない。


最初の反復期間では、現金引き出しユース ケースが、反復計画のとおり、正しく実装されたかの検証が必要である。この段階ではユース ケース全体が実装されるに至らず、下記のフローだけが実装されている。

  • 基本フロー: 設定済の金額 (10 ドル、20 ドル、50 ドル、100 ドル) の引き出し
  • 代替フロー 2: ATM の現金切れ
  • 代替フロー 3: ATM の現金不足
  • 代替フロー 4: 暗証番号の誤り
  • 代替フロー 5: 口座なし / 不適切な口座タイプ
  • 代替フロー 6: 口座残高の不足
 

このユース ケースから下記のシナリオを導出できます。

シナリオ 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 つ必要です。

  • 入力された暗証番号が間違っており、再入力できる回数がまだ残っていると、この代替フローは基本フローの「ステップ 3: 暗証番号の入力」に戻る
  • 入力された暗証番号が間違っており、再入力できる回数がもう残っていないと、この代替フローではキャッシュ カードを排出せずにユース ケースの終わりに進む
  • 再入力できる回数がもう残っていないときに正しい暗証番号が入力されると、  この代替フローは基本フローの「ステップ 5: 金額の入力」に移る

上のメトリクスにおいて、条件 (データ) に実際の値が示されていないことに注意してください。テスト ケースのメトリクスをこのような形で作成することの利点は、どの条件がテストされているのかを見分けやすいことです。また、十分なテスト ケースが設定されたかどうかを判定するのも非常に容易になり ます。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 警告メッセージが表示され、カードは排出されず、ユース ケースを終了。

上に示したテスト ケースは、この反復での現金引き出しユース ケースを検証するために必要なテスト ケースの一部にすぎません。ほかにも、次のようなテスト ケースが必要です。

  • シナリオ 6: 口座なし、または不適切な口座タイプ: 口座が見つからないかまたは利用可能でない
  • シナリオ 6: 口座なし、または不適切な口座タイプ: 口座から引き出しができない
  • シナリオ 7: 口座残高が不足: 要求額が残高よりも多い

将来の反復において、ほかのフローが実装されると、下記のためのテスト ケースも必要になります。

  • キャッシュ カードが無効 (カードの紛失または盗難届けが出ている、カードが該当の銀行のものではない、カードのストライプが損傷を受けているなど)
  • キャッシュ カードが読めない (カードリーダーが詰まっている、オフラインである、誤動作など)
  • 口座が解約されているか、凍結されているか、その他の理由で利用できない
  • ATM の金額が足りないか、または要求された金額を揃えられない (CW3 との違い は、ある金種で不足があるが、すべての金種が不足しているのではない)
  • 銀行システムに承認を求める接続ができない
  • 銀行ネットワークがオフラインになっているか、またはトランザクション処理中に停電が発生する

機能テスト ケースを設定するときに、次の点を確実に行うようにします。

  • 各ユース ケースシナリオに十分な肯定的、否定的なテスト ケースを設定する
  • ユース ケースによって実装されるビジネスルールをテスト ケースで正しく指摘する。そのために、ビジネス ルールの境界条件または境界値の内側、外側、境界上に位置するテスト ケースを用意する。
  • テスト ケースでイベントまたはアクションの任意のシーケンスが指摘されている。このようなシーケンスの例として、設計モデルのシーケンス図で識別されたもの、またはユーザー インターフェイス オブジェクトの状態または条件が挙げられる
  • ユース ケースのために定義されている任意の特殊な要求がテスト ケースで指摘されています。そのような要求の例として、場合によっては最低 / 最高負荷と関連づけられた最低 / 最高性能またはユース ケースを実行中のデータボリュームが挙げられる。

テスト ケースのためのテスト データの定義」の追加情報も参照してください。

補足仕様書からのテスト ケースの導出 ページの先頭へ

テスト対象に対する要求がすべて、ユース ケース仕様などの機能要求に反映されるとは限りません。性能、セキュリティとアクセス、構成要求のような機能外要求は、テスト対象に追加の振る舞いまたは特性を指定し、多くの場合、機能要求とは別に文書化されます。それらの追加的な要求に関するテスト ケースを導出するための主な情報源となるのが補足仕様書です。

追加のテスト ケースを導出するための下記のガイドラインを以降に説明します。

性能テストのためのテスト ケースの導出 ページの先頭へ

性能用のテスト ケースの主要な入力源となるのは補足仕様書です。これには機能外要求が記載されています (「成果物: 補足仕様書」参照)。性能テストのためのテスト ケースを導出するときは、次のガイドラインに従います。

  • 補足仕様書内の性能基準に関する各記述ごとに、テスト ケースを少なくとも 1 つ設定する。性能基準は通常、トランザクションあたりの時間、ユーザーあたりのトランザクション数、パーセントで表現される。
  • 重要なユース ケースごとに、テスト ケースを少なくとも 1 つ設定する。重要なユース ケースは、上記の記述または作業負荷分析記述書に性能尺度に基づいて評価されるべきと記述されているものである。

機能テストのためのテスト ケースと同様に、使用シナリオまたは要求につき少なくとも 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 の別のバージョンと矛盾しないことを確認する必要があります。

構成テストのためのテスト ケースを導出するには、次のガイドラインに従います。

  • 重要な各構成を確認するために、そのそれぞれにテスト ケースを少なくとも 1 つ設定します。そのためには、テスト対象の環境に必要なハードウェアとソフトウェアの構成を把握して、最も一般的なものを最初にテストするようにします。その主な対象を下に示します。
    • プリンタのサポート
    • ネットワークの接続: ローカル エリア ネットワークとワイド エリア ネットワーク
    • サーバーの構成: サーバーのドライバ、サーバーのハードウェア
    • デスクトップとサーバーの両方またはどちらか一方にインストールされているほかのソフトウェア
    • インストールされているすべてのソフトウェアのバージョン
  • 問題を起こしそうな各構成についてテスト ケースを少なくとも 1 つ設定します。その中には次のようなものがあります。
    • 性能が最低のハードウェア
    • 互換性に問題のある履歴のある共存ソフトウェア
    • 最も遅い LAN/WAN 接続を通じてサーバーにアクセスするクライアント
    • 不十分なリソース (遅い CPU 速度、最少メモリ、最低解像度、ディスク容量など)

インストール テストのためのテスト ケースの導出 ページの先頭へ

インストール テストでは、可能なすべてのシナリオのもとでテスト対象がインストール可能であることを検証する必要があります。インストール シナリオには、テスト対象を初めてインストールする場合、あるいはテスト対象の新しいバージョンまたはビルドの (古いバージョンがインストールされているマシンに) インストールなどが含まれます。インストール テストではまた、ディスク容量が足りないといった異常な条件に遭遇したときに、テスト対象の実行結果が受け入れられることを確認する必要があります。

テスト ケースでは次のようなソフトウェアのインストール シナリオをカバーする必要があります。

  • ディスク、CD-ROM、ファイル サーバーなどの配布媒体
  • 新規インストール
  • 完全なインストール
  • カスタム インストール
  • アップグレード インストール

クライアント / サーバー ソフトウェア用のインストール プログラムには、特殊化された一連のテスト ケースがあります。ホストベースのシステムとは異なり、インストール プログラムは通常はサーバーとクライアント用に分割されています。したがって、インストール テストでは、クライアント、ミドルウェア、サーバーを含むテスト対象のすべてのコンポーネントのインストールを実行することが重要です。

機能外テストのためのテスト ケースの導出 ページの先頭へ

理想的には、ユース ケース モデル、設計モデル、補足仕様書の各成果物の中からテスト ケースを導出するために必要なすべての入力情報を見つけ出すべきです。しかし、この時点で後から見つかったことを捕捉する必要に迫られることは珍しくありません。

その例を次に示します。

  • (障害が発生するまで「長期間」にわたって使用したときに、ソフトウェアが正しく機能することを検証するための) 運用テストのためのテスト ケース
  • 性能上のネック、ボリュームの能力、テスト対象を故障させるようなストレスを調査するためのテスト ケース

ほとんどの場合、前に挙げたケースから導出されたテスト ケースを変形または集成することによって、これらのテスト ケースを見つけ出すことができます。

製品受け入れテストのためのテスト ケースの導出 ページの先頭へ

製品受け入れテストはソフトウェアを導入する前の最後のテスト アクションです。受け入れテストの目的は、ソフトウェアの準備が整い、その設計目的の機能とタスクを遂行するためにエンドユーザーが使用できるようになったことを検証することです。製品の受け入れテストには、多くの場合、ソフトウェアを実行して準備状況を見る以上のことが含まれます。トレーニング、文書、パッケージングのような、すべての成果物を顧客に納入することも含まれます。

ソフトウェア成果物のためのテスト ケースを導出することは、これまで上で述べた方法で行います。製品受け入れテストの公式性の度合いに応じて、テスト ケースは上で示したものと同じまたは類似したものとするか (公式)、あるいはそのサブセット (非公式) とします。テスト ケースの深さとは関係なく、テスト ケースと製品検収基準について合意に達してから、製品受け入れテストの実装と実行を行うべきです。

ソフトウェア外成果物に関するテスト ケースは、評価対象の成果物に応じて、大幅に異なります。ソフトウェア外成果物の評価とその方法については、それぞれのソフトウェア外成果物のガイドラインとチェックリストを参照してください。

回帰テストのための検証テスト ケースの作成 ページの先頭へ

回帰テストでは、同じテスト対象の 2 つのビルドまたはバージョンを比較して、潜在的な欠陥としての差異を洗い出します。つまり、新しいバージョンは前のバージョンと同様に動作すべきであると想定して、変更の結果に欠陥が入り込まないようにします。

ある反復で使用したすべてのテスト ケースを後の反復で使用できると理想的です。回帰テストと再利用の値を最大化しながら、メンテナンスを最少に保つようなテスト ケースを設定、設計、実装するためには、次のガイドラインに従います。

  • テスト ケースでは重要なデータ要素 (テストする条件を生成しサポートするために必要なもの) のみを取り上げる
  • 各テスト ケースでは、テスト対象のユニークな振る舞いを招く、一連のユニークな入力またはイベント シーケンスを、記述または表す
  • 重複または類似したテスト ケースを除去する
  • テスト対象の初期状態とテスト データの状態が同じであるテスト ケースを一緒にグループ化する

テスト ケースのためのテスト データの定義 ページの先頭へ

テスト ケースの検討を行い、一般的な合意または承認が得られると、実際のデータ値をより詳細に示すことができ (テスト ケースの実装マトリクス)、テスト データ成果物が作成されます。

テスト データの定義と管理については、「md_tstdta.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しませんガイドライン: テスト データ」を参照してください。



Rational Unified Process   2003.06.15