コードカバレッジとは？

はじめに

ソフトウェアテストは、開発されたソフトウェアアプリケーションが要件を満たしているかどうかを確認するために実行される重要なフェーズの1つです。

そのフェーズがうまく行われるように、さまざまな確認メトリック/テストパラメータが生まれました。 そして、それらのメトリックの1つがコードカバレッジです。そこで今回はコードカバレッジついて解説します。

「コードカバレッジとは何か？」、「なぜ考慮する必要があるか？」 などの疑問が、すぐに解決しますよ。

1. コードカバレッジとは

コードカバレッジ（「網羅率」とも表現される）とは、テスト手順でソースのコードがどれだけ網羅的に正常に検証されているかを判断するソフトウェアテストメトリックであり、ソフトウェアがどの程度包括的に検証されているかを分析する助けとなります。 コードカバレッジは、ホワイトボックステストにおける形式の1つと見なされます。

コードカバレッジの価値とは、そのレポートの中にあります。

まず、レポートから全体的なパーセンテージが取得されます。 例えば、ソースコードが100行あるとしましょう。この場合、ツールで69％のコードカバレッジが出力されたら、コードの31行がテスト対象外になっているということです。これのおかげで、改善できる箇所がまだあるということが理解できます。

また、コードカバレッジは全体的なパーセンテージの算出だけに役立つものではありません。現在のコードカバレッジツールでは、モジュール、ファイル、クラスやメソッドごとの詳細ビューも表示されます。 これにより最初に低いコードカバレッジがある領域を特定できます

2. なぜコードカバレッジが必要なのか？

a) コードカバレッジの背後にある意味

テストを作成するたびに次のような質問を思いつきますよね。

テストスイート上にテストケースがもう十分に足りているか？

その答えはコードカバレッジです。

コードカバレッジ値が高いと、バグが潜在している可能性が低くなります。システムによって適当な最小パーセンテージを設定することも重要です。しかし、注意したいのはターゲットとして100％のコードカバレッジを追求することは望ましくないということです。その理由を次に説明します。

b) コードカバレッジに依存しないでそれを有利に活用するには

十分にテストされたコードベースは、通常は（常ではありませんが）適切に構造化されたコードベースと言えます。 しかし、仮にコードカバレッジが100%に到達したとしても「コードにバグがない」、または「コードがすでに完璧」という意味ではありません。

テストを通じて100％のコードカバレッジを期待することは現実的ではないばかりか、実際はその必要もありません。最後の5％から10％を追求するのは、時間、労力、およびお金の無駄と言っても差し支えないでしょう。

もちろん、100％のコードカバレッジが必要な例外ケースはあるかもしれませんが、通常ほとんどのアプリでは、80％から90％のコードカバレッジを達成できれば非常に良く、合格点と言えます。（当然ながらビジネスニーズやアプリの複雑さによって異なるケースも存在します）

c) 長所と短所

以下にコードカバレッジの長所と短所 をまとめました。

3. コードカバレッジの種類

a) どのように測定されるか？

コードカバレッジは以下のようにカバレッジの種類によって分けることができます。なお、「ステートメント」は機能、判定、ブランチ、またはオペランドに変わる可能性があります。

b) ステートメントカバレッジ/ブロックカバレッジ

この方法は、ソースコードの中ですべての実行可能なステートメントが少なくとも1回実行されたかどうかを判断する手段です。

単純に聞こえるかもしれませんが、ソースコードでは、入力値によって実行されない特定の条件が存在する可能性があります。だから、ソースコード内のそのようなすべての条件を網羅するために、様々な入力値セットを使用する必要があります。

c) 機能カバレッジ

この方法は、テスト中にソースコードに存在する関数がどの程度網羅されるかを測定する手段です。ソースコード内の関数は、少なくとも1回テストされます。あらためて関数が徹底的にテストされるように、適当な入力値で確認する必要があります。

d) 判定カバレッジ

この方法はソースコードで各ブーリアン式のTrueまたはFalseの結果を示す手段です。

条件付きブランチのみのカバレッジを測定します。

