ブラックボックステスト・ホワイトボックステストのテスト技法

ソフトウェア開発のテスト工程では、誤りを見落とすことなく、かつ効率よく検証を実施するために、様々なテスト技法が用いられている。本記事では以前の記事(テストを効果的に実施するには)で紹介したホワイトボックステストとブラックボックステストについて、より詳しく掘り下げる。

ホワイトボックステスト

テスト対象の設計や実装の内容から全ての処理経路の動作を確認するテスト

主に単体テストで用いられる。ソースコードを対象とするため、プログラミング言語に関する詳細な知識が求められる。効率よく、かつ、網羅率の高いテストケースを作成するため、以下のようなテスト技法が存在する。

制御フローテスト(制御パステスト)

プログラム中の処理経路を網羅的に実行して、正しく動作しているかを検証するテスト
全経路に対して、どこまでテストするかを示す「網羅基準」によって、分類される。

図1 制御フローテスト

ステートメントカバレッジ
①→②→③→⑤→⑥→⑧

ブランチカバレッジ
①→②→③→⑤→⑥→⑧
①→②→④→⑤→⑦→⑧

コンディションカバレッジ
①→②→③→⑤→⑥→⑧
①→②→③→⑤→⑦→⑧
①→②→④→⑤→⑥→⑧
①→②→④→⑤→⑦→⑧

  1. ステートメントカバレッジ(命令網羅)
    テスト対象の全ての命令文のうち、テストによってどれだけ実行されたかを評価する。
    ステートメントカバレッジの達成基準は、与えられたテスト対象の全ての命令文を少なくとも1回テストすることと定義される。最もテスト強度が弱いカバレッジ基準である。開発現場ではC0カバレッジとも呼称される。
  2. ブランチカバレッジ(分岐網羅)
    テスト対象の全ての判定条件について、テストによってどれだけ実行されたかを評価する。ブランチカバレッジの達成基準は、与えられたテスト対象の入り口と出口、可能な全ての分岐を少なくとも1回テストすることと定義される。各判定条件については、複数の条件文がANDやORなどで組み合わされる場合、個々の条件文を結合した結果が「true」の場合と「false」の場合の両方が実行されれば網羅されたことになる。
    ステートメントカバレッジよりかなり厳しいカバレッジ基準であり、必要なテストケースも増える。開発現場ではC1カバレッジとも呼称される。
  3. コンディションカバレッジ(条件網羅)
    テスト対象の条件文について、全ての可能な結果のうちテストを実行されたかを評価する。
    テスト対象のテスト対象の全ての判定条件について、条件文の可能な全ての条件を少なくとも1回テストすることと定義される。上記2つに比べ、非常に強いカバレッジ基準であるが、テスト量が膨大になるため、実施は難しい。開発現場ではC2カバレッジとも呼称される。

本来は全てのフローを検証することが理想だが、小さなプログラムでも制御フローの数は膨大な数であり、限定的に実施されることがほとんどである。コストと時間を効率よく利用するために、①プログラム分割などでテスト対象はできるだけ小さくする、②テストケースの作成は条件網羅レベルをクリアする、ことが重要である。また、自動的に経路や条件を調査してテストデータを生成し、膨大な経路網羅テストを実施してくれるツールの利用も有効である。

データフローテスト

データや変数の使用の仕方に矛盾が無いかを調べるテスト

図2 データフローテスト

プログラム中で扱うデータや変数について、定義→使用→消滅の各ステップが、この順番通りに行われているかが調べられるようにテストケースを設計する。
これにより、未定義、未生成、未設定など状態のデータを処理する様な不具合を発見できる。 静的解析ツールの利用が効果的である。

ブラックボックステスト

テスト対象の内部構造を一切意識せずに、インプット・アウトプットが仕様通りの結果か確認するテスト

主に機能テストやシステムテストで用いられる。内部構造を確認することがないため、プログラミング言語の知識はあまり必要ではない。効率よく、かつ、網羅率の高いテストケースを作成するため、以下のような技法が存在する。

同値分割法

ソフトウェアの仕様から判断し同一の処理がされて同様の結果をもたらすことを期待できる入力セットや出力を想定し、テストケースを設計する技法

例として、「1~100」の数字が入力可能なシステムの場合を考える。このシステムでは、入力値は整数で与えられるものとし、0以下または101以上の場合は「無効な値」として処理されるものとする。この場合、入力値は以下の同値クラス(同じ出力結果が得られる入力値のグループ)に分類できる。

  • 無効同値クラス①:0以下の整数(有効範囲より小さく無効)
  • 有効同値クラス :1から100までの整数
  • 無効同値クラス②:101以上の整数(有効範囲より大きく無効)

図3 同値分割法

このように同値クラスを分割した後、各同値クラスから代表値を選択する。明確な決まりはないものの、同値クラスの中央から以下のように選ぶべきである。

  • 無効同値クラス①:-100
  • 有効同値クラス :50
  • 無効同値クラス②:150

