エラーとコスト /ゼロ除算/ブルースクリーン /XP

ソフトウェアのバグやエラーをなくし品質を向上することは情報機器の多い現代では社会的にも重要な問題となっていますが、高度で複雑化が進むソフトウェアのエラーをなくすためのテストや開発にかかるコストが大きくなることも重要な問題です。

今回は、ソフトウェアのエラー、バグとコストの話題にしてみたいと思います。

ソフトウェア・エラーとプログラミング・エラー

ソフトウェアに関するエラーには、大きく分けて２種類があります。

１つは、ソフトウェアを実行する上でエラーとなって実行できなくなるタイプです。

身近なところでは、OSが検出してアプリケーションを停止するような「除算エラー」や「不正なメモリアクセス」などです。

　　▼e-Words IT用語辞典 : ゼロ除算【divide by zero】
　　　　http://e-words.jp/w/E382BCE383ADE999A4E7AE97.html

これらのエラーは、プログラムの不正な実行によって発生するCPUが正常範囲での継続処理が困難なためのエラーです。

実行コードや内容に問題が生じているものです。

もう１つのエラーは、プログラミング・エラーなどと呼ばれるバグです。

ソフトウェアはプログラムされた通り、正常に実行していますが、望む目的とは異なる結果や予想外の結果となるためエラーとみなすものです。

計算結果が間違っていたり、フリーズなどの挙動になるバグもこれに分類できます。

　　▼e-Words IT用語辞典 : 凍る【フリーズ】
　　　　http://e-words.jp/w/E5878DE3828B.html

「除算エラー」もバグに含められますが、プログラミング・エラーは、CPU実行自体には差し支えないエラーであることが異なります。

フリーズは、コンピュータを継続利用できなくなっていますが、人に対するリアクション部分の実行には問題が生じていますが、ある意味プログラム通りの正常動作中の現象と言えます。

フリーズに至るようなプログラムがされているという点が問題点です。

ソフトウェア・エラーもプログラミング・エラーもどちらもエラーですが、その性質や防ぐための技術的な内容はかなり異なります。

エラーと対策、テスト

ソフトウェア・エラーは、コードを実行する上での、プログラミング・エラーは、プログラム設計、実装上でのエラーという違いについて述べました。

この定義や呼称は、一般的なものかどうかは判りませんが２種類に大別できることは理解していただけると思います。

ソフトウェア・エラーの場合も、プログラミング・エラーの場合も、その対策は、やはり、大きく分けて２種類の手段で対策されているといえるかと思います。

１つは、コンパイラなどツールや言語で防御する方法で、開発言語の構文上、実行に支障のでる可能性があるコードを検出できる仕様にしてコンパイル・エラーやワーニング(警告)に落とし込むことができるようにするものです。

問題となる実行コードを生成できなくすることもこの範疇に含まれるかと思います（メモリやI/Oのアクセスコードの制限など)。

もう１つは、実際に実行させて、その動作を検証するデバッグです。

一般にテストとされるものは、例えば、XPプログラミングなどテスト手法が違っていたとしても、実行テストで問題を見つけて対処するという意味では、単体テストも結合テストも実行テストによる方法といえます。

　　▼e-Words IT用語辞典 : XP【エクストリームプログラミング】
　　　　http://e-words.jp/w/XP.html

　　▼e-Words IT用語辞典 : リファクタリング【refactoring】
http://e-words.jp/
w/E383AAE38395E382A1E382AFE382BFE383AAE383B3E382B0.html

実行によるテストは、テストツールが導入されたり、効率が工夫されて時間や実行の精度を向上させることは可能としても、エラーを検出することには必ずしも効果が高いとは限りません。

ソフトウェアの設計(プログラミング)やテスト仕様の設計に問題がある場合には、ツールやテスト方法を工夫しても問題の解決にはなりません。

テスト仕様の期待値を間違えると、当然、正常なテスト結果であるというレポートを生むに過ぎませんので、やはり、テスト内容自体が最も重要ということになります。

これは先に挙げたXPのテスト手法を導入したとしても事情は同じです。

プログラミング・エラーと同様、テストの設計が重要なポジションを占め、ソフトウェアの設計と同等のテストの設計能力が必要となるため、的確なテストを作成できるのが設計者自身である場合も往々にしてあります（そして、これが、XPのテスト手法が効果をあげる理由ですね）。

実行テストには、最低限の実行時間とその検証の時間を伴いますのでデバッグ作業の繰り返しとテスト時間はコストに与える影響が大となり、テストに最も設計能力の高い技術者を当てて対処することも決して珍しくはないこともご存知の通りです。

エラーとコストバランスと設計

上記までは、エラーや対策などについてでしたが、ここからは表題にしている対策とコストについてです。

エラーに対する対策やテストなどが技術的に困難な場合もありますが、最も難しい問題は、それに関わるコストの問題だと考えています。

例えば、大規模で複雑な状態、条件が発生するシステムの場合、組み合わせテストを最終段階で完全に網羅するテストは困難です。

網羅しているに等価とみなせるテストを行うか、個別の条件を確認することで正常動作を期待できるとみなすなどの方法が採られることが一般的かと思います。

実際に起こる組み合わせの条件を網羅していませんが原理的に、問題が生じない場合、妥当なテスト方法と言える場合もあると思いますが、完全なテストが行われていないことも事実でしょう。

複雑なソフトウェアでのテストにつては、単純にコストによる見切りが行われているに過ぎない場合も存在するだろうと思います。

コストバランスによる見切りというものも、必要なことであることは、そのコストがユーザーの対価にかかっていることを考えれば自明ですし、例えば、ワードプロセッサのテストを行うとして全てを網羅するいうことは不可能ですから（たとえ自動テストといえども無限の文字数の組み合わせを行うことは現実的ではないので文字数や組み合わせなどの）、何らかの必要条件を設けることになります。

ゲームなどのようにリアルタイム性を持つシステムの場合には、タイミングによってエラーの条件が発生する場合がありますから、さらに、テストの完全性を持たせることが困難な部類になります。

従って、どこまでが必要なテスト、コストとなるかを判断することが品質や製品コストなどの重要な問題となります。

コストは安いに越したことはありませんが、その見合いに品質が低下するようでは問題の解決にならないため、必要条件を満たしていると難しい判断が求められます。

このような膨大となり得るテストによってエラーを検出するを努力をするよりも、エラーが発生する可能性を減らす設計を重視する方が、ローコストでありながら品質を保つことができる可能性が高いことは容易に理解できます。

リアルタイムのシステムであれば、状態遷移が中間状態にならないようにしたり、データを多く扱うアプリケーションであれば、データに依存して処理が異なる部分をできる限り少なくすることで、エラーが起こりうる条件を抑える工夫が可能な場合があります。

これは、バグを出さないという単純な発想以上に、状況を作り出さないような設計段階でのアルゴリズムの設計、対策を採るということです。

エラーやバグを含む可能性を減らすことよりも、条件に対する堅牢性を高める設計、複雑度を低下する設計が、組み合わせ問題を緩和し、ローコストなテストやエラー対策での開発完了を可能とし、品質を低下させないポイントとなります。

エラーとコストバランスの問題は、このような局所的なロジックに落としたり、単純な条件となるように工夫することが最も効果的な手法の１つといえるでしょう。