初心者テスターをトレーニングするための私のコースでは、次のような肯定的なテストと否定的なテストを作成することをお勧めします。

1. 電卓でルートを計算する機能。
2. オンラインストアでのカートの操作（追加/削除/編集）。

そしてそれが私が気づいたことです - 検査結果が陽性であればすべて問題ありません、みんながアイデアを考え出しています さまざまな種類テスト (タスクはいくつか挙げることであり、すべてをリストすることではありません。したがって、チームで作業している場合でも、同じことを繰り返す必要はありません)。 しかし、多くの人が負の数に問題を抱えており、その説明を求めています。「かごの中の商品の数の数値に記号を入力し、負の数の根を計算すること以外に何も思い浮かばないからです」。

そこで、解説記事を書くことにしました。

陽性検査

テスターは、製品に関する情報をチームに提供する人です。 そこで、私たちは同じオンライン ストアを作成することに決め、コンセプトを熟考し、コードを書きました。そして、テストのタスクは、すべてが必要なとおりに機能するかどうかを判断することです。

そしてもちろん、検査で陽性反応が出ることは非常に重要です。 ユーザーが当社の Web サイトにアクセスし、カートに商品を入れることができなかったとしても、特殊文字や SQL インジェクションを入力するときに当社が美しいエラー メッセージを作成することはまったく気にしません。

したがって、何かテストすることが与えられると、私たちは喜んで新しい型を破ろうとすることができますが、 する必要があるまず正しいスクリプトを確認してください。 まず忠実で有能なユーザーを満足させてから、残りを行います。

したがって、ポジティブ テストは、主要な機能が動作することを確認することを目的としています。 当社のシステムを使用するすべてのシナリオは実行可能であり、エラーではなく期待どおりの結果が得られます。

例を見てみましょう:

主なテスト ケースは、正しい数値の根が実際に計算されるかどうかを確認することです。

次のように分解できます。 次のクラス等価：

• ルートを計算すると整数が残ります (4 のルート = 2)
• 根を計算すると小数が残る（3の根）

うーん、小数だけではない場合はどうなるでしょうか 後 ルート計算だけでなく、 に ? 2.2のルートを取れるでしょうか？ 検査で陽性反応？ ポジティブ！

数値を最大 100 までの小さな数値に分割することもできます。 次に、100 からサイズ int までの間隔を取ると、3 番目の値はさらに大きくなり、計算機に収まる程度になります。 3 つの等価クラス、区間から 1 つの値をチェックします。

境界値を忘れずに、0 を確認しましょう。検査で陽性ですか? でももちろん！ 0 の根は 0 であり、エラーではありません。

主要なものから、おそらくすべて。

ああ、そこは想像の余地がありますね！

ユーザーは非常に多くの異なるシナリオを実行できます。 しかし、まず第一に、主要で短いものを取り上げましょう。 なぜなら、それらが機能しない場合、長いチェーン (追加 - 編集 - 削除 - 再度追加など) はチェックする価値がまったくないからです。 それで：

個別に動作すれば動作すると思いますか？ いや、皆さん、テスターですよ！ プログラムの言葉を決して鵜呑みにしないでください。 脚本は思いつきましたか？ それをチェックしてください！

さらに、このようなシナリオは失敗する可能性が高く、この製品はすでにカートから削除されています。 そのため、システム上、再度追加できない可能性があります。 「もう諦めたんだね、こんにちは、全部覚えてるよ！」みたいな。 この行動は正しいのでしょうか? いいえ！

脚本自体は前向きですか？ はい！ すでに倒錯のメモが付いていますが、認めざるを得ません

陰性検査

陰性検査は陽性検査と同じくらい重要であることを覚えておく必要があります。 なぜなら、ユーザーはロボットではなく人間だからです。 そして人は間違いを犯す傾向があります。 そして私たちはこの人的要因について常に忘れてはなりません。

現場に来て、注文して、すべてがうまくいったら、また来ます。 しかし、注文をしに来て、どこかでうっかりミスをしてしまった場合、たとえば、番号の代わりに ICQ からコピーしたメッセージを貼り付けた場合、システム全体がクラッシュするのではなく、機転の利いた発言が見たいのです。

一般に、現在では、ユーザーの問題 (たとえば、何かを購入する必要があるなど) を解決するためのサイトが多数あります。 それらを見て、必要な機能がどこでも利用できることに気づいたユーザーは、最も美しくて便利なサイトを選択するでしょう。

