テストケースの書き方：例を含む究極のガイド

how write test cases

テストケースの書き方に関するこの詳細なハンズオンチュートリアルでは、テストケースとは何か、その標準的な定義、およびテストケースの設計手法について詳しく説明しました。

テストケースとは何ですか？

テストケースには、アプリケーションの機能が正しく機能しているかどうかを判断するために、入力、アクション、および予想される応答を説明するコンポーネントがあります。

Excelシートでテストケースを書く方法

テストケースは、特定のテストの目的/ターゲットを検証するための「方法」に関する一連の指示です。これに従うと、システムの期待される動作が満たされているかどうかがわかります。

このテストケースライティングシリーズでカバーされているチュートリアルのリスト：

書き方：

チュートリアル＃1： テストケースとは何ですか？テストケースの書き方 （このチュートリアル）
チュートリアル＃2： 例を含むサンプルテストケーステンプレート(ダウンロード) （必読）
チュートリアル＃3： SRSドキュメントからのテストケースの作成
チュートリアル＃4： 特定のシナリオのテストケースを作成する方法
チュートリアル＃5： テストケース作成の準備をする方法
チュートリアル＃6： ネガティブテストケースの書き方

例：

チュートリアル＃7： Webおよびデスクトップアプリケーション用の180以上のサンプルテストケース
チュートリアル＃8： 100以上のすぐに実行できるテストシナリオ（チェックリスト）

ライティングテクニック：

チュートリアル＃9： 原因と結果のグラフ–動的テストケース作成手法
チュートリアル＃10： 状態遷移テスト手法
チュートリアル＃11： 直交表テスト手法
チュートリアル＃12： エラー推測テクニック
チュートリアル＃13： フィールド検証テーブル（FVT）テスト設計手法

テストケースとテストシナリオ：

チュートリアル＃14： テストケースとテストシナリオ
チュートリアル＃15： テスト計画、テスト戦略、テストケースの違い

オートメーション：

チュートリアル＃16： 自動化テスト用の正しいテストケースを選択する方法
チュートリアル＃17： 手動テストケースを自動化スクリプトに変換する方法

テスト管理ツール：

チュートリアル＃18： 最高のテスト管理ツール
チュートリアル＃19： テストケース管理のためのTestLink
チュートリアル＃20： HP QualityCenterを使用したテストケースの作成と管理
チュートリアル＃21： ALM / QCを使用したテストケースの実行

ドメイン固有のケース：

チュートリアル＃22： ERPアプリケーションのテストケース
チュートリアル＃23： JAVAアプリケーションのテストケース
チュートリアル＃24： 境界値分析と等価分割

このシリーズの最初のチュートリアルを続けましょう。

推奨ツール：

テストケースの作成プロセスに進む前に、このテストケース管理ツールをダウンロードすることをお勧めします。これにより、このチュートリアルで説明したテストケースの作成プロセスが容易になります。

＃1）TestRail

=> TestRailテストケース管理ツールをダウンロードする

＃2）TestMonitor

トップレベルのオンラインテスト管理。革新的で簡単。

TestMonitorは、すべての組織向けのエンドツーエンドのテスト管理ツールです。テストへのシンプルで直感的なアプローチ。エンタープライズソフトウェアの実装、QAの必要性、高品質のアプリの構築、またはテストプロジェクトの支援が必要な場合でも、TestMonitorが対応します。

=> TestMonitorWebサイトにアクセスします

学習内容：

• テストケースとは何ですか？テストケースの書き方は？
  • なぜテストを書くのですか？
  • テストケースの書き方は？
  • テストケースステートメントの基本形式
• テストを書くためのヒント
  • • ＃1）シンプルに保ちますが、シンプルすぎないようにします。複雑にしますが、複雑すぎないようにします。
    • ＃2）テストケースを文書化した後、テスターとして1回確認します。
    • ＃3）テスターをバインドし、簡単にします。
    • ＃4）貢献者になる：
    • ＃5）エンドユーザーを決して忘れないでください：
• テストケースのドキュメントで卓越性を達成する方法
  • 役立つヒントとコツ
    • ＃1）テストドキュメントは良好な状態ですか？
    • ＃2）ネガティブなケースをカバーすることを忘れないでください
    • ＃3）原子テストの手順を実行する
    • ＃4）テストに優先順位を付ける
    • ＃5）シーケンスの問題
    • ＃6）コメントにタイムスタンプとテスター名を追加する
    • ＃7）ブラウザの詳細を含める
    • ＃8）ドキュメントに「バグ」と「概要」の2つの別々のシートを保持します
• テストを書かない方法
  • 3テストケースで最も一般的な問題
    • ＃1）複合ステップ
    • ＃2）アプリケーションの動作は期待される動作と見なされます
    • ＃3）1つのケースで複数の条件
• テストケースの効率を改善する方法
  • テストライティングのためのドキュメントコレクション
  • 実際の例
  • テストケースドキュメント
  • テストデータ収集
• テストケースを標準化することの重要性
  • テストケースを再利用する理由
  • Webテストの標準テストとは何ですか？
  • 結論
  • 推奨読書

