ビルド品質指標レポート

[アーティクル]
02/21/2013

ビルド品質指標レポートには、指定されたビルド定義のテストカバレッジ、コードチャーン、およびバグの数が示されます。このレポートを使用して、コードの各部分がリリース品質にどのくらい近づいているかを判断できます。

テスト率、バグ、およびコードチャーンがすべて同じ状況を示すのが最適な状態ですが、多くの場合、同じではありません。相違が見つかった場合は、ビルド品質指標レポートを使用して、特定のビルドとデータ系列の詳細を調べることができます。このレポートでは、テスト結果、テストからのコードカバレッジ、コードチャーン、およびバグが集結されるので、さまざまな側面を同時に確認できます。

レポートへのアクセス、レポートの更新または管理の方法については、「レポート (アジャイル)」を参照してください。

[!メモ]

このレポートを使用するには、チームプロジェクトを含むチームプロジェクトコレクションが SQL Server Reporting Services でプロビジョニングされている必要があります。このレポートは、チームエクスプローラーを開いて、チームプロジェクトノードを展開したときに [レポート] が表示されない場合は使用できません。

このトピックの内容

レポートのデータ
レポートに含めるビルドの数の変更
レポートの解釈
レポートのフィルター処理

このレポートを使用すると、次の事項を確認できます。

ソフトウェアの品質はどうか。
どのくらいの頻度でテストが成功し、どの程度の分量のコードがテストされているか。
コードメトリックおよびテストメトリックに基づいてチームは目標を達成できそうか。

必要なアクセス許可

レポートを表示するには、Reporting Services で閲覧者ロールが割り当てられているグループに割り当てられているか、そのグループに属している必要があります。詳細については、「チームプロジェクトへのユーザーの追加」または「アクセス許可の管理」を参照してください。

レポートのデータ

ビルド品質指標レポートに表示されるデータは、データウェアハウスから派生します。X 軸には、プラットフォーム、構成、およびビルド定義に対して設定したフィルターに基づいて、レポートに含まれるビルドの一覧が示されます。

各縦棒は、1 つ以上のビルドから派生した一連のデータを表します。レポートのコードサイズバリアントでは、各縦棒の長さはコードベースにチェックインされたコードのサイズを表します。棒は、最大の値がグラフの高さに収まるようにスケーリングされます。ビルド完了後はいつでも手動テストを実行でき、結果はそのビルドに関連付けられます。まだ実行されていないテストは "結果不確定" としてカウントされます。

ビルド品質指標レポートの例を次の図に示します。

ビルド品質評価のサンプルレポート

次の表で、このレポートの各品質指標で表示される情報について説明します。

品質指標	説明
アクティブなバグ (数)	ビルド時にアクティブだったバグの数を示す折れ線グラフ。メモバグはビルドに明示的に関連付けられていません。カウントされるバグの中には、グラフに表示されるビルドに影響しないものもあります。Area パラメーターを使用すると、製品区分でバグをフィルター処理できます。この方法により、レポートに表示されるビルドに影響する可能性が最も高いバグが表示されます。
コードチャーン (行)	チームがビルドの前にチェックインで追加、削除、および変更したコードの行数を示す折れ線グラフ。コードチャーンは、ビルドで追加、削除、または変更されたコードの行数をビルド内の合計行数で除算して算出されます。
コードカバレッジ (パーセント)	テスト対象のコードの割合を示す折れ線グラフ。
結果が不確定のテスト	正常に完了しなかったテストまたは一時停止されたテストの数を示す、積み上げ横棒グラフの灰色の部分。ビルドが正常に完了しなかった場合、テストはカウントされないか、不確定としてカウントされます。
失敗したテスト	ビルドで失敗したテストの数を示す、積み上げ横棒グラフの赤色の部分。
成功したテスト数	ビルドで成功したテストの数を示す、積み上げ横棒グラフの緑色の部分。

[!メモ]

失敗または成功のテスト結果が示す意味の詳細については、「テスト計画の進行状況レポート」を参照してください。

レポートは、次の方法でフィルター処理できます。

