コンパイラ、アセンブラ、マシン命令などのようなコンピュータプログラミングの下位コンポーネントに問題がないことをどのように確認できますか？

私たちは日々の生活の非常に重要なタスクを含め、コンピューティングにますます頼るようになっているので、私はそれらの重要なコンポーネントがどのようにテストされるのかと思っていました。

より技術的には、コンパイラとアセンブラはどのようにテストされますか？（これは停止の問題に関連すると思います!!）

確信は持てませんが、そうではないとわかるまでは、そうであると仮定するだけです。長年にわたり、コンパイラとハードウェアには多くのバグがありました。

コンパイラなどのこれらのテスト方法は、非常に狭く厳密に定義され、慎重に記述された後、膨大なテストスイートでテストされ、正確性が検証されます。さらに、コンパイラの幅広いユーザーベースを追加すると、より多くのバグが検出および報告されます。歯科医の予約スケジューリングアプリは、比較的少ないユーザーで、欠陥を検出できるユーザーはまだ少ないです。

SQLiteは約73k行のコードで構成されていますが、テストスイートは約91378k行のコードで構成されており、SQLite自体の1250倍以上のコードです。コンパイラーと他のコアツールには同じような比率があると思います。現在のプロセッサは、基本的にVerilogやVHDLなどのハードウェア記述言語を使用してソフトウェアで設計されており、ソフトウェアテストも実行されます。また、製造時点でセルフテストを実行するための専用IOピンもあります。

最終的には確率ゲームであり、テストを繰り返し幅広くカバーすることで、他のソフトウェアプロジェクトと同じように、欠陥の可能性を許容できる低いレベルまで下げることができます。

素人の言葉で：

1. できません。
2. コンパイラーおよびインタープリターは、他の（プロフェッショナル）ソフトウェアと同様に単体テストされます。
3. テストが成功したということは、プログラムにバグがないということではなく、バグが検出されなかったことを意味するだけです。
4. 長い間コンパイラを使用している幅広いユーザーベースは、ほとんどの場合バグがほとんどないことを示すかなりの指標です。ユーザーは通常、デザイナーが考えていないテストケースだからです。
5. オープンソースであることも良い指標です。「十分な目を与えられて、すべてのバグは浅いです。十分な大きさのベータテスターと共同開発者ベースを考えると、ほとんどすべての問題はすぐに特徴付けられ、修正は誰かに明白になります。」。クローズドソースコンパイラには、非常に特定の時間に発生するバグや、最適ではないマシンコードを生成するバグが存在する可能性があり、その背後にある会社は、単にその存在を開示せず、製品のロードマップで非常に低い優先度を与える可能性があります

結論：

OOP（O ld、Oペン、P opular）に行きましょう。その頭字語を作りました。

それはずっと亀です。

何も確かではありません。あなたは自信の評価に落ち着かなければなりません。

スタックと考えることができます：数学>物理学>ハードウェア>ファームウェア>オペレーティングシステム>アセンブラー/コンパイラーなど

各レベルには、自信評価を改善するために実行できるテストがあります。これらのテストの一部は形式的な証明の品質を持ち、一部は観察に基づいており、ほとんどは両方の組み合わせです。

これらのテストの一部で再帰を解くのは難しいことです。なぜなら、今ではプログラムを使用して証明や観察分析を行うためです。

最終的には、答えは考えられるすべてを試すことです。静的分析、ファジング、シミュレーション、意図的に選択された極端な入力またはランダム入力での実行、すべての制御パスの実行/マッピング、形式的な証明など。チップ/プログラム）は意図したとおりに動作しません。真剣に努力しても失敗する場合は、製品の正確性に対する信頼性を向上させることができます。

テストはせいぜい半決定的なプロセスであり、最終的にはバグが見つかることを考えますが、すべてを見つけたとは限りません。正式に検証されたソフトウェアを使用している場合でも、物理学、正式な証明を行うために使用されるツール、プログラムが（多くの場合主観的に）「意図した」ことを実行するために必要で十分であることを証明しています。それはあなたが使用している他のすべてのコンポーネントが正式な証拠を持っていないことは言うまでもありません。

これは、コードの代わりにツールを非難し始めるという点で、新しい開発者にとって「危険な」質問です（そこにいる、それをしている、あまりにも多くの人がそれをしているのを見た）。コンパイラー、ランタイム環境、OSなどにバグがありますが、開発者は現実的であり、証拠と単体テストがない限り、バグはコードにあることを覚えておく必要があります。

主にC、C ++、およびJavaでのプログラミングの25年以上で私は見つけました

• コンパイラのバグによる2つのバグ（gccおよびSunOS C）
• 約1年に1回または2回Java JVMの問題によるバグ（通常はメモリ消費/ガベージコレクションに関連）
• 約1か月に1回または2回、ライブラリのバグ。最新バージョンを使用するか、以前のバージョンのライブラリに戻すことで頻繁に修正されます。

他のすべてのバグはバグに直接関連しているか、より頻繁に、ライブラリがどのように機能するかの理解の欠如に関連しています。バグと思われるものは、非互換性が原因である場合があります。たとえば、Javaクラス構造がどのように変更されて一部のAOPライブラリが破損したかなどです。

ここで興味深い点は、大多数の商用ソフトウェア（および実際にはオープンソースソフトウェア）ライセンスが、ソフトウェアを信頼できないことを明確に指定していることです。

本ソフトウェアは、商品性、特定の目的への適合性、および非侵害の保証を含むが、これに限らず、明示または黙示を問わず、いかなる種類の保証もなしに「現状のまま」提供されます。

Microsoft Wordライセンス契約から

