私はBE（CS）に取り組んでいる学生で、私の質問は次のとおりです。

1. ソフトウェア分野でのテストが必要ですか？
2. 細心の注意を払ってソフトウェアを作成する場合、なぜテストする必要がありますか？
3. テストした後、私たちはすることができわから我々が行っているので、我々は（意図したとおりの製品/ソフトウェアが動作します）、この目標を達成していることをテストし、それのために？出来ますか？

私の質問：ソフトウェアのテストは必要ですか？

はい。どんなに上手であっても、すべてを考えることはできないからです。

• また、ソフトウェアに意図していないことを実行させるように求められます。
• あなたもなります決してあなたは確認コードが破損しないようにするあらゆる可能性を考えることができるようになりますようにクリアされている要件を持っていません。
• また、常に意図したとおりに動作するとは限らない他の人のソフトウェアやAPIを使用しますが、「完璧な」ケースの欠陥につながる、またはそうすべきだと想定します。

はい

シェフが料理中に料理を味わうのと同じ理由で。

私はこのように考えている人と仕事をしています。彼は上級プログラマーなので、コードをテストする必要がなくなったと考えています。同社は、この態度がどれほど危険であるかを理解しておらず、彼を完全に解雇する代わりに、より多くのプログラマーを雇ってバグの未処理に対処しました。このバックログがどこから来ているのか分からないので、彼らはそれがプログラミングのすべての一部であると考えています。基本的に、このモードで動作する3人のプログラマと、これら3人が作成するバグをテストして修正する以外に何もしない20人のチームがいます。

ABSENCE OF PROPER試験KILLS。

あなたが神であるか、完全な知識を持っている何らかのバージョン（今これを見たい）でない限り、またはあなたが積極的に非常に速く解雇されたくない限り、テストを開始することを強くお勧めします。

ソフトウェアは人によって書かれています。

人々は不完全であり、間違いを犯します。

事業の複雑さが増すにつれて、間違い、見落とし、または忘れられたものの潜在的な数（および影響）が上がります-通常指数関数的に。

はい、テストが必要です。バランスと視点をもたらします。

ラップトップで使用していることがわかっているOSを実行し、好きな色で死の画面を表示するフライトに乗りますか？考えてみてください。

完璧なコーダーはありません。本当に遠い、遠い、遠い。テストが必要であり、テスターは開発者に欠けていた視点（ユースケースとも呼ばれる）を持ち込むことがよくあります。

Googleで最も有名なソフトウェアバグを検索して、私が何を言っているかを理解してください。

大学レベルでは、テスト駆動開発、単体テスト、アジャイルプラクティスについて読んで、現在の状況を把握してください。

テストは、実際に使用される自明でない（サイズまたは機能において）アプリケーションにとって絶対必要です。あなたは見つけることができません、単一の開発者に対応し、そのテストが必要ではないと言うだろう（自分がこのサイトの訪問によって証明されるように）彼/彼女の工芸品を気に。

すでに投稿されているものに加えて、任意のアプリケーションで自動化された単体テストの完全なスイートを使用することで、将来のコード変更に対する自信が高まります。（ユニットテストがBIGセーフティネットを提供するため）この高い信頼性により、既存のアプリケーションへのコード変更が高速になります（バックトラッキング/ダブルチェックが少なくなるため）

エラー・ヒューマナム

バグのないソフトウェアなどはありません。

最も熟練した開発者は、バグのあるコードを記述します。完璧な開発者が存在したとしても、次の間の不一致によるバグが存在します。

• ユーザーのニーズと仕様書
• 仕様と設計
• 予想および実際のハードウェアおよびソフトウェア環境
• 昨日と今日の真実：上記のすべては、開発プロセスのすべてのステップで完全に報告されていない変更の対象です。

完璧な開発者は、全体の一部にすぎません。そして完璧な開発者は存在しません。

実際のプログラムのほとんど：

a）数百行以上のコードを含み、多数のファイルに散らばっている;
b）複数のプログラマーによって開発されている。
c）開発者の環境とは異なる環境で使用される

したがって、実際の状況でプログラムがどのように機能するかを確認しないと、プログラムがまったく機能しない可能性は100％近くになります。

