ソフトウェアのバグ

ソフトウェア バグとは、コンピュータソフトウェアのバグのことです。

多くのバグや重大なバグがあるコンピュータ プログラムは、バグが多いと表現されることがあります。

ソフトウェアのバグの影響は、軽微なもの（ユーザー インターフェイスの単語のスペルミスなど）から重大なもの（頻繁なクラッシュなど）までさまざまです。

ソフトウェアのバグは災害と関連している。1980年代、放射線治療装置セラック25のソフトウェアのバグが患者の死亡の直接の原因となった。1996年、 欧州宇宙機関の10億ドルの試作型アリアン5ロケットは、搭載誘導コンピュータプログラムのバグが原因で、打ち上げから1分も経たないうちに破壊された。 ^[1] 1994年、イギリス空軍のチヌークヘリコプターが墜落し、29人が死亡した。当初はパイロットのミスとされたが、後にエンジン制御コンピュータのソフトウェアのバグが原因だと考えられた。^[2] バグのあるソフトウェアは、21世紀初頭の英国郵便局のスキャンダルを引き起こした。^[3]

2002年に米国商務省国立標準技術研究所が委託した調査では、「ソフトウェアのバグやエラーは非常に蔓延しており、非常に有害であるため、米国経済に年間推定590億ドル、国内総生産の約0.6%の損失をもたらしている」という結論が出されました。^[4]

1950 年代以降、一部のコンピュータ システムは、操作中にさまざまなソフトウェア エラーを検出したり、自動修正したりするように設計されてきました。

ミスメタモルフィズム（ギリシャ語の「メタ」は「変化」、モルフは「形」を意味する）は、ソフトウェア展開の最終段階における欠陥の進化を指す。ソフトウェア開発ライフサイクルの初期段階でアナリストが犯した「ミス」が、サイクルの最終段階で「欠陥」につながる変化は、「ミスメタモルフィズム」と呼ばれている。^[5]

開発サイクルにおけるミスのさまざまな段階は、ミス、^{[6 ] : 31} 異常、^{[6] : 10} 障害、^{[6] : 31} 失敗、^{[6] : 31} エラー、^{[6] : 31} 例外、^{[6] : 31} クラッシュ、^{[6] : 22} グリッチ、バグ、^{[6] : 14} 欠陥、インシデント、^{[6] : 39} または副作用として説明される場合があります。

ソフトウェアの動作を説明する際に「バグ」という言葉を使うことは、認識の違いから議論を呼ぶことがあります。この用語は廃止し、 「欠陥」や「エラー」に置き換えるべきだと主張する人もいます。

バグという言葉は欠陥が自ら発生したことを意味するため、人間によって引き起こされたことを暗示するより明確な意味合いを持つため、代わりに欠陥という言葉を使うことを主張する人もいます。 ^[7]

このバグは意図的な設計上の決定を隠すために使われているのではないかと主張している人もいる。2011年、ユーザーの位置情報を暗号化されていないファイルに記録して保存していることについて、米国上院議員アル・フランケンから調査を受けた後、 ^[8] Appleはこれをバグと呼んだ。しかし、民主主義技術センターのジャスティン・ブルックマンは、この描写に真っ向から異議を唱え、「バグと呼んでいるものを修正しているのはうれしいが、ユーザーを追跡していることを強く否定していることには異議を唱える」と述べた。^[9]

ソフトウェア開発プロセスのできるだけ早い段階でバグを防ぐことは、投資とイノベーションの目標です。^{[10] [11]}

新しいプログラミング言語は、既存の言語の脆弱性に基づいて一般的なバグを防ぐように設計される傾向があります。BASICやCなどの古い言語から学んだ教訓は、C#やRustなどの新しい言語の設計に役立てられています。

言語には、静的型システム、制限された名前空間、モジュールプログラミングなどの機能が含まれる場合があります。たとえば、型付けされたコンパイル言語（Cなど）の場合:

浮動小数点数値 = "3";

構文的には正しいですが、右側の文字列を float 変数に割り当てることができないため、型チェックに失敗します。コンパイルが失敗し、開発を再開する前にこの欠陥を修正する必要があります。インタープリタ型言語では、実行時に遅くまで失敗は発生しません。

