サンプリングと、残存バグ数予測と、TV視聴率：山浦恒央の“くみこみ”な話（52）（2/2 ページ）

プログラマーの永遠の課題「プログラム中の残存バグ数の推定」に迫るシリーズ。第5回では、「サンプリング」による残存バグ数予測について解説する。サンプルとなるテスト項目をどのように選ぶかが“鍵”だ！

[山浦恒央 東海大学 大学院 組込み技術研究科 准教授（工学博士），MONOist]

3．サンプリングの方法

　例えば、ソースコードの総数が100KLOC（10万ステップ）という中規模のプログラムがあり、テスト項目数を1万件作成したとします。この場合、サンプリングとして、テスト項目の母体から「どのように」「何件」選べばいいでしょうか？

（1）サンプリング件数

　TVの視聴率調査では、0.004％の標本数で計算しています。仮に、これを残存バグ予測に適用すると、テスト件数の0.004％は0.4件となり、たった1件のテスト項目を実行するだけで残存バグ数を計算できることになります。さすがにこれは非現実的です。
　通常、作成したテスト項目の5〜10％をピックアップし、サンプルとして使用している企業やプロジェクトが多いようです。5〜10％という数は、机上デバッグ用にサンプリングするテスト項目数と同じです。

（2）サンプリングの方法

　テスト項目の母体から、どのようにサンプルを選べばよいかは非常に悩ましいところです。理想は、1．時間をかけず（従って、安価で）、2．ランダム性があり、3．サンプルを別の目的にも使えることです。

（a）乱数によりサンプリング
　TVの視聴率調査では、サンプル数が少ない分、サンプルが偏らないように、例えば、乱数を発生させて標本を選びます。テスト項目でも、乱数を発生させたり、あるいは、10番目ごとにテスト項目を選んだりするなどの方法を適用できます。この「視聴率方式」は、時間がかからず、ランダム性も確保できるのですが、選んだサンプルを別の目的に再利用できないという欠点があります。

（b）机上テストのサンプルを再利用
　机上テスト用のテスト項目として、母体のテスト項目から5〜10％をピックアップするのが普通です。これをそのまま、残存バグ数予測のためのサンプルとするのも1つの方法です。時間がかからず、サンプルを机上テストに使える点が素晴らしいですね。
　ただし、サンプルは机上テストと兼用するので、机上テストを実施した後に、残存バグ予測のためにサンプルを実行すると、机上テストで摘出したバグは既に修正されているため、サンプリングでテストしても、理論的には（あるいは、正しく開発していれば）バグは“ゼロ”になるはずです。これでは、残存バグ数を推測する意味がありません。
　この問題は、机上テスト用に選んだテスト項目を使って、先に残存バグ数を予測し、その後で机上テストを実施するという、通常とは逆の開発プロセスを採用することで解決できます。ただし、机上テスト前の残存バグ数ですので、予測バグ数はかなり多くなります。

（c）回帰テストのサンプルセットを再利用
　ソフトウェア開発の終盤、特に「エンドゲーム」と呼ばれるフェーズでは、プログラムは“ほぼ完全に”動作します。この状態でバグを修正する場合、「ほぼ完成」状態を壊したくないため、キチンとした開発プロジェクトでは、必ず、絶対に、何が何でも、「回帰テスト（regression test）」を実施します。

　たとえ、たった1行の変更であったとしても、それがどこで、どんな影響を及ぼすか、正確に予測できません。修正箇所とは全く無関係な機能が動かなくなる……、なんてことだってあり得ます。この不可解・不思議な現象を例えるなら、キッチンの水道の水漏れを修理したら、なぜか2階のトイレの電灯が点かなくなった……という感じでしょうか。

　表示メッセージを2文字短くしただけなのに、全く無間関係の機能が動かなくなってしまったという場合、恐らく、メッセージが4バイト短くなったことで、ロードモジュールが1ブロック分小さくなり、メモリに別のモジュールがローディングされ、モジュール同士が干渉し合う……といった原因が考えらます（注2）。こんな不思議な現象（専門用語で、機能退行：functional degradation）を摘出するため、エンドゲームでは、変更が完了するたびに、必ず、全機能のサンプルを実行させる必要があります。このためのテストが回帰テストです。

　回帰テスト用のテスト項目として、通常のテスト項目の正常ケースから5〜10％を選ぶことが一般的です。また、わずか1文字の変更であっても、必ず回帰テストを実行するので、実行回数が非常に多くなります。そのため、自動実行できる環境を用意しておくことも基本です。

　サンプリングによる残存バグ予測では、回帰テスト用に選んだテスト項目を使うのも1つの方法です。回帰テストのテスト項目を使えば、テストが進むにつれて、残存バグ数がどのように減少するかが分かり、品質が良くなっていく過程をモニタリングできます。ただし、回帰テストのテスト項目は、ほとんどが正常ケースなので、予測バグ件数は少なめに出るという問題点があります。

注2：もちろん、一番多いのは、プログラム自身のバグですが、コンパイラのエラー、OSのバグ、ハードウェアの誤動作などの可能性もあり、不具合を解明するには長い時間がかかります。時間の足りない終盤では、とてもそんな余裕はありません。そのため、エンドゲームでは「余計なことはするな！」が超基本です。例えば、「counter01=1, counter01=1」という重複したソースコードがあり、カッコ悪いので軽い気持ちで片方を削除すると……、機能退行を引き起こす可能性もあります。そんな変更は、バージョン2の開発時に行いましょう。

4．おわりに

　サンプリングにより、残存バグ数を推定する場合、サンプルとなるテスト項目をどのように選ぶかが重要です。オススメは、「机上テスト用に選んだテスト項目」、あるいは、「回帰テスト用に選んだテスト項目」を再利用することです。これにより、残存バグ数の予測精度は少し下がりますが、時間をかけず、また、別の目的でも使えるため、早く、安くなり、効率も良くなります。

　今回で、残存バグ数の推定手法は完結です。これまで5回にわたり、キャプチャー・リキャプチャー・モデル（別名「池の中の魚」モデル）、Gompertz曲線、バグ率、サンプリングを基にしたバグ数予測を取り上げました。活用する際は、1つだけに固執せず、2つ以上の手法を組み合わせて、残存バグ数の信頼度を上げていただければと思います。

　残存バグ数が予測できると、プログラムの品質を推測でき、また、開発エンジニアに対して、具体的に「バグの摘出目標数」を設定できます。安く、早く、高精度で品質制御が可能になりますので、実際の開発にぜひ適用してみてください。（次回に続く）

【 筆者紹介 】

山浦 恒央（やまうら つねお）
東海大学 大学院 組込み技術研究科 准教授（工学博士）

1977年、日立ソフトウェアエンジニアリングに入社、2006年より、東海大学情報理工学部ソフトウェア開発工学科助教授、2007年より、同大学大学院組込み技術研究科助教授、現在に至る。

主な著書・訳書は、「Advances in Computers」 （Academic Press社、共著）、「ピープルウエア 第2版」「ソフトウェアテスト技法」「実践的プログラムテスト入門」「デスマーチ 第2版」「ソフトウエア開発プロフェッショナル」（以上、日経BP社、共訳）、「ソフトウエア開発 55の真実と10のウソ」「初めて学ぶソフトウエアメトリクス」（以上、日経BP社、翻訳）。