ソフトウェアテストの概要（Ammann＆Offutt）は、p.32で5レベルのテスト成熟度モデルについて言及しています。

レベル0テストとデバッグの間に違いはありません。

レベル1テストの目的は、ソフトウェアが機能することを示すことです。

レベル2テストの目的は、ソフトウェアが機能しないことを示すことです。

レベル3テストの目的は、特定のものを証明することではなく、ソフトウェアを使用するリスクを減らすことです。

レベル4テストは、すべてのITプロフェッショナルがより高品質のソフトウェアを開発するのに役立つ精神的な規律です。

詳細については触れていませんが。デバッグとテストの違いは何ですか？

テストは、コードの欠陥を見つけるか、別の角度から調べて、プログラムが想定どおりに動作することを適切なレベル（100％になることはありません）に証明することを目的としています。手動でも自動でも可能で、ユニット、統合、システム/受け入れ、ストレス、負荷、ソークなどのテストなど、さまざまな種類があります。

デバッグは、プログラムから特定のバグを見つけて削除するプロセスです。すべてのバグが異なるため、これは常に手動の1回限りのプロセスです。

私の推測では、作者は、レベル0では、テスト計画や何もせずに、手動テストのみがアドホック方式で実行され、テスト担当者がテスト対象の機能を実際に徹底的にテストし、テストを確実に繰り返されます。

デバッグは、複雑で構造化されていない信頼性の低い手動の段階的なプロセスです。デバッグを介してテストすることで、再現できないシナリオを作成するため、回帰テストには役立ちません。0以外のすべてのレベル（例では）は、この正確な理由により、私の見解ではデバッグを除外します。

デバッグとは、コードを系統的に調べることにより、既知および未知の問題を修正する試みです。デバッグしているときは、通常、コード全体に集中しておらず、ほとんどの場合、実際のコードではバックエンドで作業しています。

テストとは、デバッグ可能なコードをさまざまな方法で使用して問題を作成する試みです。ほとんどの場合、ユーザー空間で行われます。エンドユーザーがコードを実行するのと同じようにコードを実行し、コードを壊そうとします。

簡単に言えば、「バグ」は、プログラムが実行時に本来の動作をしないときに発生したと言われています。つまり、期待される出力や結果を生成しません。このバグの原因を見つけ、動作を修正する方法を見つけ、コードまたは構成に変更を加えて問題を修正しようとすることを、デバッグと呼びます。

テストでは、さまざまな条件下でプログラムまたはコードが正しく確実に機能することを確認します。入力、標準の正しい入力、意図的に間違った入力、境界値、環境の変更（OS、構成ファイル）を使用してコードを「テスト」します。基本的に、テストプロセスでバグを発見し、最終的にはそれらを「デバッグ」しようとしていると言えます。お役に立てば幸いです。

ありません。あなたがそれを正しく行う場合：

ヒット 'ハイ、ヒット'ロー：

回帰テストとSaff Squeeze

スリーリバーズ研究所、ケントベック

要約：欠陥を効果的に特定するには、システムレベルのテストから始めて、欠陥を実証する可能な限り最小のテストが得られるまで、段階的にインラインとプルーニングを行います。

テストは、クライアントにリリースする前に享受できる特権です。

バグは、クライアントにリリースした後に耐える悪夢です。

他の人は、テストとデバッグの違いは何かについて述べています。

共通点を強調したい。テスターが欠陥を見つけた場合、それを分離する必要があります。デバッグは、実行時にアプリケーションの状態とそのコードを分析することにより、問題を特定して根本的な原因を見つける手法の1つです。実際、デバッグはOxford Dictionariesによって「コンピューターのハードウェアまたはソフトウェアからエラーを特定して削除するプロセス」と定義されています。

テスターであろうと開発者であろうと、誰が欠陥を特定する（または特にデバッグする）かは二次的な質問です。

リストしたテスト成熟度モデルは、開発チームの考え方の説明です。

このリストが意味するのは、明示的に言うまでもなく、心理の変化がテストの実施方法にどのように影響するかです。

開発チームが次のレベルに進むと、テストの範囲が広がります。