一部の言語では、パフォーマンスの低下を犠牲にして、バグが発生しやすい機能を除外しています。これは、複雑でバグのあるコードよりも、単純で遅い正しいコードを記述する方がよいという原則に基づいています。たとえば、Java では、一般的に高速ですが危険であると考えられているポインタ演算はサポートされていません。比較的大きなバグが発生しやすいためです。

一部の言語には、バグを防ぐために実行時のオーバーヘッドを追加する機能が含まれています。たとえば、多くの言語には、実行時の境界チェックや、クラッシュする代わりに境界外の条件を処理する方法が含まれています。

コンパイル言語では、インタープリタ言語よりもソフトウェア開発プロセスの早い段階で、実行前にいくつかのタイプミス (スペルミスのある識別子など) を検出できます。

プログラミング スタイルや防御的プログラミングなどのプログラミング手法は、タイプミスを防ぐことを目的としています。

たとえば、バグはコード内の比較的軽微なタイプミス (typo) によって発生することがあります。たとえば、このコードはが true のfoo場合にのみ関数を実行しますcondition。

if (条件) foo();

しかし、このコードは常に実行されますfoo:

if (条件); foo();

この特定の問題を防ぐ傾向がある慣例は、たとえ 1 行しかない場合でもブロックに中括弧を要求することです。

if (条件) {
  関数 foo();
}

規則の施行は、手動（コードレビューなど）または自動ツールを介して行うことができます。

プログラムの動作を規定した プログラム仕様を記述することでバグを防ぐことができると主張する人もいます。

組み合わせ爆発や不確定性の問題があるため、形式仕様は最短のプログラム以外では実用的ではないと主張する人もいます。

ソフトウェアテストの目的の 1 つはバグを見つけることです。

テスト中の測定により、残っている可能性のあるバグの数を推定できます。製品のテストと開発が長くなるほど、この推定値の信頼性は高まります。^{[引用が必要]}

アジャイル ソフトウェア開発では、比較的小さな変更を伴うソフトウェアのリリースが頻繁に行われることがあります。欠陥はユーザーからのフィードバックによって明らかになります。

テスト駆動開発(TDD)では、製品コードの作成中にユニット テストが作成され、すべてのテストが正常に完了するまで製品コードは完了したとは見なされません。

静的コード解析ツールは、コンパイラの能力を超えてプログラム テキストを検査し、潜在的な問題を発見することで開発者を支援します。一般に、仕様が与えられた場合にすべてのプログラミング エラーを見つけるという問題は解決できませんが (停止問題を参照)、これらのツールは、人間のプログラマーがソフトウェアを作成するときに特定の種類の単純なミスを頻繁に犯す傾向があるという事実を利用します。

ソフトウェアの実行中にパフォーマンスを監視するツールは、ボトルネックなどの問題を見つけるため、または正しく動作していることを保証するために、コードに明示的に埋め込まれる場合（ というステートメントのように単純な場合もありますPRINT "I AM HERE"）、またはツールとして提供される場合があります。コードの一部がほとんどの時間を費やしている場所を見つけるのは驚くようなことが多く、この前提の削除により、コードが書き直される可能性があります。

オープンソース開発では、誰でもソースコードを検査できます。エリック・S・レイモンドがリーナスの法則として広めた考え方では、人気のあるオープンソースソフトウェアは、他のソフトウェアよりもバグがほとんどないかまったくない可能性が高いとされています。「十分な数の目があれば、すべてのバグは浅い」からです。^[12]しかし、この主張には異論があります。コンピューターセキュリティの専門家であるエリアス・レヴィは、「複雑で、ほとんど理解されておらず、文書化されていないソースコードでは、脆弱性を隠すのは簡単です」と書いています。「たとえ人々がコードをレビューしていたとしても、それがその資格があることを意味するわけではありません。」^[13]オープンソースソフトウェアのバグの例としては、2008年にDebianで発生したOpenSSLの脆弱性があります。

デバッグはソフトウェア開発ライフサイクルの重要な部分です。初期のコンピュータの先駆者であるモーリス・ウィルクスは、1940年代後半に「残りの人生の大部分は自分のプログラムのエラーを見つけることに費やされるだろう」と悟ったと述べています。^[14]

