パフォーマンステストの作成

まず、左側のナビゲーションの テスト作成 ボタンをクリックし、[Performance test] を選択します。

テスト詳細の設定

テストには必ず名前が必要です。また、テストに説明やラベルを追加することもできます。

👍

テストの命名規則、テストの説明、ラベル

ベストプラクティスとして、事前にワークスペースの他のメンバーと相談して、テストの命名規則を決めておくことをお勧めします。そうすることで、テストの検索が容易にになり、かつ、テストの内容を理解しやすくなります。

テストの説明とラベルは省略することもできますが、ワークスペースをわかりやすく体系化するうえで大いに役立つため、テストには説明とラベルを指定することを強くお勧めします。

機能テストの追加

パフォーマンステストで実行する機能テストを、1つ以上選択します。

DataTable

機能テストをパフォーマンステストとしても実行する場合、パフォーマンステストでどのDataTableをテストに紐付けるかを指定します。

📘

注

1つ以上のDataTableに関連付けられたテストを追加した場合、mablはデフォルトでこれらのDataTableシナリオをパフォーマンステストで実行します。テストのデフォルトのDataTable設定をオーバーライドするには、[Data tables] をクリックし、別のDataTableを選択します。

パフォーマンステストでDataTableを使用する場合、各行(シナリオ)はそれぞれ異なる仮想ユーザに割り当てられます。DataTableのテーブルの行数よりも仮想ユーザの数が多い場合は、複数の仮想ユーザが行を繰り返し使用します。

👍

パフォーマンステストと DataTable

同時実行ユーザーを含むシナリオをシミュレートする場合、多数のクレデンシャルを含むDataTableをパフォーマンステストに関連付けることが大変効果的です。

複数のクレデンシャルの組み合わせを使うことで、テスト対象アプリケーション、サーバOS、またはテスト対象アプリケーションのデータベースなどで、1ユーザの同時接続数に関する制限を回避することができます。

負荷設定

負荷をかけるために。同時接続数を設定します。パフォーマンステストでは、同時接続数は、テストを同時に繰り返し実行する仮想ユーザーの数を表します。各ユーザーは、テストの制限時間に達するまで、何度でもテストを実行します。

🚧

ご注意

すべての機能テストにおける同時接続ユーザの合計が1000を超えることはできません。

失敗基準

機能テストの失敗率や、ブラウザーとAPIの特定のパフォーマンスメトリックに基づいて、テストの成功/失敗が決まるように設定できます。

アプリケーションのベースラインパフォーマンスがまだ調査中の場合は、チームが期待を定義できるまで、失敗基準なしでテストを実行できます。詳細については、初めてのパフォーマンステストを参照してください。

失敗基準は、チームのパフォーマンス要件に応じて決まります。以下の例を考えてみましょう。

• 設定した同時実行数で95%のテストが成功するようにしたい場合は、5%超のテストが失敗した場合に失敗となるように機能テスト失敗率を設定できます。
• ページの認識された読み込み速度を監視する場合、アプリケーションのLCP (Largest Contentful Paint) が "Poor" しきい値を超えた場合にテストが失敗するように条件を設定できます。
• 指定した同時実行数でのAPIレスポンスタイムが300ミリ秒未満に収まることを期待している場合は、95パーセンタイルのレスポンスタイムが300ミリ秒を上回った場合にテストが失敗する条件を設定できます。

失敗基準の設定に使用できるパフォーマンスメトリックの詳細については、こちらをクリックしてください。

テスト設定

関連するテスト設定に、Duration of test (テストの実行時間) と Ramp-up time (ユーザ数増加時間) があります。

• テストの実行時間: パフォーマンステストの実行時間 (最大60分) を設定します。
• ユーザ数増加時間：パフォーマンステストの仮想ユーザ数を、0から設定された同時接続数まで、直線的に増加させるのにどれだけの時間をかけるかを設定します。設定された同時接続数に達した後の残りの時間の間、パフォーマンステストは設定された同時接続数で継続されます。

テストを作成する

[Create Test] ボタンをクリックして、パフォーマンステストを作成します。