ソフトウェアテストにおけるテストカバレッジ：その測定方法

テストカバレッジとは何ですか?

テスト カバレッジは、一連のテストによって実行されるテストの量を測定するソフトウェア テストの指標として定義されます。 これには、条件付きステートメントのどの分岐が選択されたかを判断するために、テスト スイートの実行時にプログラムのどの部分が実行されるかに関する情報の収集が含まれます。

簡単に言うと、テストがコードをテストしていること、またはテストの実行によってコードのどの程度がテストされているかを確認するための手法です。

テストカバレッジとはどのようなものですか？

実際のプロジェクトにおいて、テストカバレッジは4つの実践的な活動をサポートします。

• 一連のテスト ケースで実装されていない要件の領域を見つける
• 追加のテスト ケースを作成してカバレッジを増やすのに役立ちます
• 品質チェックの間接的な方法であるテストカバレッジの定量的尺度を特定する
• カバレッジを拡大しない無意味なテスト ケースを特定する

ソフトウェアエンジニアリングにおけるテストカバレッジの利点

これらの活動は、具体的な工学的利益へと結びつく。

• テストの品質を保証できます
• リリースまたは修正のためにコードのどの部分が実際に変更されたのかを特定するのに役立ちます。
• テストされていないアプリケーション内のすべての決定点とパスを特定できるため、テストカバレッジを向上させることができます。
• 防ぐ 欠陥 漏れ
• 時間、範囲、コストを管理できる
• プロジェクトのライフサイクルの初期段階での欠陥の防止
• ユニットレベルおよびコードレベルでの要件、テストケース、欠陥のギャップを簡単な方法で見つけることができます

テストカバレッジの種類

カバー範囲は決して単一の数値ではありません。チーム track は、同じスイートに関する異なる質問に答えるタイプなので、一度に複数のタイプを回答する必要があります。以下の表は、よく遭遇するタイプをグループ化したものです。

最初の 5 つのタイプはコードレベルの対策であり、 ホワイトボックステスト一方、要件とリスク範囲はテスト計画レベルに位置する。

主な違いは何ですか Code 対象範囲とテスト範囲？

Code カバレッジ およびテスト カバレッジは、アプリケーション コードの品質を評価できる測定手法です。

これらの取材方法のブース間の重要な違いをいくつか示します。

テストカバレッジの計算式

テスト カバレッジを計算するには、以下の手順に従う必要があります。

ステップ1） 数量カウント Yあなたが使用しているソフトウェアのコードの総行数 テスト

ステップ2） 数量カウント X現在すべてのテストケースが実行するコード行数

次に、(X を Y で割った値) に 100 を掛けた値を求める必要があります。この計算の結果がテスト カバレッジ % です。

具体的な例を挙げますと、以下の通りです。

システムコンポーネントのコード行数が500行で、既存のすべてのテストケースで実行された行数が50行の場合、テストカバレッジは次のようになります。

(50 / 500) * 100 = 10%   // executed lines divided by total lines

テストカバレッジの例

以下の例が示すように、パーセンテージだけでは全体像を把握することはできません。

例1：

例えば、「ナイフ」をテスト対象とする場合、野菜や果物を正確に切れるかどうかを確認することに重点を置く必要があります。しかし、ユーザーが快適に扱えるかどうかなど、他にも考慮すべき点があります。

例2：

例えば、メモ帳アプリケーションを検証したい場合、その基本的な機能を確認することは必須です。しかし、メモ帳アプリケーションが他のアプリケーションを使用しているときに期待どおりに動作するか、ユーザーがアプリケーションの使い方を理解しているか、ユーザーが通常とは異なる操作をしようとしたときにクラッシュしないかなど、その他の側面も確認する必要があります。

テストカバレッジ手法

どちらの例も同じ結論を示しています。カバレッジ目標を達成するには、テストの数を増やすことよりも、適切なテスト設計手法を選択することが重要です。以下の手法は、カバレッジを拡大しながら、ping スイートは狭い。

