新人技術者のためのロジカル・シンキング入門（7） ―― 「ひたすら流すだけのテスト」にさよなら

【3】意外と難しい「単体テスト」，「結合テスト」の区別（2/2）

● 結合テストは一段階とは限らない

　結合テストに話を移しましょう．機能ブロックを単位とする単体テストの考え方から，結合テストは機能ブロックを組み合わせて動作させたときの確認ということになります．ここでは機能ブロック間のインターフェースが特に重要となります．図6の例でいうと，全体の入出力は（1）と（2）のデータだけですが，結合テストでは図の長円で囲った機能ブロック間のデータが正しくやりとりされているか，という確認も重要となります．機能ブロック間の連絡がうまくいっているかどうかを確認するのが結合テストのポイントだからです．

　また，初めて作り上げた機能の場合，その機能ブロックがすぐに動くとは限りません．そのような場合，いきなりA，B，Cの三つのブロックを結合させてテストするのではなく，まず，AとB，BとC，AとCの組み合わせでテストする項目を立てることも必要だと思います．これら一つ一つの組み合わせで問題がないことを確認してから，全体を結合させてテストするということです（図7）．

図7　結合テストの段階的実施
図6のようなブロック構成だと，結合テストは②～⑤のフェーズが考えられる．システムが安定しないうちは②～④を経て⑤を実施し，安定してきたら⑤のみに絞ってテスト・ケースを充実させていく，といった工夫が必要．

　もちろん，開発が進んで各機能ブロックが安定してくれば，このような部分の組み合わせの結合テストは重要性が低くなってくると思います．そのような場合，A，B，Cすべてを組み合わせたテスト・ケースに重点を移し，より派生的な機能や異常系の機能のテスト・ケースを充実させていくという進め方になるでしょう．

● テスト・ケースを「使い捨て」にしない

　以上，テスト・ケースを組み立てる際に注意すべき点について解説しました．テスト・ケースは，基本的にさまざまな入力パラメータや入力データについていろいろと場合分けすることで充実させていくことができます．また，テスト・ケースは基本的にはテストする前に用意するものです．

　しかし，テスト・ケースを見直すためには忘れてはならない重要な工程があります．それは，モジュールをリリースした後にバグが見つかったときです．十分にテストしたと思ったのにバグが見つかった場合に，テスト・ケースの見直しが必要になります．

　もちろんバグは「作る」工程におけるミスが直接の原因なので，設計またはコーディングの工程におけるミスのせい，ということになるでしょう．これは否定のしようがないことです．しかし，同時にバグは「検証する」工程のミスでもあります．ほとんどの場合，リリース後のバグはテスト・ケースの漏れが原因で発生してしまうのです．

　バグを発生させた後，「どのようなテストを実施すれば防げたか」を考えることは重要です．テスト・ケースを改善していくことは，開発対象となるモジュールだけでなく，後に行う同じような開発に対しても製品の品質向上に役立ちます．筆者の経験からいっても，重要なテスト・ケースが，「もともとは何らかのバグが発生してその予防策を考えたときに思いついたものだった」という例はいくつもあります．

　テスト・ケースは1回の開発で使い捨てにされるものではありません．組み込みシステムにおいては，開発対象のハードウェア・アーキテクチャが変わればモジュールそのものは開発し直すことになります．しかし，最初の開発で使ったテスト・ケースは，多くの場合，次の開発でも財産になるのです．ハードウェア・アーキテクチャの改版が必要となる組み込みシステム開発では，このことは見逃せません．テスト・ケースは使い捨てにするべきではないのです^注1．

注1；ソフトウェアのテストに関する古典的な文献にもこのような指摘が見られる．例えば，参考文献（1）のp.17に記されている．　「失敗から学ぶ」というのはあまりに使い古された言い方ですが，優れたテスト・ケースを考えるためには見落とすことのできない考え方です．

参考・引用＊文献
（1）Glenford J. Myers；ソフトウェア・テストの技法，近代科学社，1980年3月．

さえき・はじめ
＜筆者プロフィール＞
冴木 元．システム・エンジニア．昼休みに新聞を読むことが多いが，面白いと思うのは日本語で読める海外の新聞．最近領土問題で対立した某国の報道などは国内の新聞よりはるかに解説が詳しく専門的で，いろいろと考えさせられた．「相手の言い分を聞く」というのはいかなる紛争解決にも必要なようだ．