ホワイトボックステストは内部構造が正しく実装されているかを判定する開発者視点のテスト。
命令や条件を網羅することで意図しない動作をしないかどうかがテスト観点になる。
入出力の仕様を考慮しないため、値に依存するバグは見つけられない。
たとえば を としてしまっても論理構造に問題はないため、バグとして検出できない。
ブラックボックステストであれば を満たさないので検出できる。
また、網羅の基準が高くなるにつれてテストケースが膨大になりやすい。
命令網羅
すべての命令を少なくとも1回実行する。
たとえば if A and B then foo という分岐がある場合、以下のテストをする。
- A=true, B=true
foo という命令が実行されたのでOK。
if文の中に入らないフローの欠陥を検出できない可能性がある。
分岐が1つのとき、最少のテスト数は1。
同義語として以下がある。
- Statement Coverage (SC)
- C0
判定網羅
すべての分岐を少なくとも1回実行する。
たとえば if A and B then foo という分岐がある場合、以下のテストをする。
- A=true, B=true
- A=true, B=false
foo という命令が実行されたパターンとされなかったパターンがあるのでOK。
一部の条件に依存する欠陥を検出できない可能性がある。
上の例だと A=false の場合。
判定網羅が100%のとき、命令網羅も常に100%になる。
分岐が1つのとき、最少のテスト数は2。
同義語として以下がある。
- 判定条件網羅
- 分岐網羅
- Decision Coverage (DC)
- Branch Coverage (BC)
- C1
条件網羅
各条件の真偽について少なくとも1回ずつ実行する。
たとえば if A and B then foo という分岐がある場合、以下のテストをする。
- A=true, B=false
- A=false, B=true
AもBもそれぞれtrueとfalseのパターンが実行されたのでOK。
条件の組み合わせによってすべての命令が実行されない可能性がある。
上の例だと foo が実行されない。
したがって、条件網羅が100%であっても命令網羅や判定網羅が100%とは限らない。
最少のテスト数は2。
同義語として以下がある。
- Condition Coverage (CC)
- C2
条件判定網羅
判定網羅と条件網羅の両方を満たすように実行する。
たとえば if A and B then foo という分岐がある場合、以下のテストをする。
- A=true, B=true
- A=false, B=false
AもBもそれぞれtrueとfalseのパターンが実行された上に、foo という命令が実行されたパターンとされなかったパターンがあるのでOK。
一部の条件で分岐が決まってしまうことによる欠陥を検出できない可能性がある。
上の例だと A=false のときにBが評価されないので、Bがtrueのときの欠陥を検出できない。
具体的には、テスト対象の and と or を入れ替えてしまっても同じテスト結果になり、検出できない。
最少のテスト数は2。
同義語として以下がある。
- 判定条件/条件網羅
- Condition / Decision Coverage (DC/CC, CDC)
改良条件判定網羅
条件判定網羅を満たし、すべての条件が単独で分岐を左右するように実行する。
たとえば if A and B then foo という分岐がある場合、以下のテストをする。
- A=true, B=false
- A=false, B=true
- A=true, B=true
AもBもそれぞれtrueとfalseのパターンが実行された上に、foo という命令が実行されたパターンとされなかったパターンがあり、AまたはBが単独で結果を変えるパターンがすべて実行されているのでOK。
1つ目はBをtrueに変えると結果が変わるので、Bが単独で結果を変える。
2つ目はAをtrueに変えると結果が変わるので、Aが単独で結果を変える。
3つ目はAまたはBをfalseに変えると結果が変わるので、AもBも単独で結果を変える。
A=false, B=false のパターンは、どちらかをtrueに変えても結果が変わらないので不要。
条件がN個あるとき、最少のテスト数はN+1。
現実的なテスト数の中では最も厳しい基準。
航空機や自動車向けソフトウェアの標準や規格になっている。
同義語として以下がある。
- Modified Condition / Decision Coverage (MC/DC)
複合条件網羅
各条件の真偽についてすべての組み合わせを実行する。
たとえば if A and B then foo という分岐がある場合、以下のテストをする。
- A=true, B=true
- A=true, B=false
- A=false, B=true
- A=false, B=false
AとBの組み合わせとして全パターンがあるのでOK。
条件がN個あるとき、最少のテスト数は2^N。
テスト数が膨大になりやすいのであまり採用されない。
同義語として以下がある。
- 複数条件網羅
- Multiple Condition Coverage (MCC)
経路網羅
すべての経路を実行する。
たとえば分岐αとβがあるとき、αの複合条件網羅とβの複合条件網羅を組み合わせてテストする。
αの条件がN個、βの条件がM個あるとき、最少のテスト数は (2^N)*(2^M)。
複合条件網羅以上にテスト数が膨大になるのでほとんど採用されない。
同義語として以下がある。
- Path Coverage
カバレッジ目標
適切なカバレッジ目標はソフトウェアの性質や組織によって変わるので、普遍的に適用できる値を決めることはできない。ただ、Googleのブログ記事 を参考にできる。
- カバレッジが高くてもソフトウェアの品質が高いことを保証しない
- 逆に、カバレッジが高すぎると価値の低いテストを維持するためにコストを払っている可能性がある
- しかし、カバレッジが低いと品質も低い可能性が高い
- C1カバレッジで最低でも60%、理想的には90%
- 90%以上はカバレッジを上げても費用対効果が低い
- 頻繁に変更されるファイルを優先する