2002 年、米国国立標準技術研究所 (NIST) は、不十分なソフトウェア テストによる経済的影響を詳述したレポート (NIST レポート、2002) を発表しました。このレポートでは、次のように結論づけられています。
「…ソフトウェアテストのための不十分なインフラストラクチャによる国家の年間コストは、222億ドルから595億ドルの範囲と推定されます。」
NIST の報告書では、ソフトウェア テストの実践状況がひどく不十分であることも指摘されています。
7 年後、Wong らは IEEE 信頼性協会のレポート (Wong ら、2009 年) で、広く報道された 15 件のソフトウェア障害 (そのうちのいくつかは人命の損失につながった) をレビューし、次のように結論付けました。
「…より優れたテスト手順と実践を実装する必要があり、これは安全性が極めて重要なシステムに関連するソフトウェアに特に当てはまります。」
最近の論文では、Wong らが複数の業界にわたるさまざまなソフトウェア障害を調査し (Wong ら、2017)、かなり厳しい指摘をしています。
「…残念なことに、ソフトウェアには欠陥がまったくないわけではなく、（欠陥のある）ソフトウェアの修正やメンテナンスに毎年多額の費用が費やされています。」
論文では、1985年から2015年までの30年間のソフトウェア障害を分析し、障害を引き起こしたソフトウェアのバグの性質と、ユーザーエラーなどの他の要因を特定し、障害を致命的なもの（人命の損失につながるもの）と、致命的ではないが相当の経済的損失につながるものの2つのカテゴリに分類しました。致命的な障害には、少なくとも6人の患者が放射線の過剰投与を受けた1985年のTherac-25事件や、650人以上が命を落とした1995年から1997年までの民間航空事故が含まれています。また、電子医療記録ソフトウェアの障害によりエボラ出血熱に感染した患者が誤診され、その後死亡した2014年のエボラ出血熱事件も含まれています。致命的ではない障害には、200万ドルの損失をもたらした原子力発電所のソフトウェア障害や、70億ドルの損失をもたらしたアリアン5のソフトウェア障害などがある。結論として、著者らは次のような見解を示している。
「… 公共インフラ、交通システム、消費者製品などにおける組み込みソフトウェアの普及を考えると、複雑なソフトウェア システムに携わったことがある人が、そのようなシステムを欠陥なく構築できると信じることができるとは信じがたい…」
残念ながら、私たちがますます依存するようになっているソフトウェア システムの種類に関するこれらの厳しい説明にもかかわらず、これらの議論には重要な点が欠けています。つまり、ほとんどのソフトウェア障害は検出されず、報告もされないということです。場合によっては、障害が微妙であったり、断続的であったりするため、簡単に見逃されてしまいます。たとえば、統計ソフトウェア アプリケーションは、誤って計算された統計を表示することがあります。このような誤って計算された統計は障害ですが、特に専門家でない人にはすぐにはわからない場合があります。それでも、このような障害は誤った、または最適ではない決定につながる可能性があり、したがって非常に重大な結果を招く可能性があります。
ソフトウェアを書くという技術は、使用される統合開発環境の洗練度、プログラミング手法の洗練度、プログラマーのスキルに関係なく、不完全な技術であり、バグが生じることは明らかです。この現実は、ソフトウェアがリリースされる前にこれらのバグを発見できるかどうかは、ソフトウェア テストの厳密さにかかっていることを意味します。NIST と Wong らが指摘しているように、そうしないと重大な結果を招く可能性があります。ソフトウェア エンジニアリング コミュニティの象徴的な人物である Barry Boehm は、ソフトウェア エンジニアリングの経済学に関する独創的な論文 (Boehm、1984) で、ソフトウェアの展開後にバグを見つけて修正するコストは、展開前にバグを特定して修正するコストの少なくとも 100 倍になることを指摘しました。
このような背景を考えると、ソフトウェア テスト方法は単に不十分であるということでしょうか。私はそうではないと主張します。実際、ソフトウェア テストの研究は 50 年以上にわたって活発に研究されてきました。2014 年に、Orso と Rothermel は、論文の前の 15 年間にソフトウェア テスト方法の開発が大幅に進歩したことについて書いています (Orso and Rothermel、2014)。2000 年までの 15 年間は、ソフトウェア テスト方法が劇的に発展した時期でもありました。ソフトウェア テスト コミュニティの象徴的な人物である Glenford Myers (Myers、1978) と Boris Beizer (Beizer、1984) は、70 年代と 80 年代に先駆的な研究を行いました。残念ながら、主な問題はテスト方法の適切性ではなく、採用の問題です。ソフトウェア開発コミュニティは、その有用性に関する実証的な証拠が存在するにもかかわらず、長年にわたって厳格なソフトウェアテスト方法の採用が遅れています (Kuhn et. al., 2015、Morgan, 2018)。この状況は、ソフトウェア開発の 2 つの現実によって悪化しています。ソフトウェアテストの取り組みは、資金とリソースが不足していることで有名です。さらに、ソフトウェア開発の取り組みの速度と複雑さは近年劇的に増加しています。
ソフトウェア システムは、これまで以上に普及し、私たちの生活においてますます重要な役割を果たしています。堅牢なソフトウェア テスト方法の重要性は明らかであり、ソフトウェア開発のあらゆる実践者がより認識する必要があるソフトウェア開発の側面です。このニーズに対応するために、私たちはこの一連のブログ投稿に着手しました。この投稿はそのシリーズの 2 番目であり、今後も投稿を続ける予定です。
引用文献
Beizer, Boris.ソフトウェア システムのテストと品質保証. Van Nostrand Reinhold Co., 1984 年.
Boehm, Barry W.「ソフトウェアエンジニアリングの経済学」 IEEEソフトウェアエンジニアリング論文集（1984年）：4-21。
Kuhn, DR, Bryce, R., Duan, F., Ghandehari, LS, Lei, Y., & Kacker, RN (2015). 「組み合わせテスト: 理論と実践」 Advances in Computers , 99 , 1-66.
マイヤーズ、グレンフォード J.「プログラムテストとコードウォークスルー/検査における制御された実験。」 Communications of the ACM 21.9 (1978): 760-768。
Morgan, J. (2018) 「組み合わせテスト: カバーリング配列に基づくシステムおよびソフトウェアテストへのアプローチ」システムおよびソフトウェアテストにおける分析手法、131-158。
NIST レポート。「ソフトウェア テストのインフラストラクチャが不十分であることによる経済的影響」米国国立標準技術研究所計画レポート 02-3。2002 年 5 月。
Orso, A.、Rothermel, G. (2014)「ソフトウェアテスト：研究紀行（2000～2014）」、 Proceedings on the Future of Software Engineering 、ACM、2014年5月、pp. 117～132
Wong、W. Eric、Vidroha Debroy、Andrew Restrepo。「最近の大惨事におけるソフトウェアの役割」 IEEE 信頼性協会 2009 年技術レポート59.3 (2009)。
Wong、W. Eric、Xuelin Li、および Philip A. Laplante。「敵をもっとよく知り、前進の道を切り開く: ソフトウェア障害におけるバグの役割のレビュー」 Journal of Systems and Software 133 (2017): 68-94。
ソフトウェアが何千もの異なる機能を提供する場合、それらすべてが連携して動作すること、および 2 つの機能が 3 番目の機能と調和することを保証するのは困難になります。
これは、Jmp と JSL の Tiny Trapsで確認できます。
場合によっては、2 つまたは 3 つの優れた機能を組み合わせると、予期しない結果が生じることがあります。
これらすべての小さな相互作用をテストするのは難しいですが、ユーザーの群知能にはチャンスがあります ; )
ユーザーからのフィードバックを整理し、伝達する努力をしてくださった JMP サポート チームに深く感謝いたします。
完璧に動作するソフトウェアを熱心に提供してくれた開発者に感謝します。
組み合わせテスト (投稿からの参照については下記を参照) は、相互作用による障害に焦点を当てたテスト手法です。基礎となる数学的オブジェクトはカバー配列であるため、入力が何千個あっても非常に効率的な手法です。これは今後のブログのトピックになります。
Kuhn, DR, Bryce, R., Duan, F., Ghandehari, LS, Lei, Y., & Kacker, RN (2015). 「組み合わせテスト: 理論と実践」 Advances in Computers , 99 , 1-66.
Morgan, J. (2018) 「組み合わせテスト: カバーリング配列に基づくシステムおよびソフトウェアテストへのアプローチ」システムおよびソフトウェアテストにおける分析手法、131-158。
素晴らしいブログ @JosephMorgan 、次回を楽しみにしています。
カバー配列を使用していて、実行できるテスト セットの数に制限がある場合、最初のテストの結果/分析 (強度 2 (一部の強度 3 をカバー)) により、最初のテストでいくつかの要素を削除して強度 4 以上をキャプチャできる 2 番目のカバー配列を計画できますか? カバー配列を使用した分析と連続テストのワークフローを可能にする開発中の方法はありますか?
ありがとう！
@Vins 、これを行うための開発中の方法があります。したがって、答えは「はい、はい」です。ほんの数週間前、MEMOCODE-2024 ( https://memocode2024.github.io/program.html ) で、同僚がこれに関する講演を行いました。アイデアは、ベイズ分析を使用して後続のテスト ケースの選択をガイドすることです (つまり、順次テスト ケース設計方法)。論文のタイトルは次のとおりです。
「MaLT: 機械学習による複雑なソフトウェア システムのテスト ケース設計と障害箇所の特定」
MEMOCODE-2024 カンファレンスの議事録はまもなく公開されますが、タイトルで Google Scholar 検索を実行すると論文が見つかる可能性があります。これについては、組み合わせテストのブログで少し触れる予定です。
ソフトウェア テストの重要性、テストを実行するための可能性の広大な領域については、 @JosephMorganと@hogiの意見に同意します。
実際、組織やユーザーごとに、ソフトウェアをテストするための独自の運用構造がある場合があります。
したがって、この修正は一夜にして行うことはできないため、新しい JMP バージョンで新しい技術的問題が見つかった場合は、古いソフトウェア バージョン (ユーザーがすでに使用していたもの) を再利用する代替手段を許可する必要があると思います。