デバッガーと呼ばれるプログラムは、コードを行ごとに実行したり変数の値を表示したりするなど、プログラムの内部動作を調べることで、プログラマーが問題のあるコードを見つけるのに役立ちます。

デバッガーを使用する代わりに、コードにロジックを組み込んでデバッグ情報を出力すると、プログラムの実行をトレースして値を表示できます。出力は通常、コンソール、ウィンドウ、ログ ファイル、またはハードウェア出力 ( LEDなど) に行われます。

バグを見つけるのは一種の芸術だと主張する人もいます。

プログラムのあるセクションのバグが別のセクションの障害を引き起こし、^{[引用が必要]}システムの一見無関係な部分で追跡が困難になることは珍しくありません。たとえば、グラフィックスレンダリングルーチンのエラーにより、ファイルI/Oルーチンが失敗します。

デバッグで最も難しいのは、バグの原因を見つけることです。原因が見つかれば、問題を修正するのは簡単、あるいは簡単である場合があります。

バグは、単独の欠陥ではなく、プログラマー側の思考や計画の誤りを表す場合もあります。多くの場合、このような論理エラーにより、プログラムの一部を徹底的に修正したり書き直したりする必要があります。

コードレビューの一環として、コードをステップ実行し、実行プロセスを想像または書き写すと、バグを再現することなくエラーが見つかることが多いと主張する人もいます。

通常、バグを見つけるための最初のステップは、バグを確実に再現することです。問題を再現できない場合、プログラマーはバグの原因を見つけることができず、したがってバグを修正することができません。

一部のバグは、プログラマーが再現するのが難しい入力によって明らかになることがあります。Therac -25放射線機器の故障の原因の 1 つは、機器のオペレーターが治療計画を非常に素早く入力した場合にのみ発生するバグ (具体的には競合状態) でした。この操作をできるようになるまでに数日間の練習が必要だったため、テストやメーカーが再現を試みたときにはバグは現れませんでした。デバッガーでプログラムを実行するなど、バグを見つけやすくするためにセットアップを拡張すると、他のバグは発生しなくなる場合があります。これらはハイゼンバグ(ハイゼンベルクの不確定性原理にちなんでユーモラスに名付けられています) と呼ばれます。

1990年代以降、特にアリアン5便501便の事故以降、抽象解釈による静的コード解析など、デバッグの自動化支援への関心が高まりました。^[15]

多くの場合、バグはコーディング中に発生しますが、設計ドキュメントの不備がバグの原因となることもあります。場合によっては、コードがドキュメントと一致しなくなったとしても、コードを変更すると問題が解消されることがあります。

組み込みシステムでは、ハードウェアを変更するよりもソフトウェアを変更する方が安価であるため、ハードウェアのバグ を回避するためにソフトウェアが変更されることがよくあります。

バグは、文書化、分類、割り当て、再現、修正、修正されたコードのリリースなどのアクティビティを通じて管理されます。

ツールは、ソフトウェアのバグやその他の問題を追跡するためによく使用されます。通常、ソフトウェア開発チームが作業負荷を追跡するために使用されるツールと、カスタマーサービスがユーザーからのフィードバックを追跡するために使用されるツールは異なります。^[16]

追跡される項目は、多くの場合、バグ、欠陥、チケット、問題、機能、またはアジャイル ソフトウェア開発の場合はストーリーやエピックと呼ばれます。項目は、重大度、優先度、バージョン番号などの側面によって分類されることがよくあります。

トリアージと呼ばれることもあるプロセスでは、バグの重大度や優先度などの情報や開発スケジュールなどの外部要因に基づいて、バグごとに修正するかどうか、いつ修正するかが決定されます。トリアージには通常、原因の調査は含まれません。トリアージは定期的に行われる場合があります。トリアージは通常、前回のトリアージ以降の新しいバグと、場合によってはすべての未解決のバグのレビューで構成されます。参加者には、プロジェクトマネージャー、開発マネージャー、テストマネージャー、ビルドマネージャー、技術専門家などが含まれます。^{[17] [18]}