ビルドの数とレポートの終了日を指定して、X 軸の範囲を変更します。表示される最初のビルドの日付は、ビルド頻度によって決まります。
レポートに含めるプラットフォーム、構成、およびビルド定義を指定して、レポートに表示されるビルドの一覧をフィルター処理します。ビルド定義に使用できる値のセットはプラットフォームと構成によって異なるため、その順序でパラメーターを設定します。
レポートに含める製品区分を指定して、レポートに反映させるバグをフィルター処理します。このフィルターは、X 軸に表示されるビルドの一覧、コードチャーン、コードカバレッジ、またはテスト結果には影響しません。

詳細については、このトピックの「レポートのフィルター処理」を参照してください。

必要なテストおよびビルド管理アクティビティ

ビルド品質指標レポートを有効に使用し、このレポートで表示できるすべての品質指標を示すために、チームメンバーは次のアクティビティを実行してテストおよびビルドを管理する必要があります。

ビルドシステムの設定。Team Foundation ビルドを使用するには、ビルドシステムを設定する必要があります。

詳細については、「Configuring Your Build System」を参照してください。
ビルド定義の作成。いくつかのビルド定義を作成し、各ビルド定義を実行して別のプラットフォームでコードを生成できます。また、別の構成で各ビルドを実行することもできます。

詳細については、「ビルド処理の定義」を参照してください。
ビルドの一部として自動的に実行するテストの定義。ビルド定義では、ビルドの一部としてテストを実行し、テストに失敗した場合はビルドが失敗するように定義できます。

詳細については、「既定テンプレートに基づくビルドプロセスの定義」を参照してください。
コードカバレッジデータを収集するテストの設定。コードカバレッジデータをレポートに表示するために、チームメンバーはテストをインストルメントしてそのデータを収集する必要があります。

詳細については、「テスト設定を使用したコードカバレッジの構成は使用されなくなりました」および「How to: Gather Code-Coverage Data with Generic Tests」を参照してください。
ビルドの定期的な実行。ビルドは、設定された間隔で、またはチェックインが行われるたびに実行できます。スケジュールトリガーを使用すると、定期的なビルドを作成できます。

詳細については、「ビルド定義の作成」および「ビルドの実行、監視、管理」を参照してください。

[!メモ]

チームメンバーはビルドエクスプローラーを使用してビルドを手動で評価することができますが、この評価はビルド品質指標レポートには反映されません。ビルド評価は、ビルドの概要レポートに表示されます。詳細については、「完了したビルドの品質の評価」および「ビルドの概要レポート」を参照してください。

レポートに含めるビルドの数の変更

ビルド品質指標レポートの表示は、レポートに含めるビルドの数と、レポートに適用するその他のフィルターによって大幅に異なります。レポートに表示されるビルドの数を変更することで、レポートの範囲を特定のビルドに絞り込むことができます。

レポートに含めるビルドの数を設定するには

[ビルド数] に、含める数を入力します。
[終了 (日付)] の横にある予定表アイコンをクリックし、レポートに含めるビルドの最終実行日に対応する日付をクリックします。
[レポートの表示] をクリックします。

レポートの解釈

このレポートを確認すると、特定のビルド定義に関して次の事項を確認できます。

ソフトウェアの品質はどうか。
チームがテストしているコードの分量は十分であるか。
テストは成功しているか。
コードメトリックおよびテストメトリックに基づいてチームは目標を達成できそうか。
どのくらいの頻度でテストが成功し、どの程度の分量のコードがテストされているか。

[!メモ]

灰色のセグメントの比率には、テストの対象となったコードの割合が反映されていますが、色付きのセグメントの比率には、テストが成功または失敗したコードのおおよその割合しか反映されていません。このあいまいさは、色付きのセグメントの緑色の部分が、成功したテストの数を表していることによるものです。コードの一部分に含まれる 1 つのエラーによって多数のテストが失敗する場合や、1 つの失敗が、コードベース全体に影響を及ぼす設計上の広範囲なエラーを表している場合もあります。

正常なレポート

正常なビルド品質指標レポートには、次の指標が示されます。

ほとんどのテストが成功し (緑の領域が大きい)、失敗しているテストはほとんどない (赤の領域が少ない)。
赤の割合は 20 ～ 30% より小さい。

次の図に示すように、コードカバレッジとテスト成功率は高く、時間と共に上昇しています。コードチャーン、アクティブなバグ、結果が不確定のテスト、および失敗したテストの値はすべて低く、減少しています。

