use case use case testing complete tutorial
まず、理解しましょう 「ユースケースとは」 後で話し合います 「ユースケーステストとは」 。
ユースケースは、必要なユーザー操作を定義するためのツールです。新しいアプリケーションを作成したり、既存のアプリケーションに変更を加えたりしようとしている場合は、いくつかの議論が行われます。あなたがしなければならない重要な議論の1つは、ソフトウェアソリューションの要件をどのように表現するかです。
達成するのは非常に難しいため、ビジネスの専門家と開発者は要件について相互に理解している必要があります。それらの間のコミュニケーションを構築するための標準的な方法は、本当に恩恵になります。これにより、誤解が減り、ユースケースが登場する場所がここにあります。
このチュートリアルでは、ユースケースとテストの概念について明確に説明します。これにより、概念にまったく慣れていない人が簡単に理解できるように、ユースケースに関連するさまざまな側面を実際の例で説明します。
学習内容：
- 使用事例
- 「ユースケース」ドキュメントを使用するのは誰ですか？
- ユースケースの種類
- ユースケースの要素
- 表現
- ユースケースの書き方は？
- ユースケース図
- ユーザーアクション
- ユースケーステストとは何ですか？
- 結論
- 推奨読書
使用事例
ユースケースは、ソフトウェア開発ライフサイクルの明確なフェーズで重要な役割を果たします。ユースケースは、ユーザーアクションに対する「ユーザーアクション」と「システムの応答」によって異なります。
これは、アクター/ユーザーによって実行される「アクション」と、ユーザーの「アクション」に対応するシステムの「動作」のドキュメントです。 ユースケース システムとの相互作用に関する「アクター/ユーザー」による目標の達成につながる場合とそうでない場合があります。
ユースケースでは、 「システムは特定のシナリオにどのように対応しますか？」 。これは「システム指向」ではなく「ユーザー指向」です。
これは「ユーザー指向」です。 「ユーザーが実行するアクションは何か」と「アクターがシステムで見るもの」を指定します。
「システム指向」ではありません。 「システムに与えられる入力は何ですか？」および「システムによって生成される出力は何ですか？」は指定しません。
開発フェーズはユースケースに大きく依存するため、開発チームは「ユースケース」を作成する必要があります。
ユースケースライター、チームメンバー、およびお客様は、これらのケースの作成に貢献します。これらを作成するには、開発チームを編成する必要があり、チームはプロジェクトの概念を十分に認識している必要があります。
ケースを実装した後、ドキュメントがテストされ、それに応じてシステムの動作がチェックされます。大文字の「A」が「アクター」を意味する場合、文字「S」は「システム」を意味します。
「ユースケース」ドキュメントを使用するのは誰ですか？
このドキュメントでは、ユーザーが目標を達成するためにシステムと対話するさまざまな方法の完全な概要を説明します。より良いドキュメントは、はるかに簡単な方法でソフトウェアシステムの要件を特定するのに役立ちます。
このドキュメントは、ソフトウェア開発者、ソフトウェアテスター、および利害関係者が使用できます。
ドキュメントの使用：
- 開発者は、コードの実装と設計にドキュメントを使用します。
- テスターはそれらを作成に使用します テストケース 。
- ビジネスの利害関係者は、ソフトウェア要件を理解するためにドキュメントを使用します。
ユースケースの種類
2種類あります。
彼らです：
- 晴れた日
- 雨の日
＃1）晴れた日のユースケース
これらは、すべてがうまくいったときに発生する可能性が最も高い主要なケースです。これらは他の場合よりも優先されます。ケースが完了したら、レビューのためにプロジェクトチームに渡し、必要なすべてのケースをカバーしたことを確認します。
Webアプリケーションのテストケースの書き方
＃2）雨の日のユースケース
これらは、エッジケースのリストとして定義できます。このようなケースの優先順位は、「サニーユースケース」の後になります。ケースに優先順位を付けるために、利害関係者と製品マネージャーの助けを求めることができます。
ユースケースの要素
以下にさまざまな要素を示します。
1）簡単 説明 ：ケースを説明する簡単な説明。
2）俳優 ：ユースケースアクションに関与しているユーザー。
3）前提条件 ：ケースが始まる前に満たされるべき条件。
4）基本 フロー ：「基本フロー」または「メインシナリオ」は、システムの通常のワークフローです。これは、アクターが目標を達成するために行うトランザクションのフローです。アクターがシステムと対話するとき、それは通常のワークフローであるため、エラーは発生せず、アクターは期待される出力を取得します。
5）代替 フロー ：通常のワークフローとは別に、システムには「代替ワークフロー」を含めることもできます。これは、ユーザーがシステムに対して行うあまり一般的ではない操作です。
6）例外 フロー ：ユーザーが目標を達成できないようにするフロー。
7）投稿 条件 ：ケース完了後に確認が必要な条件。
表現
多くの場合、ケースはプレーンテキストまたは図で表されます。ユースケース図は単純であるため、どの組織でもオプションであると見なされます
ユースケースの例：
ここでは、「学校管理システム」への「ログイン」の場合について説明します。
| ユースケース名 | ログイン | |
|---|---|---|
| 3b | 無効な学生IDが4回入力されました。 S：アプリケーションが終了します | |
| ユースケースの説明 | ユーザーがシステムにログインして、システムの機能にアクセスします。 | |
| 俳優 | 保護者、生徒、教師、管理者 | |
| 事前条件 | システムはネットワークに接続されている必要があります。 | |
| ポストコンディション | ログインに成功すると、通知メールがユーザーのメールIDに送信されます |
| 主なシナリオ | シリアル番号 | ステップ |
|---|---|---|
| 俳優/ユーザー | 1 | ユーザーネームを入力してください パスワードを入力する |
| 二 | ユーザー名とパスワードを検証する | |
| 3 | システムへのアクセスを許可する | |
| 拡張機能 | 1a | 無効なユーザー名 システムにエラーメッセージが表示される |
| 2b | 無効なパスワード システムにエラーメッセージが表示される | |
| 3c | パスワードが4回無効 アプリケーションは終了しました |
注意点
- 参加者がユースケースで行うよくある間違いは、特定のケースに関する詳細が多すぎるか、詳細がまったくないことです。
- これらは、必要に応じてテキストモデルであり、視覚的な図を追加する場合と追加しない場合があります。
- 該当する前提条件を決定します。
- プロセスステップを正しい順序で記述します。
- プロセスの品質要件を指定します。
ユースケースの書き方は？
以下に要約されているポイントは、これらを書くのに役立ちます。
=> ケースを作成しようとしているときに、最初に提起する必要がある質問は、「お客様の主な用途は何ですか？」です。この質問により、ユーザーの観点からケースを作成できます。
=> これらのテンプレートを入手したに違いありません。
=> それは生産的で、シンプルで、強力でなければなりません。強力なユースケースは、たとえ小さな間違いがあっても、聴衆を感動させることができます。
=> 番号を付ける必要があります。
=> プロセスステップをその順序で記述する必要があります。
=> シナリオに適切な名前を付けます。名前は目的に応じて行う必要があります。
=> これは反復的なプロセスです。つまり、初めて書くときは完璧ではありません。
=> システム内のアクターを特定します。システム内に多数のアクターが見つかる場合があります。
例 、アマゾンのようなeコマースサイトを検討すると、バイヤー、セラー、卸売業者、監査人、サプライヤー、ディストリビューター、カスタマーケアなどのアクターを見つけることができます。
最初に、最初のアクターについて考えてみましょう。同じ動作をする複数のアクターを持つことができます。
例えば 、 買い手と売り手の両方が「アカウントを作成」できます。同様に、「買い手と売り手」の両方が「アイテムの検索」を行うことができます。したがって、これらは重複した動作であり、排除する必要があります。重複するケースを使用することとは別に、より一般的なケースが必要です。したがって、重複を避けるためにケースを一般化する必要があります。
=> 該当する前提条件を決定する必要があります。
ユースケース図
ユースケース図は、システム内のユーザーのアクションを図で表したものです。これは、このコンテキストで優れたツールを提供します。図に多数のアクターが含まれている場合は、非常に理解しやすいです。高レベルの図の場合、詳細はあまり共有されません。複雑なアイデアをかなり基本的な方法で示しています。
図番号：UC 01
に示すように 図番号：UC 01 これは、長方形が「システム」を表し、楕円形が「ユースケース」を表し、矢印が「関係」を表し、男性が「ユーザー/アクター」を表す図を表します。それはシステム/アプリケーションを示し、次にそれと相互作用する組織/人々を示し、「システムは何をするのか」の基本的な流れを示します。
図番号：UC 02
図番号：UC 03 –ログインのユースケース図
これは、「ログイン」ケースのユースケース図です。ここでは、複数のアクターがあり、それらはすべてシステムの外部に配置されています。生徒、教師、保護者が主役と見なされます。そのため、これらはすべて長方形の左側に配置されます。
管理者とスタッフはセカンダリアクターと見なされるため、長方形の右側に配置します。アクターはシステムにログインできるため、アクターとログインケースをコネクタで接続します。
システムにある他の機能は、パスワードのリセットとパスワードを忘れた場合です。これらはすべてログインケースに関連しているため、コネクタに接続します。
ユーザーアクション
これらは、システム内でユーザーによって実行されるアクションです。
例えば： オンサイトでの検索、お気に入りへのアイテムの追加、連絡の試行など。
注意：
- システム 「あなたが開発しているものは何でも」です。これは、Webサイト、アプリ、またはその他のソフトウェアコンポーネントにすることができます。通常、長方形で表されます。ユースケースが含まれています。ユーザーは「長方形」の外側に配置されます。
- ユースケース 通常、その中のアクションを指定する楕円形で表されます。
- 俳優/ユーザー システムを使用する人々です。ただし、他のシステム、個人、または他の組織である場合もあります。
ユースケーステストとは何ですか？
これは、機能ブラックボックステスト手法の対象となります。ブラックボックステストであるため、コードの検査は行われません。このセクションでは、これに関するいくつかの興味深い事実について簡単に説明します。
これにより、ユーザーが使用するパスが意図したとおりに機能しているかどうかが確認されます。これにより、ユーザーがタスクを正常に実行できるようになります。
いくつかの事実
- ソフトウェアの品質を判断するために実行されるのはテストではありません。
- エンドツーエンドのテストの一種であっても、ユーザーアプリケーションの全体的なカバレッジを保証するものではありません。
- ユースケーステストでわかったテスト結果に基づいて、本番環境の展開を決定することはできません。
- 統合テストの欠陥を見つけます。
ユースケースのテスト例：
ユーザーがオンラインショッピングサイトからアイテムを購入しているシナリオを考えてみましょう。ユーザーは最初にシステムにログインし、検索の実行を開始します。ユーザーは、検索結果に表示されている1つ以上のアイテムを選択し、それらをカートに追加します。
この後、彼はチェックアウトします。したがって、これは、ユーザーがタスクを実行するためにシステムで実行する、論理的に接続された一連のステップの例です。
このテストでは、システム全体のエンドツーエンドのトランザクションフローがテストされます。ユースケースは通常、特定のタスクを実行するためにユーザーが使用する可能性が最も高いパスです。
したがって、これにより、ユーザーが初めてアプリケーションを使用するときにユーザーが遭遇する可能性が高いパスが含まれているため、ユースケースで欠陥を簡単に見つけることができます。
ステップ1： 最初のステップは、ユースケースドキュメントのレビューです。
機能要件が完全で正しいことを確認して確認する必要があります。
ステップ2： ユースケースがアトミックであることを確認する必要があります。
例えば： 「ログイン」、「学生の詳細の表示」、「マークの表示」、「出席の表示」、「スタッフへの連絡」、「料金の送信」など、多くの機能を備えた「学校管理システム」について考えてみます。この例では、 「ログイン」機能のユースケースを準備します。
通常のワークフローで他の機能と混同する必要がないことを確認する必要があります。 「ログイン」機能のみに完全に関連している必要があります。
ステップ3： システムの通常のワークフローを検査する必要があります。
ワークフローを検査した後、ワークフローが完了していることを確認する必要があります。システムまたはドメインの知識に基づいて、ワークフローで欠落しているステップを見つけることができます。
ステップ4： システムの代替ワークフローが完了しているかどうかを確認します。
ステップ5： ユースケースの各ステップがテスト可能であることを確認する必要があります。
ユースケーステストで説明されている各ステップはテスト可能です。
例えば、 システム内の一部のクレジットカード取引は、セキュリティ上の理由によりテストできません。
ステップ6： これらのケースを復活させたら、テストケースを作成できます。
通常のフローと代替フローごとにテストケースを作成する必要があります。
例えば 、 学校管理システムの「生徒のマークを表示」の場合を考えてみましょう。
ユースケース名： 学生マークを表示する
俳優： 生徒、教師、保護者
事前条件：
1） システムはネットワークに接続されている必要があります。
二） アクターは「学生ID」を持っている必要があります。
「学生マークを表示する」のユースケース：
| 主なシナリオ | シリアルナンバー | ステップ |
|---|---|---|
| A：俳優/ S：システム | 1 | 学生名を入力してください |
| 二 | システムは学生名を検証します | |
| 3 | 学生IDを入力してください | |
| 4 | システムは学生IDを検証します | |
| 5 | システムは学生マークを表示します | |
| 拡張機能 | 3a | 無効な学生ID S：エラーメッセージを表示します |
「学生マークを表示」ケースに対応するテストケース：
| テストケース | ステップ | 期待される結果 |
|---|---|---|
| に | 学生マークリストの表示1-通常のフロー | |
| 1 | 学生名を入力してください | ユーザーは学生名を入力できます |
| 二 | 学生IDを入力してください | ユーザーは学生IDを入力できます |
| 3 | ビューマークをクリックします | システムは学生マークを表示します |
| B | 学生マークリストの表示2-無効なID | |
|---|---|---|
| 1 | 学生マークリスト1の表示の手順1と2を繰り返します。 | |
| 二 | 学生IDを入力してください | システムはエラーメッセージを表示します |
ここに示されているテストケースの表には、基本的な情報のみが含まれていることに注意してください。 「テストケーステンプレートの作成方法」については、以下で詳しく説明します。
この表には、上記の「学生マークを表示」ケースに対応する「テストケース」が表示されます。
テストケースを作成する最良の方法は、最初に「メインシナリオ」のテストケースを作成し、次に「代替ステップ」のテストケースを作成することです。 ‘ ステップス テストケースでは、ユースケースドキュメントから取得されます。一番最初の ‘ ステップ」 「学生マークを表示」の場合、「学生名を入力」が最初になります ステップ 「テストケース」で。
ユーザー/アクターはそれを入力できる必要があります。これが 期待される結果 。
「」のようなテスト設計手法の助けを求めることができます。 境界値分析」 、テストケースの準備中の「等価分割」。テスト設計手法は、テストケースの数を減らし、それによってテストにかかる時間を短縮するのに役立ちます。
テストケーステンプレートを作成する方法は？
テストケースを準備するときは、エンドユーザーのように考えて行動する必要があります。つまり、エンドユーザーの立場に立つ必要があります。
このコンテキストで役立つために市場で利用可能ないくつかのツールがあります。 ' TestLodge ’はその1つですが、無料のツールではありません。購入する必要があります。
テストケースを文書化するためのテンプレートが必要です。よく知られている「FLIPKARTログイン」という一般的なシナリオを考えてみましょう。 Googleスプレッドシートを使用して、テストケーステーブルを作成し、チームメンバーと共有できます。とりあえず、Excelドキュメントを使用しています。
これが例です
=> このテストケーステーブルテンプレートをここからダウンロードします
まず第一に、テストケースシートに適切な名前を付けます。プロジェクト内の特定のモジュールのテストケースを作成しています。したがって、を追加する必要があります 「プロジェクト名」 そしてその 「プロジェクトモジュール テストケーステーブルの ’列。ドキュメントには、テストケースの作成者の名前が含まれている必要があります。
したがって、追加します 'によって作成された' そして '作成日' 列。ドキュメントは誰か（チームリーダー、プロジェクトマネージャーなど）がレビューする必要があるため、追加します 'によってレビュー' 列と 「レビュー日」 。
次のコラムは 「テストシナリオ」 、ここでは、テストシナリオの例を示しました 「Facebookログインの確認」 。列を追加します 「テストシナリオID」 そして 「テストケースの説明」 。
すべてのテストシナリオについて、次のように記述します。 「テストケース ’。したがって、列を追加します 「テストケースID」 そして 「テストケースの説明 ’。すべてのテストシナリオについて、 「事後条件」 そして 「事前条件」 。 「Post-Condition」列と「Pre-Condition」列を追加します。
もう1つの重要な列は 'テストデータ' 。これには、テストに使用するデータが含まれます。テストシナリオでは、期待される結果と実際の結果を想定する必要があります。列を追加します '期待される結果' および「実際の結果」。 '状態' は、テストシナリオの実行結果を示しています。合格/不合格のいずれかです。
テスターはテストケースを実行します。として含める必要があります 「実行者」 そして 「実行日」 。 「コマンド」がある場合は追加します。
結論
ユースケースとユースケーステストについて明確なアイデアが得られたと思います。
これらのケースを作成することは、反復的なプロセスです。これらのケースを作成するには、少しの練習とシステムに関する十分な知識が必要です。
簡単に言うと、アプリケーションで「ユースケーステスト」を使用して、欠落しているリンクや不完全な要件などを見つけることができます。それらを見つけてシステムを変更すると、システムの効率と精度が向上します。
ユースケースとテストの経験はありますか？下記のコメントセクションでお気軽に共有してください。