レベル0では、チームは必要ないと考えているため、テストは行われません。

レベル1では、基本機能の公称範囲を提供するためにテストが行​​われます。

レベル2では、レベル1のすべてを含むようにテストが拡張され、破壊テスト（ソースコードやバイナリを含む、開発者がアクセスできるすべての情報にアクセスでき、バグである可能性があるバグを見つけようとする専用テストチーム）が追加されます。ユーザー役割からトリガー）

レベル3では、レベル1〜2のすべてに加えて、非機能ベースのテスト/非正確性ベースのテスト（パフォーマンス特性など）が追加されます。

レベル4では、ソフトウェアテストの目標は、顧客に面したITスタッフを含むすべての人がよく理解しています。したがって、ITスタッフは、テストするシナリオについてフィードバックを提供し、レベル4のリスク範囲を改善できます。

（免責事項：私はテキストにアクセスできないため、私の用語が正しくない場合があります。）

バグは目に見えるエラーです。デバッグは、テストケースの設計後に開始されるプロセスです。デバッグプロセスではエラーの原因を見つけて削除する必要があるため、テストよりも難しいタスクです。そのため、デバッグによってユーザーが不満を感じることがあります。

日常的な、実用的な言葉で言えば、それは完全にコンテキストに依存すると思います。

MED-大規模なチームでは、（銀行、軍事、大規模、高予算やビジネスクリティカルなシステムを考えて）高い/非常に高い水準に取り組んで、私ははっきりと思う「テストの結果」は「デバッグ」、と彼らは明らかにされています非常に異なるもの。理想的には、テストは（ステージング環境での）デバッグにつながり、本番環境ではゼロに近いものが必要です。

テストの範囲は広く、規則的で非常に形式化されています-デバッグは特定の障害を修正する必要がある場合に時々発生する特定のプロセスですが、これは明白ではなく、システムの機能と結果の出力の詳細な調査が必要です。

ここで私の心の中でテストは不可欠なものですが、デバッグは、障害への解決策が不透明な場合にのみ必要な特定のツールです。

大規模なチームやシステム向けのTDDの明らかな有用性を完全に理解しています。また、複雑な（多くの場合「バックエンド」）システム、または出力と比較してコードの複雑さが高い割合である場合にも、明らかに意味があります。次に、「テスト」は、いつ、なぜ失敗が発生するかを知らせる現実的な可能性を秘めています。多くの複雑な作業を行い、結果として明確に測定可能な出力が得られるシステムは、一般に容易にテスト可能であるため、テストはデバッグとは異なります。これらの場合、テストは、期待と実際のアウトプットの一致を確認または確認解除する手順ベースの正式な方法を強く意味します。テストは常に行われ、デバッグの必要性について時々通知されます。

これがユビキタスな真実であるならばそれは素晴らしいでしょう、もし私の開発サイクルが明確に定義されたバイナリ出力（赤、緑）によって区切られていれば私はそれが好きです...

私の場合（これは確かに特定です-中小規模で資金不足のWebベースのデータ中心の企業管理システムで98％一人で働いています）TDDがどのように私を助けてくれるのか本当にわかりません。つまり、「デバッグ」と「テスト」は事実上同じです。

主に「テスト」という用語の使用は、TDDの方法論を示唆/密接に関連しています。

私はこれが完全に非ツァイトガイストであることを知っており、「信じない者を避けなさい、避けなさい、避けなさい」、言うのはひどくクールなことです。しかし、私のコンテキストについて考えると、漠然としたことはありませんが、実際の帽子をかぶってさえも、想像を絶する中で、TDDがクライアントにより多くのお金の価値を提供するのにどのように役立つかを見てください。

むしろ、「テスト」は正式なコードベースのプロセスであるという一般的な仮定に強く同意しません。

私の基本的な反論（私の中に該当する特定の *コンテキスト*）は、そのです...

私はコードを書くカント場合、それは確実に動作します-そして、どのように地獄は私が確実に動作書き込みコードになっていますテストサブ標準コードおそらく言いました。