しかし、どんなに便利なサイトであっても、人的要因の影響で機能しなくなってしまえば、ユーザーは遅かれ早かれ離れてしまいます。 「左にステップ、右にステップ - 実行」、誰がそれを好むでしょうか？ 間違いを犯して修正できるようになり、画面いっぱいに恐ろしいエラー メッセージが表示されることのないようにしたいと考えています。

そのため、陰性検査を実施しています。 陰性検査とは何ですか? これは明らかに間違ったデータを入力しています。 プログラムを入力して、プログラムがどのように動作するか、エラー メッセージが明確かどうかを確認します。

しかし、そのようなテストを作成するにはどうすればよいでしょうか? 例を見てみましょう:

1. 電卓でルートを計算する機能。

最初に思い浮かぶのは、負の数の根を計算するとどうなるかということです。

しかし、ここで他に何が考えられますか?

• 空白からのルート - 境界値について覚えておいてください。負の長さの文字列を入力することはできませんが、境界値 (長さ 0 の文字列) を入力することはできます。
• シンボルのルート - シンボルを入力または貼り付けた場合にシステムが何を表示するかを確認する必要があります。 さらに、記号をロシア語、英語、特殊記号に分けてご紹介します！
• 「4」を意味するシンボルの語源は、アブラカダブラと「タイプナンバー」に分けることもできます。 さて、そんな「数字の種類」といえば……。
• 数値を表す文字列を入力してみましょう。 そしてそこから根を取り除きます。

わかりますか？ 実際、テストの数はそれほど多くありません。 別途、「できるだけ大きな数を入力する」というテーマについてコメントしたいと思います。 試してみてはいかがでしょうか? しかし、これはルート計算よりも二乗シナリオに悪影響を及ぼします。

ルートには、可能な最大の数値を入力することはできませんが、そこからルート（小数値）が非常に長くなり、画面に収まらないことが判明するような数値を入力します。その場合、どうなりますか？切れたのか壊れたのか？

2. オンライン ストアのショッピング カートを操作します。

ここでも、電卓で行ったように、数値フィールドを見つけて操作できます。 ここでは「商品数量」フィールドが非常に適しています。 しかしその一方で、こんなに異なるアプリケーションで同じテストを行うのは退屈ではないでしょうか?

たった 2 つの単語を覚えておいてください - さまざまなタブ !

感じますか？ 説明しましょう。 カートからアイテムを削除するためのネガティブ テストは、既に削除されたアイテムを削除しようとすることです。 これを行う方法のオプションは次のとおりです。

• 2 つのブラウザ タブでカートを開きます。 まず 1 つ目で「削除」を押し、次に 2 つ目で「削除」を押しました。 つまり、自分自身が既にゴミ箱から削除したものを削除しようとする試みです。
• 管理者によって削除された製品を削除しようとしました。 管理者の下の 1 つのタブでは、原則として製品を完全に削除し、もう 1 つのタブでは、ユーザーの下のカートから商品を削除しようとします。

ちなみに、管理者によって削除された商品を追加したり、数量を編集したりすることもできます。 また、管理者は製品を削除することはできませんが、別のカテゴリに移動することはできます。 そしてここでは何も壊れるべきではありません！ 削除の場合は正しいエラー メッセージが表示され、転送の場合はそのまま作業を続行できます。

管理者がストア階層内で製品を移動せず (製品を別のカテゴリに移動しました。製品は元々間違って配置されていました)、単純に修正して説明を編集した場合はどうなりますか? 何も壊れてはいけません！

また、ストアがなくても、別のストアがある場合でも、さまざまなタブのテクニックをどのように適用できるかを常に考えてください。

たとえば、人物、建物、同じ本、その他のカードを作成できます。2 つのウィンドウで編集してみてください。 1 つ目では、1 つのフィールドを変更して保存し、2 つ目では、別のフィールドを変更して保存します。 または、何かを削除し、2 番目のウィンドウで追加または変更します。

常にそのようなもので遊ぼうとすると、プログラムにとって悲惨な結果に終わることがよくあります。 また、たとえチームが重大ではないとしてそのような欠陥を当面は修正しないと決定したとしても、それは問題ではありません。 私たちにとって重要なことは彼らについてです 知る ！ 情報を提供し、それをどう扱うかを決定します...

