カバレッジ（網羅率）

カバレッジとは

特定のテスト対象で行うべきテストをどれくらい網羅してるのか？という指標

すべきテストが100あったとして、その中で30ほどしかテストできてないなら、カバレッジは30%となる

テスト対象としてよくあるのが「ソースコード」

ソースコードにおけるカバレッジの測り方は大きく4つある

1. 命令網羅（= C0）

「ソースコードにある命令文がそれぞれ少なくとも1回はどこかのテストで実行されるようにしよう」ていう測り方

全命令文を全体のテストで網羅できてるならカバレッジは100%

2. 分岐網羅（= C1）

「ソースコードにある判定条件における真偽がどちらも1回は実行されるようにしよう」て言う測り方

3. 条件網羅（= C2）

「それぞれの条件文における真偽が少なくとも1回は実行される」測り方

4. 複合条件網羅（= MCC）

「それぞれの条件における真偽の組み合わせがすべて実行される」測り方

カバレッジ利用の目的

テストケースの網羅率を把握できるようにする

極端にカバレッジが低ければ、バグ混入の可能性が高くなってることを意味する

テストケースの網羅率が低さを可視化するのが目的

カバレッジの注意点

「カバレッジを上げること」と「テスト工数の低下」は反比例する。つまり、トレードオフの関係にある。

なので、カバレッジ100%は目指さなくていい。

常に80-85%以上であればOKくらいに思っておくのが良い

ソースコードを対象にしたカバレッジなんかは、100%でも漏れてるテストケースが存在する

カバレッジの探し方だけでは見つけ出せないテストケースが存在するので、そのテストケースはカバレッジに関係なく見つけ出す必要あり

以下参考

code: sample.py

def hoge(a, b):

return a / b

このコードは適当なテストケースを1つ加えただけで、カバレッジ100%になる。

そのテストケースも追加してあげないといけないのに、カバレッジの指標を見てるだけでは、ここに気づけない

カバレッジ利用のポイント

参考

切り取り線.icon

「カバレッジが低ければ、ソースコードの品質が低い」と言えるが、「カバレッジが高ければ、ソースコードの品質が高い」とは言えない

あとは、C0で網羅できてると言っても、予測されたバグに対して追加のテストケースが必要になったりする

ここら辺は、ちゃんと見つけ出しておかないといけない。

例え、カバレッジが100%だとしても、その中に自動でテストケース洗い出しができてるわけではないから

ソフトウェアテストの進捗を表す尺度の一つで、テスト対象のソースコードのうち、どの程度の割合のコードがテストされたかを表すもの。

プログラムを構成するコード全体のうち、テスト済みのコードの割合を表す

このコードの処理を通るパターンまだテストしてないよね？的な

コードの何を数えるのかによっていくつかの測定手法に分かれる。

ソースコードを構成する個々の命令や文（statement）に着目し、なるべく多くの文をテストする考え方を「文網羅」「命令網羅」（statement coverage）という。

制御構文による分岐に着目し、なるべく多くの分岐をテストする考え方を「分岐網羅」（branch coverage）あるいは「判定条件網羅」（decision coverage）という。

なるほど？どゆことですかねこれはwwww

具体的に違いをイメージできひんな

コード中に含まれる条件判定に着目し、なるべく多くの条件について真（true）の場合と偽（false）の場合をテストする考え方を「条件網羅」（condition coverage）という。

複合的な条件式がある場合に、条件の真偽の組み合わせをなるべく多くテストする考え方を「複合条件網羅」（multiple condition coverage）という。

でも、全部で種類が4つあるのね、カバレッジの計算方法としては

それはわかった

https://scrapbox.io/files/634aa80cc817e900224dbe30.png

何が違うんやろ...

大枠としては...

処理文を網羅できてるか

条件を網羅できてるか

処理文・条件ともに網羅できてるか

言葉ではまあ、なんとなくわかるけど、やっぱ具体わからんな

C0, C1, C2になるごとにカバレッジレベルが上がっていく

C2ではC1で対応できない箇所も網羅してる

C1が100%だとしても、C2では100%じゃないってことを意味する

まあ、そこまでやるとテスト量が増えて大変そうな気もするが

「特定のカバレッジアイテム」の何％をテストしたのか、の意です。

カバレッジアイテム１～１００があったとして、そのうち３０の実行が済んでいたら「テストカバレッジ３０％」ということになります。

こいつの全体量に対して、どれだけテストしたかってのなんやな、カバレッジてのは。

カバレッジアイテム（coverage item）

テスト技法を使用して、一つ以上のテスト条件から導出される属性または属性の組み合わせ。テスト実行の完全性を測定するために使用する。

テスト技法から編み出された測定値的なやつかな

世の中では「カバレッジ」あるいは「テストカバレッジ」といったときに、暗黙にソースコードカバレッジを指すことがあるようです。 カバレッジアイテムをソースコードの網羅率（これも複数の基準がある）として、そのうちどのくらいの割合をテストできているの？を表す指標です。

テストカバレッジ＝ソースコードカバレッジ、という前提で読んでしまうと、E2Eのテストを自動化してテストカバレッジが向上しました！と言われても「ん？」となるわけですね。

カバレッジアイテムってそう言うことか。

何の網羅率を見るのかにおける「何の」の部分か、なるほど。

ソースコードをカバレッジアイテムと設定してる

となると、ユースケースをもとにテストする統合テスト？的なのは、ユースケースがカバレッジアイテムになるのか？

テストケースのカバレッジを計測することにより、テストの抜け・漏れを把握することができ、テスト対象の潜在的な不具合の発見にもつながります。

ここが1つのカバレッジを測る意味・意義よな

カバレッジが30%とかやと、明らかにテストが足りてないってのが一目でわかる

これでテスト品質を、よりbetterな状態にできるって感じやな

C0：

テスト対象となるソースコードのうち、実行可能なステートメント（命令）がテストで実行されたかをカバレッジ基準として評価します。

やっぱ。本番コードに存在する処理文のうち、どれだけテストで処理実行されたか的な感じやんな

C2：

テスト対象となるソースコードのうち、分岐の真/偽が各1回は出現するよう実行された割合です。

しかし、プログラム中の分岐が論理和（OR）/論理積（AND）を含む複合条件の場合、各条件式の組み合わせは考慮されないため、ブランチカバレッジでは判定式内にある不具合を検出できないケースがあります。

結局、trueかfalseには収まるんやからさ

答え見えてるやん

C2：

テスト対象となるプログラム中のブランチが複合条件の場合、各条件の組み合わせをどれくらい実施したのかを表す割合のことです。

ふ〜〜〜ん