カバレッジ概要ダッシュボード

カバレッジ概要ダッシュボードで、テストスイートの状況を一目で素早く把握できます：カバレッジ > 概要。このダッシュボードには、パフォーマンスの低下の可能性や、パフォーマンスが低いテスト、不安定なテストを特定するために使用できるチャートと表が含まれています。この記事では、mablがこのダッシュボードの基礎となるメトリクスをどのように計算しているかを説明し、データを効果的に解釈できるようにします。

ダッシュボードフィルター

カバレッジ概要ダッシュボードでメトリクスを分析する前に、フィルターを展開して、評価したいテストを定義してください。たとえば、特定のラベルを持つテストや、過去2週間のdev環境内のすべてのテストなどです。

「アプリケーション」および「プランラベル」のフィルターには、プランに関連付けられたテストのみが含まれることに注意してください。

最新のテスト成功率

最新のテスト成功率は、定義されたテストスイート内のアクティブなテストの最新ステータスを示します。このメトリックは、リリースの状態を把握するうえで役立ちます。

たとえば、次のリリースに向けて100件のテストを実行し、最新のテスト成功率が40%である場合、最新の実行で100件のうち40件のテストが成功し、残りの60件のテストは失敗しています。

累積テスト実行数

累積テスト実行数グラフは、特定の日付の範囲内で設定したフィルターに一致するすべてのアクティブなテストの一意のテスト実行数を示します。このメトリックを使用すると、フィルターで定義されたリリースに対して実行されているテストスイートの割合をすばやく確認できます。

たとえば、累積テスト実行数が149/177となっている場合、フィルターに一致する総数177個のテストのうち149個の一意のテストが実行されたことを示しています。

フィルターを適用すると、累積テスト実行数のメトリックが変更されます。たとえば、ワークスペース内に100個のアクティブなテストが存在し、これらのテストのうちの20個に「checkout」というテストラベルが付いている場合、カウントされるテスト数はフィルターによって次のようになります。

• フィルターの設定なし = 総数100個のテストをカウント
• テストラベルフィルターを「checkout」に設定 = 総数20個のテストをカウント
• 開始/終了時刻のみを設定 = 総数100個のテストをカウント
• 環境のみを設定 = 総数100個のテストをカウント

アプリケーションの読み込み時間の増加が上位のテスト

[アプリの読み込み時間が増加したテスト] (アプリケーションの読み込み時間の増加が上位のテスト) の表には、フィルターに一致するテストでのパフォーマンスのリグレッションの可能性が示されます。この表には、次の内容が示されます。

1. テストからアクセスされるページやエンドポイントでのパフォーマンスの低下が最大であったブラウザーおよびAPIテスト。テストまたは変化率をクリックすると、そのテストのパフォーマンスに関する詳細が表示されます。
2. フィルターで定義されたリリースのすべてのテスト実行を対象とするアプリケーション平均読み込み時間および平均APIレスポンスタイムの全体的な増減。

アプリケーションの読み込み時間とAPIレスポンスタイム

mablは、アプリケーションの読み込み時間とAPIレスポンスタイムを使ってテストパフォーマンスを算出します。

• アプリケーション累積読み込み時間とは、テストのすべてのステップのスピードインデックスの和です。アプリケーション累積読み込み時間を使用すれば、エンドユーザーがアプリケーションの読み込みを待っている間に実際に体験する時間の合計を測定できます。mablによるテスト実行にかかる時間は含まれません。
• 累積APIレスポンスタイムは、テスト内のすべてのリクエストのAPIレスポンスタイムの和を測定するもので、リクエストの間の時間など、他の「mabl」時間は含まれません。

プランの実行に含まれる完了したクラウド実行のみがパフォーマンスデータに含まれます。データに表示されるには、テストは以下の条件を満たす必要があります:

1. プランで実行: ローカル実行およびアドホッククラウド実行のデータは、パフォーマンスメトリクスに含まれません。
2. 最小実行数: テストは、日付の範囲の前半で3回以上、後半で3回以上実行されている必要があります。
3. 一致するフィルター: パフォーマンスカードに含まれるためには、テストはリリースカバレッジページで設定されたフィルターに一致する必要があります。
4. パフォーマンス悪化のトレンド: 日付の範囲の前半よりも後半のほうがアプリケーション読み込み時間 (ブラウザーテスト) またはAPIレスポンスタイム (APIテスト) が長くなっているテストだけが、パフォーマンスカードに含まれます。

品質メトリック

[品質指標] タブには、フィルターされたテストのグループに関するテストアクティビティ、テスト実行履歴、アプリケーション平均読み込み時間、分類された失敗の詳細が表示されます。

テストアクティビティ

上部にあるカードは、フィルタリングされた範囲のテストのテストアクティビティを表しています。

• テスト実行: フィルタリングされた範囲内に実行されたブラウザーテストおよびAPIテストの総数。この数字には、フィルタリングされた範囲のテストに対するデフォルトの「ホームページ訪問」テストと「リンククローラー」テストのテスト実行が含まれています。
• 新しいテスト: フィルタリングされた範囲内に作成された新しいテストの数。
• 更新されたテスト: フィルタリングされた範囲内に更新されたテストの数。

テスト実行履歴

テスト実行履歴チャートには、フィルターで設定された日付の範囲内の実行履歴が表示されます。

アプリケーション平均読み込み時間

フィルターに一致するテストの平均アプリ読み込み時間を表示します。平均アプリ読み込み時間は、ChromeとEdgeでのプランにおけるすべてのmablクラウド実行について、Google Lighthouseの「Speed Index」メトリックから自動的に収集されます。

このチャートを使用して、すべてのテストを対象に、パフォーマンスの改善と悪化の両面での大きなトレンドを把握することができます。

分類された失敗

失敗したテスト実行に失敗の理由を追加した場合、このチャートには、フィルターに一致する分類されたテストの失敗が表示されます。

テスト作成アクティビティ

更新されたテストと新しいテストを時系列で確認し、編集の急増やメンテナンスのボトルネックを特定します。

テストステータス

テストステータステーブルは、フィルターで定義されたすべてのテストの実行ステータスを要約します。このテーブルは、自動テストの定期的なレビューを実施する際に特に便利です。

たとえば、不安定なテストを見つけるには、テスト成功率ヘッダーをクリックして、結果別にテストを並べ替えることができます。成功率が低いものの0%ではないテストは、不安定性を示していることがよくあります。

テストの品質

テスト品質テーブルは、フィルターで定義されたすべてのテストの全体的な品質を測定します。このテーブルは、メンテナンスが必要なテストを特定する際に特に役立ちます。テーブルには以下の測定値が含まれています。

• Quality score - 成功率、安定性、信頼性を組み合わせた0から100の総合スコア。
• Pass rate - プランの実行において、テストのすべての試行が成功した割合。
• Stability - プランの実行全体を通じて、テストが同じ結果をどれだけ一貫して生成するかを示します。安定性が低いテストは、成功と失敗を繰り返す不安定なテストであることを示しています。
• Reliability - テストが連続した実行間で成功し続ける安定度を示します。安定性が高いにもかかわらず信頼性が低いテストは、継続的に失敗しており、不安定というよりも壊れているサインです。

総合的なquality scoreでは、これらの各ディメンションに異なる重みが付けられており、3つのディメンションのいずれかのスコアが低いと、全体のスコアが大幅に下がる可能性があります。たとえば、信頼性が50%のテストは、50%という数値が実際にはまったく信頼できないため、品質スコアを大幅に引き下げる可能性があります。