実際の実践からもう一つ例を挙げたいと思います。 また、「作成」をクリックして新しいカードを追加できる Web インターフェイスもあります。 ユーザーはそれを追加しますが、毎回、型が外れてしまいます。 なぜ？

彼らはそれを知り始めた。 そして彼らは理解しました。 ユーザーは一度に多くのカードを作成 (移行) する必要があったため、Ctrl キーを押しながら「作成」を数回クリックしました (新しいタブで開きます)。 そしてタブを調べて作成しました。

陰性検査はどこにあるのでしょうか？ 結局のところ、ユーザーは同じカードを変更することで矛盾する変更を行うことはありません。 いいえ、彼は新しいものを作成します。つまり、情報を入力します。 違う カード。 でもシステムはそう考えたんだ 窓を開ける「新しいカード」には何かの情報を詰め込もうとするユーザーの傲慢な試みに大声で憤慨している。

さあ、みんな、頑張れ！ 別のタブを開いて先に進み、プログラムが相反する影響下でどのように正確に動作するかについての情報を探してください。

PS - これは初心者テスター向けの私の本からの抜粋であり、私の学校のテスター向けの学生を支援するために書かれました。

ぜひ遊びに来てください！

つ

そして、すべてのプロガーがこれに満足しているわけではありませんが、テスターは陰性テストのことを決して忘れません。 しかし、そのようなチェックは「邪悪なテスター」の気まぐれではなく、脆弱性を解決し、システムに侵入するハッカーやボット、Dos/DDos 攻撃から保護する必要があるために行われます。

もちろん、テスト専門家の使命とは何でしょうか?問題を見つける必要があります。 ほとんどの場合、誰も考える時間がなく、誰も見たくない、対処したくない問題です。 そして、それがチェックされているだけでなく、 正しい仕事システムだけでなく、その異常な動作も含めると、チーム内の緊張が高まります。

ご存知のように、プログラマーは、インスピレーションの翼に乗って、計画されたリリースで結果を目指してソフトウェアを作成します。 そして検証段階に入ります。 多数の修正そして「理想的な」コードに編集します。 それで終わりです、どこかに隠れてください、システムはテスト中です。

専門家の中には、誰にも迷惑をかけないように、期限や予算を削減するために陰性検査を後回しにしたり、検査を完全に無視したりする人もいます（恐ろしい！）。 では、プログラムが本来すべきことを行っていないかどうかを確認する必要はありません。 いいえ。

陽性検査と陰性検査

しかし、まず最初に。テスト ケースを使用してソフトウェアをテストする場合、肯定的なチェックと否定的なチェックの 2 セットのチェックがあります。 さらに、通常は前者よりも後者の方が多くなります。

陽性検査- これは、技術仕様に従って、システムの動作が通常の (標準、予想される) 動作に準拠しているかどうかをチェックすることです。 つまり、ここでは、ソフトウェアが期待どおりの動作をするかどうか、実装が最新の要件を満たしているかどうか、ガイドラインがサポートされているかどうかを確認します。 ユーザーインターフェース等

あ 陰性検査- これはシステムの異常な動作をテストしています。 ソフトウェアが誤ったデータ入力に耐性があるかどうか、例外状況がどのように処理されるか、エラー メッセージにどのような情報が表示されるか、製品の機能を中断したり、ソリューションのパフォーマンスに影響を与える可能性があるかどうかなどを検討します。の上。

一部の専門家は陰性検査を後回しにしたり、完全に忘れたりしているとすでに述べましたが、これはほぼ同じことです。 ご存知のとおり、後回しにしたものは、ほとんどの場合、満たされないままになります。

したがって、私たちの意見では、

陰性検査と陽性検査を分離したり、時間の間隔をあけたりする必要はありません。

なぜなら、正しい入力に対する応答をテストするだけで、システムが正常に動作していると言えるでしょうか?

陽性陰性検査

テストするときは、直観、本能、狩猟本能がどれほど重要であるかを、好きなように呼んでください。 ここでは当社のエンジニアが座って、たとえば登録フォームをチェックしています。

彼は仕様とテストシナリオに従ってすべてをチェックし、データがどのように処理されるかを観察し、ユーザーがフィールドに入力する必要があります（ちなみに、実際に入力するわけではありません）。 このログインフィールドに通常のテキストではなく「%adynadyn/>」を入力すると、間違いなく何かが起こるように思えます。 暗くて暗い何かが間違っています。

