テスト ケースは、ソフトウェア テストの動作を管理可能なモデルに変換することを目的とした、ソフトウェア テストの動作を科学的にまとめたものです。テスト ケースは、テストを具体的に定量化する方法の 1 つであり、ソフトウェアごとにテスト ケースも異なります。一般的に、一般的に使用されるテスト方法には 7 つのカテゴリがあります。同値クラス分割、境界値、シナリオ法、デシジョンテーブル、因果関係図、誤り推論法、直交検定法。
等価クラス分け
等価クラスの分割では、考えられるすべての入力データをいくつかの領域に分割し、各領域からテストのために少量の代表データを取り出します。この領域のすべての入力条件は同等です。
境界値テスト
境界値テストは、プログラムの入力ドメインの境界をテストする方法です。境界値テストの目的は、境界条件をテストすることでエラーを検出し、入力ドメインの境界条件を最大限にカバーすることです。プログラムの実際の動作を考慮し、テストに適切な境界値を決定する必要があります。
シナリオテスト方法
シナリオ テストは、典型的なユーザー シナリオに基づいてテスト ケースを設計する方法です。シナリオ テスト手法は、ユーザーの視点から開始し、システムの実際の使用状況をよく反映できる特定の使用シナリオに基づいてテスト ケースを設計します。ただし、さまざまなシナリオをカバーするにはさらに多くのテスト ケースが必要になる場合があり、他のユース ケース設計方法と組み合わせて使用する必要があります。
ユーザーがシステムを使用する一般的なシナリオを分析します。ログインシナリオ、支払いシナリオなど。
各シナリオの主要な手順を特定します。たとえば、ログイン シナリオには、ユーザー名、パスワードの入力、ログイン ボタンのクリックなどが含まれます。
シナリオの主な成功パスをカバーするユースケースを設計します。通常のログイン処理のテストケースなど。
異常なシナリオのテスト ケースを設計します。パスワードが間違っているなど。
シナリオの組み合わせを検討してください。たとえば、ログインしたまま支払いが行われます。
高リスクのシナリオのユースケースの設計を優先します。支払いシーンなど。
デシジョンテーブル方式
インプットとアウトプットの関係がある場合に使用され、業務の該当部分をデシジョンテーブルで整理し、デシジョンテーブルの各項目と組み合わせて、境界値を絞り込むテストを行います。同等クラスです。デシジョンテーブルは、複数の論理条件の組み合わせを解決するのに適しています。漏れを避けるために、さまざまな論理的な組み合わせをリストします。繰り返しの動作は表現できません。
判定テーブルには、条件山、条件項目、アクション山、アクション項目が含まれる。
条件パイル: すべての条件をリストします。順序は関係ありません。
条件項目: 対応する条件に対して考えられるすべての状況の値をリストします。
アクションパイル: 可能なアクションをリストします。順序は関係ありません。
アクション項目: 条件項目がさまざまな値を取る場合に実行されるアクションをリストします。
因果関係図
さまざまな入力の組み合わせをグラフィカルな手法で解析してテストケースを設計する手法で、プログラムの入力条件のさまざまな組み合わせを確認するのに適しています。
エラー推論
プログラム内で考えられるすべてのエラーを推測するための経験と直観に基づいて、的を絞った方法でテスト ケースを設計する方法。プログラム内で考えられるすべてのエラーと、エラーが発生する可能性が高い特殊な状況をリストし、それらに基づいてテスト ケースを選択し、ソフトウェアの実際の条件を組み合わせて、問題が発生する可能性のある場所について的を絞った推測を行い、それに応じてユース ケースを設計します。
直交実験計画法
入力条件が多い場合、特性特性図などの設計手法で設計されるユースケースの数は膨大になることがよくありますが、直交手法を使用するとユースケースの数を効果的に削減できます。直交法の中心的な考え方は、大量のテスト データからテストの代表点を選択し、それによってテスト ケースの数を減らすことです。
テストケース設計のヒント
テスト方法の 7 つの主要なカテゴリを上で紹介しましたが、以下では、実用的な観点からユースケースを迅速に設計するためのいくつかのヒントを共有します。
1. ニーズに応じて、まず主要なユースケースとして大きな機能ポイントを分割します。たとえば、一般的な追加、削除、変更、クエリは主要な機能ポイントであり、主な使用例として使用できます。
2. 同値クラス分割を使用します。分類別にユースケースを設計する 基本的な分類は、ポジティブなシナリオとネガティブなシナリオから始めることができます。たとえば、作成が成功した場合と作成が失敗した場合の 2 つのシナリオに対してユース ケースを個別に設計できます。
3. 境界値をうまく利用し、同値クラスと組み合わせて使用できます。テストには大量のデータが含まれる場合がありますが、すべてのデータを走査するのは非効率的です。手動で実行する場合、すべてのデータをカバーするのはより困難です。より効率的なアプローチは、最初に等価クラスを分割し、次にいくつかを選択することです。テスト用の等価クラスからのパラメータ。境界値は、同値クラスのすべてのオプション パラメータの中で最も問題を引き起こす可能性が高いため、通常は境界値がテストの焦点として選択されます。
4. 組み合わせテストを検討します。検索時には複数のフィールドを使用して検索することができるため、ユースケースを設計する際には、これらのフィールドを組み合わせて検索シナリオをカバーする必要があります。
5. パスのカバレッジを考慮します。動作シーケンスによる機能検証を行う場合は、抜け漏れを防ぐため、すべてのパスを網羅したフローチャートを作成することをお勧めします。
例えば、オンラインショッピングでは、ショッピングカートに商品を追加する→ショッピングカート内で商品を選択する→注文を送信する→支払いという流れが一般的ですが、このプロセス中、ユーザーはどの段階でも注文をキャンセルしたり返品したりすることができます。これらの操作パスがユースケースに含まれていることを確認してください。
6. 隠れたニーズについて考える。例: パフォーマンス、互換性、安定性、セキュリティ、ユーザー エクスペリエンスなど。明確に定義されていない場合は、漏れを避けるために率先して理解する必要があります。
7. インターフェイスの表示と詳細なテスト ポイントは機能的なユース ケースに含めることができますが、1 つのユース ケースであまりにも多くのことをカバーしすぎないように注意してください。ユースケースの粒度はユースケース設計において非常に重要なポイントであり、一般的には機能ポイントごとにユースケースを設計することが推奨されます。ただし、インターフェースの表示や詳細なテストポイントなどは、ユースケースを別々に設計するとユースケースが大きくなりすぎる場合があり、実際の作業ではこれらの点を機能テストケースに統合することも可能ですが、本来の用途が損なわれないように注意してください。焦点や粒度から逸脱するケースが大きすぎます。