• 境界値分析： 各有効範囲の端、つまり欠陥が最も集中している部分から入力を選択します。参照 境界値解析 処理済みの事例について。
• 同値分割： アプリケーションが同一に扱う入力をグループ化することで、単一のケースで値のクラス全体を安全に表現できます。
• 決定表テスト: 単一のグリッド内に、複数の条件の組み合わせとその予想される結果を網羅的に表示します。
• 状態遷移テスト: アプリケーションの状態間の有効な遷移と無効な遷移をすべて検証します。
• 基本パステスト: 制御フローグラフから、独立パスの最小セットを導出します。
• リスクベースの検査: ビジネスへの影響度に基づいて機能をランク付けし、リスクの高いものから優先的に取り上げます。
• 探索的テスト: 台本通りの事件や報道では決して明らかにならない抜け穴を暴き出す。

テストカバレッジはどのように達成できるのか？

技術が選択されると、確立された4つのルートによってカバー範囲が確保される。

• テストカバレッジは、ピアレビュー、検査、ウォークスルーなどの静的レビュー手法を実行することで実行できます。
• アドホックな欠陥を実行可能なテスト ケースに変換することによって
• コード レベルまたは単体テスト レベルで、自動化されたコード カバレッジ ツールまたは単体テスト カバレッジ ツールを利用することでテスト カバレッジを達成できます。
• 機能テストのカバレッジは、適切なテスト管理ツールの助けを借りて実行できます。

テストカバレッジを向上させる方法

カバレッジの確立は出発点であり、それを向上させることは繰り返し行うべきルーチンです。リリースサイクルの開始時に、この手順を必ず実行してください。

1. 現在の数値を基準値とする。 カバレッジレポートを実行し、ステートメント、ブランチ、要件のカバレッジを個別に記録することで、ギャップがプロジェクト全体の平均値の中に隠れてしまうのではなく、モジュールごとに可視化されます。
2. テストを要件にマッピングする。 ビルド tracすべての要件を少なくとも1つのテストケースにリンクさせた妥当性グリッド。空欄の行は、疑いではなく、確定したギャップを示します。
3. モジュールをリスク順にランク付けする。 決済、認証、データ移行のロジックは、静的なヘルプ画面よりもはるかに詳細な説明が必要なので、予算は障害が発生した場合に最も大きな損害が生じる箇所に投入すべきです。
4. 否定的なケースや例外的なケースも追加する。 入力値が空の場合、値が大きすぎる場合、ネットワークタイムアウト、権限エラーなどが発生すると、正常系テストでは決して触れることのない分岐が発生します。
5. テストレベルを重ね合わせる。 組み合わせる 単体テスト, 統合テストまた、エンドツーエンドのチェックも必要です。なぜなら、各レベルは構造的に他のレベルではカバーできない部分をカバーしているからです。
6. 回帰テストスイートを自動化する。 Promo安定したケースを 自動化テスト そしてそれらを内部で実行する CI / CDパイプライン コミットごとに。
7. 重複しているケースは削除する。 実行時間を増やすだけで、未カバー行を1行も追加しない重複テストを削除します。
8. Revスプリントごとにトレンドを確認する。 Trackカバレッジの隣に 欠陥密度均一な被覆率に対して漏洩が増加する場合は、死角が発生している兆候です。

⚠️ 警告: 100%を目標にしてはいけません。強力なアサーションを含む85%のチェックスイートは、結果を検証せずにコードを実行するだけの95%の浅いチェックよりも、リリースをはるかに効果的に保護します。

テストカバレッジの欠点

保険適用範囲は依然として価値があるが、割合を報告する前に明記しておくべき制限事項も存在する。

• 自動化するツールがないため、テスト カバレッジ内のタスクのほとんどは手動で行われます。 そのため、要件を分析してテストケースを作成するには多大な労力がかかります。
• テスト カバレッジを使用すると、機能をカウントし、複数のテストに対して測定することができます。 しかし、常に判断ミスの余地が存在します。

よくあるご質問