テストカバレッジを高めるための戦略

本稿はStrategies for Higher Test Coverageの抄訳です。


多くのソフトウェア開発プロジェクトで見られる現象として、初期段階ではテストよりも設計や機能開発に注力する傾向があります。これは最初の目標が「動作するソフトウェアの実現」であることから、自然な流れとも言えます。しかし、ソフトウェアが一度リリースされて新機能が追加されたりメンテナンスが必要になったりすると、その優先順位は変わるべきです。なぜなら、新機能の追加は必ずしも容易なものではなく、プロジェクトの拡大は既存機能に対して予見できない影響を及ぼす可能性があるからです。

コードカバレッジツールは、プロジェクトが進行中でも品質を保つ上で重要な手段となります。本稿では、そのツールをテストモニタリングに有効に活用する方法をお伝えし、開発のさまざまなシナリオに対応できるよう、品質を保つためのテストカバレッジの向上策をご提案します。

コードカバレッジメトリクスの適切な選択

テストモニタリング戦略を作り出す前に、何を追跡し、何を分析するべきなのかをはっきりさせることが大切です。テストの進捗を追跡する指標としてよく知られているコードカバレッジですが、粒度によって様々なバリエーションがあります。これには、関数カバレッジ、行カバレッジ、ステートメントカバレッジ、決定カバレッジ、条件カバレッジ、修正条件/決定カバレッジ(MC/DC)、複数条件カバレッジ(MCC)などが含まれます。例えば、安全性が重視される規格によって指定されていない限り、自分たちにとって最も関連性の高いものを選ぶことが求められます。

一般的な誤りとして、「どれを選ぶべきか迷うから全て追跡しよう」という考え方があります。しかし、基本的には一つの問題に対しては一つの指標でモニタリングするべきです。これは分析をシンプルにし、解釈を容易にするためです。全ての指標を追跡すると、結果の解釈が難しくなる可能性があります。例えば、一つの指標が品質向上を示している一方で、他の指標がそうでない場合、我々はどう解釈すれば良いのでしょうか?

コードカバレッジ分析では、基本的には適切な指標を選ぶのはそれほど難しくないはずです。ます最初に、指標を精度が高い順に整理することができます。

  • 関数カバレッジ:関数内のコードは考慮しないため、精度がかなり低い。
  • 行カバレッジ:コードの書式によっては指標が影響を受けるため、信頼性に欠ける。
  • ステートメントカバレッジ
  • 決定カバレッジ
  • 条件カバレッジ
  • MC/DC:解釈が難しいものの、条件カバレッジとMCCの間のバランスを取る指標として使える。
  • MCC:非常に精確だが、複雑なブール式をカバーするためには大量のテストセットが必要となる場合がある。

このメトリクスリストの特性として、ある指標でコードが100%カバレッジを達成した場合、それより前の全ての指標も100%カバレッジを達成するという点が挙げられます。つまり、条件カバレッジが100%ならば、関数、行、ステートメント、決定のカバレッジも100%となります。ただし、その逆は必ずしも成り立たないため、MC/DCやMCCのカバレッジが100%になるとは限らないのです。そのため、複数のカバレッジ指標を追跡する必要はありません。精度とテスト網羅性のバランスを見つけるため、適切な妥協点を選ぶことが大切です。優秀なカバレッジツールならば、全ての指標を記録することが可能です。

カバレッジメトリクスを一元化する戦略

メトリクスを記録するだけでは十分ではなく、カバレッジ指標に基づいた戦略が必要となります。一つの有効な戦略としては、製品に対して最低限のカバレッジを要求することが考えられます。

全体的なコードカバレッジの最低基準

この戦略は、単体テストとアプリケーションテストのカバレッジが混在している状況では、一般的に適用することが難しいです。アプリケーションテストのカバレッジは急激に広がり、少数のテストでもカバレッジの50%を達成することが可能です。しかし、その伸びはある程度以降では鈍化し、カバレッジ75%以上を達成することは難しくなります。一方で、単体テストのカバレッジはテストの量に応じてゆっくりと増えていきますが、多くの場合は高いカバレッジを達成できます。事実上、カバレッジ100%を達成する唯一の方法とも言えます。
 
