コードカバレッジを賢く利用してテストを最大限に効率化

(この記事は、開発元Parasoft社 Blog 「Intelligently Use Code Coverage to Maximize Testing Effort」2018年3月30日の翻訳記事です。)

重要なアジャイルの原則の1つは、変化する要件に対応し、少しずつ機能を追加しながらリリースされる製品を常にデリバリー可能な品質に保つことです。しかし、既存の機能が正しく動作することの検証と、新しい機能のテストのバランスをとることは難しく、多くのアジャイル開発チームが、拡大するテストスイートの作成、およびメンテナンスに悩まされています。適切な情報がなければ、最終的には、製品の品質とセキュリティの両方に自信を持ってアジャイルを加速することが非常に困難になります。

テスト中に実行されたコードの量を見るのは、どれほどリスクが軽減されたかのレベルを理解するのに有用な指標ですが、その指標は誤って利用されることが多く、マクロレベルでは有効な品質の指標とはなりません。この記事では、コードカバレッジメトリックを賢く利用して、新しいテストが必要な場所を把握することで、最も必要な場所にテスト作業を集中させる方法を説明します。また、メンテナンス性の高いテストスイートを作成するためのベストプラクティスについても説明します。

有用なコードカバレッジとは

コードカバレッジは、十分なテストが行われたかを判断するための「唯一の」数字ではなく、重点を置くべき場所を示すのに役立つ数字の「ひとつ」です。

残念なことに、コードカバレッジが不適切に使用され、数字自体を重視したり、たとえば「リリースするには80%のカバレッジが必要」「カバレッジの数値が以前のリリース以上でなければならない」といったポリシーによって、特定のパーセンテージを目標にする誤った管理がされることがあります。

このアプローチの問題点は、目標となるカバレッジの数値を達成し続けることは困難で時間もかかるということです。そのため、盲目的に数値を追い求めることになり、次のような重要な質問をする時間がありません。

  • 80%というのは、どのカバレッジを意味しているのか?
  • テストの結果、品質は検証され、デリバリー対象のアプリケーションのリスクは軽減されるか?
  • コードの発展に伴ってテストをどのようにメンテナンスするか?

以前のブログで説明したように、コードの変更はリスクの導入を表しており、既存のコードに対する変更の具体的な影響と、リスクの軽減方法を理解することが重要です。

コードの変更を識別し、コードカバレッジを利用して変更にテストを関連付けると、どの部分に再テストが必要かに基づいて、最適なテストプランを作成することができます(変更ベースのテストについて詳しくは、こちらを参照してください )。

しかし、これですべてのリスクがカバーされるわけではありません。新しい機能のテストを作成する必要があるのは当然ですが、既存コードやレガシーコードについてはどうでしょうか?話を聞いてみると、多くの組織は60〜80%のコードカバレッジを目標にしていますが、現実には50%を超えるのに苦労しています。したがって、既存のコードへの変更は、既存のテストケースではカバーされない可能性があります。純粋にマクロ的なカバレッジの目標数値を維持すること、または段階的に増やすことに注力しても、「もう何年も動いていた」レガシー機能に手戻りが入り込むのを防ぐことはできません。

コードカバレッジを目標にするのではなく、カバレッジの詳細をしっかりと調べると、カバーされていない特定の変更行をすばやく特定できるので、チームは新しいテストの作成が必要な場所に重点的に取り組むことができます。さらに、テストケースとそれらが実行する特定のコードとの間のトレーサビリティを使用して、変更をカバーするために複製または拡張できる潜在的なテストケースを特定できます。

プロジェクト全体の安定性に影響を与える要因(たとえばレガシーコードの修正など)を排除しつつ新しいコードのリスクを軽減するためには、「全体で80%のカバレッジ」という目標よりも、修正されたコードの100%カバレッジを達成することに焦点を当てるほうがはるかに効率的です。

役に立つ変更コードカバレッジ

このようなインテリジェントなコードカバレッジを測定するのに、Parasoft DTPのModified Code Coverageウィジェット(Parasoft DTPのProcess Intelligence Engine(PIE)の分析スライス)を使用することができます。このウィジェットでは、2つのビルド(たとえば、現在のビルドと任意のターゲットビルド)の間で追加または変更されたコードのカバレッジを簡単に確認できます。図1はウィジェットを示しています。この例では、2つのビルドの間に177行のコードが追加または変更され、そのうちの109行(61.6%)がテストされています。これは、68行の新規または変更されたコードがテストによってカバーされていない、したがって検証されていないことを意味し、コードのリスクを表しています。

 

このウィジェットの背後には、変更カバレッジレポートがあります。このレポートには、適切なテストが欠けているコードに関する詳細な情報が記載されています。これは、開発者とテスターが労力を集中させるために必要な、重要な情報です。図2はそのようなレポートを示しています。レポートの中では、変更されたファイルは変更の行数、またはテストされていないコード行数に基づいてソートできます。また未カバーの変更行が赤いマークで示されます。

このレポートは、「どのテストが不足しているか?」という質問に答えます。各ビルドの情報に基づいて、テストプランを作成することができます。

どのテストを作成するべきか

テストが行​​なわれていないコードを見つけたら、ギャップを埋めるためにテストを作成する必要がありますが、そこでどんな種類のテストを作成するべきでしょうか?テストピラミッドは( Martin FowlerMike Cohnが伝えているように)、効率的で管理しやすく保守性の高いテストポートフォリオの作成方法を表します。脆弱なUIレベルのテストを最小限に抑え、ユニットテストの堅固な基盤(包括的なサービス/ APIレベルのテストにバックアップされる)を築くことに焦点を当てると、スケーラビリティ、メンテナンス性にすぐれ、継続的に実行可能なテスト戦略を構築できます。

この記事では、ユニットテストやAPIテストの作成の詳細には触れませんが、私が以前に書いたユニットテストに関する記事を参照するとよいでしょう。また、Parasoft SOAtestを使用してAPI/サービスレベルテストの作成を容易にする方法については、これから記事を公開する予定です。

まとめ

コードカバレッジは重要なメトリクスですが、特に品質の測定に使用される場合、しばしば過信され、誤用されることがあります。コードカバレッジからより多くの価値を引き出すために、Parasoft DTPの分析インテリジェンスを活用して、新しいテストが必要な場所を検出し、リスクを軽減し、テストを集中させると、品質目標を最適に達成することとなるでしょう。

 

Parasoft DTP および Parasoft 社製テストツールを実際に触ってみたい、使い勝手を確認したいという方のために、無料体験版をご用意しております。お気軽にお申し付けください。

Top