私の場合、（特定のコンテキストで）考えたことさえあるほど十分に熱狂した例や議論を見たことがありません。単一のテストを書いて、私は今、いくつかのばかばかしいほど非現実的なテストコードを書くことができ、多分「ユーザーの私のリポジトリの復帰を行いますName == Xのエンティティ、正確に-そしてそれだけ-それを要求するとき」ですが、このストリーミングを作成している私にはおそらくより多くのユーティリティがあります。おそらく、インターネットの再接続は、純粋な純粋な愚かさです。自己満足、ワイルド、アンダー、インフォームド、ブラッド、ボイリング、無知、ウェイストフル、バカバカしいゴミですが、私はここで悪魔の支持者を演じる必要性を感じています。（誰かが私に光を見せて私を変えてくれることを望んでいるようなものです、おそらくこれは私のクライアントにお金のより良い価値を与えることになるでしょう？）

間違いなく「デバッグ」は「テスト」と同じ場合があります。これはつまり、私の日常生活の中で、少なくとも3分の1の時間をシステムのローカルバージョンでさまざまなブラウザーで遊んで、必死にさまざまな風変わりなことを試し、仕事を中断して調査していることを意味します。それが失敗した理由とそれらを修正しました。

私はTDDのマントラ「red / green / refactor」の明らかな実用性に100％同意しますが、私（低予算、solo dev RIAランドで作業）では、誰かが私にどのようにして私にできるかを教えてほしいおそらく、論理的かつ極めて現実的 に、実際に実際の人間の相互作用に結び付けられている私の努力の完全な（そして本質的に唯一の）出力と実際にやり取りするよりも（潜在的に欠陥のあるテストコードと同じように）より多くの追加の値を書きます。

私にとって開発者が「テスト」について話すとき、それは一般にTDDを意味します。

私はテストがあったかのようにコーディングしようとします。このテストに焦点を当てた開発が奨励したすべてのパターン/プラクティスとトレンドは素晴らしくて美しいと思いますが、私の小さな世界では、「テスト」はより多くのコードを書くのではなく、実際に現実世界をテストすると、現実に近い方法で出力が出力されます。これは実質的にデバッグと同じです。つまり、ここでのアクティブな変更は、出力中心の非自動「テスト」による直接的な結果である「デバッグ」です。これは、「テスト」を自動化された形式的なものとして、また「デバッグ」を人間的でその場しのぎの、または非構造化されたものとして一般に認められている見方とは対照的です。

目標が本当にお金/努力の価値であり、Webベースのインタラクティブアプリケーションを作成している場合、努力の出力はWebページであり、非常に基本的には人間の入力にどのように反応するかです。したがって、「テスト」はテストによって最もよく達成されます。それらのWebページは、実際の人間の対話を通じて。この相互作用が予期しないまたは望ましくない出力につながると、「デバッグ」が発生します。デバッグは、プログラムの状態をリアルタイムで検査するという考え方にも密接に関連しています。テストは一般的に自動化に関連付けられていますが、これはしばしば残念な関連であると私は思います。

目標が本当に努力に値するものであり、自動テストが効率的で非常に有益である一方で、デバッグがそのテストの単なる出力であるか、自動テストの不十分な代替である場合、なぜ世界で2番目にアクセス数の多いWebサイトなのか（Facebook ）多くの場合、目立たないほど明白な（ユーザーには明らかですが、テストチームやテストコードには明らかにありません）バグに悩まされていますか？

多分それは彼らが安心できる青信号に集中していて、実際に彼らの仕事の出力を使うことを忘れているからでしょうか？

あまりにも多くの開発者が、テストはコードを使用して行うものであり、デバッグはアイコンを赤に変えて理由を理解できないためにIDEで時々行うものだと考えていますか？これらの言葉には、不幸な価値判断が関連付けられていると思います。これは、期待と成果のギャップを埋めるために焦点を当てるべきことの実際的な現実を一般的に覆い隠してしまうものです。

単に、

テストとは、デバッグ中にソフトウェアが失敗する原因となる入力を見つけることは、特定の障害の障害を見つけるプロセスです。