正常なビルド品質評価レポート

問題のあるビルド品質指標レポート

問題のあるビルド品質指標レポートには、次の問題が 1 つ以上見られます。次のガイダンスに従って原因を調べることができます。

コードカバレッジが減少し、コードチャーンが上昇している。次の図は、コードカバレッジが減少し、コードチャーンが上昇している状態を示しています。このデータは、単体テストで対処せずに新しいコードをチェックインしていることを示す明らかな警告です。
テストの実行率が低い。次の図は、テストの実行率が低い状態を示しています。このデータは、チームが十分なテストを実行していないことを示している可能性があります。この障害状態は、リソースが不足しているか、テスト担当者が他の操作を行っている (現在の機能をテストする代わりに自動テストを作成しているなど) ことを示しています。どちらの場合も、リソースのバランスを調整する必要があります。
コードチャーンが高く、コードカバレッジが低い。コードチャーンが高いということは、変更の副作用としてバグが追加されることを示します。完全にリファクターされたプロジェクトでは、コードカバレッジまたはテスト成功率が変化せずにコードチャーンが発生します。それ以外の場合にコードチャーンが高いということは、カバレッジが減少しており、テストを再作成する必要があることを示している可能性があります。

次の図は、テスト成功率が高いままであるのに、コードチャーンが高く、テストからのコードカバレッジが低い状態を示しています。このデータは、実行中のテストが新しいコードを実行していないことを示しています。
テストの失敗率が高い。次の図は、多くのテストが妥当なコードカバレッジで実行されているが、テストが失敗している状態を示しています。このデータは、開発の手法が緩いか、初期のイテレーションで現在の製品段階に対してテストが厳格すぎることを示している可能性があります。

失敗しているテストには、できる限り迅速に対処する必要があります。コードを修復することが実用的でない場合は、失敗しているテストを一時的に無効にしてバグを記録する必要があります。プロジェクトの初期の段階では、コード分析の失敗に緊急に対処しなくても許容される場合もありますが、赤色のセクションが大きくなりすぎないようにする必要があります。
テスト成功率が高く、アクティブなバグの率が高い。次の図は、テスト成功率が高いが、バグの発生率が高いままの状態を示しています。この状況が発生する原因は複数あります。テストが現在の製品段階に対して十分に厳格ではない可能性があります。

初期のイテレーションでは単純なテストが適していますが、製品が完成に近づくにつれて、より広範囲のシナリオおよび統合をテストで実施する必要があります。テストが古くなっているか、誤った機能をテストしている可能性があります。テスト手法の切り替えを検討してください。
テスト成功率が上昇しているが、コードカバレッジが上昇していない。通常は、実行されるテストが多いほど、カバーされるコードも多くなります。これに対して、テスト実行率およびテスト成功率が上昇しているが、コードカバレッジが上昇していない場合は、インクリメンタルテストが重複している可能性があります。
アクティブなバグの数が増加しているが、失敗したテストが増加していない。アクティブなバグの数が増加しているが、失敗したテストが増加していない場合は、バグが報告されているのと同じ機能がテストされていない可能性があります。
アクティブなバグの数が減少しているが、成功したテストが増加していない。アクティブなバグの数が減少しているが、テスト成功率が上昇していない場合は、再アクティブ化率が上昇しているおそれがあります。
灰色の領域が大きい。灰色の領域は、指定されたビルドでビルドまたはテストされなかったコードを示します。このデータは、指定された 1 つ以上のビルドが期間内に発生しなかった場合にのみ、定期的なレポートに表示されます。

レポートのフィルター処理

ビルド品質指標レポートは、次の方法でフィルター処理できます。

ビルドの数とレポートの終了日を指定して、レポートの時間間隔を変更します。
レポートに含めるプラットフォーム、構成、およびビルド定義を指定して、レポートの対象であるビルドの一覧をフィルター処理します。

[!メモ]

ビルド定義を設定して、テストを実行しない、一部のテストのみ実行する、またはすべてのテストを実行することを指定できます。レポートは、ビルド定義の構成に応じて大きく変わります。
レポートに含める製品区分を指定して、レポートに反映させるバグをフィルター処理します。

使用できるフィルターを次の図に示します。

ビルド品質評価のフィルター