how classify positive
あなたは簡単な方法でも難しい方法でも何かをすることができます-重要なことはあなたがそれをすることです。簡単な日常のことはほとんどありませんが、自信がなければ、それらについての何かが私たちの心に完全に適合せず、成功の程度はヒットまたはミスです。
今日は簡単な例を1つ取り上げて、概念を明確にするだけでなく、常に正しく理解できるようにするショートカットを見つけましょう。
テストシナリオ/ケースのポジティブまたはネガティブ分類
テスト設計プロセスは3つあります。
- 要件を特定する
- テストシナリオを書く （何をテストするかについての1行のポインター）
- テスト方法の詳細な手順を設計する（テストケース）
テストシナリオを作成するときは、それらを正と負の条件に分類します。 （あなたがそれについて考えるとき、この分類をすることは本当に重要ですか？はいの場合、それはどのような目的に役立ちますか？とにかくそれらをすべてテストする必要がありますね？）それはほとんどの場合私にも勝っています。しかし、これは適切なカバレッジを確立するための試みであり、システムが処理することになっているハッピーパスと代替パスの両方をテストしていることを確立するのに役立つと思います。これが行われる他の理由を知っている場合は、以下にコメントしてください。
それでは、いくつかの要件を見て、テストシナリオを作成し、分類を実行しましょう。
＃1）ログイン ：正しい資格情報を入力したユーザーがシステムに入ります。資格情報が正しくない場合、アクセスは拒否され、エラーメッセージが表示されます。
＃2）製品を見る： システムで利用可能なすべての製品のオンラインカタログがあり、(製品の表示)リンクをクリックすると、それらすべてがリストに表示されると仮定します。
＃3）ログアウト： このリンクをクリックすると、ユーザーはログアウトされます。
これらの要件について、いくつかのテストシナリオを作成します。
表A：正しい方法
| テストシナリオID | テストシナリオの説明 | ポジティブ/ネガティブ |
|---|---|---|
| TS_login_01 | 入力した資格情報が正しい場合、ユーザーが正常にログインするかどうかを検証します | ポジティブ |
| TS_login_02 | 入力した資格情報が正しくない場合にユーザーがアクセスを許可されていないかどうかを検証します | 負 |
| TS_ViewProduct_01 | (商品を表示)リンクをクリックしたときにすべてのアイテムがリストされているかどうかを検証します | ポジティブ |
| TS_logout_01 | ログアウトをクリックしたときに、すでにログインしているユーザーがシステムからサインアウトしているかどうかを検証します | ポジティブ |
ただし、このように記述されたテストシナリオが表示されることがあります。
表B： マークされたエントリネット無効なテストシナリオです。
| テストシナリオID | テストシナリオの説明 | ポジティブ/ネガティブ |
|---|---|---|
| TS_login_01 | 入力した資格情報が正しい場合、ユーザーが正常にログインするかどうかを検証します | ポジティブ |
| TS_login_02 | 入力した資格情報が正しくない場合にユーザーがアクセスを許可されていないかどうかを検証します | 負 |
| TS_ViewProduct_01 | (商品を表示)リンクをクリックしたときにすべてのアイテムがリストされているかどうかを検証します | ポジティブ |
| TS_ViewProduct_02 | (商品を表示)リンクをクリックしたときに、すべてのアイテムがリストされていないかどうかを検証します | 負 |
| TS_logout_01 | ログアウトをクリックしたときに、すでにログインしているユーザーがシステムからサインアウトしているかどうかを検証します | ポジティブ |
| TS_logout_02 | ログアウトリンクがクリックされたときにユーザーがログアウトしないかどうかを検証します | 負 |
ログインが成功した場合は、成功しなかった場合と同じで反対のケースがあります。すべての要件がそのように想定されているわけではなく、それらにとって、否定的なシナリオを書くことを強制されることは実際にはありません。
結論：すべての要件に否定的なケースがあるとは限りません。
この時点で、「どうすればわかりますか」または「まだわからない」と考えている場合は、次の簡単なチートシートが役立ちます。
偽の会社の電子メールIDを作成する方法
アプリケーションについて一般化できるものが1つあるとすれば、それは動的であるということです。私たちが提供する入力（データ、クリックなど）により、アプリケーションは特定の方法になり、特定の出力が生成されます。
入力変数と出力変数の間の単純な相関関係により、これを理解しやすくなります。
ログインのために以下を試してみましょう：
| 入力 | 出力 | ポジティブ/ネガティブ |
|---|---|---|
| 正しい（正しいログイン情報） | 正解（ユーザーがログイン） | ポジティブ |
| 正しくない（ログイン情報が正しくない） | 正解（エラーメッセージ） | 負 |
| 正しい（正しいログイン情報） | 不正解-ログインに失敗する | バグ/欠陥 |
| 正しくない（ログイン情報が正しくない） | 不正解（システムがログインします）–「ああ、ホラー！」 :) | バグ/欠陥 |
したがって、上記の表からわかるように、プライマリフローはポジティブとして分類され、代替フロー（アプリケーションの正しい動作も）はネガティブとしてマークされていると言えます。
赤字の最後の2つのケースは、実際にはバグです。テストは要件の検証に関するものであり、要件が意図したとおりに機能しない場合、バグが見つかります。欠陥の検証は行わないため、最後の2つのケースは無効です。
同じ考え方に従い、それをログアウトして製品を表示するために適用すると、次のようになります。
| 入力 | 出力 | ポジティブ/ネガティブ |
|---|---|---|
| ログアウト（クリック） | 正解-ログアウト | ポジティブ |
| ログアウト（クリック） | 不正解-サインインしたまま | バグ/欠陥 |
| 製品を見る（クリック） | 正解-製品を表示します | ポジティブ |
| 製品を見る（クリック） | 正しくない（リストではない、またはリストの表示が正しくない） | バグ/欠陥 |
ご覧のとおり、これらの要件については、誤った入力を提供する可能性はありません。したがって、ネガティブなテストシナリオ/ケースを作成する必要はありません。
結論：
システムは、正または負の入力を受ける可能性があります。いずれにせよ、システムは正しい出力を生成する必要があります。正しい入力を処理する傾向があるケースは肯定的です。ほぼ正しいが負の入力であるものは負です。
いくつかの指針：
＃1） いつ エンドツーエンドのテストケース UATまたはシステムテスト用に作成されている場合、フローに組み込まれるのは常にポジティブなテストケースです。
＃二） 時々、分類は主観的です。例えば、サイトで何かを削除しようとしていて、「このエントリを削除してもよろしいですか？」という確認メッセージが表示された場合。 (OK)と(キャンセル)オプションを使用–私によると、(キャンセル)をクリックするのは良いケースです。ただし、「削除」オプションの主な目的は操作をキャンセルするのではなく削除することであるため、否定的な考えもあります。したがって、テスターの判断も分類に影響します。
＃3） すべての肯定的なケースについて、常に等しく反対の否定的なケースがあるとは限りません。
上記の方法は常に正しい分類を保証します。自分で試してみて、そうでない場合は教えてください。 :)「ショートカットはしばしば間違ったカットです。」-しかし、この場合はそうではないかもしれません！
ネガティブテストのより正式な説明については、=>を確認してください。 ネガティブテストとは何ですか？ネガティブテストケースの書き方は？
著者について： この記事は、STHチームメンバーのSwatiSによって書かれています。彼女のライブQAトレーニングコースにここから参加してください。 これまでにない最高のソフトウェアテストトレーニング！ 「」
この記事が気に入って、今後の記事で簡単に説明されているそのような基本的な概念を見たい場合は、お知らせください。
あなたのコメント、質問、フィードバック、読者は、ここSTHで高く評価され、高く評価されています。ハッピーテスト！