この技法は、主に処理や出力結果に着目して入力を選択する。このとき、同じとみなせる入力領域(入力セット)や出力領域のことを同値クラスと呼称される。同じような意味を持つデータばかりに偏ったテストケースになることが避けられる。つまり、そのままでは膨大な量になるテストケースの一部を省くことで、効率よくテストが実施できる。また、意味のあるデータに関するテスト漏れを防ぐことも可能である。

境界値分析

同値分割法とセットで用いられ、入力同値クラスと出力同値クラスの端(境界値)や、その上下の隣接値に着目して効果的に欠陥を検出する技法

先ほどの同値分割の例を用いると、2ヶ所に境界値が存在する。

  • 無効同値クラス1と有効同値クラスの境界
    無効同値クラス1における境界値…0
    有効同値クラスにおける境界値…1
  • 無効同値クラス2と有効同値クラスの境界
    無効同値クラス1における境界値…101
    有効同値クラスにおける境界値…100

図4 境界値分析

同値クラスの境界付近には、範囲指定によるミスによってバグが集中するという経験則に基づいている。「以上、以下」、「~から~まで」、「最大、最小」といった表現は設計者と実装者間で齟齬が生まれやすく、認識の差がバグの発生につながる。

網羅方のブラックボックステスト技法

デシジョンテーブルテスト

テスト対象の仕様をデシジョンテーブルで整理し、作成された入出力の組み合わせパターンをテストケースとして考える技法

例として以下のような遊園地の料金システムを元に考える。

  • 子供、夜間は割引
  • 休日は夜間割引なし

割引の有無を判断する際に、デシジョンテーブルで表すと以下のように整理できる。

図5 料金システムのデシジョンテーブル

3つの分類にそれぞれ2種類の入力値があるため、単純に考えると2×2×2=8パターンできる。しかし子供の場合は無条件で割引されるため、このようにパターンを大幅に省略できる。このように不要なパターンを「-(どちらでもない)」を活用することで最終的に半分の4パターンにまで整理できるのである。
「決定表」と呼称されることもあり、入力・条件に対する出力・動作を決定するために用いられる整理方法である。

ユースケーステスト

テスト対象の仕様をユースケース記述で整理し、発生しうるフローをテストケースとして考える技法

図6 自動販売機のユースケース図

上記の図はアクターを設定し、アクターがどのような機能を求めているのかを簡易的に示したものである。これをもとにユーザが操作する手順を想定し、テストケースを作成する。入力項目に不備があった場合の対処で分岐するような手順を含めることで網羅率を向上させる。そのため事前に網羅基準を決定することが必要である。

状態遷移テスト

テスト対象の仕様を状態遷移モデルで整理し、発生しうる遷移列をテストケースとして考える技法

図7 自動ドアの状態遷移図

機能テストやシステムテストにおいて状態遷移図や状態遷移表を作成して、テスト対象が正しく設計仕様通りに動くか確認する。
状態遷移図では、入力後の状態の遷移を図で表すことで、機能の経路を把握しやすくする。操作によって「遷移できること」を明らかにする。また状態遷移表では、状態の組み合わせを全て表示することで、「できないこと」、「遷移しないこと」を可視化する。とくに「遷移しないこと」は、設計段階で可能な限り明確に定義しておいたほうが良い。テストの段階で、この部分に誤りが見つかった場合には、大幅な手戻りが発生してしまう恐れがある。

探索的テスト

直前のテスト結果に応じて、次のテストを探索的に実施するテスト技法

図8 記述的テストと探索的テスト

これまでは、事前に作成したテストケースに沿って行うテストを記述的テストと呼称される。一方で、探りを入れながら、次のテストを臨機応変に決めるテストを探索的テストと呼称する。テストケースをその場で作成するため、場当たり的な作業と思われがちだが、チャーターと呼ばれる文書でテストの方向性を指定することもある。
事前知識がなければ、テスト対象の挙動が「おかしい」、「不自然」だと気づけないため、製品知識と豊富な経験、洞察力が必要である。

まとめ

本記事ではテストを効率良く進めるために用いる基礎的な技法を紹介した。これらの技法を毎回必ず行うというわけではないが、どのような場面にも対応できるように引き出しを多くすることが大切である。普段のテスト手法を振り返って、より良くするにはどうすればよいか考えるきっかけとなれば幸いである。


テクバンの品質ソリューション事業部 特設サイトでは、「ソフトウェアテスト」や「テスト自動化」に関するサービスのご紹介をしております。

「プロダクトやサービスの品質がなかなか上がらない…」

「テスト自動化の導入/運用をしたいがどう進めたらよいか分からない…」

などのお悩みをお持ちの方は、以下のリンクからぜひお気軽にご相談ください。

また、「ソフトウェアテスト」や「テスト自動化」のお役立ち資料も掲載しておりますので、こちらも合わせてご利用ください!