テストケースとは何ですか？テストケースの書き方は？

効果的なケースを書くことはスキルです。そして、テスト対象のアプリケーションの経験と知識からそれを学ぶことができます。

テストの書き方の基本的な手順については、次のビデオを確認してください。

上記のリソースは、テスト作成プロセスの基本を提供するはずです。

テスト作成プロセスのレベル：

• レベル1： このレベルでは、あなたは書くでしょう 利用可能な仕様からの基本的なケース およびユーザードキュメント。
• レベル2： これは 実用段階 ケースの作成は、アプリケーションの実際の機能およびシステムフローによって異なります。
• レベル3： これは、いくつかのケースをグループ化する段階です。 テスト手順を書く 。テスト手順は、おそらく最大10の小さなケースのグループにすぎません。
• レベル4： プロジェクトの自動化。 これにより、システムとの人間の相互作用が最小限に抑えられるため、QAは、回帰テストで忙しくするのではなく、現在更新されている機能に焦点を合わせてテストできます。

なぜテストを書くのですか？

ケースを書くことの基本的な目的は アプリケーションのテストカバレッジを検証します。

CMMi組織で作業している場合は、テスト基準がより厳密に守られています。ケースを作成すると、ある種の標準化がもたらされ、テストでのアドホックなアプローチが最小限に抑えられます。

テストケースの書き方は？

田畑：

• テストケースID
• テストするユニット： 何を確認する必要がありますか？
• 仮定
• テストデータ： 変数とその値
• 実行する手順
• 期待される結果
• 実結果
• 合格/不合格
• コメント

テストケースステートメントの基本形式

確認
使用する (ツール名、タグ名、ダイアログなど)
と (条件)
に (返されるもの、示されるもの、示されるもの)

確認： テストステートメントの最初の単語として使用されます。
使用： テストされているものを識別するため。状況に応じて使用する代わりに、ここで「入力」または「選択」を使用できます。

どのアプリケーションでも、次のようにすべてのタイプのテストをカバーする必要があります。

• 機能的なケース
• ネガティブケース
• 境界値の場合

これらすべてを書いている間 TCはシンプルで理解しやすいものでなければなりません 。

************************************************

テストを書くためのヒント

ソフトウェアテスター（SQA / SQC担当者）の最も頻繁で主要な活動の1つは、テストシナリオとケースを作成することです。

この主要な活動に関連するいくつかの重要かつ重要な要因があります。まず、これらの要素を俯瞰してみましょう。

執筆プロセスに関連する重要な要素：

a）TCは、定期的に改訂および更新される傾向があります。

私たちは絶えず変化する世界に住んでおり、同じことがソフトウェアにも当てはまります。ソフトウェア要件の変更は、ケースに直接影響します。要件が変更されるたびに、TCを更新する必要があります。

しかし、TCの改訂と更新を引き起こす可能性があるのは、要件の変更だけではありません。 TCの実行中に、多くのアイデアが頭に浮かび、単一のTCの多くのサブ条件が識別される可能性があります。これらすべてがTCの更新を引き起こし、時には新しいTCの追加につながることさえあります。

さらに、回帰テスト中に、いくつかの修正や波紋により、改訂されたTCまたは新しいTCが必要になります。

b）TCは、これらを実行するテスター間で配布される傾向があります。

もちろん、1人のテスターがすべてのTCを実行するような状況はほとんどありません。通常、単一のアプリケーションのさまざまなモジュールをテストするテスターが複数います。したがって、TCは、テスト対象のアプリケーションの所有領域に応じてテスター間で分割されます。

アプリケーションの統合に関連する一部のTCは複数のテスターに​​よって実行される場合がありますが、他のTCは単一のテスターに​​よってのみ実行される場合があります。

c）TCは、クラスタリングとバッチ処理を行う傾向があります。

単一のテストシナリオに属するTCは通常、特定の順序で、またはグループの形式で実行することを要求するのが普通で一般的です。 TCの特定の前提条件があり、それ自体を実行する前に他のTCの実行を要求する場合があります。

同様に、AUTのビジネスロジックに従って、単一のTCが複数のテスト条件に寄与する場合があり、単一のテスト条件が複数のTCで構成される場合があります。

d）TCには相互依存の傾向があります。

これは、TCが相互に依存し合う可能性があることを示す、TCの興味深く重要な動作でもあります。複雑なビジネスロジックを備えた中規模から大規模のアプリケーションまで、この傾向はより顕著です。

この動作を確実に観察できるアプリケーションの最も明確な領域は、同じアプリケーションまたは異なるアプリケーションの異なるモジュール間の相互運用性です。簡単に言えば、単一のアプリケーションまたは複数のアプリケーションが相互に依存している異なるモジュールがある場合は常に、同じ動作がTCにも反映されます。

e）TCは、開発者間で配布される傾向があります（特にテスト駆動開発環境で）。

TCに関する重要な事実は、TCがテスターに​​よって利用されるだけではないということです。通常の場合、開発者がバグを修正しているとき、開発者は間接的にTCを使用して問題を修正しています。同様に、テスト駆動開発が行われる場合、TCは、ロジックを構築し、TCによってアドレス指定されるコード内のすべてのシナリオをカバーするために、開発者によって直接使用されます。

