検索
連載

猫でも分かるソフトウェアのテスト網羅(7):C2カバレッジは「裸の王様」山浦恒央の“くみこみ”な話(90)(2/3 ページ)

「制御パステスト」をテーマとする「猫でも分かるソフトウェアのテスト網羅」シリーズの第7回(最終回)では、前回に引き続き、パス・カバレッジの王者である「C2カバレッジ」の弱点を解説します。

Share
Tweet
LINE
Hatena

2.2 仕様のバグが検出できない

 本項は、このコラムで、何回も述べていることで、もう説明不要でしょう。制御パステストは、実装した機能や命令語しか考慮しないため、実装抜けや仕様抜けの検出は非常に困難です(存在しない物の中身はチェックできません)。仕様書に記述してある機能がソースコードでも実装しているかをチェックするには、同値分割など、ブラックボックス・テストによる検証が必要です。

2.3 怪しいコードの検出ができない

 プログラムを見ると、無意味なコードや未使用の変数があったりします(*2)。例えば、無意味な加減乗算や、未使用の変数がある場合などがあると思います。参照文献[2]によると、このような怪しいコードの例として、「未初期化の変数の読み込み」「未使用の値」「到達不能なコード」を挙げています。

 「未初期化の変数」とは、変数宣言を実施したが、値を代入しないままとなっている変数です。「未使用の値」とは、算術演算などで値は代入しても、出力や代入しないまま、無意味なコードとなっている場合です。「デッドコード」とは、どんな入力を入れても実行できないパスです。

 デッドコードは、カバレッジ・ツールを用い、実行済みの命令語の色付けができれば検出はできるでしょうが、「未初期化の変数の読み込み」と「未使用の値」はC0カバレッジ(命令文の網羅)としてカウントして、見掛け上は網羅しますが、検出はあまり期待できません。

 このコードのタチが悪いのは保守担当エンジニアへ多大な迷惑を掛けることです。保守の場合、元のプログラムを理解して機能変更・追加を実施することになりますが、意味のあるコードかどうかの判定が非常に困難となり、つぎはぎだらけのコードとなります(*3)。「怪しいコード」は、コードレビュー、静的解析ツールやコンパイルオプションなどで早いうちに検出しておきましょう。

*2:猫でも分かるソフトウェアテスト網羅(5)において、未使用の変数などの怪しいコードを総称してデッドコードと記述しました。厳密な用語として、「デッドコード」とは「到達不能コード (unreachable code または dead code)」と呼び、到達出来ないコードをいいます。本記事では、誤解を与えないように、怪しいコードと変更しました。

*3:なぜ、デッドコードが生まれるか? 新規開発で、いきなりデッドコードが発生する例はあまりないようです。リリース当初は、キチンと構造化、階層化、モジュール化してあり、コメントもインデンテーションも真面目に施してどこへ出しても恥ずかしくないプログラムも、いろいろなエンジニアの手を経て保守フェーズに入ると、だんだん構成や秩序が崩れます。観光地にオープンしたできたてほやほやの高級旅館も、20年、30年も過ぎると、経年変化で老朽化し、建て増しに次ぐ建て増しで廊下が45度の鋭角で交わっていたり、ホールの真ん中に意味不明の柱があったりと、ボロボロになってきます。ソフトウェアの場合も同じで、「機能追加しなければならないけれど、このモジュールのどの部分をどう変更するかを理解・解析するのが面倒だなぁ」と考えるプログラマーは、そのモジュールを新規で作り直して機能追加し、元のモジュールに蓋をして「開かずの間ルーティン」にする荒業を使ったりします。元のモジュールを削除すればいいのですが、「もし、これでうまくいかなかったら、昔のモジュールを復活させよう」と思い、そのまま残す場合がほとんどです。かくして、プログラムの規模が膨れ上がり、実行できない命令語が増え、「パンドラの箱」的なソフトウェアになるのです。

2.4 割り込みやマルチタスクのバグ

 マルチタスクや割り込み関連のバグは、複雑な事象が重なるため、非常に検出が困難です。書籍などでもこのバグへの対処法は書いておらず、エンジニアの悩みの種です。その場合は、過去のバグを分析し、傾向と対策を立てざるを得ません(*4)。参照文献[3]では、そんなエンジニアへ向けたヒントを記述しています。

  • データがプロセス・スレッド間で共有しているかチェックし、データに関するアクセスパターンからテスト項目を作成する
  • 全てのプロセス・スレッドの生成と消滅をテストする
  • できるだけたくさんのプロセス・スレッドを立ち上げてテストする

 上記を考慮しながらテスト項目を作成してみると良いでしょう。

*4:この手のバグは非常に厄介なので、ベテランエンジニアに仕様やテスト項目を見せ、バグがありそうな箇所を洗い出してもらいましょう。

Copyright © ITmedia, Inc. All Rights Reserved.

ページトップに戻る