他のすべての優れた答えに加えて、完璧でバグのないことを知っていても、将来あなたのコードを処理しなければならない他のプログラマーについて考えてください。彼らはあなたのようにそれを知りませんし、あなたのテストに頼って、彼らが変更を加えた後に何も壊していないことを保証したいと思うでしょう。もちろん、これはあなたが一年以内にコードを見なかった後のあなた自身にも当てはまります！

はい。

以下に、まだまだカバーされていないもう少し微妙な視点を示します。

「独立した検証」の必要性を過小評価しないでください。それは、出版のために大量の文章を提出する前に、数人の独立した編集者にあなたの作品を調べてもらうのが良い理由と同じです。たとえあなたがどんなに優れた作家であっても、ときどき脳みそをして、「それ」の代わりに「中」のような何かを書くでしょう。自分で読み直した場合、非常に慎重であっても、通常は見逃します。なぜなら、脳は思考プロセスの流れを正しいものとして自動的に受け入れ、エラーを無視するからです。新鮮な目には、この種の間違いは通常かなり目立っています。

プログラミングでも同じことが言えます。コード、または独自のコードの基本的な「開発テスト」のいずれかのフローに入るのは非常に簡単です。テストして特定の方法で使用しているため、正しいように見えます。しかし、その後、もう1組の手が来て、わずかに異なる方法または順序で物をクリックすると、すべてがクラッシュします。

もちろん、理論的には、コード内のすべての可能性とロジックブランチをすべて自分で正式に検証するルートをたどることができますが、非自明なソフトウェアの場合、他の誰かが叩くよりもはるかに高価で時間がかかりますあなたのためのコード。そして、あなたはまだあなたが考えもしなかったことをまだ見逃しているでしょう。

まだ触れられていないこと：コードが完璧であっても、まだ安全ではありません。コンパイラには、コンパイル後に完全なコードでさえ正しく動作しないバグがあります。オペレーティングシステムには、実行時に完全なバイナリが正しく動作しないバグがあります。ハードウェアには、問題を引き起こす可能性のあるバグがあります。

1台のマシンでテストするだけでは商用製品には不十分な理由でもあります。それらは、可能な限りハードウェアとソフトウェアの可能な限り多くの組み合わせでテストする必要があります。

スペースシャトル用のソフトウェアを書いているチームのリーダーは、打ち上げの前に飛び出し、ソフトウェアがシャトルに害を及ぼさないことを示す署名をしました。

彼にそうする自信を与えたと思いますか？

コンパイルして使用するだけでコードを常にテストしています。一部のIDEでは、入力時に健全性チェックが行われます。実際にコードを実行したことがない限り、テストを行っています。

テストする量は、実際この種の質問の根源であり、その答えはリスクにかかっています。リスク管理の観点からテストするのが理にかなっている限りテストします。通常、すべてをテストするか、何もテストすることは不可能です。何もないところをテストすることは、通常、悪い動きです。リスクレベルと成果物の露出度に応じて、その間のすべてが公正なゲームになります。

宿題の質問のような匂い。

ソフトウェア分野でのテストが必要ですか？

はい。絶対に。すべてのレベルで。いくつかの特殊なドメイン以外では、コードが特定のバグに対して正しいことを数学的に証明できる段階にまだありません（少なくとも妥当な時間枠ではありません）。それが壊れる場所。

細心の注意を払ってソフトウェアを作成する場合、なぜテストする必要がありますか？

テストとは、コーディングエラーを見つけることだけではありません。また、すべての要件を満たしていること、およびシステム全体が期待どおりに動作することを確認することも重要です。失敗したトランザクションが特定のエラーコードを返す必要があるという要件がある場合は、機能が存在することと正しく機能することの両方を検証するテストを作成する必要があります。

そして、仕様と設計が完全で、正しく、内部的に一貫していることを前提としていますが、多くの場合そうではありません。文字の仕様を満たし、最後のドットとセミコロンまでデザインをたどっても、仕様またはデザインが悪い場合、統合時に問題が発生します。多くの場合、システムまたは統合テストは、仕様自体にバグがあり、修正する必要があることが判明したときに行われます（以下の戦争の話を参照）。