効果的なテストを書くためのヒント：

上記の5つの要素を念頭に置いて、効果的なTCを作成するためのヒントをいくつか紹介します。

はじめましょう！！！

＃1）シンプルに保ちますが、シンプルすぎないようにします。複雑にしますが、複雑すぎないようにします。

この声明は逆説のようです。しかし、そうではないことをお約束します。 TCのすべてのステップをアトミックかつ正確に保ちます。正しい順序で手順を説明し、期待される結果に正しくマッピングします。テストケースは、自明で理解しやすいものでなければなりません。これが私がそれを単純にすることを意味するものです。

さて、それを複雑にするということは、それをテスト計画や他のTCと統合することを意味します。必要に応じて、他のTC、関連するアーティファクト、GUIなどを参照してください。しかし、これはバランスの取れた方法で行ってください。単一のテストシナリオを完了するために、ドキュメントの山を行き来するテスターを作成しないでください。

一方、テスターに​​これらのTCを非常にコンパクトな方法で文書化させないでください。 TCを作成するときは、自分または他の誰かがTCを改訂および更新する必要があることを常に忘れないでください。

＃2）テストケースを文書化した後、テスターとして1回確認します。

テストシナリオの最後のTCを作成したら、ジョブが完了したとは決して考えないでください。最初に移動して、すべてのTCを一度確認しますが、TCライターやテストプランナーの考え方ではありません。テスターの心ですべてのTCを確認します。合理的に考えて、TCをドライランしてみてください。

すべてのステップを評価し、理解しやすい方法でこれらを明確に述べており、期待される結果がそれらのステップと調和しているかどうかを確認します。

ことを確認 テストデータ TCで指定されているのは、実際のテスターだけでなく、リアルタイム環境にも対応しています。 TC間に依存関係の競合がないことを確認し、他のTC /アーティファクト/ GUIへのすべての参照が正確であることを確認します。そうしないと、テスターが大きな問題を抱えている可能性があります。

＃3）テスターをバインドし、簡単にします。

テスターに​​テストデータを残さないでください。特に計算を実行する場合や、アプリケーションの動作が入力に依存している場合は、さまざまな入力を提供します。テストデータ項目の値を決定させることはできますが、テストデータ項目を自分で選択する自由を与えることはできません。

なぜなら、意図的または意図せずに、同じテストデータを何度も使用する可能性があり、TCの実行中にいくつかの重要なテストデータが無視される可能性があるためです。

テストカテゴリおよびアプリケーションの関連領域ごとにTCを編成することにより、テスターを安心させます。明らかに、どのTCが相互依存および/またはバッチ処理されているかを指示して言及します。同様に、テスターがそれに応じて全体的なアクティビティを管理できるように、どのTCが独立していて分離されているかを明示的に示します。

この時点で、ブラックボックステストで使用されるテストケース設計戦略である境界値分析について読むことに興味があるかもしれません。クリック ここに それについてもっと知るために。

＃4）貢献者になる：

FSまたは設計ドキュメントをそのまま受け入れないでください。あなたの仕事は、FSを通過してテストシナリオを特定することだけではありません。 QAリソースであるため、アプリケーションで何かを改善できると感じた場合は、ビジネスに貢献し、提案をすることを躊躇しないでください。

特にTC主導の開発環境では、開発者にも提案してください。ドロップダウンリスト、カレンダーコントロール、選択リスト、グループラジオボタン、より意味のあるメッセージ、注意、プロンプト、使いやすさに関連する改善などを提案します。

QAであるため、テストするだけでなく、違いを生むことができます。

＃5）エンドユーザーを決して忘れないでください：

最も重要な利害関係者は、最終的にアプリケーションを使用する「エンドユーザー」です。したがって、TCの執筆のどの段階でも彼を決して忘れないでください。実際、エンドユーザーはSDLC全体のどの段階でも無視されるべきではありません。それでも、これまでの私の強調は、私のトピックに関連しているだけです。

したがって、テストシナリオを特定する際には、ユーザーが主に使用するケースや、使用頻度が低くてもビジネス上重要なケースを見逃さないでください。エンドユーザーの立場に立ってから、すべてのTCを確認し、文書化されたすべてのTCを実行することの実際的な価値を判断します。

************************************************

テストケースのドキュメントで卓越性を達成する方法

ソフトウェアテスターであるあなたは、完璧なテストドキュメントを作成することは本当に難しい作業であることに確かに同意するでしょう。

私たちは常に改善の余地を残しています テストケースのドキュメント 。 TCを通じて100％のテストカバレッジを提供できない場合や、テストテンプレートが標準に達していない場合や、テストに優れた読みやすさと明確さを提供できない場合があります。

テスターとして、テストドキュメントを書くように求められたときはいつでも、その場限りの方法で始めるのではありません。文書化プロセスに取り組む前に、テストケースを作成する目的を十分に理解することが非常に重要です。