しかし、自動化されたテストスイートがない既存の製品に対しては、この戦略は別の問題を引き起こします。製品は、完全ではなくても使用に耐えうる品質でリリースされます。形式的なテストがないという事実は、その製品が機能しないということを意味するものではありません。製品のカバレッジ目標を90%などに設定し直すということは、莫大な労力を必要とし、現実的ではないかもしれません。さらに、何年も触れられていないレガシーコード、あるいは開発者の経験に基づいて動作が保証されているコードに対してテストを書くというのは、実際にはどれほど意義があるのでしょうか。

新たなコミットにおけるカバレッジの基準値

上記のような状況では、全体的なカバレッジの目標を設定するのではなく、新たに開発する機能に対して要求を設定するのが良いと言えます。コードカバレッジツールを使えば、以下の二つの異なる方法でこれを実現することが可能です:

  • 二つのソフトウェアリリースを比較する
  • パッチ分析(またはテスト影響分析):具体的なコミットを分析する

これらのアプローチにより、新たに開発した機能に対するカバレッジを的確に測定し、品質を確保することができます。

二つのソフトウェアリリースを比較する

2つのリリース間でカバレッジを比較することで、変更されたコード部分のカバレッジを得ることができます。この戦略は、全体的なカバレッジを監視するよりもいくつかのメリットがあります:
 
カバレッジを上げるために必要な労力は、時間の経過とともに指数関数的に増大することが一般的です。製品のカバレッジが30%であれば、さらに1%増やすことは大きな仕事ではありません。しかし、カバレッジが90%に達した場合、さらに1%のカバレッジを得るためには、最初の50%を達成するのに必要だった労力よりもはるかに大きな労力が必要となります。2つのリリース間で変更されたコードのカバレッジを監視することにより、リリースごとに一定の労力を維持することができます。
この戦略では、全体的なカバレッジ目標を達成するために、開発者がレガシーコードに対して人工的なテストを書くことを強制する必要がありません。
新しく開発された機能の品質に関してより具体的な評価を提供できるため、リリースするかどうかの決定をより恣意的なものにしないという利点があります。

パッチ分析

リリース間の比較は、製品開発の品質を監視するための良い方法ですが、よくある開発シナリオでは、製品リリース後にホットフィックスを公開する必要が出てきます。このようなシナリオでは、既存の機能が壊れるリスクがあります。コードのレビューは重要ですが、パッチ分析といった定量的なチェックに比べて堅牢さが欠けています。
 
パッチ分析は、バージョン管理システムから生成されるパッチに対して以下のような情報を付加します:
 
  • パッチ自体のカバレッジに関する統計
  • パッチが影響を及ぼすテストのリスト
  • テストが適用されていない行のリスト
 
このような情報があると、レビュアーはパッチが適切にテストされているか、またリリースする際のリスクが適切であるかを分析でき、レビューが容易になります。

まとめ

コードカバレッジ解析の使用目的は、アプリケーションの品質に対するより詳細な評価を得るためです。自動テストが初めから作られていない既存のソフトウェアにおいても、コードカバレッジツールの活用により、今後リリース予定の製品の品質を確実に保つことが可能となります。テストカバレッジを向上させるには様々な方法がありますが、カバレッジ目標を定めるだけでなく、その背後にある戦略をよく考えて、それが効率的かどうかを確認することが大切です。

おわりに

コードカバレッジツールCocoをはじめとするQtのQA(品質保証)ツールにご興味のおありの方は、Qt JapanのEメールアドレスjapan@qt.ioまでお気軽にご連絡ください。

概要のご説明から詳細な技術的相談、また無料のツールトライアルのご案内もいたしております。


Blog Topics:

Comments