ページカバレッジダッシュボードでは、アプリケーションのmablテストカバレッジを測定します。ページ別のカバレッジの内訳を見るには、[Application pages]テーブルまでスクロールします。この記事では、[Application pages]テーブルを解釈する方法と、データをフィルタリングしてmablテストカバレッジを詳細に理解する方法について説明します。
Application pagesテーブル
[Application pages]テーブルには、リストされた各ページについて、直近のリンククローラー実行で取得したスクリーンショットと、このページをカバーするテストの詳細なメトリックが表示されます。
Application pagesテーブル
デフォルトでは、過去2週間のページカバレッジのメトリックが報告されます。特定のページにアクセスしたテストまたはテストステップが、上流テストの失敗または条件ロジックが原因でクラウド上で実行されなかった場合、メトリックの合計には含まれません。特定のアプリケーションのデータが表示されない場合、またはメトリックが正しくない場合は、テストカバレッジのトラブルシューティングに関する記事を参照してください。
次のメトリックを使用して、ページの既存のカバレッジレベルを把握します。
| メトリック | 説明 |
|---|---|
| Performance | 最近のテスト実行でこのページの読み込みにかかったスピードインデックス(秒) の平均。 |
| Tests | 特定のページにアクセスした一意のテスト数。あるテストが複数のプランに属し、そのページに対して複数回実行される場合、最初の一意の実行のみがページカバレッジダッシュボードにカウントされます。 |
| Steps |
選択された期間内にこのページにアクセスしたテストに含まれる個別の操作ステップの数。ステップでは、操作対象のエレメントと実行したアクションによって区別されます。 この合計値には、アサーション、echoステップ、waitステップなど、ページを操作しないステップは含まれません。 |
| Assertions | 選択された期間内にこのページにアクセスしたテストに含まれる個別のアサーションステップの数。 |
| Complexity | ページのクローリング時や定期的なテスト実行の間にmablが測定したDOM自体の全体的な複雑さ。数値が大きいほど、ボタン、リンク、フィールドなど、ページに含まれる操作エレメントが多くなります。 |
| Linked | リンククローラーによって検知された、このパスに直接リンクするページの数。ページがアプリケーション内の深い場所にあるほど、この値は小さくなります。 |
| Depth | リンククローラーによって記録された、特定のパスにアクセスするために必要なクリックの回数。たとえば、アプリケーションのホームページの深さ (Depth) が0の場合、ログインページの深さはおそらく1です。 |
| Daily users | 特定のページにアクセスする一意ユーザーの1日あたりの平均数。このメトリックは、Segmentインテグレーションから取得したデータを使用します。 |
データのフィルタリング
テストカバレッジがないページの特定
テストカバレッジがないページを特定するには、[Tests]列をクリックして、昇順で並べ替えます。ページのテスト数が0の場合、リンククローラーを除き、このページにアクセスするテストがないことを意味します。
[Steps]列でフィルタリングすると、ページを操作するステップがないページを特定できます。
[Assertions]列でフィルタリングすると、ページの状態を検証するアサーションがないページを特定できます。
カバレッジがないテストの特定
リンクが多いページのテストカバレッジの評価
アプリケーション内で頻繁にリンクされるテストを特定するには、[Linked]列を2回クリックして降順で並べ替えます。リンクが多いにもかかわらずテストカバレッジがないページは、テストのギャップを示している可能性があります。
トラフィックが多くカバレッジがないページの特定
mablワークスペースとSegmentを統合している場合、トラフィックが多く、カバレッジがないページを特定できます。mablのSegmentのソースに接続すると、ページカバレッジダッシュボードに [Users] というメトリックが追加されます。[Users]列には、各ページを操作している一意ユーザー数が表示されます。
[Users]列を2回クリックして、1日のユーザー数の多い順にページを並べ替えます。1日のユーザー数が多く、テスト数が比較的少ないページは、テストカバレッジにギャップがあることを示している可能性があります。