テストケース

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

ソフトウェアエンジニアリングでは、テストケースは、特定のプログラムパスの実行や検証など、特定のソフトウェアテストの目的を達成するために実行される単一のテストを定義する入力、実行条件、テスト手順、および期待される結果の仕様です。特定の要件への準拠。[1]テストケースは、無計画ではなく系統的なテストの根底にあります。テストケースのバッテリーを構築して、テスト対象のソフトウェアの目的のカバレッジを作成できます。正式に定義されたテストケースを使用すると、ソフトウェアの連続するバージョンに対して同じテストを繰り返し実行できるため、効果的で一貫性のある回帰テストが可能になります。[2]

正式なテストケース

アプリケーションのすべての要件が満たされていることを完全にテストするには、要件ごとに少なくとも2つのテストケースが必要です。1つはポジティブテスト、もう1つはネガティブテストです。[3]要件にサブ要件がある場合、各サブ要件には少なくとも2つのテストケースが必要です。要件とテストの間のリンクを追跡することは、トレーサビリティマトリックスを使用して頻繁に行われます。書面によるテストケースには、テストする機能の説明と、テストを確実に実施できるようにするために必要な準備を含める必要があります。

正式に作成されたテストケースは、既知の入力と、テストが実行される前に実行される期待される出力によって特徴付けられます。[4]既知の入力は前提条件をテストする必要があり、期待される出力は事後条件をテストする必要があります。

非公式のテストケース

正式な要件のないアプリケーションまたはシステムの場合、同様のクラスのプログラムの受け入れられた通常の操作に基づいてテストケースを作成できます。一部のテストスクールでは、テストケースはまったく作成されていませんが、テストの実行後にアクティビティと結果が報告されます。

シナリオテストでは、テスターが複雑な問題やシステムについて考えるのを助けるために、架空のストーリーが使用されます。これらのシナリオは通常、詳細に書き留められていません。それらは、テスト環境の図のように単純な場合もあれば、散文で書かれた説明の場合もあります。理想的なシナリオテストは、やる気を起こさせ、信頼でき、複雑で、評価しやすいストーリーです。これらは通常、テストケースが単一のステップであるのに対し、シナリオはキーのいくつかのステップをカバーするという点で、テストケースとは異なります。[5] [6]

典型的な書かれたテストケースフォーマット

テストケースは通常、アプリケーションの正しい動作/機能、機能をテストするための単一のステップ、または場合によっては一連のステップです。通常、期待される結果または期待される結果が示されます。[7]

含まれる可能性のある追加情報:[8]

  • テストケースID-このフィールドは、テストケースを一意に識別します。
  • テストケースの説明/概要-このフィールドは、テストケースの目的を説明します。
  • テスト手順-このフィールドには、テストケースを実行するための正確な手順が記載されています。
  • 前提条件-このフィールドは、テストステップを実行する前に従わなければならない条件またはステップを指定します。
  • テストカテゴリ
  • 著者-テスターの名前。
  • 自動化-このテストケースが自動化されているかどうか。
  • 合格/不合格
  • 備考

大規模なテストケースには、前提条件の状態または手順、および説明が含まれる場合もあります。[8]

書面によるテストケースには、実際の結果の場所も含まれている必要があります。

これらの手順は、ワードプロセッサのドキュメント、スプレッドシート、データベース、またはその他の一般的なリポジトリに保存できます。

データベースシステムでは、過去のテスト結果、結果の生成者、およびそれらの結果の生成に使用されたシステム構成を確認できる場合もあります。これらの過去の結果は通常、別のテーブルに保存されます。

多くの場合、テストスイートには[9]も含まれています。

  • テストの概要
  • 構成

テストする機能の説明、およびテストを確実に実行できるようにするために必要な準備に加えて、テストケースで最も時間のかかる部分は、テストを作成し、システムが変更されたときにそれらを変更することです。

特別な状況では、テストを実行して結果を生成する必要がある場合があります。その後、専門家のチームが結果を合格と見なすことができるかどうかを評価します。これは、新製品のパフォーマンス数値の決定でよく発生します。最初のテストは、後続のテストおよび製品リリースサイクルのベースラインとして使用されます。

書面によるテストケースのバリエーションを使用する受け入れテストは、通常、システムのエンドユーザーまたはクライアントのグループによって実行され、開発されたシステムが指定された要件または契約を満たしていることを確認します。[10] [11]ユーザー受け入れテストは、ハッピーパスまたはポジティブテストケースを含めることで、ネガティブテストケースをほぼ完全に除外することで区別されます。[12]

も参照してください

参照

  1. ^ システムおよびソフトウェアエンジニアリング–語彙Iso / Iec / IEEE 24765:2010(E)2010-12-01。pp。1–418。土井10.1109/IEEESTD.2010.5733835ISBN 978-0-7381-6205-8
  2. ^ Kaner、Cem(2003年5月)。「良いテストケースとは何ですか?」(PDF)スターイースト:2。
  3. ^ 「利害関係者の要件を検証するためのテストルールの作成」StickyMinds
  4. ^ Beizer、Boris(1995年5月22日)。ブラックボックステストニューヨーク:ワイリー。p。 3ISBN 9780471120940
  5. ^ 「シナリオテストの概要」(PDF)CemKaner 2009年5月7日取得
  6. ^ クリスピン、リサ; グレゴリー、ジャネット(2009)。アジャイルテスト:テスターとアジャイルチームのための実用ガイドアディソン-ウェスリーpp。192–5  _ ISBN 978-81-317-3068-3
  7. ^ https://www.softwaretestingstandard.org/part3.php ISO / IEC / IEEE 29119-4:2019、「パート4:テスト手法」
  8. ^ a b Liu、Juan(2014)。「GUIに基づくソフトウェアテストプロセスの研究」コンピュータ、ネットワークに関する2014年国際会議:113–121。土井10.1109/CSCI.2014.104ISBN 9781605951676S2CID15204091  _ 2019-10-22を取得
  9. ^ Kaner、Cem; フォーク、ジャック; グエン、ハングQ.(1993)。コンピュータソフトウェアのテスト(第2版)。ボストン:トムソンコンピュータープレス。p。 123–4ISBN 1-85032-847-1
  10. ^ Goethem、Brian Hambling、Pauline van(2013)。ユーザー受け入れテスト:ステップバイステップガイドBCSラーニング&デベロップメントリミテッド。ISBN 9781780171678
  11. ^ ブラック、レックス(2009年8月)。テストプロセスの管理:ハードウェアとソフトウェアのテストを管理するための実用的なツールとテクニックニュージャージー州ホーボーケン:ワイリー。ISBN 978-0-470-40415-7
  12. ^ Cimperman、Rob(2006)。UAT定義:実用的なユーザー受け入れテストのガイドピアソン教育。pp。第2章ISBN 9780132702621

外部リンク