初めてのパフォーマンステスト

期待の定義からベースラインの確立まで

アプリケーションのパフォーマンスは品質全体の重要な部分を占めます。サイトが遅い場合や反応しない場合、ユーザーはサイトの背後にあるブランドや組織に対して悪い印象を持ち、アプリケーションの利用を完全に中止することにもなりかねません。パフォーマンステストを行うことで、アプリケーションを監視し、ユーザーエクスペリエンスの低下を防ぎ、トラフィックの繁忙期に備えることができます。

mablのパフォーマンステストでは、既存の機能テストを使用してアプリケーションへの負荷をシミュレートし、その出力を確認することで、アプリケーションがユーザーの期待に応えられるかどうかを見極めることができます。このチュートリアルでは、新規ユーザーの方々を対象に、mablのパフォーマンステストの基本事項について説明します。

📘

早期アクセスプログラム

現在、パフォーマンステストは、早期アクセスプログラムとして利用できます。パフォーマンステストの早期アクセスプログラムをご希望の場合は、こちらからお申し込みください。

本機能の一般提供開始後には、アクセスおよび価格が変更される可能性があります。パフォーマンステストは一般提供の前に予告なく変更されることがあります。

開始する前に

最初のパフォーマンステストを作成する前に、チーム内で以下の点について検討する必要があります。

  • どのテストをパフォーマンステストとして使用するか
  • 現在期待するパフォーマンスは何か

機能テストの選択

mablのパフォーマンステストでは、既存の機能テストを再利用します。パフォーマンステストを作成する前に、テストするAPIを検討する必要があります。

📘

APIテストのみ

現在、パフォーマンステストは、APIテストでのみ利用できます。

機能テストとしては、プリプロダクションまたはQA環境、あるいは開発環境のAPIを検証する機能テストを選択してください。本番環境にデプロイする前にAPIのパフォーマンステストを実施することで、問題を早期に見つけ出し、本番環境でのボトルネックや障害を回避することができます。

📘

プライベートネットワークでのテスト

APIをプライベート環境でテストする場合、許可リストにmablの静的IPアドレスを追加してください。パフォーマンステスト用のIP範囲は、34.31.138.224/27です。

パフォーマンステストでは、mabl Linkはまだサポートされていません。

期待の定義

期待するパフォーマンスは、アプリケーションによって異なります。mablのパフォーマンステストにおける期待は、失敗条件で定義します。

  • 期待するパフォーマンスがアプリケーションですでにサービスレベル目標 (SLO) などの形で明確に定義されている場合は、パフォーマンステストセットアップガイドで失敗条件のオプションの詳細を確認してください。
  • チーム内でアプリケーションに期待するパフォーマンスをまだ定義していない場合は、まず失敗条件なしでパフォーマンステストを実行し、アプリケーションのパフォーマンスを把握してください。

テストの作成

最初のテストを作成するには、次の手順を実行します。

  1. mablのホームページで、左側のナビゲーションにある [New test] ボタンをクリックします。
  2. [Performance test] を選択します。
  3. テスト名を指定します。

👍

命名規則とラベル

チームでは、ワークスペース内で練習用のテストとその他のテストを区別するのに使用できる命名規則とラベルについて話し合っておきます。以下のような例を検討してください。

  • 命名規則: 「ウォークスルー - パフォーマンステスト - 各自の名前」
  • ラベル: 「チュートリアル」、「ウォークスルー」、「練習用」は、練習用のテストを区別するのに適したラベルです。
  1. [+ API test] ボタンをクリックして、機能テストを追加します。最初のパフォーマンステストの場合は、範囲を1つまたは少数のテストに限定してください。
  2. ドロップダウンからテストを選択します。
  3. 同時接続数を設定します。同時接続数とは、仮想ユーザーの数を表します。
  4. テスト時間を設定します。テスト時間とは、パフォーマンステストの実行時間を表します。
  5. [Save] をクリックすると、テストが作成されます。

👍

小さく始める

最初のパフォーマンステストでは、同時接続数とテスト時間を「小さく」してください。たとえば、同時接続数を5ユーザー、テスト時間を15分に設定します。

一定の負荷条件でアプリケーションのパフォーマンスが把握できたら、以降のテストで同時接続数を徐々に増やします。

チーム内でパフォーマンスのSLOを定義していない場合、最初のパフォーマンステストでは失敗条件を省略することをお勧めします。アプリケーションのパフォーマンスを把握し、パフォーマンスのSLOについてチーム内で合意が形成されたら、それに基づいて失敗条件を設定します。

Setting up a performance test

パフォーマンステストのセットアップ

パフォーマンステストのセットアップの詳細については、こちらのガイドを参照してください。

テストの実行

新しいパフォーマンステストの詳細ページで、テストを実行するために次の手順を実行します。

  1. [Run test] ボタンをクリックします。
  2. アドホック実行パネルで、パフォーマンステストに関連するアプリケーションを選択します。
  3. [Start 1 run] をクリックします。

テストの実行が始まると、テストのステータスが [Start 1 run] ボタンの下に表示されます。ステータスをクリックして、パフォーマンステストの出力ページを表示します。

Triggering an ad hoc run of a performance test

パフォーマンステストのアドホック実行のトリガー

パフォーマンステストの実行の詳細については、こちらのガイドを参照してください。

出力の確認

パフォーマンステストのテスト出力は、次の2つのセクションで構成されています。

  • テスト実行中のパフォーマンステストの指標を示すチャート
  • 各指標の詳細を示す一連の表
Performance test output

パフォーマンステストの出力

アプリケーションのパフォーマンスを把握すると、これらの指標を基に失敗条件を判断し、パフォーマンスのリグレッションを見つけ出すことができます。パフォーマンステストの出力の確認の詳細については、こちらのガイドを参照してください。

次のステップ

最初のパフォーマンステストを作成して実行した後、結果をチームと共有し、次にとるべき最適なステップについて話し合います。次にとるべきステップには、以下のようなものがあります。

  • どの時点でAPIエンドポイントが失敗し始めるかを把握するために、同時接続数とテスト時間を増やす計画を立てる。
  • 期待するパフォーマンスをチームで定義する。これらの期待を基に失敗条件を設定する。

アプリケーションに期待するパフォーマンスのベースラインを決定しておくと、アプリケーションに新しい変更を加えるときにテストを開始し、変更を本番環境に移行する前にパフォーマンスのリグレッションを検出することができます。

パフォーマンステストの詳細については、こちらの概要を参照してください。