性能負荷テストの進め方～実施・評価編～

Last updated at 2025-12-23Posted at 2025-12-23

概要

以前書いた、性能テストの進め方に対する記事の続きです。今回は実施と評価について書いていきます。
性能負荷テストの進め方　～準備編～

前回は続きを書くまでに4年たっていましたが、今回は1年ですみました。えらい。

性能負荷テストの進め方に関する記事は今回で最終回となる予定です。

ここまでに計画・準備してきた内容に従ってテストケースを実施し、その結果を評価していきます。
具体的には以下を実施することになります。

それぞれ詳細に見ていきます。

ここは特に難しくないですね。準備したデータを環境へ投入するだけです。
データ量の多さゆえに投入手段によっては時間がかかるため、できればテスト実施日の前日までに済ませておくのがベターです。
準備で実施する疎通確認の中で済ませておけるとスムーズです。

ここが重要です。計画で定めた合格条件を満たすかどうか評価するためにもサーバリソースの取得は必須です。
折角性能テストを実施しても、サーバリソースが取得できていなければやり直しになってしまいます。

今はクラウドの機能で簡単に取得できることがほとんどだと思いますが、ちゃんと取得できる状態かどうか実施前に確認しておくと安心して性能テストが実施できると思います。

コンテナではなくサーバを立ててその上にアプリを構築する場合はvmstat等の監視コマンドを使うようにしましょう。テスト実施前に実行し忘れないよう注意が必要です。（n敗）

性能テストでは評価に使わないサーバリソースやログの取得も大事になってきます。
というのも、性能テストではシステムに高い負荷がかかるため、各種リソースの枯渇や、DBアクセスの競合など、普通の機能テストでは発生しないような不具合が発生します。

そういった不具合はアプリのログだけでは解析できないことがあります。
不具合が起きたけど解析に必要な情報が足りない、といったことにならないよう、できる限り多くの情報を取得するようにしておくのがベターです。

以下に解析で見ることになるサーバリソースやログの例を示します。

ここまで来たらようやくテストシナリオの実施です。
負荷ツールを実行し、テストケースを消化します。
この時、各種情報の取得がうまくいっているか見ておくと安全です。

シナリオ実行結果を確認し、想定通りの実行結果であることを確認します。
ケース実施用のシナリオだけでなく、負荷用のシナリオについても実行結果を確認するようにしましょう。
基本的には以下を確認することになると思います。どれも基本的な負荷ツールの機能で見れるはずです。

シナリオの実行結果に問題がなくてもまだ性能テスト合格とはなりません。
サーバリソースやアプリのログについて、例えば以下の確認が必要です

ここまで確認して問題がなければ晴れて性能テスト合格となります。

ここまでの確認で問題があれば性能テスト不具合として対応していきます。
性能テストの不具合は複雑なものが多く、情報を総合的に分析しながら原因を特定していくことになります。

アプリだけに限らず、各種クラウドサービスやミドルウェアの設定もチューニングしながら対応を進めていきます。
環境の作り直しなど内容次第では時間がかかるため、性能テストの中断も視野に入れて判断します。

全部合わせると６年もかかってしまいましたが、これにて完結です。
色々と古い部分もあるかもしれませんが、少しでも参考になれば幸いです。