この質問は、以前のポジティブ テスト ケースとネガティブ テスト ケースの質問の続きです。
アルファベットのみを受け入れるフィールドがあり、アルファベットのみを使用してそれをテストするテスト ケースを作成するとします。これはポジティブ テスト ケースです。
アルファベット以外の値を入力すると、「アルファベットのみが許可されています!」というエラー メッセージが表示されることが予想されます。
そして、数値でチェックすると、「アルファベットのみが許可されています!」というエラーメッセージがスローされます。（予想どおり）では、これはネガティブなテストケースですか、それともポジティブなテストケースですか？
フィールドへの間違った入力はNegative test case. ネガティブなテスト ケースを作成すると、次の 2 つの結果が生じる可能性があります。
これwill work as expectedは、エラーメッセージが表示され、テストに合格したと言うことを意味します。negative test passed
または itwill breakは、入力を受け入れることを意味します。この場合、テストは失敗しnegative test case has failed, this is a bugました。
機能の説明が「yiffy フィールドでは、アルファベット文字のみが許可されています」のようなものである場合、数字のテストはネガティブ テストケースです。
ただし、アルファベット以外の文字を入力しないことが重要であり、機能の説明が「yiffy フィールドでは、ユーザーはアルファベット以外の文字を入力できない」のようになっている場合は、数字でのテストは肯定的なテストケースになります。
ただし、テストは灰色の線を見つけることがすべてであるため、これに厳密になりすぎないでください。私の言語では、ijは完全に普通の文字ですが、ドイツでßは非常に一般的です。٠١٢٣٤٥٦٧٨٩数字/数字です (実際にはアラビア数字です)。テスターとして、そのテストケースについて考え、テスト中に機能がどれほど重要であるかを評価する必要があります (誰かがこれを行うリスクは何ですか)。ナンセンスなテストに貴重な時間を費やしたくありません。
申し訳ありませんが、私の回答はトピックから外れますが、(私の) 根拠は以下で説明します。
テスト ケースを肯定的または否定的に分類することが重要なのはなぜですか? とにかく両方のテストを実行する必要があります。テストを「プライマリ」と「代替」に分類することを好みます。「プライマリ」はハッピー パス、つまりエンド ユーザーが実際にソフトウェアを使って仕事をするためのパスを表します。代替テスト ケースは、エンド ユーザーが仕事をしたり、結果を達成したりするのを妨げる経路を記述します。(無効な入力、間違った認証情報、リソースが利用できない、...)
これは、テストを分類するための私の定義です。これらは私の言葉です (外部の記事から借用し、定義を明確にしています) 最初にプライマリ テストを作成/実行し、次に代替テストを作成/実行するので、私にとっては役に立ちます。ユーザーが何をどのようにやりたいかを考えて一次テストを書きます。(UX モード) 私は、システム データの破損、企業情報の漏えい、および考えられるその他すべての悪事など、実際に何が「うまくいかない」かを考えて代替テストを作成します。(QAモード)
テストを分類するために 2 つの単語 (ポジティブ/ネガティブ) を使用することの重要性は、同じプロジェクトであなたの周りの多くの人がこれらの単語を使用する場合にのみ重要になります。次に、共通の定義に同意する必要があります。(および分類基準) これらの単語をグーグルで検索しても絶対的な答えが得られるとは思いません。単にローカルのテスト文化の反響です...テストに関する本やテストに関するウェブサイト、またはテストに関する企業文書。