パフォーマンステストが実行されると、mablは、アプリケーションのパフォーマンスを複数のチャートやテーブルに表示します。この記事では、負荷がかかった状態でのアプリケーションのパフォーマンスの現状を理解し、課題を特定するために、以下を含むパフォーマンステストの出力をフィルタリングする方法について説明します:
パフォーマンステスト結果詳細
パフォーマンステストのステータスを確認する際には、以下の点に留意してください:
- パフォーマンステストは、少なくとも1つの失敗基準のしきい値が満たされると失敗します。
- パフォーマンステストに失敗基準がない場合は、常に成功となります。たとえば、失敗基準がなく、機能テストの失敗率が100%でも、パフォーマンステストは合格としてマークされます。
- パフォーマンステストを停止すると、すべてのテストの実行が停止するまで最大1分かかります。停止したパフォーマンステストは、テストが停止するまでの請求可能なVUH数を消費します。
パフォーマンステストのサマリーのチャートをカスタマイズ
パフォーマンステストのサマリーチャートは、テスト実行中のパフォーマンステストメトリックを追跡します。
各パフォーマンスメトリックの正確な意味については、システムパフォーマンスの測定の記事を参照してください。
異なるメトリックの表示
チャートに表示されるメトリックをカスタマイズするには、View more metricsボタンをクリックし、表示するメトリックを最大4つまで選択します。
パフォーマンステストサマリーに表示するメトリックのカスタマイズ
テストでフィルタリング
特定の機能テストまたはブラウザテストステップのデータを表示するには、チャートの上にあるSelect functional testドロップダウンから選択します。
ブラウザーテストメトリックのフィルタリング
[Browser Test Metrics] タブでは、個々のブラウザーテスト実行のパフォーマンスメトリックがすべて集計され、各メトリックの75パーセンタイル結果が表示されます。
列を使用して、パフォーマンスに関する問題があるステップをフィルタリングできます。ブラウザーのパフォーマンスを確認する際の推奨事項を以下に示します。
- [LCP] 列をクリックすると、LCPの時間が最も長いステップを知ることができます。LCPは、ユーザーが認識するページのパフォーマンスに最も近似するものと一般に考えられています。
- [Step duration] 列をクリックすると、時間がかかっているステップを知ることができます。シングルページアプリケーション (SPA) の場合、Chromeではコアウェブバイタルを収集できないため、代わりにステップ実行時間を使用してパフォーマンスを測定するのが適切です。
- ネットワークコールを調査する: ステップ自体をクリックすると、そのステップ中に発生したネットワークリクエストがドメインとリソースタイプ別に分類されて表示されます。ステップが予想以上に時間がかかる原因は、時々ネットワークリクエストにあります。
時間がかかるステップが見つかった場合、ステップを展開して、ステップで集計された各テストのネットワークアクティビティを表示します。
ブラウザーテストのAPIステップでは、エラー率とレスポンスタイムのデータが収集されます。これらは、mablが [API Test Metrics] タブで収集するのと同じメトリックです。
APIテストメトリックのフィルタリング
[API Test Metrics] タブでは、個々のAPIテスト実行すべてに関して、エラー率とAPIレスポンスタイムが集計されます。
APIパフォーマンスを確認するためのヒントを以下に示します。
- [Error Rate] 列をクリックすると、エラー率が最も高いエンドポイントを見つけることができます。一般的な応答エラーの内訳を見るには、リクエストをクリックします。
- レスポンスタイムパーセンタイルをクリックすると、時間がかかっているエンドポイントを見つけることができます。たとえば、最も時間がかかっているエンドポイントを95パーセンタイルで特定するには、[95th] の列をクリックします。
他の実行との比較
[Test Run History] タブでは、現在のテスト実行を他の実行の結果とともに見ることができます。この表は、パフォーマンスの変動について調べるための出発点として便利です。
- 負荷の増加: 同時接続数を増やしながらアプリケーションのパフォーマンスを監視します。
- リグレッションの確認: アプリケーションに新しい変更が導入されたときにパフォーマンスを監視します。