重大度は、バグが及ぼす影響の尺度です。^[19]この影響には、データ損失、財務、信用の失墜、無駄な労力などがあります。重大度レベルは標準化されておらず、業種や追跡ツールなどのコンテキストによって異なります。たとえば、ビデオゲームのクラッシュは、銀行のサーバーのクラッシュとは異なる影響を及ぼします。重大度レベルには、クラッシュまたはハング、回避策なし（ユーザーはタスクを達成できない）、回避策あり（ユーザーはタスクを達成できる）、視覚的な欠陥（スペルミスなど）、ドキュメントエラーなどがあります。重大度の別の例としては、重大、高、低、ブロック、些細などがあります。^[20]バグの重大度は、修正の優先度とは別のカテゴリである場合もあれば、2つを個別に定量化して管理する場合もあります。

製品のリリースを遅らせるほど重大なバグはショーストッパーと呼ばれます。^{[21] [22]}

優先度は、他のバグとの関係で、バグを解決することの重要性を表します。優先度は、1 から 5 などの数値、またはcritical、high、low、deferredなどの名前で表されます。優先度は異なる側面ですが、値は重大度評価と似ているか、同じである場合があります。

優先度は、バグの重大度と修正にかかる労力レベルの組み合わせで決まります。重大度は低いが修正が容易なバグは、修正にかなりの労力を要する中程度の重大度のバグよりも優先度が高くなる場合があります。

優先度が十分に高いバグについては、パッチと呼ばれる特別なリリースが必要になる場合があります。

バグ修正を重視したソフトウェア リリースは、新機能やその他の変更を重視したリリースと区別するために、 メンテナンスリリースと呼ばれることがあります。

既知の低優先度のバグやその他の問題を抱えたままソフトウェアをリリースすることはよくあることです。考えられる理由には次のようなものがありますが、これらに限定されるわけではありません。

• 期限を守らなければならないが、期限までにすべてのバグを修正するにはリソースが不足している^[23]

• このバグは今後のリリースですでに修正されており、優先度は高くありません。

• バグを修正するために必要な変更はコストがかかりすぎたり、他の多くのコンポーネントに影響を与えたりして、大規模なテスト活動が必要になる

• 一部のユーザーが既存のバグのある動作に依存していることが疑われる、または知られている可能性があります。提案された修正により、互換性を損なう変更が発生する可能性があります。

• 問題は、今後のリリースで廃止される領域にあるため、修正する必要はありません。

• 「それはバグではなく、機能です」^{[24]期待される動作と実際の動作、または}文書化されていない機能との間に誤解が存在​​する

ソフトウェアのバグが引き起こす損害の量と種類は、ソフトウェアの品質に関する意思決定、プロセス、ポリシーに影響を及ぼします。有人宇宙飛行、航空、原子力、医療、公共交通機関、自動車の安全性などのアプリケーションでは、ソフトウェアの欠陥が人身事故や死亡を引き起こす可能性があるため、このようなソフトウェアは、たとえばオンライン ショッピング サイトよりもはるかに厳しい監視と品質管理の対象となります。銀行業務などのアプリケーションでは、ソフトウェアの欠陥が銀行やその顧客に深刻な経済的損害を引き起こす可能性があるため、品質管理は、たとえば写真編集アプリケーションよりも重要です。

バグによって引き起こされる損害以外にも、バグのコストの一部はバグ修正に費やされた労力によるものです。1978年にLientzらは、プロジェクトの中央値は開発労力の17％をバグ修正に費やしていることを示しました。^{[25] 2020年の}GitHubリポジトリの調査では、中央値は20％であることが示されました。^[26]

1994年、NASAゴダード宇宙飛行センターは、平均エラー数を1000行コード（SLOC）あたり4.5個から1000行コードあたり1個に削減することに成功しました。^[27]

1990年の別の研究では、非常に優れたソフトウェア開発プロセスでは、展開失敗率が1000 SLOCあたり0.1まで低下すると報告されています。^{[28]この数字は、}スティーブ・マッコーネルのCode Complete ^[29]やNASAのFlight Software Complexity ^[30]の研究などの文献でも繰り返されています。 一部のプロジェクトでは、欠陥ゼロを達成しました。63,000 SLOCで構成されるIBM Wheelwriterタイプライターのファームウェアや、 500,000 SLOCのスペースシャトルソフトウェアなどです。^[28]

テストとデバッグに関する再現可能な研究を容易にするために、研究者はバグの厳選されたベンチマークを使用します。

