失敗の分析 Excel レポート
失敗の分析レポートを使用すると、検出された回帰の数をテスト チームが監視するのに役立ちます。 回帰とは、以前のバージョンのソフトウェアでは出現せず、テスト対象のバージョンのソフトウェアでは出現したバグです。 回帰テストを実行するチームは、新しいバージョンのソフトウェアにのみ出現するバグを検出することに重点を置きます。 失敗の分析レポートには、過去 4 週間以内の、以前は合格し、今回は失敗した各テスト ケースの構成の数が示されます。
このレポートは、チームがテスト計画を作成して、Microsoft Test Manager でテストを開始した後にのみ使用できます。 テスト スイートおよびテスト計画を定義する方法の詳細については、「Team Web Access での手動テストの計画」を参照してください。 このレポートにアクセスする方法については、「Excel レポート」を参照してください。
注意
失敗の分析レポートは、テストのダッシュボードから表示できます。このダッシュボードにアクセスできるのは、チーム プロジェクト ポータルが有効化され、SharePoint Server Enterprise Edition を使用するように構成されている場合だけです。
必要なアクセス許可
レポートを表示するには、チーム プロジェクトの SharePoint 製品に対する [読み取り] アクセス許可が割り当てられているグループに割り当てられているか、そのグループに属している必要があります。
レポートを変更またはカスタマイズするには、SQL Server Analysis Services の TfsWarehouseDataReaders セキュリティ ロールのメンバーである必要があります。 また、チーム プロジェクトの SharePoint 製品に対する [メンバー] アクセス許可が割り当てられているグループに割り当てられているか、そのグループに属している必要があります。 詳細については、「Visual Studio ALM 用データ ウェアハウスのデータベースへのアクセスの許可」を参照してください。
レポートのデータ
失敗の分析レポートは、過去 4 週間以内のすべての構成のテスト ケースで失敗に終わったすべての結果の累積数を、積み上げ面グラフで示します。 失敗の種類には、"新しい問題"、"既知の問題"、および "回帰" があります。
.png "失敗の分析 Excel レポート")
このレポートは、データ ウェアハウスに格納されている過去 4 週間以内のテスト結果データを示すピボットグラフに基づいています。
システムは、テスト ケースが実行された各構成を検証し、テスト ケースの同じ構成の過去の結果を識別しようと試みます。 テスト ケースまたは構成に割り当てられる失敗の種類は、次の基準に基づいて決定されます。
回帰: 直前の結果が "成功" だった場合。
新しい問題: 直前の結果が見つからない場合。
既知の問題: 直前の結果が "失敗" だった場合。
回帰の監視に必要なアクティビティ
正確で効果的な失敗の分析レポートが生成されるようにするためには、チームは次のアクティビティを実行する必要があります。
テスト ケースとテスト計画を定義し、テスト ケースをテスト計画に割り当てます。
手動テストの場合は、テスト ケースの各検証手順の結果を、成功または失敗としてマークします。
重要
テスト担当者は、テスト ステップが検証テスト ステップである場合、そのことを示す状態でマークする必要があります。テスト ケース全体の結果は、テスト担当者がマークしたすべてのテスト ステップの状態を反映します。したがって、テスト担当者がテスト ステップを失敗とマークしている場合、またはまったくマークしていない場合、テスト ケースは失敗の状態になります。
自動テストの場合、各テスト ケースは成功または失敗として自動的にマークされます。
(省略可能) フィルター処理をサポートするには、イテレーション パスと領域パスを各テスト ケースに割り当てます。
レポートの解釈
失敗の分析レポートは、現在製品開発サイクルのどの段階であるかに応じて異なるということを理解しておく必要があります。 イテレーションの初期の段階では、回帰アクティビティは少ししかないか、まったくありません。 開発サイクルの後半になると、いくつかの回帰があることを想定しておく必要があります。 具体的には、このレポートをレビューして、次の事項を確認する必要があります。
全体でいくつのテストが回帰しているか。
チームは回帰または失敗したテストの総数を想定の範囲内またはチームのゴール内に抑えているか。
チームは問題を特定してからすぐにその問題に対処しているか。 既知の問題に適時に対処しているか。
正常な失敗の分析レポートには、適度な数の新しい問題、既知の問題、および回帰が示されます。 これらの区分の 1 つ以上でスパイクが発生した場合、チームはさらに詳しく調査する必要があります。 スパイクの発生は、チームがチェックインしているテスト動作またはコード品質のいずれかの問題を示している可能性があります。
また、最新のビルドの状態、バグの状態、およびコード チャーンをチェックして、これらの要因の測度によってテスト動作の線の変化を説明できないかどうかを判断することをお勧めします。
レポートの更新とカスタマイズ
失敗の分析レポートは、Office Excel で開いて、ピボットテーブル レポートのフィルター オプションを変更することで更新できます。 このレポートは、次の表に示すその他のビューをサポートするようにカスタマイズできます。
ビュー |
アクション |
|---|---|
イテレーションの失敗の分析 |
Iteration のフィルターを変更します (既定 = すべて)。 |
製品区分の失敗の分析 |
Area のフィルターを変更します (既定 = すべて)。 |
特定のテスト計画またはテスト計画のスイートに対する失敗の分析 |
Test Plan のフィルターを追加します (既定 = すべて)。 |
過去 6 週間、8 週間、またはそれ以上の期間内の失敗の分析 |
列の [ピボットテーブルのフィールド リスト] で、@@Last 4 weeks@@ を別の Set に置き換えます。 |
ピボットテーブル レポートおよびピボットグラフ レポートの使用とカスタマイズの方法の詳細については、Microsoft Web サイトの次のページを参照してください。