そして何？彼は自分自身にこう言い聞かせなければなりません。 今のところ、陽性反応を示す検査のみを行う必要があります。それ以外は何もする必要はありません。 来週は予定が入っていないので、%adynadyn/> の時間になります。 多分"？

私たちは陰性検査に対するこのアプローチは効果がないと考えています。その理由は次のとおりです。

1. 陽性検査と陰性検査を別々に行うと、さらに時間がかかります。 少なくとも、すでに 2 回のテストが繰り返されることになるためです。
2. テスターとプログラマーは締め切りに追われています。 また、時間が厳しく制限されている場合、陰性検査を後まで延期すると、最終的には忘れられてしまうリスクが高まります。 結局のところ、瞬間 X に近づくほど時間の流れは速くなり、割り当てられたタスクを完了し、欠陥を修正し、最終的なビジネス要件 (変更される可能性があります) を適用し、その他の多くの作業をより早く完了する必要があります。 締め切り - 忙しい時期です!
3. 私たちの意見では、陰性検査と陽性検査を分離することは、検査者の性質にまったく反しています。 結局のところ、その主なタスクは、エンド ユーザーの考えられるすべてのアクションについてシステムをチェックすることです。 しかし、人間のほとんどは非論理的であり、ソフトウェアを使用するとあらゆる種類の卑劣なことができます;)

私たちテスターは、システムにネガティブなカテゴリーに分類されるチェックエラーが含まれているかどうかを非常に心配しています。 特に、そのようなエラーの結果がシステム全体にとって重大な場合にはなおさらです。 しかし、私たちはそれらを報告することを恐れていません。 特にこのようなエースがいる場合、チームには女性テスターがいます。 そして、彼らが優しい声でプロジェクトのパフォーマンスを木っ端微塵に引き裂くとき、誰がコードの「理想性」を頑固に守ることができるでしょうか？ 同じことです。

では、どのような結論を導き出せるでしょうか?

陰性検査のことを忘れずに、陽性検査と組み合わせ、経験豊富な専門家をチームに集め、報告の仕事を女子生徒の肩に移してみてください。 最後の項目を除くすべてを 100% 推奨します。プロジェクト マネージャーが解決します。

そしてもちろん、必ず製品をチェックしてください。プログラマーがすぐにクリーンで美しいコードを書くとは考えないでください。それでもバグなしではやっていけないのです。 言うまでもなく、個人データや機密データが定期的にネットワークに漏洩することからわかるように、多数の脆弱性があります。

品質保証用語

今回は開発におけるQA（品質保証）について見ていきます。 ソフトウェア。 これらはすべてソフトウェア テストに関連していますが、この記事では複雑なことについては説明せず、用語についてのみ理解します。 QA の用語は非常に重要であり、それがなければ製品をテストすることができません。 すでにご存知かと思いますが、qaはQuality Assuranceの略で、品質保証(品質管理)を指します。 用語の話に移りましょう。

陽性検査

これは、システムの通常の (標準的、予想される) 動作に対応するデータまたはシナリオに対するテストです。 「ポジティブ」テストの主な目的は、システムが設計どおりに実行できることを検証することです。

陰性検査

これは、異常な動作に対応するデータまたはシナリオに対するテストです。 「ネガティブ」テストの主な目的は、さまざまな種類の影響に対するシステムの耐性をチェックし、間違ったデータセットを検証することです。

機能テスト

これは、ユーザーの問題を解決するための機能要件の実現可能性を検証するためのテストです。

機能テストには次のものが含まれます。

• 機能的適合性
• 正確さ
• 相互運用性
• 規格および規制の遵守
• 安全

パフォーマンステスト

これは、動作速度を確認するために実行されるテストです。 コンピューティングシステムまたは、特定の負荷がかかっている状態の一部。 また、スケーラビリティ、信頼性、リソース消費など、他のシステム品質属性をテストおよび検証するのにも役立ちます。

パフォーマンス テストには次のものが含まれます。

• 負荷テスト
• ストレステスト
• 安定性試験（安定性・耐久性・浸漬試験）

ユーザビリティテスト