• シーメンスのベンチマーク
• ManyBugs ^[31]は、9つのオープンソースプログラムにおける185個のCバグのベンチマークである。
• Defects4J ^[32]は、5つのオープンソースプロジェクトの341個のJavaバグのベンチマークです。これには、さまざまなパッチタイプをカバーする対応するパッチが含まれています。

注目すべきバグの種類:

バグは、仕様に基づいた不十分な設計または誤った設計によって発生する可能性があります。たとえば、仕様が単語のリストをアルファベット順に並べることである場合、設計で記号が考慮されていないと、記号を含む単語が誤ったアルファベット順に並べられ、設計上のバグが発生する可能性があります。

数値演算は、予期しない出力、処理の遅延、またはクラッシュを引き起こす可能性があります。^[33] このようなバグは、丸めによる精度の低下、数値的に不安定なアルゴリズム、算術オーバーフローとアンダーフローなどのデータストレージの品質に関する認識不足から発生する可能性があります。また、ゼロ除算など、いくつかの言語では例外がスローされ、他の言語ではNaNや無限大などの特殊な値を返すなど、さまざまなソフトウェアコーディング言語による計算の処理方法に対する認識不足から発生する可能性があります。

制御フローバグ(別名ロジック エラー) は、エラーで失敗しないものの、無限ループ、無限再帰、条件文での誤った比較 (誤った比較演算子の使用など) 、オフバイワン エラーなど、期待どおりの動作をしないコードによって特徴付けられます。

• API の使用法が正しくありません。
• プロトコルの実装が正しくありません。
• ハードウェアの取り扱いが不適切です。
• 特定のプラットフォームに関する誤った想定。
• 互換性のないシステム。2 つのシステムが異なるバージョンを使用している場合、新しいAPIまたは通信プロトコルが機能しているように見えることがありますが、一方のバージョンで実装されている機能または特徴が別のバージョンでは変更されていたり欠落していたり​​すると、エラーが発生する可能性があります。継続的に実行する必要がある実稼働システムでは、通信業界^[34]やインターネット[35] などのメジャー アップデートのためにシステム全体をシャットダウンすることができない場合があります。 ^{[36 ] [37]}この場合、大規模システムの小さなセグメントが個別にアップグレードされ、大規模ネットワークの中断を最小限に抑えます。ただし、一部のセクションが見落とされてアップグレードされず、互換性エラーが発生する可能性があり、そのエラーを見つけて修復するのが難しい場合があります。
• コード注釈が正しくありません。

• デッドロック- 1 つのタスクは 2 番目のタスクが終了するまで続行できませんが、同時に、1 番目のタスクが終了するまで 2 番目のタスクは続行できません。
• 競合状態- 複数の同時タスクがリソースを競合します。
• クリティカル セクション、相互排他、および並行処理のその他の機能におけるエラー。TOCTOU ( Time-of-Check-To-Time-of-Use ) は、保護されていないクリティカル セクションの一種です。

• ヌルポインタの逆参照。
• 初期化されていない変数を使用します。
• それ以外の点では有効な命令を間違ったデータ型で使用する(パック 10 進数/ 2 進化 10 進数を参照)。
• アクセス違反。
• リソース リーク。有限のシステム リソース (メモリやファイル ハンドルなど) が解放されずに繰り返し割り当てられることで使い果たされる状態です。
• バッファ オーバーフロー。プログラムが割り当てられたストレージの末尾を超えてデータを保存しようとする現象です。これにより、アクセス違反やストレージ違反が発生する場合と発生しない場合があります。これらは、多くの場合、セキュリティ バグです。
• 過度の再帰は、論理的には有効ですが、スタック オーバーフローを引き起こします。
• システムが参照するメモリを解放した後にポインタが使用される、解放後使用エラー。
• ダブルフリーエラー。

• 等価テストの代わりに代入を実行するなど、間違ったトークンの使用。たとえば、一部の言語では、x=5 は x の値を 5 に設定しますが、x==5 は x が現在 5 であるか、または他の数値であるかをチェックします。インタープリタ型言語では、このようなコードは失敗します。コンパイル型言語では、テストが始まる前にこのようなエラーをキャッチできます。

