テストケースと優先度の定義

テスト対象を決定し、テストケースを定義して優先順位を付けます。

Ramona Schwering

前回の記事では、テスト戦略、アプリケーションのテストに必要なテスト数、リソースを考慮しながら結果の信頼性を最大限に高めるために最適なテストを見つける方法について説明しました。ただし、これはテストの量を把握するための参考情報にすぎません。テストする内容を正確に決定する必要があります。次の 3 つの基準は、テストで想定される結果を把握し、最適なテストの種類と詳細レベルを把握するのに役立ちます。

  1. ハッピー パスを管理する。これは、アプリの最も一般的なユーザー ストーリーであり、ユーザーがエラーにすぐに気付くものです。
  2. 詳細レベルを慎重に決定する。ユースケースが脆弱であるか、エラーによって大きな損害が発生する可能性がある場合は、詳細を把握します。
  3. 可能であれば、上位のエンドツーエンド テストよりも、下位のテスト（単体テストや統合テストなど）を優先します。

以降の記事では、これらの基準と、テストケースの定義時にこれらの基準を適用する方法について説明します。

テストケースとは

ソフトウェア開発において、テストケースとは、ソフトウェア プログラムまたはアプリケーションの有効性を確認するために考案された一連のアクションまたは状況です。テストケースの目的は、ソフトウェアが計画どおりに動作し、すべての機能が正しく動作することを確認することです。通常、ソフトウェア テスターまたはデベロッパーは、ソフトウェアが指定された要件と仕様を満たしていることを保証するために、これらのテストケースを作成します。

テストケースの検証中。

テストケースを実行すると、ソフトウェアは一連のチェックを実行し、目的の結果が得られることを保証します。テストは、次のタスクを実行します。

  • 検証。ソフトウェアがエラーなく機能することを確認するために、ソフトウェアを徹底的にチェックするプロセス。作成されたプロダクトが必要な非機能要件をすべて満たし、目的を達成しているかどうかを判断することが重要です。回答する質問は「プロダクトは正しく構築されているか？」です。
  • 検証。ソフトウェア プロダクトが必要な標準または高レベルの要件を満たしていることを確認するプロセス。実際のプロダクトが想定どおりのプロダクトと一致しているかどうかを確認します。基本的には、「ユーザーの要件に合ったプロダクトを構築しているかどうか」という質問に答えます。

プログラムが期待どおりの結果をもたらさなかったとします。その場合、テストケースがメッセンジャーとなり、失敗した結果を報告します。デベロッパーまたはテスターは、問題を調査して解決策を見つける必要があります。チェックとアクションは、テストの種類に関係なく、コンピュータがたどるパスと考えてください。チェックに使用される入力データまたは条件のグループは「等価クラス」と呼ばれます。テスト対象システムから同様の動作や結果が得られるはずです。テスト内で実行される特定のパスは異なる場合がありますが、テストで実行されるアクティビティとアサーションと一致する必要があります。

テストパス: 一般的なテストケースの種類

ソフトウェア開発におけるテストケースとは、特定の動作が想定され、テストされるコード実行シナリオです。通常、テストケースを作成するためのシナリオは 3 つあります。

ハッピーパス。

最初の方法は最もよく知られており、すでに使用している可能性があります。これは「ハッピーパス」（「ハッピー デイ シナリオ」または「ゴールデン パス」とも呼ばれます）です。機能、アプリケーション、変更の最も一般的なユースケース（お客様にとって正常に機能する方法）を定義します。

恐ろしいパス。

テストケースでカバーする必要がある 2 番目に重要なテストパスは、その名前が示すように不便なため、しばしば除外されます。これは「恐ろしいパス」であり、ネガティブ テストです。このパスは、コードの動作が不正になるか、エラー状態になるシナリオを対象としています。これらのシナリオのテストは、ステークホルダーやユーザーに高いリスクを課す、脆弱性の高いユースケースがある場合に特に重要です。

他にも知っておくべきパスや、使用を検討すべきパスがありますが、一般的にはそれほど使用されません。次の表に簡潔にまとめます。