テスト後、この目標を達成したことを確認できます（製品/ソフトウェアは意図したとおりに動作します）。出来ますか？

いいえ、100％ではありません。最も単純なコードを除き、考えられるすべての入力または実行パスの組み合わせをテストすることはできません。すべての環境要因を説明することはできません。考えられるすべての故障モードを想像することはできません。

大きな問題がないことを合理的に確信できるポイントまでテストできます。繰り返しますが、これがすべてのレベルでテストする必要がある理由です。一連のテストを作成して、コードがエッジ条件を適切に処理することを確認します（不正な入力、予期しない結果、例外など）。コードが要件を満たしていることを確認する単体テスト。エンドツーエンド処理を検証するシステムテスト。すべてのコンポーネントが互いに正しく通信することを確認する統合テスト。ユーザビリティテストを行って、顧客があなたを撃ちたくないような方法で全体が機能することを確認します。

現実のシナリオ-私は、画面上のテーブルに表示するためにGUIサービスに更新を時々送信するバックエンドシステムで作業していました。プロジェクト中に、ディスプレイにフィルタリングを追加するための要件が​​追加されました（たとえば、オペレーターはテーブル内のエントリのサブセットを表示することを選択できます）。設計ミス＃1-フィルタリングは GUIサービスによって行われるべきでした（ディスプレイ管理機能はディスプレイ管理ソフトウェアの責任であるという古風な古風な概念があります）が、政治と問題を認識する前に認識できないためです問題、その要件はバックエンドサービスに置かれました。まあ、大丈夫、問題ありません、私はそれを行うことができます。状態の変更をフィルターし、メッセージを取得してから、作成または削除メッセージを送信しますテーブル内の各行、それがインターフェースの仕組みです（設計ミス＃2-単一のメッセージで複数の行に更新を送信する方法がありません。テーブル全体）。

まあ、開発中はすべてが正常に機能します。ユニット、システム、および統合のテストにより、正しい情報を送信し、フィルターの変更を正しく処理できることがわかりました。次に、ユーザビリティテストを実施しますが、データの量が圧倒的だったため、全体が激しく落ちます。バックエンドサービスとGUI間のネットワーク遅延は、.15〜.25秒のオーダーでした。数十行程度の更新のみを送信する必要がある場合は悪くありません。 数百の更新を送信する必要がある場合は致命的です。フィルターの状態を変更した後、GUIがフリーズするというバグレポートを取得し始めました。まあ、いや、何が起こっていたのかは数分程度かかっていた 骨付きの1行ずつ更新するメッセージプロトコルが実際のシナリオを処理できなかったため、表示を更新します。

事前に最も基本的な分析さえ行うことに煩わされていた場合、そのすべてがプライムコントラクトのすべての人に期待されていたはずであることに注意してください。私が提供する唯一の防御策は、6か月のプロジェクトの2年目を終了したことです。

これがテストの最終的な理由であるCYAにつながります。現実のプロジェクトはさまざまな理由で失敗します。その多くは政治的なものであり、物事がうまくいかない場合に全員が誠実に行動するわけではありません。指先を突きつけられ、告発されます。そして、一日の終わりには、少なくとも自分のものが想定どおりに機能したことを示す記録を指すことができる必要があります。

テストは常に行われ、バグは常に発見されます。テストはチームによって内部で行われるか、エンドユーザーがテスターに​​なるというだけです。エンドユーザーが発見したバグのコストは、テスト中に発見された場合よりも非常に高くなります。

優れたフォールトトレラントコンピューティングコースを受講することをお勧めします。ソフトウェアの注意深い設計は、ソフトウェア製品の堅牢性を達成するための柱の1つにすぎません。他の2つの柱は、十分なテストと冗長設計です。基本的な目的は、指数関数的な数の未知の障害状態に対応し、既知の障害のいくつかを優先的に処理することです。

1.）設計および適切な実装により可能な限り多くの障害を排除2.）さまざまな形式のテスト（ユニット、統合、ランダム）により設計段階および不正確な実装から予期しない障害を排除3.）冗長性により残りの障害に対処（時間的=>再計算、再試行、または空間=>コピーを保持、パリティ）