e) ブランチカバレッジ

各条件判定内のブランチがソースコードで少なくとも1回実行されるようにすることを目的としています。

条件付きブランチと無条件ブランチの両方のカバレッジを測定します。

★ブランチカバレッジと判定カバレッジの違い★

ブランチカバレッジは判定カバレッジと密接に関連しており、100％のカバレッジではまったく同じ結果が得られます。だたし、まだいくつかの異なる点があるため、以下の例を見てみましょう。

判定カバレッジの場合、条件「If(a> 3)」の結果のみ考慮します。この例では、1つのケースがTrueで1つのケースがFalseという結果が出力します。

ブランチカバレッジは判定カバレッジと同じケースがありますが、無条件のブランチ「Print (a)」も考慮しているため、パーセンテージが異なります。

f) 条件カバレッジ/表現カバレッジ

条件カバレッジの目標は、条件ステートメント内に各論理条件（logical condition）または各部分式（sub-expression）の結果（例えば：true、false）をチェックすることです。
条件カバレッジは、決定カバレッジよりもフロー制御に優れています。

★ブランチカバレッジと条件カバレッジの違い★

ブランチカバレッジは、コンディションカバレッジと混同されるかもしれませんが、この2つは異なります。
下記の簡単なコード例で説明しましょう。

・ブランチカバレッジの場合：

ブランチカバレッジの目的は、すべてのブランチを少なくとも1回実行することです。

上記の例では、全部の「If (a > 0) & (b > 0)」の条件結果を考慮します。テストケース1にThen部分が実行されてテストケース2にElse部分が実行されています。テストケース2,3と4はElse部分という同じ結果があるため、テストケース2を3または4に変更できます。

・条件カバレッジの場合：

条件式にAND, OR, XORなどのブール演算子（Boolean operators）が含まれると、条件カバレッジは全体的な可能性の結果を示さず、各条件の部分式の結果を示します。

上記の例では、（a> 0）と（b> 0）のそれぞれの結果を考慮します。 AND演算子を使用するので結果は4つのテストケース（True-True、True-False、False-True、False-False）になり、それぞれの出力結果から条件カバレッジの25％が得られます。

4. どのコードカバレッジ種類を選択すべきか？

これは確かにとても難しい質問です。システム、ビジネスにより違いますが、最適なコードカバレッジを選択する上で、いくつかの確認が必要な項目を以下に挙げます。

・テスト対象のコードに未発見の欠陥があること
・潜在的なペナルティのコスト
・失われた評判のコスト
・失われた販売のコスト
　　などなど

重要なポイントとしては、欠陥が生産障害を引き起こす可能性が高いほど、カバレッジのレベルの選択は厳しくなるということです。

個人的に、最も役立つものはブランチカバレッジと関数カバレッジです。

ステートメントカバレッジは実行されたステートメント数を確認するだけです。その一方、ブランチカバレッジはアプリのロジックも考慮に入れます。

仮にステートメントカバレッジの結果が良かったとしてもブランチカバレッジが低いと、1つのブランチで大きなコードブロックをテストしている際に他のブランチがミスをしまうということも起こります。一方、ブランチカバレッジの結果が高く、ステートメントカバレッジが低い場合、多くのステートメントを含んだブランチを確認するために、より多くのテストを追加することはがあまり現実的ではありません。

次に役立つ方法としては関数カバレッジを挙げたいと思います。その理由はアプリケーション内にテストされていない関数を速く判断できるためです。

5. まとめ

高品質なソフトウェア製品は、現在のような技術の進展がインターネットの世界で欠かせないものです。

高品質なソフトウェアを保証することは、QAエンジニアの責任であるだけでなく、開発者とQAエンジニア双方の責任とも言えます。 今回ご紹介したコードカバレッジをうまく活用することにより、QAチームはより高品質なソフトウェア製品を提供することが可能になります。

最後に、コードカバレッジツールはさまざまなものが出回っていますが、どのツールを使うべきかについてはそれほど悩む必要はありません。コードカバレッジツールのページを見て、お気に入りものを探しましょう。