テストパス 説明
怒りのパス これによりエラーが発生しますが、これは想定されたエラーです（たとえば、エラー処理が正しく機能することを確認する場合など）。
延滞パス このパスでは、アプリケーションが満たす必要があるセキュリティ関連のシナリオに対応します。
荒れ果てた道 アプリのシナリオをテストするパスで、null 値のテストなど、機能するために十分なデータが取得されません。
忘れっぽいパス リソース不足の状態でアプリケーションの動作をテストする（データ損失をトリガーするなど）。
決定できないパス アプリでアクションを実行しようとしているユーザーや、ユーザー ストーリーに沿って操作を試みたものの、ワークフローを完了していないユーザーを対象にテストします。たとえば、ユーザーがワークフローを中断した場合などが考えられます。
貪欲パス 大量の入力またはデータを使用してテストしようとしている。
ストレスの多いパス アプリケーションが機能しなくなるまで、あらゆる手段でアプリケーションに負荷をかける（負荷テストに似ている）。

これらのパスを分類する方法はいくつかあります。一般的なアプローチは、次の 2 つです。

  • 同等パーティショニング。テストケースをグループまたはパーティションに分類し、同等クラスの作成に役立つテスト方法。これは、パーティション内の 1 つのテストケースで欠陥が検出された場合は、同じパーティション内の他のテストケースでも同様の欠陥が検出される可能性があるという考えに基づいています。特定の等価クラス内のすべての入力は同じ動作を示すため、テストケースの数を減らすことができます。等価分割の詳細
  • 上限分析。入力値の上限または極端な値を調べて、システムの機能または制約の上限で発生する可能性のある問題やエラーを検出するテスト方法。境界値分析とも呼ばれます。

ベスト プラクティス: テストケースの作成

テスターが作成する従来のテストケースには、実施するテストの内容を把握し、テストを実行するために役立つ特定のデータが含まれています。一般的なテスターは、テスト作業をテーブルに記録します。この段階で使用できるパターンは 2 つあります。テストケースの構造化と、後でテスト自体の構造化に役立ちます。

  • Arrange、Act、Assert パターン。「準備、実行、アサート」（「AAA」または「トリプル A」とも呼ばれる）テストパターンは、テストを 3 つの個別のステップ（テストの準備、テストの実行、最後に結論の導出）に分類する方法です。
  • Given-When-Then パターン。このパターンは AAA パターンに似ていますが、振る舞い駆動開発にルーツがあります。

テストの構造について説明したら、これらのパターンについて詳しく説明する記事を公開する予定です。この段階でこれらのパターンについて詳しく学びたい場合は、Arrange-Act-Assert: A pattern for writing good tests と Given-When-Then の 2 つの記事を参照してください。

この記事で学んだことをまとめると、次の表のようになります。

情報 説明
前提条件 テストの作成前に行う必要があるすべてのこと。
テスト対象のオブジェクト 確認が必要な内容
入力データ 変数とその値。
実行する手順 テストを実行するために行うすべての操作: テストで行うすべてのアクションやインタラクション。
期待される結果 どのような動作が期待され、どのような期待に応える必要があるか。
正解値 実際の結果

自動テストでは、テストケースをすべてテスト担当者が必要とする方法で記録する必要はありません。記録することは間違いなく有用ですが、注意深くテストを実施すれば、これらの情報はすべてテストで確認できます。では、この従来のテストケースを自動テストに変換しましょう。

情報 テスト自動化への変換
前提条件 必要なもの、テストの準備、テストのシナリオを実現するために必要なものをすべて検討します。
テスト対象のオブジェクト この「オブジェクト」は、テスト対象のアプリケーション、フロー、ユニット、コンポーネントなど、さまざまなものになります。
入力データ パラメータ値。
実行する手順 テスト内で実行されるすべてのアクションとコマンド、実行対象、特定の操作を行った場合にどうなるかを確認します。
期待される結果 アプリケーションの検証に使用するアサーション。アプリケーションでアサートする内容。
正解値 自動テストの結果。