信頼性について-2: MTTFによるテスト

クリーンルーム手法では品質保証を目的としたテストの指標としてMTTF(Mean Time To Failure)を利用する。そして、バグ密度のような指標は品質にとっては意味がないと言っている。クリーンルーム手法はホーア理論に基づいた形式手法の一種である。

また一方、ソースコード検証ツールであるPolySpaceのWebセミナーは

1. プログラム検証によって発見されたソースコードのバグを100%取る必要は無い。95%ぐらいでよい。
2. 機能テストとプログラム検証は違う。
3. プログラム検証をやっても機能テストは必要だ。5%の取り残しバグがあっても機能テストをパスすれば良い。

と言っている。

クリーンルームの方は、機能テストをすればプログラム検証は必要ないという言い方になっていて一見すると別のようだが、障害の有無が重要でありfaultの数は重要でないと言う点では一致している気がする。バグは欠陥(fault)に対応し障害(failure)と同じでないことはすでに述べた。テストの世界では、ホワイトボックステストとブラックボックステストという分類があるが、ホワイトボックスはfaultの検出、ブラックボックスはfailureの検出と対応づけることができるかも知れない。

クリーンルームでは、ユーザの使用特性を分析して、それに基づいて実際にシステムを動かしてMTTFを測定する。ある欠陥が発見されてから次の欠陥が発見されるまでの時間がMTTFになる。このMTTFがある値以上になれば出荷基準に達したと判断する。

クリーンルーム手法によってプログラムを作ればfaultは無いはずだからfailureの検出が重要だとも説明している。またfaultの無いプログラムを高品質と定義している。faultの無いプログラムであればMTTFの測定が出来る。それでどのようなテストをするかというと、品質を測定するためのテストであり、まず利用モデルと言うものを作る。利用モデルには以下のものが含まれる。

利用者: システム外部の実態、アクターやデバイスなど
利用の仕方: 動作モデル
環境: プラットフォーム、利用の状況(昼/夜、緊急時、オートモード)

動作モデルは、状態遷移図や決定表で表現される。利用モデルからテストケースを生成するには利用の仕方の統計的情報が必要になる。具体的には各遷移の遷移確率を入れた状態マシンを利用する。同値分割とかは利用しない。ソースコードの作り方はシステムの品質とは無関係と考える。具体的にどのようにテストケースを生成するのか、MTTFをどのように測定するのかについては色々な論文を読まなくてはならない様だ。

参考文献