コンパイラ、アセンブラ、機械命令などのコンピュータプログラミングの下位コンポーネントに欠陥がないことをどのように確認できますか？
日常生活の非常に重要なタスクを含め、コンピューティングにますます依存するようになっているので、これらの重要なコンポーネントがどのようにテストされるのかと思っていました。
より技術的には、コンパイラとアセンブラはどのようにテストされますか？ （これは 停止の問題 !!に関連すると思います）
あなたは確信が持てないかもしれませんが、彼らがそうでないことを発見するまで、彼らは彼らがそうであると仮定します。長年にわたり、コンパイラとハードウェアには多くのバグがありました。
これらがコンパイラなどのようにテストされる方法は、非常に狭く厳密に定義されており、慎重に記述されてから、enormousテストスイートでテストされて、正当性を検証します。それに加えて、コンパイラの幅広いユーザーベースを追加すると、より多くのバグが検出され、報告されます。歯科医の診察予約アプリは、比較的、ユーザー数が少なく、欠陥を検出できるユーザーの数も少なくなっています。
SQLiteは約73k行のコードで構成されていますが、テストスイートは約91378k行のコードで構成されており、SQLite自体の1250倍以上です。コンパイラと他のコアツールは同じような比率になると思います。今日のプロセッサは、基本的にソフトウェアで設計されており、VerilogやVHDLなどのハードウェア記述言語を使用しています。これらのプロセッサではソフトウェアテストも実行され、製造時にセルフテストを実行するための専用のIOピンも用意されています。
最終的には確率ゲームであり、テストを繰り返し広範囲にカバーすることで、他のソフトウェアプロジェクトと同じように、欠陥の確率を許容可能な低いレベルにまで下げることができます。
簡単に言えば：
- それはいけません。
- コンパイラーとインタープリターは、他の（プロフェッショナル）ソフトウェアと同様に単体テストされています。
- テストが成功しても、プログラムにバグがないというわけではなく、バグが検出されなかったことを意味するだけです。
- コンパイラを長期間使用している幅広いユーザーベースは、設計者が考えていなかったテストケースをユーザーが通常テストするため、バグが非常に少ないことを示しています。
- オープンソースであることも良い指標です。 "十分な眼球があれば、すべてのバグは浅い...十分な大規模なベータテスターと共同開発者のベースが与えられれば、ほとんどすべての問題はすぐに特徴付けられ、修正は誰かにとって明白になるでしょう。" 。クローズドソースコンパイラには、非常に特定の時間に発生するバグや、最適ではないマシンコードを生成するバグがあり、その背後にある企業は単にその存在を明らかにせず、製品のロードマップで非常に低い優先度を与える可能性があります。
ボトムライン：
OOP（[〜＃〜] o [〜＃〜]ld、[〜＃〜] o [〜＃〜]）ペンと[〜＃〜] p [〜＃〜]opular）。私はその頭字語を作りました。
カメはずっと下にいます。
何も確かではありません。あなたは信頼の評価に落ち着く以外に選択肢はありません。
スタックと考えることができます：数学>物理演算>ハードウェア>ファームウェア>オペレーティングシステム>アセンブラー/コンパイラーなど
各レベルでは、信頼度を向上させるために実行できるテストがあります。これらのテストのいくつかは正式な証明の品質を持っています、それらのいくつかは観察に基づいています、ほとんどは両方の組み合わせです。
私たちがプログラムを使用して証明と観測分析を行うため、これらのテストの一部では再帰を解明するのが難しい部分です。
結局のところ、答えはあなたが考えることができるすべてのものを試すことです。静的分析、ファジング、シミュレーション、意図的に選択された極端な入力またはランダムな入力での実行、すべての制御パスの実行/マッピング、正式な証明など。チップ/プログラム）が意図したとおりに機能しません。真の努力をしても失敗する場合は、製品の正確性に対する信頼度を向上させることができます。
テストはせいぜい半決定的なプロセスです。つまり、バグがあると最終的にそれを見つけることができますが、すべてを見つけたかどうかはわかりません。正式に検証されたソフトウェアであっても、物理学、正式な証明を行うために使用されるツール、およびプログラムが（しばしば主観的に）「意図する」ことを実行するために必要かつ十分であることを証明するために使用されるツールです。正式な証明がない、使用している他のすべてのコンポーネントについては言うまでもありません。
これは、コードの代わりにツールを非難し始めるという点で、新しい開発者にとって「危険な」質問です（そこにいると、それが終わって、あまりにも多くの人がそうしているのを見ました）。コンパイラ、ランタイム環境、OSなどにはバグがありますが、開発者は現実的であり、それ以外のことを示す証拠と単体テストがあるまでは、バグはコードにありますであることを覚えておいてください。
主にC、C++、およびJavaでの25年以上にわたるプログラミングで、私は次のことを発見しました。
- コンパイラのバグによる2つのバグ（gccおよびSunOS C）
- Java JVMの問題（通常はメモリ消費量/ガベージコレクションに関連））に起因するバグが毎年1〜2回程度
- 約1〜2か月に1回、ライブラリのバグ。これは、最新バージョンを使用するか、以前のバージョンのライブラリに戻すことで頻繁に修正されます。
他のすべてのバグはバグに直接関連しているか、または多くの場合、ライブラリの動作に関する理解の欠如です。バグと思われるのは、非互換性が原因である場合があります。たとえば、Javaクラス構造がどのように変更され、一部のAOPライブラリが壊れたかなど）。
ここで興味深い点は、商用ソフトウェア（および実際にはオープンソースソフトウェア）ライセンスの大部分が、ソフトウェアを信頼できないことを明確に指定していることだと思います。
本ソフトウェアIS提供された「現状有姿」、いかなる種類の保証もありませんOR市場性、特定の目的への適合性、および非侵害性の保証に限定されるものではありません。
Microsoft Wordライセンス契約から
。限定保証を除き、適用される法律で許可される最大限の範囲で、マイクロソフトおよびそのサプライヤーは、ソフトウェアおよびサポートサービス（存在する場合）をASISおよびすべての障害とともに提供し、これにより他のすべての保証および条件を否認します、明示的、黙示的、または法的であるかどうかにかかわらず、商品性、特定の目的への適合性、信頼性または可用性、応答の正確性または完全性、結果の暗黙的保証、義務または条件を含みますが、これらに限定されません。 、ソフトウェアに関するすべて、およびソフトウェアを介したサポートまたは他のサービス、情報、ソフトウェア、および関連コンテンツの提供または提供の失敗、またはその他の方法で生じる、手間のかかる努力、ウイルスの欠如、過失の欠如ソフトウェアの使用の。
基本的に、使用するほとんどすべてのソフトウェアのライセンスのこの文は、使用するコンパイラはもちろん、ソフトウェアを信頼できないことを示しています。
ソフトウェアは科学理論のようなものであり、それが機能しなくなるまで、仕様どおりに機能すると見なされます。
数学言語*のコンパイラー・ライターとして、私の経験から言えば、理論的にはそうは言えません。そして、いくつかのバグは、（私の恥リストから）_6/3*2_を正しい6/(3*2)から計算し、クラッシュしたり無意味なコンパイルエラーを発生させたりせずに1を出力するなど、誤った結果を与えるだけです。
しかし、私見の多くのコンパイラには、他のソフトウェアほど多くのバグはありません。
- 単体テストの作成は簡単です。各ステートメントはユニットであり、テストは次のように簡単に記述できます。
test_unit("2+(-2)*(-2+1)*3+1",9); - プログラムはステートメントの組み合わせであり、プログラムが正しい結果を出力するためには、個々のステートメントが（ほとんど）正しい結果を出さなければなりません。そのため、プログラムが正しい結果を出す間、バグが発生することはほとんどありません。
- 書かれたプログラムのサイズと数が増えると、バグを捕らえる可能性が劇的に高まります。
アセンブラ、機械命令などについては、上記も当てはまります。一方、チップの設計と製造における検証と検証は、巨大なビジネスであるため、より厳密なプロセスがあります 電子設計の自動化 。
生産に入る前に、各バグのコストはほぼ数百万ドルであるため、各CPUを厳密にテストする必要があります。チップの生産には、繰り返し発生しない莫大な生産コストがかかります。したがって、企業は生産に入る前に多くのお金をかけ、設計のために多くのシミュレーションコードを記述しますが、これは100％の保証を提供するものではありません。たとえば、Pentium FDIVバグです。
要するに、コンパイラ、マシンコードなどに重大なバグがある可能性は非常に低いです
控えめな数学言語 *
完璧？そうではありません。私は最近、いくつかの「更新」をインストールしましたが、さまざまな基本的なものがどのように機能または失敗するかについての原因不明の変更が原因で、ASP.NETサイトが再び適切に機能するまでに数か月（およびコードのいくつかの再プログラムされたセクション）がありました。
ただし、これらはテストされてから、多くの非常に賢い詳細指向の人々によって使用され、ほとんどのことに気づき、報告して修正する傾向があります。 Stack Exchangeは、これらのツールを使用するすべての人々が、少なくとも実用的な限りにおいて、これらの驚くほど複雑で低レベルのツールがどのように機能するかをテストおよび分析するのに役立つ優れた例（および改善）です。
しかし、完璧です。 Stack Exchangeのユーザーがパフォーマンスの詳細と標準への準拠と癖について印象的な洞察を得ているのを見ることもできますが、特に欠陥が何であるかについて異なる人々が異なる意見を持っている場合は、常に欠陥と欠陥があります。