テストは常に明確で明快でなければなりません。これらは、各テストで定義された手順に従って、テスターが完全なテストを簡単に実行できるように作成する必要があります。

さらに、テストケースドキュメントには、完全なものを提供するために必要な数のケースが含まれている必要があります テストカバレッジ 。 例えば 、ソフトウェアアプリケーション内で発生する可能性のあるすべてのシナリオのテストをカバーするようにしてください。

上記の点を念頭に置いて、テストドキュメントの卓越性を達成する方法についてのツアーを紹介します。

役立つヒントとコツ

ここでは、他の人からあなたのテストドキュメントに足を踏み入れることができるいくつかの有用なガイドラインを提供するつもりです。

＃1）テストドキュメントは良好な状態ですか？

テストドキュメントを整理するための最良かつ簡単な方法は、それを多くの単一の有用なセクションに分割することです。テスト全体を複数のテストシナリオに分割します。次に、各シナリオを複数のテストに分割します。最後に、各ケースを複数のテストステップに分割します。

Excelを使用している場合は、各テストケースを1つの完全なテストフローについて説明しているワークブックの個別のシートに文書化します。

＃2）ネガティブなケースをカバーすることを忘れないでください

ソフトウェアテスターは、既成概念にとらわれずに考え、アプリケーションが遭遇する可能性をすべて引き出す必要があります。テスターとして、ソフトウェアへの不正な入力の試みや、アプリケーション全体に流れる無効なデータを停止して報告する必要があるかどうかを確認する必要があります。

したがって、否定的なケースは肯定的なケースと同じくらい重要です。シナリオごとに、 2つのテストケース-1つは陽性、もう1つは陰性 。正のフローは意図されたフローまたは通常のフローをカバーし、負のフローは意図しないフローまたは例外的なフローをカバーする必要があります。

＃3）原子テストの手順を実行する

各テストステップはアトミックステップである必要があります。これ以上のサブステップはありません。テストステップが単純で明確であればあるほど、テストを進めるのは簡単になります。

＃4）テストに優先順位を付ける

多くの場合、アプリケーションのテストを完了するための厳しいスケジュールがあります。この場合、ソフトウェアの重要な機能と側面のいくつかのテストを見逃す可能性があります。これを回避するには、テストを文書化するときに、各テストで優先度にタグを付ける必要があります。

テストの優先度を定義するために、任意のエンコーディングを使用できます。通常、3つのレベルのいずれかを使用することをお勧めします。 高、中、低 、または1、50、100。したがって、厳密なタイムラインがある場合は、最初にすべての高優先度テストを完了してから、中優先度テストと低優先度テストに移動する必要があります。

swfファイルを開くにはどうすればよいですか

例えば –ショッピングWebサイトの場合、アプリへの無効なログイン試行に対するアクセス拒否の確認は優先度の高いケースであり、ユーザー画面での関連製品の表示の確認は優先度の高いケースであり、に表示されるテキストの色の確認画面ボタンは優先度の低いテストになる可能性があります。

＃5）シーケンスの問題

テストの手順の順序が完全に正しいかどうかを確認します。手順の順序が間違っていると、混乱を招く可能性があります。できれば、ステップでは、テスト中の特定のシナリオで、アプリに入るからアプリを出るまでのシーケンス全体も定義する必要があります。

＃6）コメントにタイムスタンプとテスター名を追加する

アプリケーションをテストしている場合、誰かが同じアプリと並行して変更を加えている場合、またはテストの完了後に誰かがアプリを更新している場合があります。これにより、テスト結果が時間とともに変化する可能性があります。

したがって、テスト結果（合格または不合格）をその特定の時点でのアプリケーションの状態に帰することができるように、テストコメントにテスターの名前を含むタイムスタンプを追加することをお勧めします。または、「 実行日 ’列がテストケースに個別に追加され、テストのタイムスタンプを明示的に識別します。

＃7）ブラウザの詳細を含める

ご存知のとおり、Webアプリケーションの場合、テストの結果は、テストが実行されるブラウザによって異なる場合があります。他のテスター、開発者、またはテストドキュメントを確認している人が簡単に使用できるように、ブラウザーの名前とバージョンをケースに追加して、欠陥を簡単に再現できるようにする必要があります。

＃8）ドキュメントに「バグ」と「概要」の2つの別々のシートを保持します

Excelで文書化する場合、ワークブックの最初の2枚はSummaryとBugsである必要があります。要約シートにはテストシナリオを要約し、バグシートにはテスト中に発生したすべての問題をリストする必要があります。これらの2つのシートを追加することの重要性は、ドキュメントの読者/ユーザーにテストの明確な理解を与えることです。

したがって、時間が制限されている場合、これらの2つのシートは、テストの概要を提供するのに非常に役立つことがわかります。

テストドキュメントは、可能な限り最高のテストカバレッジ、優れた読みやすさを提供し、全体を通して1つの標準形式に従う必要があります。

テストケースドキュメントの構成としていくつかの重要なヒントを念頭に置き、TCに優先順位を付け、TCを実行するためのすべての必須の詳細を含め、すべてを適切な順序で配置し、明確で明快なテスト手順を提供することで、テストドキュメントの卓越性を実現できます。上記のようになど。