このユーザビリティ テストでは、ユーザー インターフェイスを通じて提供されるシステム機能にユーザーがどの程度簡単にアクセスできるかを判断します。

UIテスト

GUI テストには、アプリケーションが GUI 要件を満たしているかどうか、プロフェッショナルに見えるかどうか、一貫したスタイルで設計されているかどうかのチェックが含まれます。

セキュリティテスト

さまざまな攻撃に対するソフトウェアの脆弱性を評価するプロセス。

ローカリゼーションテスト

これはローカライズ版をテストするプロセスです ソフトウェア製品。 ユーザー インターフェイス要素の正しい翻訳のチェック、システム メッセージとエラーの正しい翻訳のチェック、「ヘルプ」/「ヘルプ」セクションおよび付属ドキュメントの翻訳のチェック。

互換性テスト

非機能テストの一種。その主な目的は、特定の環境で製品が正しく動作することを検証することです。

環境には次の要素が含まれる場合があります。

• ハードウェアプラットフォーム。
• ネットワークデバイス。
• 周辺機器 (プリンター、CD/DVD ドライブ、Web カメラなど)。
• オペレーティング システム (Unix、Windows、MacOS など)
• データベース (Oracle、MS SQL、MySQL など)
• システム ソフトウェア (Web サーバー、ファイアウォール、ウイルス対策など)
• ブラウザ ( インターネットエクスプローラー、Firefox、Opera、Chrome、Safari)

ブラックボックステスト

テスト対象のオブジェクトの内部構造に関する知識を使用せず、外部世界の観点からオブジェクト (プログラム、システム) の機能的動作をテストする方法。

ホワイトボックステスト

プログラムの内部構造の問題を検出するために実行されます。 このため、審査官には深い知識が求められます。 内部構造したがって満たすことはできません 一般ユーザー。 このようなテストの一般的なタスクは、プログラム アルゴリズムの各ステップを検証することです。

グレーボックステスト

ホワイトボックステストとブラックボックステストを組み合わせたものです。 このテストの目的は、アプリケーションの不適切な設計または不適切な使用に起因する欠陥がある場合に、それを見つけることです。

手動テスト

これは、あたかもユーザーであるかのように、プログラムのすべてのコンポーネントのパフォーマンスをテストするときに、プログラムの動作における欠陥を検索するプロセスです。

自動テスト

このテストプロセスでは、 ソフトウェアテストを実行して実行結果を検証するため、テスト時間の短縮とテスト プロセスの簡素化に役立ちます。

単体テスト (コンポーネント/単体テスト)

個々のモジュールが正しいかどうかをチェックできるプロセス ソースコードプログラム。

結合テスト

ソフトウェア テスト。個々のソフトウェア モジュールを組み合わせてグループとしてテストします。 統合テストは単体テストの後、システム テストの前に行われます。

システムテスト（システム/エンドツーエンドテスト）

これは、システムが元の要件を満たしていることを確認するために、完全な統合システムに対して実行されるソフトウェア テストです。 システム テストはブラック ボックス テスト手法を指すため、システムの内部構造に関する知識は必要ありません。

ここで説明した用語はほんの一部ですが、QA では非常に重要です。 もしかしたらテストの話題にも触れるかもしれませんが、今日はここまでです。

関連記事：

問題解決 アドビフラッシュの上 YouTubeの例- 読む

1. pidvalがこの投稿を「スキ!」と言っています
2. alexruzhykがこの投稿を「スキ!」と言っています
3. anko-777がこの投稿を「スキ!」と言っています
4. この投稿を「スキ!」と言っています
5. yujiがこの投稿を「スキ!」と言っています
6. yyyyyyがこの投稿を「スキ!」と言っています
7. eridiがこの投稿を「スキ!」と言っています
8. sarahがこの投稿を「スキ!」と言っています

なぜ人は心理テストを受けるのでしょうか? 当然のことながら、誰もが独自の動機を持っています。 誰かが自分自身を理解し、「私が誰であるかを理解したい」と思っています。 自分の性格についての既存の意見を確認したい人がいます。 自由時間を潰して楽しんでいる人もいます。 しかし、誰もが、たとえそれが気づかずにあったとしても、純粋に自分自身について何か良いことを聞きたいと思っています。 何のために？ そう、そうすることで気分が高揚するからです。 私たちがあなたに受けることをお勧めするテストの唯一の目的は、あなたの現在の状態に少しでも前向きな気持ちをもたらすことです。 実際、これはテストではなく、ポジティブな予測のようなものです。 そして、ご存知のとおり、それらは非常に頻繁に実現します。