• 伝播されない更新。たとえば、プログラマーは「myAdd」を変更しましたが、同じアルゴリズムを使用する「mySubtract」を変更するのを忘れました。これらのエラーは、「Don't Repeat Yourself」哲学によって軽減されます。
• コメントが古くなっているか間違っている: 多くのプログラマーは、コメントがコードを正確に説明していると想定しています。
• ドキュメントと製品の違い。

ニューアメリカという団体が運営するオープンテクノロジー研究所^[38]は、2016年8月に報告書「システムのバグ」を発表し、米国の政策立案者は研究者がソフトウェアのバグを特定し、対処するのを支援するために改革を行うべきだと述べた。報告書は「ソフトウェアの脆弱性の発見と開示の分野における改革の必要性を強調している」。^[39]報告書の著者の1人は、議会はサイバーセキュリティというより大きな問題と戦うためにいくつかの法案を可決しているにもかかわらず、サイバーソフトウェアの脆弱性に対処するために十分な対策を講じていないと述べた。 [ ^39]

ソフトウェアの欠陥を発見するのは、通常、政府の研究者、企業、サイバーセキュリティの専門家です。報告書は、コンピュータ犯罪と著作権法の改革を求めています。^[39]

報告書によると、コンピュータ詐欺および濫用防止法、デジタルミレニアム著作権法、電子通信プライバシー法は、セキュリティ研究者が合法的なセキュリティ研究を行う際に日常的に行う行為を犯罪とし、民事罰を規定している。^[39]

• ビデオゲームでは、「グリッチ」という用語はソフトウェアのバグを指すために使用されることがあります。例としては、グリッチと非公式のポケモン種である MissingNo があります。
• 1968年の小説『2001年宇宙の旅』と、それに対応する1968年の映画『 2001年宇宙の旅』の両方で、宇宙船の搭載コンピュータHAL9000が乗組員全員を殺害しようとします。1982年の続編小説『2010年宇宙の旅2』と、それに伴う1984年の映画『2010年』では、この行動はコンピュータが2つの矛盾した目的、すなわちすべての情報を完全に開示することと、飛行の真の目的を乗組員に秘密にしておくこと、でプログラムされていたために引き起こされたことが明らかになります。この矛盾により、HALは妄想症になり、最終的には殺人鬼になりました。
• ネーナの1983年の曲「99 Luftballons (99 Red Balloons)」の英語版では、「ソフトウェアのバグ」の結果として、99個の赤い風船のグループの放出が敵の核ミサイル発射と誤解され、同等の発射対応が必要となり、大惨事につながるという。
• 1999 年のアメリカのコメディ映画「オフィス・スペース」では、3 人の社員が、会社の Y2K コンピュータ バグへのこだわりを利用しようとしますが、失敗します。その目的は、端数を切り捨てた 1 セント硬貨を銀行口座に送金するコンピュータ ウイルスを使用することです。これは、サラミ スライスと呼ばれる古くから知られている手法です。
• 2004年にエレン・ウルマンが書いた小説『The Bug』は、データベースアプリケーションにおける見つけにくいバグを見つけようとするプログラマーの試みを描いたものである。^[40]
• 2008 年のカナダ映画「Control Alt Delete」は、1999 年末に会社で 2000 年問題に関連するバグを修正しようと奮闘するコンピュータ プログラマーを描いた作品です。

• アンチパターン
• 自動バグ修正
• バグ報奨金プログラム
• グリッチ除去
• ハードウェアのバグ
• ISO/IEC 9126では、バグを欠陥または不適合のいずれかに分類しています。
• ソフトウェアのバグ一覧
• 直交欠陥分類
• レーストラックの問題
• リスクダイジェスト
• シングルイベントの番狂わせ
• ソフトウェア欠陥インジケーター
• ソフトウェアの回帰
• ソフトウェアの腐敗
• VUCA

• 「共通脆弱性一覧」 – NIST.gov のバグに特化した専門ウェブページ
• ジム・グレイのバグタイプ – 別のバグタイプ
• Wayback Machineの「最初のコンピュータ バグ」の写真(2015 年 1 月 12 日アーカイブ)
• 「最初のコンピュータバグ！」 – 1981 年にホッパー提督のバグについて書かれた電子メール
• 「GCC と LLVM のコンパイラのバグの理解に向けて」。2016 年のコンパイラのバグに関する研究