はじめに
PostmanのAPIパフォーマンステストは2023年6月にベータリリース（＊）されました。この機能により、Postmanのコレクションに登録されているAPI群に対して、手軽にクライアントから負荷をかけ、APIのパフォーマンスや性能問題などの確認ができるようになりました。PostmanでAPI開発しながら素早くサクッとAPIの性能フィードバックが得られることがこの機能の魅力です。
本記事ではその使い方、注意点・制限などについて簡単にご紹介します。
ベータリリースについて
本記事の執筆・最終更新時点でPostmanパフォーマンステスト機能はベータリリースのステータスとなっており、Postman無料、Basic、Professionalプランでのみ利用可能となっているのでご注意ください。料金プランについて詳しくはこちら
Postman APIパフォーマンステストを使ってみる
事前準備
APIパフォーマンステストは、2023年6月時点でPostmanデスクトップアプリからのみ利用可能です。まだインストールしていない方はこちらよりダウンロードしてください。
次に、機能紹介で利用するサンプルAPIを用意します。ここではPublished Postman TemplatesというワークスペースにあるPostman Echo APIコレクションをForkして利用します。キーワードPublished Postman Templatesでワークスペース検索すれば見つかります。その中のPostman Echoを自分のワークスペースにForkしてください。これで準備完了です。
コレクションAPIに対してパフォーマンステストを実行する
ここではPostman EchoコレクションのRequest MethodフォルダのAPIを利用します。次のように、サイドバーにあるPostman EchoコレクションのRequest Methodフォルダを選択してください。そして、右側にあるコレクションOverviewタブにあるRunアイコンをクリックしてください。
次のようなコレクションRunnerタブが開きます。なお、PostmanフッターにあるRunnerを選択しても同じタブが開きます。RunnerタブではPerformanceを選択してください。
NOTE: Run Orderについて。パフォーマンステストでは上図のコレクションRunnerに設定されているRun Orderの順番でリクエストが実行されます。この順番はツール上から変更できます。
Performanceタブで、Virtual Users(仮想ユーザー数)、Test Duration(テスト実行時間、分単位)、Load Profile(負荷プロファイル)、Data file(データセット用ファイル)の指定ができます。
-
Load Profile(デフォルトはFix): 負荷のかけ方のパターンを指定でき、Fixed(固定)、Ramp up(徐々に負荷を上げる)、Spike(スパイク発生)、Peak(徐々に負荷を上げて徐々に下げる)の４つの中から選ぶことができます -
Data file(オプショナル): パフォーマンステストで、使用するデータセットを含むCSVまたはJSON形式のファイルを選択します。このファイルを指定してパフォーマンステストを実行すると、各仮想ユーザーはそのデータセットを元にコレクションのリクエストの変数を設定します。
ここでは、下記のように仮想ユーザー数20、実行時間2分で、１分間のRamp up、つまり１分かけて徐々に仮想ユーザー数を指定した数まで上げていく方式を指定します。Runボタンをクリックしてテストを開始します。
Load Profileの種類と設定画面
上述の通り、Load Profileでは全部で４種類ある負荷のかけ方のパターンを指定できます。それぞれのパターンの設定画面は以下の通りです。
Fixed (固定の負荷)
Ramp up (徐々に負荷を上げる)
Spike (スパイク発生)
Peak (徐々に負荷を上げて徐々に下げる)
リアルタイムで負荷シュミレーション結果の表示
テストが開始されるとSummaryタブにてリアルタイムで負荷のシュミレーション結果が表示されます。
上のイメージではレスポンス時間のメトリクス（青線）を平均時間で表示させてますが、平均以外にもMax、Min、90、95、99%thでの表示が可能です。また、マウスでホバーさせるとその時間のリクエスト詳細が表示されます。
Errorsタブを選択すると、発生したエラーのステータスと時間が確認できます。今回のテストでは単発で502 Bad Gatewayエラーが発生しただけなのであまり参考にはなりませんが、エラーが大量に発生する場合は、次のようにエラー時間やトレンドなどが確認できトラブルシュート時に有益な情報になるかと思います。
ref: Testing API performance: Viewing error trends
過去のテスト結果を見る
コレクションの過去のテスト実行結果はコレクションのRunsタブで確認できます。パフォーマンステスト結果の場合は、次のようにコレクションを開いて、Runsタブ選択 → Performanceタブ選択で確認できます。
注意点・制約など
利用可能プラットフォーム
上述のとおりAPIパフォーマンステストはPostmanデスクトップアプリからのみ利用可能です。Webブラウザ版やCLIからは利用できません。
利用可能プラン
パフォーマンステスト機能は、Free、Basic、またはProfessionalプランでのみ利用可能です。
仮想ユーザー数とシステムリソースについて
Postmanプランごとに使用できる仮想ユーザー数に制限があるので注意が必要です。無料プランの場合は最大100まで、それ以上の仮想ユーザー数は有料プランへアップグレードすることで設定できます。参考記事: Test your API’s performance by simulating real-world traffic with Postman
また、パフォーマンステストでシュミレーションできる仮想ユーザー数は、実行するクライアントマシンのシステムリソース（CPU、メモリ）やテストで使用するコレクションに依存します。コレクションでpre-requestやtest scripts機能を利用しているとシミュレーションできる仮想ユーザーの数が減るようです。詳しくはこちらの説明を参照ください。
さいごに
APIパフォーマンステストは大規模なピークシナリオをテストするための機能ではありません。冒頭の繰り返しになりますが、API開発しながら素早くサクッとAPIの性能フィードバックが得られることができます。これがこの機能の最大の魅力だと思ってます。
みなさんはシステムの信頼性をあげるために日々さまざまなテストを実施しているとおもいますが、パフォーマンステストは中でも割りと手間のかかる部類であり、ソフトウェアライフサイクルにおける比較的後ろのフェーズで実施されがちではないかと思います。ツールやその設定、実行環境などさまざまな準備を要するし、結局リリース前には負荷試験は実施するからそこでまとめてやればよいだろうという意識もあるかもしれません。少なくとも私の場合はそうでした。
しかし、もしリリース直前の負荷試験でパフォーマンス問題が発覚したらどうでしょう？しかも、アーキテクチャやデータ構造の変更を迫られるようなものだとするとそのダメージは大きいですよね？
そのような事態を避けるためには、比較的早い段階でパフォーマンステストが実施されていることが理想です。本番環境に依存する問題だったりエッジケースで発覚するような比較的レアな問題はあるものの、大部分は開発環境やスモールセットの環境テストで潰せる可能性があります。また、テストは手軽にかつ小刻みに実施できるのが理想です。変更のたびに小刻みに実施することで大きな手戻りのリスクも減らせます。APIパフォーマンステストがフィットするのはまさにそこです。
FAQ
Q: パフォーマンステストのリクエスト実行箇所はクライアントからのみ？
A: Yes。お使いのPostmanデスクトップアプリ（クライアントインスタンス）からのみの実行になります。サーバー（Postamnクラウド）からの実行モードはサポートされていません（本記事最終更新時点）。
Q: パフォーマンステストではpre-requests/post-responseスクリプトの失敗は検知される？
A: 検知しません。スクリプトそのものは実行されているものの、pre-requests/post-responseスクリプトの失敗は検知しません。また、テスト(pm.test)の成功/失敗も検知しません。当然ながらUI上でも表示されないし、console.logにのログがでません。