ソフトウェア開発者の大企業は、プログラムのバグをどのようにチェックしますか？
ソフトウェア開発者の大企業がプログラムのバグをどのようにチェックするのかと思っていました。
彼らは数台のコンピューターでテストするだけですか？
ここでは、Googleが使用するテクニックの一部を紹介します。
- 信頼できるコードを生成する可能性が高い優れた開発者を雇います。
- 単体テスト かなり。
- code review を使用します。
- 継続的ビルド を設定して、統合の問題をキャッチします。
- 専用のQA部門があります。エンドユーザーをシミュレートするテストと自動化されたプログラム（Seleniumを使用するなど）の両方を意味します。
- 本番環境で監視を行い、不正な動作の証拠を見つけます。
私はこれらをバグの検出における有効性の降順であると思われるものにランク付けしました。
大企業には通常、Q/A部門全体があり、コードをテストし、想定どおりに機能することを確認します。これは通常、あなたが説明したとおり、多くのマシンをテストする多くの人々です。テストは自動化されている場合とそうでない場合があります。参照 品質保証-ウィキペディア
多くの場合、開発者自身が開発プロセス中にバグを発見します。また、顧客がバグを最初に発見することもよくあります。
私が現在働いているような中小企業は アジャイルテストの実践 を使用します
企業の成熟度とサイズではない :)について言えば、貧弱な開発慣行を持つ大企業と最先端の小企業があります。
一般に、成熟した開発チームは次の活動に従事します。システムへの新しいバグの導入を最小限に抑える2。既存のシステムのバグを見つけます。
単体テスト：これらは、メソッドが実行することを確認するための個々のメソッドの「ミニドライバー」です。これらは常に自動テストです。
統合テスト：これらのテストは、より大きな機能単位がシステム内で機能することを確認することを目的としています。これには、データベース統合またはサードパーティライブラリとの統合のテストが含まれる場合があります。これらも自動テストです。
受け入れテスト：受け入れテストは、ユーザー要件をテストするために作成されます。これらは通常、「ハッピーパス」をテストするだけです。私のチームでは、これらのテストは、ユーザーが使用するように設計された機能をユーザーが使用する場合、問題がないことを示すように設計されています。手動または自動化できます。
機能テスト：これらのテストは受け入れテストに似ていますが、「不幸な道」もテストします。これらのテストは、それほど明白ではないシナリオをテストすることを意味します。手動または自動化できます。
回帰テスト：この用語は、システムが顧客にリリースされる前にシステムの「完全なテスト」を行うために使用します。手動または自動。
ゴリラテスト：（手動のみ）。これは、非常に賢い人間が意図的にアプリケーションを破壊しようとした場合の種類のテストです。
パフォーマンステストパフォーマンスが許容範囲内であり、時間の経過とともに低下しないことを確認することを目的としています。通常は自動化されています。
安定性テスト：これらのテストは、システムが長期にわたって安定していることを確認するために設計されています。自動化。
継続的インテグレーション：これは、コードを自動的にチェックアウトしてコンパイルし、自動テストを実行するシステムです。開発者がコードをコミットするたびに、より高速なテスト（ユニット、統合）が実行されます。他の一部は、毎晩（受け入れ、機能）または毎週（パフォーマンス、安定性）実行されます。
コードカバレッジレポート：テストされたコードの量を示します。テストカバレッジがないコードは、壊れる可能性が高くなります。
コードを分析するさまざまなツール：これらは通常、潜在的なバグが発生しにくくするためにコードをリファクタリングする必要がある場所を示します。
ペアプログラミング：機能を提供するために協力し合う2人の開発者。 「まとまりのあるペアは、その部分の合計よりも優れています。」
最も重要なのは自動化および継続的積分です。
それは会社と開発する製品に依存します。
まず、多くの企業は、コードレビューや必須のリンティング（自動バグ検出ツール）などのコーディング手法を適用して、リポジトリに入るエラーの量を減らしています。多くの企業も単体テストを採用しています。これは私が働いている場合です（Google）。コードがチェックインされると、すべてに対してテストが実行され、新しいエラーが発生しないことを確認します。
次に、多くの企業には、行動の検証を担当するQA部門があります。これは、金融では特に一般的です（間違いは高価であり、検証ルールは複雑です）が、リコールが高額になる可能性のあるユーザーに製品を販売する会社（Intel、Microsoftなど）にも存在します。
3番目に、可能な企業は常にドッグフーディングを行い（自分のユーザーに製品を内部で使用して）、限定ベータ版をリリースします。この段階で多くのエラーがキャッチされます。たとえば、Microsoftで働いている人々は、OfficeやWindows、DevStudioの内部バージョンが、外部のものよりも新しいバージョンを使用しています。次に、限られたユーザーグループまたは契約企業がサンプルを取得します。同様に、Googleではリリース前に内部バージョンのGMailとドキュメントを使用しています。ゲーム会社はオープンベータ版を編成して、製品やサーバーの負荷などをテストします。
もちろん答えは「それがかかる」ですが、私はこれまでで最大のプロジェクトからサンプルを提供します。
基本的なセットアップ：BizTalkで大量のデータを処理するためのバックエンドソフトウェア。
防御の第一線はユニットテストです。私たちの場合、これらはソース管理にチェックインされたすべてに対して毎日実行され、通常、チェックイン前に開発者が手動で実行したものもあります。単体テストは主に開発者によって作成されましたが、テスターによる追加のテストで修正されることもあります。
次のステップは、毎週のVirtual PCビルドでした。テスターは、各コンポーネントの仕様ドキュメントに基づいて、主に自動化された一連のエンドツーエンドテストをデータフローで実行しました。
その後、同じVirtual PCが実際のデータに非常に近いいくつかのビジネスデータで強化され、いくつかの特定の使用例で再度テストされました。
次に、Virtual PCを他の部門の他のシステムコンポーネント（ほとんどは仮想）と組み合わせて、ユーザーがデータを入力してからデータフローの最後までのエンドツーエンドのテストに基づいて統合テストサイクルを行いました。
別のトラックでは、システムプロバイダーによってインストールパケットがテストされ、本番環境のような環境に正しくインストールされているかどうか、および何かが失敗した場合にロールバックできるかどうかが確認されました。
本番環境のような環境にインストールした後、全体的な安定性をテストするためにそこで負荷テストとストレステストを実行しました（10個のBizTalkサーバー、8個のSQLサーバー、およびXMLアクセラレータのような他の特殊なハードウェアの束で実行する場合は、簡単なことではありません）専用アーカイブ-もちろんすべてがクラスター化されています）。
すべてのテストに満足したら、コードを本番環境に配置しました。コード内のバグを修正するまでにかなりのレイテンシが発生し（テストサイクル全体で4〜6週間など）、これらのすべてのテストを行うのはコストがかかりますが、全体的な安定性はかなり良好でした。実際、私が今まで見た中で最高です。繰り返しになりますが、これは毎日数百万ドル相当の処理を行うシステムでは非常に重要です。要件はさまざまですが、それが私たちのやり方であり、うまくいきました。
元の質問は、提供された非常に詳細な回答のほとんどよりも、概念的に一般的です。
より詳細なレベルから見てみましょう。ソフトウェアは、誰か（人、会社など）からの特定のニーズに対応するために開発されています。
これらのニーズは、最近（構築フェーズで）ソースコードに実装される個々のストーリー/要件にマッピングする必要があります。
ストーリー/要件を明確に定義することは、品質保証（QA）チーム（実際のソフトウェアテスター）が実行時に最終コードを検証し、それらのストーリーと要件の要求に対応するために不可欠です。したがって、その目的のために、QAチームはその検証を行うための「テストケース」を作成します。
QAチームにリリースされたコードはテストされ、バグが特定されます。さまざまなタイプと重大度のバグ。これらのバグは追跡され、開発者は最終的に修正するよう割り当てられます。
現在、仮想マシンを使用すると、1人のテスターが1つの実際のハードウェアで異なる環境を実行できます。しかし、QAフェーズ専用のコンピューターが必要になる場合もあります。
全体のプロセスを（大まかに）理解するのに役立つことを願っています。
まあ、私は皮肉を言うのは嫌いですが、特定の「デバイス」オペレーティングシステムの未解決のバグの数を考えると、会社が大きくて豊かであるほど、作成してエンドユーザーに配信できるバグが増えるようです。ソフトウェアが機能してクールに見える場合は、とにかくそれをリリースするだけです。マネージャーが準備ができていると考えれば、準備は整っています。その時、本当に厄介なバグが木工細工から出始め、エンドユーザーはモルモットになります。 10年ほど後、ほとんどのバグは解決され（そしていくつかは適切に追加されます）、会社は次の大きなアイデアに進む準備ができています。