テスト段階を排除すると、障害に対処するための設計段階と冗長性段階だけが残ります。

また、製品の観点から、利害関係者（管理、ユーザー、投資家など）は、製品が特定の品質および安全仕様、基準などを満たしていることを何らかの形で保証したいと思うでしょう。 「健全性チェック」のためだけに構築しましたか？これらすべての理由により、ソフトウェアテストはより魅力的になります。

すべてのプログラムには、少なくとも最初はバグがあります。

テストされていないコードの5行ごとに約1つのバグに収束するいくつかの研究があります。

歴史の教訓：

1960年代に、IBMは実際にプログラムを実行せずにJCLでいくつかの機能を実行できるように、「NOP」プログラムを必要としていました。開発者は、コード全体がその名前「IEFBR14」に含まれる1行のアセンブラープログラムを思い付きました。実際のコードは次のとおりです。

       BR 14 * brach to return address in register 14

長い間、この1行のプログラムは2つのバグ報告と5つの修正の対象となりました。

コードリファクタリングは、ユニットテストがある場合に非常に高速です。単体テストでは、具体的な関数の簡単な使用方法も示されるため、プログラマーがコード全体を正確に知らない大きなプロジェクトで非常に役立つ「ハウツー」があります。

TDD（テスト駆動開発）を使用して開発する場合、不要なゲッター/セッターなどは必要ありません。必要なものを作成するだけです。

質問の3番目に答えるには：

プログラマーであり、ソフトウェアテスターでもあります。テスト中にソフトウェアの要件を満たしていることを確認できます。

{QAハットをかける}

どうやって？これを行うには、テストをテストコードから受け入れ基準まで、受け入れ基準を機能まで、機能を要件までトレースします。デザインチェーンですべてのテストをトレースし、それらが1つ以上の要件にマップされている場合、テストが使用されていることを確認して、コードが要件を満たしていることを確認できます（ただし、これにより、適切なテストカバレッジの概念が表示されますが、別のトピック）。テストを設計チェーンまでたどることができない場合、必要のないものをテストしている可能性があり、これは時間の無駄です。受け入れ基準には、望ましくない動作のチェックも含まれる場合があります。これもテストすることができ、品質のリリースに一歩近づきます。

{QAハットオフ}

バグのないコードはありません。開発中に品質を評価するためにより多くの労力が費やされると、時間の経過とともにコストが削減されます。

私はもう3年ソフトウェアテスターです。開発部門とプロジェクト管理が仕事をすれば、ソフトウェアの間違いは起こらないと思ったので、当初私自身はテストの必要性に懐疑的でした。

しかし、これはそうではありません。++++++++

ミスは頻繁に発生し、その一部はプロジェクトの運営に不可欠です。クロスブラウザーテスト（SAFARI、FIREFOX、CHROME、Internet Explorerなどの異なる既存のブラウザーでのテストを意味します）もあり、すべてのブラウザーでのみ動作しない調査ウィンドウでYESおよびNOのようなシンプルなインターフェイスボタンを使用するプロジェクトに取り組みましたそれらのいくつか。

私はインターネットページのテストに取り組み、単純なテキストの変更をテストしていましたが、この単純な作業には地球上で欠陥は存在しないと思いましたが、それは起こりません。

また、新しい開発者がチームに参加し、外部ページへの多数のリンク/呼び出しを含む既存の複雑なインターネットアプリケーションフォームの更新ワークピースが与えられたとき、古い開発者と新しい開発者の間の通信不足のためにミスが発生したことを見ました、さまざまな理由（教育する時間がない、教育する意志がないなど）。

はい

ソフトウェアが論理関数AND（b1、b2）のみであり、b1とb2がビットのみであると想像してください。それを使用して、周囲の環境が指定されたとおりに正確に機能する場合、ソフトウェアにエラーがないことを確認するために4つのテストケースが必要です。

現在、システムは多くの関数で構成されており、最も単純な関数はその論理関数よりもはるかに複雑です。エラーがないことをどのように確認しますか？

（つづく）