Loading article…
ソフトウェア工学において、テストケースとは、特定のプログラムパスを実行したり、特定の要件への準拠を確認したりするなど、特定のソフトウェアテストの目的を達成するために実行される単一のテストを定義する入力、実行条件、テスト手順、および期待される結果の仕様です。 [1]テストケースは、行き当たりばったりではなく系統的なテストの基礎となります。一連のテストケースを構築することで、テスト対象のソフトウェアの必要なカバレッジを実現できます。正式に定義されたテストケースを使用すると、同じテストをソフトウェアの連続バージョンに対して繰り返し実行できるため、効果的で一貫性のある回帰テストが可能になります。[2]
正式なテストケース
アプリケーションのすべての要件が満たされていることを完全にテストするには、各要件に対して少なくとも 2 つのテスト ケース (1 つのポジティブ テストと 1 つのネガティブ テスト) が必要です。[3]要件にサブ要件がある場合は、各サブ要件に少なくとも 2 つのテスト ケースが必要です。要件とテスト間のリンクの追跡は、多くの場合、トレーサビリティ マトリックスを使用して行われます。記述されたテスト ケースには、テストする機能の説明と、テストを確実に実行するために必要な準備が含まれている必要があります。
正式な文書化されたテストケースは、テストが実行される前に作成された既知の入力と予想される出力によって特徴付けられます。[4]既知の入力は前提条件をテストし、予想される出力は事後条件をテストする必要があります。
非公式テストケース
正式な要件のないアプリケーションまたはシステムの場合、同様のクラスのプログラムの受け入れられた通常の操作に基づいてテスト ケースを作成できます。一部のテスト スタイルでは、テスト ケースはまったく作成されず、テストの実行後にアクティビティと結果が報告されます。
シナリオテストでは、テスターが複雑な問題やシステムについて考えるのを助けるために、架空のストーリーが使用されます。これらのシナリオは通常、詳細に記述されることはありません。テスト環境の図のように単純なものでも、散文で書かれた説明でもかまいません。理想的なシナリオテストは、やる気を起こさせ、信頼性が高く、複雑で、評価しやすいストーリーです。通常、シナリオは主要なステップを複数カバーするのに対し、テストケースは単一のステップである点で、テストケースとは異なります。[5] [6]
典型的な記述テストケースの形式
テスト ケースには通常、アプリケーションの正しい動作/機能および特徴をテストするための単一のステップまたは一連のステップが含まれます。通常、予想される結果または成果が与えられます。
含まれる可能性のある追加情報: [7]
- テスト ケース ID - テスト ケースの一意の識別子。
- 説明/概要- テストケースの目的。
- テスト手順- 実行する正確な手順。
- 期待される結果- 期待される成果と、それが実現されたかどうかを判断する方法。
- 実際の結果
- 前提条件- テスト実行前に存在する必要がある条件、または必要な準備。
- テストカテゴリ
- 著者- テスターの名前。
- 自動化- このテスト ケースが自動化されているかどうか、また自動化されている場合はどのように自動化されているか。
- 合格/不合格
- 備考
より大きなテストケースには、前提条件となる状態や手順、および説明も含まれる場合があります。[7]
書かれたテストケースには、実際の結果を入力する場所も含める必要があります。
これらの手順は、ワードプロセッサ文書、スプレッドシート、データベース、またはその他の共通リポジトリに保存できます。
データベース システムでは、過去のテスト結果、その結果を生成したユーザー、その結果を生成するために使用されたシステム構成を確認することもできます。これらの過去の結果は通常、別のテーブルに保存されます。
テストスイートには多くの場合、 [8]も含まれる。
- テストの概要
- 構成
テストする機能の説明と、テストを確実に実行するために必要な準備の他に、テスト ケースで最も時間のかかる部分は、テストを作成し、システムが変更されたときにテストを変更することです。
特別な状況では、テストを実行して結果を生成し、専門家チームがその結果が合格とみなせるかどうかを評価することが必要になる場合があります。これは、新製品のパフォーマンス数値の決定でよく発生します。最初のテストは、その後のテストと製品リリース サイクルのベースラインとして使用されます。
受け入れテストは、書かれたテストケースのバリエーションを使用して、開発されたシステムが指定された要件または契約を満たしていることを確認するために、システムのエンドユーザーまたはクライアントのグループによって一般的に実行されます。 [9] [10]ユーザー受け入れテストは、ハッピーパスまたはポジティブテストケースを含め、ネガティブテストケースをほぼ完全に排除することによって区別されます。[11]
参照
参考文献
- ^ システムおよびソフトウェアエンジニアリング - 語彙。Iso/Iec/IEEE 24765:2010(E)。2010-12-01。pp. 1–418。doi : 10.1109 / IEEESTD.2010.5733835。ISBN 978-0-7381-6205-8。
- ^ Kaner, Cem (2003 年 5 月)。「良いテスト ケースとは何か?」(PDF)。STAR East : 2。
- ^ 「ステークホルダーの要件を 確認するためのテストルールの作成」。StickyMinds 。
- ^ Beizer, Boris (1995年5月22日).ブラックボックステスト. ニューヨーク: Wiley. p. 3. ISBN 9780471120940。
- ^ 「シナリオテスト入門」(PDF) . Cem Kaner . 2009 年 5 月 7 日閲覧。
- ^ クリスピン、リサ、グレゴリー、ジャネット (2009)。アジャイルテスト：テスターとアジャイルチームのための実践ガイド。アディソン・ウェズリー。pp. 192–5。ISBN 978-81-317-3068-3。
- ^ ab Liu, Juan (2014). 「金融市場における意思決定プロセスの均衡」。2014国際計算科学および計算知能会議。pp. 113–121。doi :10.1109 / CSCI.2014.104。ISBN 9781605951676. S2CID 15204091 . 2019年10月22日閲覧。
- ^ Kaner, Cem; Falk, Jack; Nguyen, Hung Q. (1993). Testing Computer Software (第 2 版). ボストン: Thomson Computer Press. p. 123–4. ISBN 1-85032-847-1。
- ^ Hambling, Brian; van Goethem, Pauline (2013).ユーザー受け入れテスト: ステップバイステップガイド. BCS Learning & Development Limited. ISBN 9781780171678。
- ^ Black, Rex (2009 年 8 月)。テストプロセスの管理: ハードウェアおよびソフトウェアのテストを管理するための実用的なツールとテクニック。ニュージャージー州ホーボーケン: Wiley。ISBN 978-0-470-40415-7。
- ^ Cimperman, Rob (2006). UAT の定義: 実践的なユーザー受け入れテストのガイド。Pearson Education。第 2 章。ISBN 9780132702621。
外部リンク
- ソフトウェア テスト ケース エンジニアリング (Ajay Bhagwat 著)