************************************************

テストを書かない方法

私たちはほとんどの時間をこれらの作成、レビュー、実行、または保守に費やしています。テストが最もエラーが発生しやすいテストでもあるのは非常に残念です。理解の違い、組織のテスト慣行、時間の不足などが、多くのことが望まれるテストをしばしば目にする理由のいくつかです。

このトピックに関する私たちのサイトにはたくさんの記事がありますが、ここに表示されます テストケースを書かない方法–独特で、質が高く、効果的なテストを作成するのに役立ついくつかのヒント。

読み進めて、これらのヒントは初心者と経験豊富なテスターの両方を対象としていることに注意してください。

3テストケースで最も一般的な問題

1. 複合ステップ
2. アプリケーションの動作は期待される動作と見なされます
3. 1つのケースで複数の条件

これらの3つは、テスト作成プロセスでよくある問題のトップ3リストに含まれている必要があります。

興味深いのは、これらは新しいテスターと経験豊富なテスターの両方で発生し、同じ欠陥のあるプロセスをたどり続けるだけで、いくつかの簡単な方法で簡単に修正できることに気付かないことです。

それを手に入れて、それぞれについて詳しく説明しましょう。

＃1）複合ステップ

まず、複合ステップとは何ですか？

たとえば、ポイントAからポイントBへの道順を示しています。「XYZの場所に移動してからABCに移動する」と言っても、あまり意味がありません。ここでは、「どうすればよいか」と考えているからです。そもそもXYZに着きます」-代わりに「ここから左折して1マイル進み、Rdを右折します。 11がXYZに到達しない」と、より良い結果が得られる可能性があります。

まったく同じルールがテストとそのステップにも適用されます。

例えば 私はAmazon.comのテストを書いています–任意の製品を注文してください。

以下は私のテストステップです（注：私はステップを書いているだけで、期待される結果などのテストの他のすべての部分は書いていません）

に 。 Amazon.comを起動する
b 。画面上部の「検索」欄に商品のキーワード/名前を入力して商品を検索します。
c 。表示された検索結果から、最初の検索結果を選択します。
d 。製品の詳細ページで(カートに追加)をクリックします。
です 。チェックアウトして支払います。
f 。注文確認ページを確認してください。

さて、 これらのどれが複合ステップであるかを識別できますか？ 右ステップ（e）

テストは常にテストの「方法」に関するものであるため、テストでは「チェックアウトと支払いの方法」の正確な手順を記述することが重要です。

したがって、上記の場合は、以下のように書くとより効果的です。

に 。 Amazon.comを起動する
b 。画面上部の「検索」欄に商品のキーワード/名前を入力して商品を検索します。
c 。表示された検索結果から、最初の検索結果を選択します。
d 。製品の詳細ページで(カートに追加)をクリックします。
です 。ショッピングカートページの(チェックアウト)をクリックします。
f 。 CC情報、配送、および請求情報を入力します。
g 。 (チェックアウト)をクリックします。
h 。注文確認ページを確認してください。

したがって、複合ステップは、いくつかの個別のステップに分割できるステップです。次回テストを書くときは、この部分に注目しましょう。私たちが思っているよりも頻繁にこれを行うことに同意していただけると思います。

＃2）アプリケーションの動作は期待される動作と見なされます

最近、ますます多くのプロジェクトがこの状況に対処しなければなりません。

ドキュメントの欠如、エクストリームプログラミング、迅速な開発サイクルは、テストを作成するか、テスト自体のベースにするためにアプリケーション（古いバージョンなど）に依存することを余儀なくされるいくつかの理由です。いつものように、これは証明された悪い習慣です-常に実際にではありません。

心を開いて、「AUTに欠陥がある可能性がある」という期待を維持している限り、無害です。あなたがそう思わないときだけ、物事はうまくいきません。いつものように、私たちは例に話をさせます。

以下があなたが書いている/あなたがテストステップを設計しているページであるならば：

ケース1：

テストケースの手順が次の場合：

1. ショッピングサイトを立ち上げます。
2. (配送と返品)をクリックします-期待される結果：(配送と返品)ページが表示され、(ここに情報を入力)と(続行)ボタンが表示されます。

次に、これは正しくありません。

ケース2：

1. ショッピングサイトを立ち上げます。
2. (配送)をクリックして返品します。
3. この画面に表示される(注文番号を入力してください)テキストボックスに、注文番号を入力します。
4. (続行)をクリックします-期待される結果：配送と返品に関連する注文の詳細が表示されます。

ケース2は、参照アプリケーションが正しく動作しない場合でも、それをガイドラインとしてとらえ、さらに調査を行い、予想される正しい機能に従って予想される動作を記述するため、より優れたテストケースです。

結論： 参照としてのアプリケーションは簡単なショートカットですが、それ自体に危険が伴います。注意深く批判的である限り、それは驚くべき結果を生み出します。

＃3）1つのケースで複数の条件

もう一度、から学びましょう 例 。

以下のテスト手順をご覧ください。以下は、ログイン機能の1つのテスト内のテスト手順です。

