否定的なテストケースの混乱
SheihkのKoiralaからのソフトウェアテストの本で、彼らは言う：
肯定的なテストとは、有効な入力を行い、仕様に従って何らかのアクションが完了することを期待する場合です。
ネガティブテストは、無効な入力を入力してエラーを受信した場合です。
私の質問の一部：
要件があるとしましょう：顧客名== "James Bond"の場合、何かを行います。
name<>"James Bond"陰性または依然として陽性のテストで、要件を確認していますか？
またはログイン機能：
正しいログインポジティブテストケースと間違ったネガティブテストケースですか？
またはログイン失敗は、パスワードが正しい必要があるという要件の確認です->無効なパスの確認は機能しません。
たとえば、人が1〜100のフィールドに「101」と入力したときにプログラムがエラーを表示すると想定されている場合、エラーが表示されればそれは正です。ただし、ユーザーが101を入力したときにアプリケーションがエラーを出さない場合は、否定的なテストになります。
簡単な言葉であなたの混乱を解決してみましょう。
ネガティブテストは、定義されている範囲外のシステムの応答を決定するために設計されたテストです。したがって、システムの設計または要件に従っていないあらゆる種類の入力は、ネガティブテストの一部であり、システムは、それを処理するのに十分な能力を備えている必要があります。クラッシュしたり、予期しないエラーをスローしたりすることはありません。
正と負は1つの命名法であり、真と偽は別のものです。一般に、ブール型の性質である2つのものを区別する必要があります。
- テスト自体は要件に従って記述されていますか、それとも違反していますか？これらをtrueおよびfalseと呼ぶことにします。
- テストの実行は成功したかどうか。これらをpositiveおよびnegativeと呼ぶことにします。
あなたの引用が「ポジティブ」と「ネガティブ」として示しているのは、実際には可能な4つの組み合わせのうち2つだけです。引用されたフレーズ「ポジティブ」は、true-positive結果、つまり有効な入力と成功したテスト結果を意味します。したがって、「負」はfalse-negative、つまり無効な入力と失敗したテストを意味します。
結果の分類
4つの可能な組み合わせのそれぞれの簡単な説明と、それらの背後に隠されているものは次のとおりです。
真陽性
入力が仕様に準拠していて、結果が期待どおりである最も単純なケース。これらについて本当に言うことはあまりありません。
真陰性
これらも良いです。有効な入力を提供し、失敗したテストは製品に問題があることを通知します。
偽陽性
これらはモンスターです。それらは緑色のチェックマークとしてレポートに表示されますが、実際にテストがテストしているものは仕様に準拠していません。
偽陰性
繰り返しますが、意味のない何かをテストしていて、失敗する方法でそれを行います。これらについての良い点は、少なくとも失敗したテストによって問題に気づくということです。
101例への応用
これを101の例に適用してみましょう。
真のテスト
最初に、2つのテストケースを記述します。テスト＃1は有効な入力に対してユーザーにエラーメッセージが表示されないことを確認し、テスト＃2は有効な範囲外の入力に対してエラーが表示されることを確認します。どちらのテストも仕様に準拠しているため、以下のtrueケースのみで終了する可能性があります。
- Test＃1真陽性：50を入力してもエラーは表示されない
- Test＃2真陽性：101を入力するとエラーが表示される
- Test＃1真陰性：50を入力しましたが、エラーが表示されます
- Test＃2真陰性：101と入力しましたが、エラーは表示されません
どちらも負の場合は、実装を修正する必要があることを示しています。
偽りのテスト
次に、さらに2つのテストを考えます。テスト＃3では、1〜100の数値を入力すると、エラーメッセージが表示されることを確認します。テスト＃4は、101を入力してもエラーメッセージが表示されないことを確認します。これらのテストは両方とも仕様に準拠していません。しかし、結局のところ、これらは実行可能なテストなので、実行することはできます。可能なケースは次のとおりです。
- テスト＃3偽陽性：50を入力するとエラーが表示される
- テスト＃4偽陽性：101を入力してもエラーは表示されません
- テスト＃3偽陰性：50を入力しましたが、エラーは表示されません
- テスト＃4偽陰性：101を入力しましたが、エラーが表示されます
ご覧のとおり、これらのテストの性質上、True-Xの結果は得られません。偽陰性の結果は問題を指摘するため、より優れています。
開発への影響
開発者としての私たちの問題は、たとえばIDEでテスト実行の結果を成功または失敗として表示するだけであり、後者にマップするpositiveまたはnegative。テストがtrueかfalseかはわかりません（テストが仕様に準拠していると自動的に判断するのは簡単なことではありません）。
真陰性は修正が比較的簡単です。コードを修正して、顧客が望んでいることを実行するだけです。
偽陰性はさらに厄介です：これは実際にテスト自体であり、欠陥があるため、製品コードを「修正」することによって偽陰性を偽陽性に変えようとする貴重な時間を失うリスクがあります。
誤検知は発生時には問題ではありませんが、将来的には問題となります。すべてのテストが成功したが、その後のいくつかのバージョンで1つのテストが突然失敗したとします。これはずっと機能してきているので、最近のコードの変更がそれを壊したと思いますが、実際、テスト自体はすでに壊れていました。
テストのFalse-Xバリアントを作成してはならないと主張するかもしれません-もちろんそれは正しいです。しかし、誰かがそれらを書いたためではなく、むしろだれかがずっと前に書いたために、他の誰かが要件/仕様を変更したため、通常はそれらは存在しません。簡単な例は、51〜150を有効な入力として許可するように例を変更することです。入力200のエラーをチェックするテストはTrue-Xテストのままですが、101を入力しようとしてエラーを予期するテストはFalse-Xになります。喜んで、それは失敗します。
さらに問題になるのは、50を入力し、エラーがないことを期待するテストです。仕様が変更されたため、50は有効な入力ではなくなりましたが、テストではまだすべてが問題ないため、アプリケーションがそれを簡単に有効なものとして受け入れることはわかりません。仕様変更により、テストは真陽性から偽陽性に変わりました。
教訓：仕様を変更するときは、必ずテストも更新してください。
参考文献
真/偽陽性/陰性の命名法は、統計、特に医療検査に由来します。彼らはしばしば問題を抱えています。テストはソフトウェアの場合のように本質的に決定論的ではないため、 感度と特異度 にも関心があります。
別の命名法（統計でも）は、false-Xのケースを タイプIおよびタイプIIエラー と呼ぶことです。
要件が数値== 101の場合にエラーを表示するように指示しているため、これはネガティブテストではないと思います。 101とも入力します。要件を検証しています。
プログラムが101の入力に対してエラーを生成するという要件をテストしている場合、101を入力してエラーを予期することはポジティブテストです。
プログラムが1から100までの値を受け入れることをテストしている場合、101を入力してエラーを予期すると、否定的なテストになります。
つまり、ポジティブテストとネガティブテストの違いは、テストする対象によって異なります。肯定的なテストは、動作が正しく機能する（または機能しない）ことを決定し、否定的なテストは、誤った入力が失敗したことを決定します。
私にとって、陽性と陰性の違いは簡単です。
positiveテストでは、valid入力が正しく処理されていることを確認します。 negativeテストでは、invalid入力によって検証が失敗することを確認します。 （肯定的なテストでは、すべての検証は必ず合格します。合格しない場合、テストは失敗します。）
または言い換えると、特定の入力/シナリオに対してすべての検証に合格すると予想される場合、テストは肯定的です。少なくとも1つの検証が失敗すると予想される場合、テストは否定的です。
したがって、私の理解では、この本は「101」の例に関しては間違っています。このような場合、無効な入力についてnegativeテストを実行します。これは、関連付けられている検証（この場合、タイプされた番号は1〜100の範囲です）は失敗します。
これはまた、有効または無効であることがわかっていない一部の入力については、動作が定義されておらず、テストされていないことを意味します。
ネガティブを2倍にしたり、ポジティブを否定したりすると、常に多くの意味上の混乱が生じます。それは方法論のテスト理論よりも英語の制限です。本質的に、多くのシナリオは何が起こるべきか、何が起こらないべきかの両方で説明することができます。 1つは「正の」効果（何が起こるか）であり、もう1つは「負の」効果-エラーです。しかし実際には、これらはテストしている2つの異なる機能です。
たとえば、1〜100の例では、2つの機能は「1〜100の入力のみを受け入れる」と「入力が1〜100でない場合にエラーメッセージを表示する」です。これらのではない同じテストの肯定的な側面と否定的な側面ですが、2つの異なるテストがあります。最初のテストの肯定的な要素は、1〜100の入力を与え、関数が機能することを確認することです。否定的な側面は、101の入力を与えて、それがしないであることを確認することです。それで全部です。
2番目の機能の場合、陽性テストは、101、またはInt32.MinValue、または0、またはその他のEdgeケースの入力を与えることであり、示されているエラーを確認します。否定的なテストは、40の入力を与え、エラーが表示されないことを確認することです。
あなたはテストと条件を台無しにしています。
参考にした本のイラストを見ると、コイラーラとシェイクは決定分岐ではなくシステム全体について話していることがわかります。
彼らは有効なシステムテスト、つまりブラックボックステストのみを見て、その結果は正しいです。
したがって、このコンテキストでは、
- 肯定的なテストとは、有効なデータを入力し、システムがdoesを処理した場合
- 否定的なテストとは、無効なデータを入力すると、システムがしないそれを処理する（そして理想的にはそれをユーザーに伝える）
データの有効性がどのように決定されるか、または要件の表現が正確に何であるかは重要ではありません。
最初に（おそらく意図せずに）*比較*を使用する例は問題を混乱させる傾向があります。比較が正しく実装されているかどうかのテスト（ポジティブテスト）と混同された否定的な表現のように聞こえる比較 "a <> b"を取得します。 。
したがって、ポジティブテストでは、システムがユースケースを正しく実装しているかどうかをテストします。 （自動販売機のユースケース「顧客がコーラを入手できる」のテストを考えてください）。
ネガティブテストでは、ユースケースの例外が適切に処理されるかどうかをテストします。 （上記のユースケース「ユーザー入力外国コイン」の例外を考えてください）。
ユースケースが成功した場合、ポジティブテストケースは合格です。
ユースケースが失敗した場合、ネガティブテストケースはパスします。
およびその逆。
ポジティブテストは、機能することが期待される機能のテストです。
例：
- 1）ユーザーが間違ったユーザー名とパスワードの組み合わせを入力した。 2）ユーザー予想されるログインしない。3）テストするユーザーがログインしていない。
ネガティブテストは、失敗すると予想されるケースのテストです。
例：
- 1）ユーザーがパスワードフィールドに無効な文字を入力した。 2）ユーザー期待されている「無効な文字」メッセージが表示されます。 3）：Test thatユーザーは「無効な文字」メッセージによってプロンプトが表示されます。