目次 †
コードカバレッジ †
- テスト対象をどの程度網羅したテストなのかを示す指標のひとつ。
- 単体テストでは特にソースコードに対するカバレッジとして、コードカバレッジという指標を利用する。
- 制御パステスト（ホワイトボックステストでよく使用される）により、ソースコード内の要素をどれだけ実行（網羅）したかを示す値を指すこともある。
- テストケースを増やせばコードカバレッジは増えていくが、最も少ないテストケース数でコードカバレッジの値を高めることが重要である。
- コードカバレッジが100%であることが望ましいが、コードカバレッジの目的はテストの漏れがないことを確認するためであり、コードカバレッジの値を高めるためにテストが不要なケースに対してテストコードを書くのは本末転倒である。
コードカバレッジの種類 †
| コードカバレッジの名称 | C記法 |
| 命令網羅（ステートメントカバレッジ） | C0 |
| 分岐網羅（ブランチカバレッジ、判定条件網羅） | C1 |
| 条件網羅（コンディションカバレッジ） | C2 |
| 複合条件網羅（マルチコンディションカバレッジ） | C2 |
[補講]ステートメントカバレッジ、ディシジョンカバレッジという言葉でも押さえておくこと。 ◇
- 通常のプロジェクトでは命令網羅と分岐網羅が使用されることが多い。
命令網羅 †
- テストにより実行された命令文の割合。
- ソースコード内のすべての命令を1回以上実行すると、命令網羅は100%になる。
- 一般に単純なsetter/getterは単体テスト対象外とするが、その場合はsetter/getter内のコードがテスト時に実行されないので命令網羅が100%になることはない。
分岐網羅 †
- テストにより実行された分岐の割合。
- ソースコード内のすべての分岐に対して、真と偽となるパターンを1回以上実行すると分岐網羅100%になる。
- 分岐網羅が100%であれば、命令網羅は100%になる。その逆は成り立たない。よって、分岐網羅は命令網羅よりも網羅性が高いといえる。
条件網羅 †
- テストにより実行された条件の割合。
- ソースコード内のすべての条件に対して、真と偽となるパターンを1回以上実行すると条件網羅100%になる。
- 条件網羅は分岐網羅を前提していない。よって、分岐網羅は条件網羅より網羅性が高いとは言い切れない。
複合条件網羅 †
- テストにより実行された条件の組み合わせの割合。
- ソースコード内の各分岐におけるすべての条件に対して、真と偽のすべての組み合わせパターンを1回以上実行すると複合条件網羅100%になる。
コードカバレッジの計算 †
1
2
3
4
5
6
7
8
9
10
| -
|
-
|
!
-
|
!
|
!
| public int getValue(final int x, final int y) {
int z = 0; if (x >= 0 || y > 0) { z = x + y; }
if (y == 0) { z = -1; }
return z; }
|
命令網羅 †
| テストケース | x | y | 分岐1 | 分岐2 |
| テストケース1 | 1 | 0 | true | true |
(x,y)=(1,0)のときは、分岐1と分岐2の条件がtrueであるため、処理2,3も実行される。つまり、処理1〜4がすべて実行されるため、テストケース1は命令羅100%になる。
分岐網羅 †
| テストケース | x | y | 分岐1 | 分岐2 |
| テストケース1 | 1 | 0 | true | true |
| テストケース2 | 2 | -1 | false | false |
(x,y)=(2,-1)のときは、分岐1と分岐2の条件がfalseである。表を確認すると、分岐1に対してtrue,falseが両方とも現れている。また分岐2に対しても同様である。このように、すべての分岐においてtrue,falseが現れていれば分岐網羅は100%になる。
また、次のようなテストケース群でも分岐網羅が100%になる。
| テストケース | x | y | 分岐1 | 分岐2 |
| テストケース1 | 0 | -1 | true | false |
| テストケース2 | -1 | 0 | false | true |
どちらのテストケース群も命令1〜4をすべて通るため、命令網羅も100%になる。
条件網羅 †
| テストケース | x | y | 条件1 | 条件2 | 条件3 |
| テストケース1 | 1 | 0 | true | false | true |
| テストケース2 | -1 | 1 | false | true | false |
表を確認すると、各条件は必ずtrue,falseとなるテストケースが存在する。つまり、条件網羅は100%である。
[補講]分岐網羅が100%になるテストケース例として次を挙げた。
この場合は条件1,3はtrue,falseとなるテストケースが存在するが、条件2に関してはtrueとなるテストケースが存在しない。
| テストケース | x | y | 分岐1 | 分岐2 | 条件1 | 条件2 | 条件3 |
| テストケース1 | 0 | -1 | true | false | true | false | false |
| テストケース2 | -1 | 0 | false | true | false | false | true |
よって、条件網羅は66%(=2/3)となる（たまたま分岐網羅よりも低い値になっただけ）。
複合条件網羅 †
| テストケース | x | y | 分岐1 | 分岐2 | 条件1 | 条件2 | 条件3 |
| テストケース1 | 0 | -1 | true | false | true | false | false |
| テストケース2 | -1 | 1 | false | false | false | true | false |
| テストケース3 | -1 | 0 | false | true | false | false | true |
表を確認すると、各分岐・各条件は必ずtrue,falseとなるテストケースが存在する。つまり、複合条件網羅は100%になる。
コードカバレッジが低い原因 †
- テストケースが漏れている。
- 本来テストすべき箇所がテストされているかを判断するのがコードカバレッジを測る一番の目的である。
- 数値を見て判断した後に、テストされていないソースコードが発見されれば、その部分をテストするテストケースを追加する。
- テストでは実施できないソースコード
- UTでは発生させることが難しい例外、テスト実施時点では接続できない外部システムとの連携など、テスト実行不可能な箇所がある。
- このような箇所に関するテストケースはUTの対象外とし、以降のITやSTで実施するようにする。
- ただし、その部分がテストできないことは以降の工程への申し送り事項として報告書などに残す。
- 不要な処理
- 仕様になり処理がソースコードに含まれている場合である。この場合は不要な部分をソースコードから削除する。
- ソースコードをもとにテストを実施するホワイトボックステストの場合はこのようなことが起こらないが、仕様をもとにしたブラックボックステストを実施しているとこのようなケースがありえる。
コードカバレッジ測定用ツール †
Eclipseプラグイン †
- djUnit
- モックオブジェクトを利用したUTもサポートしている。
- djUnitでは命令網羅は「%line」、分岐網羅は「%branch」として表される。
- djUnitの分岐網羅は一般的な定義の分岐網羅とは異なるので注意。
- EclEmma
- GroboUtils
- Clover
参考文献 †