a。有効な詳細を入力して、(送信)をクリックします。
b。 (ユーザー名)フィールドは空のままにします。 (送信)をクリックします。
c。パスワードフィールドを空のままにして、(送信)をクリックします。
d。すでにログインしているユーザー名/パスワードを選択し、(送信)をクリックします。

4つの異なるケースでなければならなかったものが1つにまとめられます。あなたは考えているかもしれません-それの何が問題なのですか？これにより、多くのドキュメントが節約され、4でできること、1で実行できます-それほど素晴らしいことではありませんか？まあ、完全ではありません。理由は？

読む：

• 条件の1つが失敗した場合はどうなりますか？テスト全体を「失敗」としてマークする必要があります。ケース全体を「失敗」とマークした場合、4つの条件すべてが機能していないことを意味しますが、これは実際には当てはまりません。
• テストにはフローが必要です。前提条件からステップ1まで、そしてすべてのステップを通して。このケースに従うと、ステップ（a）で成功すると、「ログイン」オプションが使用できなくなったページにログオンします。それで、ステップ（b）に到達すると、テスターはどこにユーザー名を入力しますか？ほら、流れが壊れています。

したがって、 モジュラーテストを書く 。大変な作業のように聞こえますが、必要なのは、物事を分離し、親友のCtrl + CとCtrl + Vを使用して作業することだけです。 :)

************************************************

テストケースの効率を改善する方法

ソフトウェアテスターは、ソフトウェア開発ライフサイクルの初期段階から、ソフトウェア要件フェーズで最もよくテストを作成する必要があります。

テストマネージャーまたはQAマネージャーは、以下のリストに従って、可能な限り多くのドキュメントを収集して準備する必要があります。

二分探索木javaコード例

テストライティングのためのドキュメントコレクション

＃1）ユーザー要件ドキュメント

これは、ビジネスプロセス、ユーザープロファイル、ユーザー環境、他のシステムとの相互作用、既存のシステムの交換、機能要件、非機能要件、ライセンスとインストールの要件、パフォーマンス要件、セキュリティ要件、ユーザビリティと同時要件などを一覧表示するドキュメントです。 。、

＃2）ビジネスユースケースドキュメント

このドキュメントでは、 使用事例 ビジネスの観点からの機能要件のシナリオ。このドキュメントでは、ビジネスアクター（またはシステム）、目標、前提条件、事後条件、基本フロー、代替フロー、オプション、要件に基づくシステムのすべてのビジネスフローの例外について説明します。

＃3）機能要件ドキュメント

このドキュメントでは、要件に基づくシステムの各機能の機能要件について詳しく説明します。

通常、機能要件ドキュメントは、開発チームとテストチームの両方、およびコミットされた（場合によっては凍結された）要件の顧客を含むプロジェクトの利害関係者にとって共通のリポジトリとして機能します。これは、ソフトウェア開発にとって最も重要なドキュメントとして扱う必要があります。

＃4）ソフトウェアプロジェクト計画（オプション）

プロジェクトの詳細、目的、優先順位、マイルストーン、アクティビティ、組織構造、戦略、進捗監視、リスク分析、仮定、依存関係、制約、トレーニング要件、クライアントの責任、プロジェクトスケジュールなどを説明するドキュメント。

＃5）QA /テスト計画

このドキュメントでは、品質管理システム、ドキュメント標準、変更管理メカニズム、重要なモジュール、機能、構成管理システム、テストプラン、欠陥追跡、受け入れ基準などについて詳しく説明します。

ザ・ テスト計画 ドキュメントは、テストする機能、テストしない機能、テストチームの割り当てとそのインターフェイス、リソース要件、テストスケジュール、テストライティング、テストカバレッジ、テスト成果物、テスト実行の前提条件、バグレポート、および追跡を識別するために使用されます。メカニズム、テストメトリックなど、

実際の例

次の図のように、使い慣れたシンプルな「ログイン」画面のテストケースを効率的に作成する方法を見てみましょう。ザ・ テストのアプローチ より多くの情報と重要な機能を備えた複雑な画面でもほぼ同じです。

＃1） テストケースプロセスの最初のアプローチは、可能であれば、上記のようなスクリーンプロトタイプ（またはワイヤーフレーム）を入手することです。これは一部の機能では利用できない場合があり、開発の初期段階でプロトタイプを設計することの重要性に依存します。

しかし、 SRS （ソフトウェア要件仕様）ドキュメント はプロジェクトで利用可能であり、ほとんどのスクリーンプロトタイプはプロジェクトチームによって開発されています。この種の画面は、テスターの仕事を簡素化し、テストの効率を高めます。

＃二） 次に、 機能要件仕様 。組織のプロセスによって異なりますが、複数のドキュメントのスイートで利用できます。

したがって、ケースを作成するのに最適なドキュメントを決定します。これは、ユーザー要件ドキュメントまたは機能要件仕様（または、テストチームが快適に理解できる場合はSRSドキュメント）のいずれかであり、選択した完全な機能フローを提供します。テストする機能。

＃3） 画面のプロトタイプと機能仕様が整ったら、テスターは次のアプローチと基準でケースの作成を開始する必要があります。