06.10.2018 16947 +67

他の人があなたの名前をどう認識しているか知りたいですか?無料 オンラインサービス音韻分析を使用すると、特定の単語が潜在意識レベルでどのように認識されるかを知ることができます。 これを利用すると、たとえば、子供の名前や会社の名前を選択できます。
1ヶ月後の自分の気持ちを確かめてみましょう！現在、私たちのウェブサイトであなたのバイオリズムを完全に無料で計算できます。 計算結果に基づいて、個人的な推奨事項と翌月のバイオリズムの変更スケジュールが表示されます。
人気の心理テストあらゆる好みに合わせた人気の心理テストが多数収録されています。 男性向け、女性向け、難解な内容、プロフェッショナル向け...そしてこれらはすべてオンラインで無料、登録なしでご利用いただけます。

この記事は、フォーラムで受け取った批判と勧告を考慮して改訂されました。

この記事では、ソフトウェア テストについての私の理解を説明したいと思います。このプロセスは、私にとって常々思っていたように、簡単ではなく、想像すらできなかった非常に興味深いプロセスです。

私はソフトウェアテストとは何なのか、ずっと興味がありました。 開発者自身がそのような優先度の低いタスクに数時間費やすことができるのであれば、ソフトウェア製品のテストに人を雇う必要はありません。 そして最後に、そもそもなぜテストするのでしょうか? 結局のところ、プログラマーは賢い人たちであり、正しく書きます。 しかし

すべてが私に思われたほど単純ではありません。

プログラマーからテスターに​​転身した私は、十分な理論を身につけずに、意図的に間違った入力データを提供してソフトウェア製品を「壊す」ことにかなりの時間を費やしました。 そして、奇妙なことに、それは壊れました。 エラーメッセージが生成され、また一日が無駄ではなかったと考えられました。

その後、どれだけテストを実行してもエラーが発生するという事実に遭遇するようになりました。 テスト対象のアプリケーションに入力として何をどのように与えるべきか全く分からず、テスト プロセスは終わりがないように思えました。 その結果、テストの期限は守られず、PMは怒り、開発者は「ナンセンス」にうんざりするという悪循環が生まれます。

そして、ソフトウェアをテストするために実行する必要がある一連のアクションを明確に自分で特定したのは、ずっと後になってからです。

1. 仕様を勉強してください。 この段階は最も重要であり、設計分析や要件分析とも呼ばれます。 時々「仕様テスト」という名前が使用されますが、なぜ「テスト」なのかは少し後で理解します。 ここでは、アプリケーションのドキュメント (仕様) を注意深く読む必要があります。
2. 煙のテスト。 この段階では、システムがまったく機能しているかどうか (正しく機能しているかどうか、正しく機能していない場合に正しく「誓う」かどうかなど) を確認する必要があります。 これは、アプリケーションがさらなるテストに適しているかどうか、またはまったく機能しない (正しく動作しない) かどうかを理解するために行われます。
3. 「陽性」検査。 この第 3 段階では、アプリケーションが「正しい」入力データを受け取ったときの結果を確認する必要があります。
4. 「陰性」検査。 これは初期テストの 4 番目で最後の段階です。 ここでは、アプリケーションが「間違った」データを入力として受け取ったときにどのように動作するかを確認する必要があります。 これは、この場合にアプリケーションがどのように動作するかを決定するために行われます。 このようなオプションが仕様書に記載されており、記載する必要がある場合は、期待される結果と得られた結果を比較してください。

それでは、すべてを順番に見てみましょう。

仕様、要件、SRS。

アプリケーション自体がいつどのように動作するのか、いつどのように「中断」するのか (つまり、システムまたはそのモジュールが無効なデータや誤ったユーザーの動作にどのように反応するのか) をどのように判断するのでしょうか? 正しい処理を行った場合、どのような結果が得られるか、どのような条件および入力データで正しい処理が行われる必要があるか? テスト対象のアプリケーションが誤って実行された場合、どのような状況で何が起こるでしょうか?

