(cache) ライフサイクル：テスト：【真実32】テストしたパスは全網羅していない

2013-11-22

■[真実とウソ]ライフサイクル：テスト：【真実32】テストしたパスは全網羅していない

十分テストをしたとプログラマが自信を持つソフトウェアでも、全パスの55～60％程度しか網羅していない。

パス・カバレッジ・アナライザのような自動化ツールを使うと、網羅率が85～90％に上がる。

しかし、100％のパスを網羅するのは不可能だ。

テストには、様々なアプローチがあります。たとえば、以下の様なテストです。

仕様ベースのテスト
- 仕様通りにプログラムが動作するかのテスト
構造ベースのテスト
- ソフトウェアを構成するモジュールが、すべて正しく動くか確認するテスト
統計ベースのテスト
- 無作為に操作して、ソフトウェアがどれだけの期間、稼働するかをテストするもの
リスク・ベースのテスト
- 大きなリスクを正しく扱えるかのテスト

仕様ベースのテストは必須ですが、十分ではありません。「仕様爆発」があるからです。「爆発」分の設計仕様が、コーディングはされるのに、仕様として明確に定義していないため、テストされることがなくなってしまうからです。

よって、構造ベースのテストが必要になります。仕様に十分反映されない爆発部分をテストするには、ソフトウェアの全「構成要素」の実行を「試行」する必要があります。「試行」、としたのは、すべてをテストするのは不可能だからです。「構成要素」、としたのは、最も効果的な構造ベースのテストは、ロジックをもとにしたものですが、これ以外のアプローチとして、データ・フローをベースにしたものもあるからです。

統計ベースのテストは、製品を買いそうな客に、ソフトウェアは間もなく出荷できる品質であることをデモンストレーションするのに適しています。

リスク・ベースのテストは、すべてのリスクを叩き出して処理する必要のある高リスク・プロジェクトで、非常に重要なテストです。

一般に、仕様ベースのテストと構造ベースのテストを完全実施するだけでも、十分大変です。よって、統計ベースやリスク・ベースのテストは、非常に重大なプロジェクトか、信頼性を特別に確保しなければならない特殊なプロジェクトでしか使われません。

今回の主題は、「構造ベースのテスト」に関するものです。「構造ベースのテスト」は、「ロジック・セグメント」のテストを意味していて、これをの基本単位とします。

テストの対象には、ソースコードの全ステートメント・全パス・全モジュールやコンポーネントなどがあります。モジュールやコンポーネントのテストは、構造ベースのテストでは必須ですが、それだけでは不十分です。一つのモジュールやコンポーネントの中には、さらにテストを必要な個所があるためです。また、ステートメント・レベルのテストでも十分ではありません。

いろいろな研究によると、構造テストのパスの網羅性について、プログラマが「全ソースコードを完全にテストした」と言う場合、実際には、全パスの55～ 60%しか実行してないという結果になりました。これは、ソフトウェアが複雑であることの証明でもあります。ソフトウェアを作った本人も、プログラムの中身を完全に理解していないことを示すからです。

構造テストを実行した個所を表示するツールがあれば、網羅率を85%～ 90%まで上げられます。ただし、パスの網羅率を100%にすることは不可能です。ソースコードには、アクセスできないパスや、条件を満たすのが非常に面倒な例外処理など、きわめて難解な部分があるからです。網羅できなかったパスをカバーする方法としては、コード・インスペクションが推奨されています。

テストの方法は多数ありますが、ソフトウェアは非常に複雑なので、どんな方法を使っても、すべてのバグを見つける完全なテストはできません。