• UIテスト ：ユーザーに表示されるコントロール/フィールド。テストする機能に使用できる静的制御と動的制御があります。 例えば、 上記のログイン画面では、「ユーザー名とパスワード」のテキストは静的フィールドであり、テキストのみを表示するためだけに、ユーザーの操作を必要としません。

• 機能的なケース ：一方、ログインボタンとハイパーリンク（パスワードをお忘れですか？＆登録）は動的フィールドであり、コントロールをクリックしてユーザーが操作する必要があります。これにより、後で何らかのアクションが実行されます。

• データベースケース ：ユーザーがユーザー名とパスワードを入力すると、関連するデータベースをチェックするためのテストが作成され、ユーザー名とパスワードが適切なデータベースとテーブルでチェックされ、ユーザーがテスト対象のアプリケーションにログインする権限を持っているかどうかを確認できます。
  

• プロセステスト ：これは、機能に関連するプロセス（画面で使用可能な表示コントロールに関連するアクションではありません）に関連しています。 例えば、 上記のサンプル画面で(パスワードを忘れた場合)リンクをクリックすると、ユーザーに電子メールが送信される場合があります。したがって、適切なプロセスと確認のために電子メールをテストする必要があるかもしれません。

4） 最後に、「 BAOEマントラ '、 手段 i）基本フローii） 代替フロー iii）オプションおよびiv）例外 テストする機能フローと機能を完全に網羅しています。すべての概念は、ポジティブテストとネガティブテストに適用する必要があります。

例えば、 上記のサンプルログイン画面の簡単なBAOEアプローチを見てみましょう。

• 基本的な流れ： 任意のブラウザでログインのURLパスを入力し、必要な情報を入力して、アプリケーションにログインします。
• 代替フロー： モバイルデバイスにアプリケーションをインストールし、必要な情報を入力して、アプリケーションにログインします。
• オプション： 同じログイン画面を表示するために利用できるオプションは何ですか？ 例えば、 アプリケーションにログインした後、(ログアウト)をクリックすると同じ画面が表示される場合があります。または、セッションタイムアウトまたはセッションの有効期限が切れている場合、ユーザーはログイン画面が表示される場合があります。
• 例外： テストが陰性の場合の例外は何ですか？ 例えば、 ログイン画面に間違った資格情報が入力された場合、ユーザーにエラーメッセージが表示されるか、アクションが関連付けられないか。

これらすべての情報が手元にあるので、ログイン画面のTCを、完全なカバレッジとトレーサビリティ、および詳細情報を備えた形式で書き始めましょう。 ‘を識別する論理的な順序と番号付け テストケースID」 テストケースの迅速な識別実行履歴に非常に役立ちます。

また読む=> Webおよびデスクトップアプリケーション用のすぐに使用できる180以上のサンプルテストケース。

テストケースドキュメント

注意 ：テスト列は、以下のサンプルテストドキュメントに限定されません。Excelシートで維持して、完全なトレーサビリティマトリックスに必要な数の列を含めることができます。つまり、優先度、テストの目的、テストの種類、エラーのスクリーンショットの場所等。、

また読む=> 例を含むサンプルテストケーステンプレート。

このドキュメントを簡単に読みやすくするために、ログイン画面のテストの予想される実際の動作を再現する手順を以下に詳しく説明します。

注意 ：このテンプレートの最後に「実際の動作」列を追加します。

テストデータ収集

テストケースを作成する場合、テスターに​​とって最も重要なタスクは、テストデータを収集することです。テストケースはいくつかのサンプルデータまたはダミーデータを使用して実行でき、データが本当に必要なときにフィードできることを前提として、このアクティビティはスキップされ、多くのテスターに​​よって見落とされています。これは、テストケースの実行時にマインドメモリからサンプルデータまたは入力データを供給するという重大な誤解です。

テストの作成時にデータがテストドキュメントで収集および更新されていない場合、テスターはテストの実行時にデータを収集するために異常に多くの時間を費やします。テストデータは、機能の機能フローのすべての観点から、ポジティブケースとネガティブケースの両方について収集する必要があります。このような状況では、ビジネスユースケースドキュメントが非常に役立ちます。

上記のテストのサンプルテストデータドキュメントを見つけます。これは、テスト実行時の作業を容易にするデータをどれだけ効果的に収集できるかを知るのに役立ちます。

************************************************

テストケースを標準化することの重要性

この忙しい世界では、同じレベルの関心とエネルギーで毎日繰り返し行うことはできません。特に、仕事で同じ仕事を何度も繰り返すことに情熱を注いでいません。私は物事を管理し、時間を節約するのが好きです。 ITの誰もがそうあるべきです。

すべてのIT企業はさまざまなタイプのプロジェクトを実行します。これらのプロジェクトは、製品ベースまたはサービスベースのいずれかです。これらのプロジェクトのうち、それらのほとんどはウェブサイトを回避し、 ウェブサイトのテスト 。それについての良いニュースは、すべてのウェブサイトが多くの類似点を持っているということです。また、Webサイトが同じドメイン用である場合、それらにはいくつかの共通の機能もあります。