。限定保証および適用法で許可される最大限の範囲を除き、マイクロソフトおよびそのサプライヤーは、ソフトウェアおよびサポートサービス（存在する場合）を現状のままおよびすべての障害とともに提供し、明示的、黙示的、または商法、特定の目的への適合性、信頼性または可用性、応答の正確性または完全性、結果、職人的な努力の黙示の保証、義務または条件を含むがこれらに限定されない法定ソフトウェアに関するすべてのウイルスの欠如、および過失の欠如、およびソフトウェアを介したサポートまたはその他のサービス、情報、ソフトウェア、および関連コンテンツの提供または提供の失敗、またはソフトウェアの使用から生じる。

基本的に、使用するほとんどすべてのソフトウェアのライセンスに含まれるこの文は、使用するコンパイラはもちろんのこと、ソフトウェアを信頼できないことを具体的に示しています。

ソフトウェアは科学理論のようなものであり、機能しないまで仕様どおりに機能すると見なされます。

数学言語*のコンパイラライターとして、私の経験から、理論的にはできないと言えます。そして、いくつかのバグは、（私の恥ずべきリスト6/3*2から）右から計算し、6/(3*2)クラッシュしたり無意味なコンパイルエラーを出さずに1を出力したりするような間違った結果を与えます。

しかし、私見の多くのコンパイラには、他のソフトウェアほど多くのバグがありません。

• 単体テストの作成は簡単です。各ステートメントはユニットであり、次のような簡単なテストを作成できます。test_unit("2+(-2)*(-2+1)*3+1",9);
• プログラムはステートメントの組み合わせであり、プログラムが正しい結果を出力するためには、個々のステートメントが正しい結果を（ほとんど）提供する必要があります。そのため、プログラムが正しい結果を提供している間にバグが発生することはほとんどありません。
• 書かれたプログラムのサイズと数が増加するにつれて、バグをキャッチする可能性が劇的に増加します。

アセンブラー、機械命令などについては、上記も当てはまります。一方、チップの設計と製造における検証と検証は、巨大なビジネスであるため、はるかに厳格なプロセスです：電子設計自動化。

各バグは数百万ドル近くかかるため、生産に移る前に各CPUを厳密にテストする必要があります。チップの生産には莫大な非経常的な生産コストがあります。そのため、企業は、Pentium FDIVバグなど、100％の保証を提供するものではありませんが、生産に移る前に設計に多くのお金を費やし、多くのシミュレーションコードを記述します。

要するに、コンパイラ、マシンコードなどに深刻なバグがあることはほとんどありません。

私の謙虚な数学言語 *

完璧ですか？そうではありません。最近、いくつかの「更新」をインストールしましたが、ASP.NETサイトが再び正常に機能するまでに数か月（およびコードのいくつかの再プログラムされたセクション）がありました。

ただし、それらはテストされてから、ほとんどのことに気付き、報告し、修正する傾向のある多くの非常に賢いディテール指向の人々によって使用されます。Stack Exchangeは、これらのツールを使用するすべての人が、少なくとも実際の使用に関しては、これらの驚くほど複雑で低レベルのツールがどのように機能するかをテストおよび分析するのに役立つ素晴らしい例（および改善）です。

しかし、完璧です。Stack Exchangeのユーザーがパフォーマンスの詳細や標準への準拠と奇抜さに関する印象的な洞察を得ているのを見ることができますが、特にさまざまな人々が欠陥とは異なる意見を持っている場合、常に欠陥と欠陥があります。

基礎となるシステムに問題がないことを示すために、

a）完璧であることを証明する必要がある

1. 数学的証明
2. 些細なプログラムでのみ現実的に可能

b）完全なテストを行う

1. 些細なプログラムといくつかの単純なプログラムでのみ可能
2. タイミング要素がテストに入ると、時間を無期限に分割できるため、網羅的なテストを実行することはできません。
3. 些細なプログラムを超えて、可能な実行オプションは指数関数的に爆発します。

ソフトウェアテストでは、徹底的なテストはいくつかの単純な機能の単体テストでのみ使用されます。

例：いくつかのフィールドへの8文字のutf-8入力をテストする場合、バイトでutf-8の最大長6の8倍で入力をカットすることを選択します。これにより、8 * 6 = 48バイトが実際に有限の可能性。

これで、8文字のそれぞれの1,112,064個の有効なコードポイントのみをテストする必要があると考えることができます。1,112,064 ^ 8（たとえば10 ^ 48）テスト（既に可能性は低い）ですが、実際には各48バイトの各値、またはチェスと同じ複雑さである10 ^ 120前後の256 ^ 48をテストする必要がありますおよそ10 ^ 80の宇宙の原子の総数と比較して。

代わりに、努力の昇順で使用することができ、各テストは以前のすべてをカバーする必要があります：

a）良いサンプルと悪いサンプルをテストします。

b）コードカバレッジ。コードのすべての行をテストしてみてください。ほとんどのコードでは比較的簡単です。これで、テストできないコードの最後の1％が...バグ、デッドコード、ハードウェア例外などにあるのではないかと思います。

c）パスカバレッジ、すべての組み合わせのすべてのブランチのすべての結果がテストされます。関数に10を超える条件が含まれている場合に、テスト部門があなたを嫌う理由がわかりました。また、最後の1％をテストできない理由も疑問に思います。一部のブランチは以前のブランチに依存しています。

d）データテスト、境界値、一般的な問題のある値およびマジックナンバー、ゼロ、-1、1、最小+/- 1、最大+/- 1、42、rnd値で多数のサンプルをテストします。これでパスカバレッジが得られない場合は、分析ですべての値を把握していないことがわかります。

すでにこれを行っている場合は、ISTQB基礎試験の準備ができているはずです。