これらの質問はすべて、テスト対象のアプリケーションのドキュメントで答えられます。 いずれの場合でも、答えが存在する必要があります。そうでない場合、ドキュメントは不完全であり、ドキュメント内のエラーとなります。 この段階ですでに最初の欠陥が発生する可能性があることを留保したいと思います。仕様 (要件) の欠陥は、システムにとって同じくらい重要です (場合によっては、 背が高い 優先的に!) 欠陥。 要件テストは本格的なタイプのテストであるにもかかわらず、不当にもほとんど注目されていないことにも言及する価値があります。 要件テストの成功の主な指標は、完全性 (テスト容易性) と要件の一貫性の基準の達成です。

このドキュメントを使用すると、アプリケーションをテストする主な手順、アプリケーションがどこでどのように動作するのか、どこで「壊れる」のかを自分で理解することができます。 そして、同じくらい重要なことですが、 どうやって 壊す。 テストが成功したときに何を「言う」か、テスト中にどのようなエラー メッセージが表示される可能性があるか、または表示されるべきか。

アプリケーションの要件に関するすべての「知識」と、開発者によるこれらの要件の実装の機能を理解したら、最終結果のテストを開始できます。

テストプロセス

このプロセスは次の手順で説明できます。

1. 「正しい」データを入力として受け取ったときにアプリケーションがどのように動作するかを確認します (「何が良いのか、何が悪いのか」を知るには、ドキュメントを読んでください)。
2. すべてが正常に動作し、正しく動作する場合 (つまり、仕様に記載されているとおりに)、次のステップは境界値 (つまり、「正しい」データがどこで始まり、どこで終わるのか) をチェックすることです。
3. 許容値の範囲外のデータを入力した場合のアプリケーションの動作を確認します（もう一度仕様を確認してください）。

最初と 2 番目の段落では、「陽性」テストと呼ばれるプロセスについて説明します。 「ポジティブ」テストは、テスト対象のシステムの通常の (標準的、予想される) 動作に対応するデータまたはシナリオに対するテストです。

3 番目のポイントは、「陽性」 - 「陰性」テストの逆のプロセスを説明します。 これは、さまざまなエラー メッセージ、例外状況、「法外な」状態など、テスト対象システムの異常な動作に対応するデータまたはシナリオに対するテストです。

ただし、「陽性」および「陰性」検査の前に「煙」検査を行う必要があります。

Information Dictionary には、「煙テスト」という用語がかなり明確に定義されています。

• ソフトウェア製品の構成を変更した後、またはソフトウェア製品 (ソフトウェア製品) 自体を変更した後にテストする基本的な形式。 煙テスト中、テスターはソフトウェアに「煙」が存在するかどうかをチェックします。 何かを探しています 重大なエラープログラム。
• 重要な変更または「ビルド」後のプログラムの最初の起動。

テストの優先順位

「陽性」検査が「陰性」検査よりも桁違いに重要だと考えられるのはなぜですか?

システムが「不正な」入力データに対してあまり耐性がないと仮定しましょう。 怖いですか？ 多くの場合、多すぎません。 ユーザーは遅かれ早かれ、「」を回避することを学ぶでしょう。 落とし穴」、「危険」または「不正な」行為は行わない、サービス テクニカルサポートユーザーが通常どのような問題を抱えているかをすぐに思い出し、「いかなる状況でもこのフィールドを空のままにしてはいけません。そうでない場合は...」などのアドバイスをくれるでしょう。

しかし、システムがその主な目的を果たさない場合、ユーザー（顧客）がビジネス上の問題を解決できない場合、すべてを正しく実行し、適切なデータを入力しても結果が得られない場合、これらすべてはまったく起こりません。 そして、この状況では彼らに何もアドバイスすることは不可能です。 そして彼らは去ります...

これが、「陽性」テストが「陰性」テストよりもはるかに重要である理由です。

ただし、これは「陰性」検査を無視できるという意味ではありません。 価値の優先順位は、ソフトウェアのライフサイクルのすべての段階で変わらないわけではありません。

再開する

アプリケーションをテストする最初のステップを成功させ、肯定的な結果を受け取ったので、「もっともっと」と言われるように、アプリケーションをテストするためのより洗練された方法を考えることができます。 それはすべて、必要なテストレベルの深さ、アプリケーションをテストする意欲と能力によって異なります。 当然のことながら、上記の 4 つの段階はアプリケーションのテスト サイクル全体をカバーするものではありませんが、初期テストには必須です。