テストケース
テストケース (英: test case) は、ソフトウェア工学では、特定のプログラムパスの実行や検証など、特定のソフトウェアテストの目的を達成するため、もしくは特定の要件への準拠を確認するために実行される単一のテストを定義する入力、実行条件、テスト手順、および期待される結果の仕様のこと[1]。
テストケースは、無計画ではない系統だったテストを行うための根底にある仕組みである。一連のテストケースを構築して、テスト対象のソフトウェアを適切にカバーする。正式に定義されたテストケースを使用すると、ソフトウェアの連続するバージョンに対して同じテストを繰り返し実行できるため、効果的で一貫性のある回帰テストが可能になる[2]。
正式なテストケース
編集アプリケーションのすべての要件が満たされていることを完全にテストするには、要件ごとに少なくとも2つのテストケースが必要です。1つはポジティブテスト、もう1つはネガティブテストである[3]。要件にサブ要件がある場合、各サブ要件には少なくとも2つのテストケースが必要となる。要件とテストの間のリンクを追跡することは、トレーサビリティマトリックスを使用して頻繁に行われる。書面によるテストケースには、テストする機能の説明と、テストを確実に実施できるようにするために必要な準備を含める必要がある。
正式に作成されたテストケースには、既知の入力と、テストが実行される前に実行される期待される出力が記載されている[4]。既知の入力により前提条件を、期待される出力は事後条件をテストする。
非公式のテストケース
編集正式な要件のないアプリケーションまたはシステムの場合、同様のプログラムから類推して通常の操作に基づいてテストケースを作成する。
シナリオテストでは、架空のストーリーに従って、テスターが複雑な問題やシステムについて考られるようにしている。これらのシナリオは通常、詳細までは書かれていない。それらは、テスト環境の図のように単純な場合もあれば、散文で書かれた説明の場合もある。理想的なシナリオテストは、やる気を起こさせ、信頼でき、複雑で、評価しやすいストーリーであることだ。これらは通常、テストケースが単一のステップであるのに対し、シナリオは重要ないくつかのステップをカバーするという点でテストケースとは異なる[5][6]。
典型的なテストケースの記述形式
編集テストケースは通常、アプリケーションの正しい動作/機能、機能をテストするための単一のステップ、または場合によっては一連のステップである。通常、期待される結果または期待される結果が示されている[7]。
通常含まれている追加情報：[8]
- テストケースID-このフィールドは、テストケースを一意に識別します。
- テストケースの説明/概要-このフィールドは、テストケースの目的を説明します。
- テスト手順-このフィールドには、テストケースを実行するための正確な手順が記載されています。
- 前提条件-このフィールドは、テストステップを実行する前に従う必要のある条件またはステップを指定します。
- 深さ
- テストの分類
- 作成者-テスターの名前。
- 自動化有無-このテストケースが自動化されているかどうか。
- 合格/不合格
- 備考
大規模なテストケースには、前提条件の状態または手順、および説明が含まれる場合もある[8]。
書面によるテストケースには、実際の結果を保存してある場所も含まれている必要がある。
これらの手順は、ワードプロセッサの文書、スプレッドシート、データベース、またはその他の一般的なリポジトリに保存されている。
データベースシステムでは、過去のテスト結果、結果の生成者、およびそれらの結果の生成に使用されたシステム構成を確認できる場合もある。これらの過去の結果は通常、別のテーブルに保存されている。
- テストの概要
- 構成
テストする機能の説明、およびテストを確実に実行できるようにするために必要な準備に加えて、テストケースで最も時間のかかる部分は、システムが変更されたときに既存のテストケース変更することである。
特別な場合であるが、テストを実行して生成した結果を、専門家のチームが見て合否を評価する。これは、新製品のパフォーマンス数値の決定でよく発生する。最初のテストは、後続のテストおよび製品リリースサイクルのベースラインとして使用される。
書面によるテストケースの変種を使用する受け入れテストは、通常、システムのエンドユーザーまたは顧客の担当部門によって実行され、開発されたシステムが指定された要件または契約を満たしていることを確認する[10][11]。ユーザー受け入れテストは、ハッピーパスまたはポジティブテストケースを含める一方、ネガティブテストケースはほぼ完全に除外される[12]。
関連項目
編集脚注
編集- ^ Systems and software engineering – Vocabulary. (2010-12-01). 1–418. doi:10.1109/IEEESTD.2010.5733835. ISBN 978-0-7381-6205-8
- ^ Kaner, Cem (May 2003). “What Is a Good Test Case?”. STAR East: 2.
- ^ “Writing Test Rules to Verify Stakeholder Requirements”. StickyMinds. 2020年12月21日閲覧。
- ^ Beizer, Boris (May 22, 1995). Black Box Testing. New York: Wiley. p. 3. ISBN 9780471120940
- ^ “An Introduction to Scenario Testing”. Cem Kaner. 2009年5月7日閲覧。
- ^ Crispin, Lisa; Gregory, Janet (2009). Agile Testing: A Practical Guide for Testers and Agile Teams. Addison-Wesley. pp. 192–5. ISBN 978-81-317-3068-3
- ^ https://www.softwaretestingstandard.org/part3.php ISO/IEC/IEEE 29119-4:2019, "Part 4: Test techniques"
- ^ a b Liu, Juan (2014). “Studies of the Software Test Processes Based on GUI”. 2014 International Conference on Computer, Network: 113–121. doi:10.1109/CSCI.2014.104. ISBN 9781605951676 2019年10月22日閲覧。.
- ^ Kaner, Cem; Falk, Jack; Nguyen, Hung Q. (1993). Testing Computer Software (2nd ed.). Boston: Thomson Computer Press. p. 123–4. ISBN 1-85032-847-1
- ^ Goethem, Brian Hambling, Pauline van (2013). User acceptance testing : a step-by-step guide. BCS Learning & Development Limited. ISBN 9781780171678
- ^ Black, Rex (August 2009). Managing the Testing Process: Practical Tools and Techniques for Managing Hardware and Software Testing. Hoboken, NJ: Wiley. ISBN 978-0-470-40415-7
- ^ Cimperman, Rob (2006). UAT Defined: A Guide to Practical User Acceptance Testing. Pearson Education. pp. Chapter 2. ISBN 9780132702621
外部リンク
編集- Writing Software Security Test Cases - Putting security test cases into your test plan by Robert Auger
- Software Test Case Engineering By Ajay Bhagwat