Loading article…
ソフトウェアエンジニアリングにおいて、テストケースとは、特定のソフトウェアテストの目的（特定のプログラムパスの実行や特定の要件への準拠の検証など）を達成するために実行される単一のテストを定義する、入力、実行条件、テスト手順、および期待される結果の仕様です。[ 1 ]テストケースは、無秩序ではなく体系的なテストの基盤となります。テスト対象ソフトウェアの望ましいカバレッジを実現するために、一連のテストケースを構築できます。正式に定義されたテストケースにより、ソフトウェアの連続するバージョンに対して同じテストを繰り返し実行できるため、効果的で一貫性のある回帰テストが可能になります。[ 2 ]
アプリケーションのすべての要件が満たされていることを完全にテストするには、各要件に対して少なくとも 2 つのテスト ケース (1 つの肯定テストと 1 つの否定テスト) が必要です。[ 3 ]要件にサブ要件がある場合は、各サブ要件に少なくとも 2 つのテスト ケースが必要です。要件とテストのリンクを追跡するには、トレーサビリティ マトリックスを使用することがよくあります。記述されたテスト ケースには、テストする機能の説明と、テストを実行できるようにするために必要な準備を含める必要があります。
正式な書面によるテストケースは、既知の入力と期待される出力によって特徴付けられ、これらはテストの実行前に検討されます。[ 4 ]既知の入力は事前条件をテストし、期待される出力は事後条件をテストする必要があります。
正式な要件のないアプリケーションやシステムの場合、テストケースは、類似のプログラムの一般的な動作に基づいて作成できます。テスト手法によっては、テストケースを全く作成せず、テスト実行後にアクティビティと結果を報告するものもあります。
シナリオテストでは、架空のストーリーを使用して、テスターが複雑な問題やシステムについて考えるのを助けます。これらのシナリオは通常、詳細に記述されません。テスト環境の図のように単純なものから、散文で書かれた説明まで様々です。理想的なシナリオテストは、動機付けがあり、信憑性があり、複雑で、評価しやすいストーリーです。通常、テストケースとは異なり、テストケースは単一のステップであるのに対し、シナリオは主要なステップの多くをカバーします。[ 5 ] [ 6 ]
テストケースは通常、アプリケーションの正しい動作／機能や特徴をテストするための単一の手順、または一連の手順で構成されます。通常、期待される結果または成果が示されます。
追加情報として含めることができるもの：[ 7 ]
より大規模なテストケースには、前提条件となる状態や手順、および説明が含まれる場合もあります。[ 7 ]
記述式のテストケースには、実際の結果を記入する欄も設けるべきである。
これらの手順は、ワープロ文書、表計算ソフト、データベース、またはその他の一般的なリポジトリに保存できます。
データベースシステムでは、過去のテスト結果、結果を生成した担当者、および結果生成に使用されたシステム構成を確認できる場合もあります。これらの過去の結果は通常、別のテーブルに保存されます。
テストスイートには多くの場合[ 8 ]も含まれています
テストケースにおいて、テスト対象となる機能の説明や、テストを実施するために必要な準備に加えて、最も時間のかかる部分は、テストの作成と、システム変更時のテストの修正である。
特別な状況下では、テストを実施して結果を出力し、その後、専門家チームがその結果を合格とみなせるかどうかを評価する必要が生じる場合があります。これは、新製品の性能数値を決定する際によく見られます。最初のテストは、その後のテストおよび製品リリースサイクルの基準値として使用されます。
受け入れテストは、記述されたテストケースのバリエーションを使用し、開発されたシステムが契約で指定された要件を満たしていることを確認するために、システムのエンドユーザーまたはクライアントのグループによって一般的に実行されます。 [ 9 ] [ 10 ]ユーザー受け入れテストは、ネガティブなテストケースをほぼ完全に排除し、ハッピーパスまたはポジティブテストケースを含めることで区別されます。 [ 11 ]