いつも私を困惑させる質問は次のとおりです。「たとえば、1000回前にテストされた小売サイトなど、ほとんどのアプリケーションが類似している場合、「さらに別の小売サイトのテストケースを最初から作成する必要があるのはなぜですか。 」以前の小売サイトのテストに使用された既存のテストスクリプトを引き出すことで、時間を大幅に節約できませんか？

確かに、私たちがしなければならないかもしれないいくつかの小さな調整があるかもしれませんが、全体的にそれはより簡単で効率的で時間とお金を節約し、それによって常にテスターの関心レベルを高く保つのに役立ちます。同じテストケースを繰り返し作成、レビュー、維持するのが好きな人はいますか？既存のテストを再利用することでこれを大幅に解決でき、クライアントもこれを賢く論理的に感じるでしょう。

論理的には、同様のWebベースのプロジェクトから既存のスクリプトを取得し始め、変更を加えて、それらを簡単に確認しました。また、色分けを使用して行われた変更を表示し、レビュー担当者が変更された部分にのみ焦点を合わせることができるようにしました。

テストケースを再利用する理由

＃1） ウェブサイトのほとんどの機能領域は、ほとんどログイン、登録、カートへの追加、ウィッシュリスト、チェックアウト、配送オプション、支払いオプション、製品ページのコンテンツ、最近表示された、関連製品、プロモーションコード機能などです。

＃二） ほとんどのプロジェクトは、既存の機能の単なる拡張または変更です。

＃3） 静的および動的な方法で画像アップロードのスロットを定義するコンテンツ管理システムも、すべてのWebサイトに共通です。

＃4） 小売ウェブサイトには CSR （カスタマーサービス）システムも。

＃5） JDAを使用したバックエンドシステムとウェアハウスアプリケーションもすべてのWebサイトで使用されています。

＃6） Cookie、タイムアウト、セキュリティの概念も一般的です。

＃ 7） Webベースのプロジェクトでは、要件が変更されることがよくあります。

＃8） ザ・ テストの種類 必要なのはブラウザのように一般的です 互換性テスト 、 性能試験 、 セキュリティテスト

ご覧のとおり、一般的で類似したものはたくさんあります。

再利用性が進むべき道であると言っても、変更自体に多少の時間がかかる場合とそうでない場合があります。あまり変更するよりも、最初から始める方が良いと感じる場合があります。

これは、一般的な機能ごとに一連の標準テストケースを作成することで簡単に処理できます。

Webテストの標準テストとは何ですか？

• ステップ、データ、変数など、完全なテストケースを作成します。これにより、類似のテストケースが必要な場合に、類似していないデータ/変数を簡単に置き換えることができます。
• 入口と出口の基準を適切に定義する必要があります。
• 変更可能なステップまたはステップ内のステートメントは、すばやく見つけて置き換えるために、別の色で強調表示する必要があります。
• 標準のテストケースの作成に使用される言語は、一般的なものである必要があります。
• 各Webサイトのすべての機能は、テストケースでカバーする必要があります。
• テストケースの名前は、テストケースがカバーしている機能または機能の名前である必要があります。これにより、セットからのテストケースの検索がはるかに簡単になります。
• 機能の基本または標準のサンプルまたはGUIファイルまたはスクリーンショットがある場合は、関連する手順を添付する必要があります。

上記のヒントを使用することで、標準スクリプトのセットを作成し、さまざまなWebサイトにほとんどまたは必要な変更を加えることなくそれらを使用できます。

これらの標準的なテストケースも自動化できますが、再利用性に重点を置くことは常にプラスです。また、 オートメーション はGUIに基づいているため、複数のURLまたはサイトでスクリプトを再利用することは、個人的には効果的だとは思いませんでした。

わずかな変更を加えたさまざまなWebサイトの手動テストケースの標準セットを使用することが、Webサイトテストを実行するための最良の方法です。必要なのは、適切な標準と使用法でテストケースを作成して維持することです。

結論

テストケースの効率を改善することは、単純に定義された用語ではありませんが、それは演習であり、成熟したプロセスと定期的な実践を通じて達成できます。

テストチームは、品質の世界でより大きな成果を上げるための最良のツールであるため、このようなタスクの改善に関与することに飽きることはありません。これは、ミッションクリティカルなプロジェクトや複雑なアプリケーションで世界中の多くのテスト組織で証明されています。

テストケースの概念に関する膨大な知識が得られたことを願っています。テストケースの詳細については、一連のチュートリアルをご覧ください。下のコメントセクションで、お気軽にご意見をお聞かせください。

次のチュートリアル

推奨読書

• 機能テストと非機能テスト
• 実用的な例を含む移植性テストガイド
• ソフトウェアテストの種類：詳細を含むさまざまなテストの種類
• 最高のソフトウェアテストツール2021 (QAテスト自動化ツール)
• アルファテストとベータテスト（完全ガイド）
• システムテストとは-究極の初心者向けガイド
• ISTQBテスト認定サンプル質問用紙と回答
• ソフトウェアテストの週次ステータスレポートの書き方