例を使用してテスト ケースを作成する方法
トーマス・ハミルトン
テストケースとは何ですか?
A テストケース のセットです 行動、入力、期待される結果 ソフトウェアの特定の機能や動作が意図したとおりに動作するかどうかをテスト担当者が検証するのに役立つ。 ステップバイステップガイド 何をテストするか、どのようにテストするか、どのような結果が期待されるかを定義します。
テストケースを次のように考えてみましょう 検証のレシピ — 正確な材料 (テスト データ)、プロセス (実行する手順)、そして完璧な料理 (期待される結果) がどのようなものになるかがわかります。
適切に記述されたテスト ケースは、次の点を保証するのに役立ちます。
- このソフトウェアは ビジネス要件とユーザー要件。
- バグや予期しない動作は 早期発見。
- テストは 繰り返して復習する QA プロフェッショナルなら誰でも。
- チームは次のことができます トレース 各テストが検証する要件。
👉 無料のライブソフトウェアテストプロジェクトに登録する
手動テストでテストケースを作成する手順
シナリオのテスト ケースを作成しましょう: ログイン機能のチェック
ステップ1） シナリオを説明する簡単なテスト ケースは次のとおりです。
| テストケース ＃ | テストケース Descriptexpression CMS |
|---|---|
| 1 | 有効なメールアドレスとパスワードが入力されたときの応答を確認する |
ステップ2） データをテストします。
テストケースを実行するには、次のものが必要です テストデータ。 以下に追加します
| テストケース ＃ | テストケース Descriptexpression CMS | テストデータ |
|---|---|---|
| 1 | 有効なメールアドレスとパスワードが入力されたときの応答を確認する | メールアドレス: [email protected] パスワード: lNf9^Oti7^2h |
テスト データの特定には時間がかかる場合があり、場合によってはテスト データを新たに作成する必要がある場合があります。 文書化する必要がある理由。
ステップ3） アクションを実行します。
テスト ケースを実行するには、テスターは AUT に対して特定の一連のアクションを実行する必要があります。 これは次のように文書化されています。
| テストケース ＃ | テストケース Descriptexpression CMS | テスト手順 | テストデータ |
|---|---|---|---|
| 1 | 有効なメールアドレスとパスワードが入力されたときの応答を確認する | 1) メールアドレスを入力
2) パスワードを入力 3) 「サインイン」をクリックします |
メールアドレス: [email protected]
パスワード: lNf9^Oti7^2h |
多くの場合、テスト手順は上記のように単純ではないため、ドキュメント化が必要です。また、テストケースの作成者は、組織を退職したり、休暇を取ったり、病気で勤務できなくなったり、他の重要な業務で非常に忙しくなったりすることもあります。新入社員にテストケースの実行を依頼することもあるでしょう。手順をドキュメント化しておくことは、その社員にとって役立つだけでなく、他の関係者によるレビューも容易になります。
ステップ4） AUT の動作を確認します。
ソフトウェアテストにおけるテストケースの目的は、AUTの動作が期待通りの結果となるかどうかを確認することです。これは以下のように文書化する必要があります。
| テストケース ＃ | テストケース Descriptexpression CMS | テストデータ | 期待される結果 |
|---|---|---|---|
| 1 | 有効なメールアドレスとパスワードが入力されたときの応答を確認する | メールアドレス: [email protected] パスワード: lNf9^Oti7^2h |
ログインは成功するはずです |
テスト実行中に、テスターは予想される結果を実際の結果と比較してチェックし、合格または不合格のステータスを割り当てます。
| テストケース ＃ | テストケース Descriptexpression CMS | テストデータ | 期待される結果 | 実結果 | 合否判定 |
|---|---|---|---|---|---|
| 1 | 有効なメールアドレスとパスワードが入力されたときの応答を確認する | 電子メール: [email protected] パスワード: lNf9^Oti7^2h | ログインは成功するはずです | ログインに成功しました | 合格 |
ステップ5） それとは別に、テストケースには次のようなフィールドが含まれる場合があります。
テストを実行する前に必要な条件を指定する前提条件。今回のテストケースでは、テスト対象のサイトにアクセスするためにブラウザがインストールされていることが前提条件となります。また、テストケースには、テストケースの完了後に適用される条件を指定する事後条件も含まれる場合があります。今回のテストケースでは、ログインの日時がデータベースに保存されることが事後条件となります。
テストケースの主要要素
標準的なテスト ケースには通常、次の内容が含まれます。
- テストケースID – 一意の識別子（例：TC001）
- タイトルまたは Descriptexpression CMS – テストで検証するもの
- 前提条件 – テスト開始前に何が必要か
- テスト手順 – 実行する正確なアクション
- テストデータ – 入力値またはパラメータ
- 期待される結果 – 目に見えてくる結果
- 実結果 – 実際に何が起こったのか
- ステータス – 合格、不合格、またはブロック
テスト ケースとテスト シナリオ
A テストシナリオ テストする必要がある内容（広範な機能またはユーザー ジャーニー）を説明します。
A テストケース、 一方、その機能がどのように検証されるか（正確な手順、データ、および予想される結果）について説明します。
簡単な言葉で：
- テストシナリオ = アイデア 何をテストするか。
- テストケース = 実装 そのアイデアをテストする方法。
こう考えてみましょう。
「テストシナリオが章のタイトルだとすると、各テストケースはその章を詳細に説明する段落になります。」
図の例:
わかりやすくするために例を挙げてみましょう。
テストシナリオ：
「ウェブサイトのログイン機能を確認してください。」
関連テストケース:
- 有効なユーザー名とパスワードでログインを確認してください。
- 無効なパスワードでエラー メッセージを確認してください。
- 空のフィールドでログインを確認します。
- パスワード確認フィールドでは入力テキストが非表示になります。
ここでのシナリオは 単一の機能目標、 テストケースではそれを分解します 特定のテスト可能な条件。
詳細については、以下をご覧ください。 テストケースとテストシナリオの違い
高品質なテストケースを書くメリット
- 高品質のテストケースにより徹底した テスト範囲、 QA プロセス全体にわたって一貫性とトレーサビリティを実現します。
- テスターがキャッチするのに役立つ バグを早期に発見し、 維持する 回帰安定性すべての機能がビジネス要件に適合していることを保証します。
- よく書かれたテストケースは 明確で、再利用でき、繰り返し可能で、 あらゆるテスターや自動化ツールが確実に実行できるようになります。
- また、 コミュニケーションブリッジ 開発者、テスト担当者、関係者間の曖昧さを減らし、時間を節約します。
- テストの目的、手順、結果を文書化することで、チームは 進捗状況を測定し、基準に準拠し、 更新を効率的に管理します。
- 最も重要なのは、良いテストケース メンテナンスコストを削減し、 自動化を加速し、 ソフトウェアの品質に対する自信。
- これらは、新しいテスターのオンボーディングのための生きたドキュメントとして、またAIや テスト管理ツール。
テストケースを書く際に避けるべきよくある間違い
経験豊富なテスターでも、テストの品質を低下させる小さなエラーが発生することがあります。
これらの間違いを避けることで、 正確性、明瞭性、保守性 テスト スイートの。
- 漠然とした手順を書く: 「ログインページを確認してください」のような曖昧な指示はテスターを混乱させます。明確でアクションベースの手順を使用してください。
- ネガティブなシナリオをスキップする: 完全なカバレッジを確保するには、常に無効な入力または境界テストを含めます。
- 不明確なテストデータの再利用: ラベル付けされていないデータや一貫性のないデータは、テスト結果の信頼性を低下させます。共有テストデータシートを維持してください。
- テストケースの過度な複雑化: 長くて複数のステップから成るケースはメンテナンスが困難です。各ケースを焦点を絞ったアトミックな状態に保ってください。
- 製品変更後の更新を無視する: 古いテストケースは誤った結果を生み出します。 Rev定期的に確認して改訂してください。
- トレーサビリティの欠如: カバレッジとコンプライアンスを追跡するには、常にテスト ケースを要件にリンクします。
- ピアレビューのスキップ: 新鮮な視点で見ると、不明瞭な手順や冗長な手順が早期に見つかります。
