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

冴木 元

tag: 組み込み

技術解説 2008年10月 6日

【2】モジュール単体のテスト・ケースを考える(1/2)

 モジュール単体のテスト・ケースを考える場合,誰でも思い付きそうなことは,「モジュールに与えられたパラメータの組み合わせを考え,それらを一通りテストする」というものでしょう.表1のようなツリーを使った分類でも,パラメータの種類と個別のパラメータを分けてテスト・ケースを充実させていくのが普通のアプローチの仕方だと思います.実際,一般に普及しているソフトウェア工学ですと,このような考え方にたって「複合条件網羅」といったテスト・ケースの設計条件が整理されているようです.読者の中には情報処理試験の受験のためにそうした知識を覚えた方もいるでしょう.

 しかしこの考え方には,見落とされている点があると筆者は考えます.それは,そのモジュールに「ステート」があるかないかでテスト・ケースに対する考え方が変わってくるということです.

 ステートの有無というのは,要するにテスト対象のモジュールの中にスタティック・データが存在するかどうかです.スタティック・データとは,モジュール処理が終わっても次の処理まで値を保持するデータのことです.C言語であれば,外部変数を使うとか,mallocを使って実装するデータです(連載第2回).このようなステートが存在するモジュールの場合,単純に入力パラメータの組み合わせを網羅してもテスト・ケースに漏れが生じます.

● ステートがなく,自動化できれば全数テストがお勧め

 まず,ステートがないモジュールから考えることにしましょう.ここでは,このようなモジュールをハードウェア回路に倣って,「組み合わせ回路」と呼ぶことにします.

 図1のようなAND回路を例にとって考えてみましょう.AND回路とは,図1(b)の真理値表のような動作を行う回路のことです(ハードウェア技術者の方にとっては当たり前過ぎて今更解説の必要などないかもしれないが...).図1(b)を見ると,4通りの入力の組み合わせに対して,Yの期待値が与えられていることが分かります.入力信号の状態としては'0'または'1'しかないため,AとBの2種類で22=4通りの入力パターンが考えられるというわけです.

zu01_01.gif
図1 AND回路の例
組み合わせ回路の場合,入力パターンをすべて掛け算すると全数テストになる.組み合わせ回路はステートを持たないからである.

 このように,組み合わせ回路については,起こり得るすべての入力パターンを拾い上げれば全数テストになります.回路がステートを持たないため,入力に対して出力が一意に決まるということがその理由です.

 この考え方によると,どんなに複雑な回路(あるいはモジュール)であっても,それが組み合わせ回路である限り,入力パターンをすべて拾い上げれば全数テストになります.ハードウェアの観点からいうと「テストベンチ」,ソフトウェアの立場からいえば「テスト用メイン」を作って,テスト・ベクタ(テスト用の期待値データ)との比較でテストができるような場合,多少パターンが多くても全数テストを実施するのが確実といえそうです.例えば図2に示すように,入力信号がA~Eの五つで,それぞれ8個の入力パターンがある回路を考えると,85=32768通りのテスト・ケースがあることになります.

zu02_01.gif
図2 全数テストとその限界
全数テストを実施するのが確実だが,テスト・ケースが膨大になることもある.やみくもにテスト・ケースを増やせばよいというものでもないが,テストの実施を自動化して効率化を図れるのであれば頑張って全数テストを行うことも大事.

 テスト・ケースの数だけを考えると,「ちょっとやり過ぎ」といえなくもありません.しかし,テストベンチを組んでテストを自動化してしまえるのであれば,労をいとわずに全数テストを実施してしまう方が後々楽ともいえます.なぜなら,テストが一度自動化されてしまえば,再テストの実施は短時間で実施できるようになるからです.

● ソフトでは限界値テストで絞り込みが必要なケースも

 一方,ソフトウェアの場合,そうもいっていられないケースが起こり得ます.テスト用関数でテストを自動化できない場合です.例えば図2のような多数の入力パターンが存在するにもかかわらず,それらをすべて操作画面からユーザが手入力しないと出力が得られないようなシステム(あるいはモジュール)がそれにあたります.また,期待値と出力値のファイル比較で合否の判定ができない場合も自動化できません.例えば,目視しないと結果の合否を判定できないような場合などがこれにあたります.

 このような場合は表2に示すように,各入力信号に限界値(表の濃い灰色の部分)を振り分けることによって,テスト・ケースの絞り込みを図るべきでしょう.自動化でテストを効率化できない場合にやみくもに全数テストにこだわるのは,かえってテストの質を下げてしまいかねません.なぜなら人間は,自分の作ったモジュールをテストする場合は特に「正しく動いてほしい」という思い込みがあるため,ついついOKと判定してしまいがちだからです.そのため,やみくもに数にこだわったテストは,繰り返し行えば行うほどその質を下げてしまうことになります.

hyo02_01.gif
表2 限界値によるテスト・ケースの絞り込み
自動化が困難な場合などは限界値を適宜振り分け,テスト・ケースを絞り込むことも大事.パソコンのOSを介して手入力が必要なシステムなどの場合,自動化はそう簡単ではない.テスト・ケースの数のみに固執するとテストそのものがいいかげんになり,かえって品質低下を招くこともある.

組み込みキャッチアップ

お知らせ 一覧を見る

電子書籍の最新刊! FPGAマガジン No.12『ARMコアFPGA×Linux初体験』好評発売中

FPGAマガジン No.11『性能UP! アルゴリズム×手仕上げHDL』好評発売中! PDF版もあります

PICK UP用語

EV(電気自動車)

関連記事

EnOcean

関連記事

Android

関連記事

ニュース 一覧を見る
Tech Villageブログ

渡辺のぼるのロボコン・プロモータ日記

2年ぶりのブログ更新w

2016年10月 9日

Hamana Project

Hamana-8最終打ち上げ報告(その2)

2012年6月26日