負荷テストに関しては、「パフォーマンスの面では、クライアントはアプリケーションとシステムで何をしたいですか?」 私はあなたがその質問に簡単な答えを得ることは決してないと確信しています、そして私たちのほとんどは常にいくつかのことを仮定し、パフォーマンステストを実行し、テストの重要な部分を見逃し、不幸なクライアントで終わるかもしれません。 不幸なクライアントとは、組織に対するビジネスの喪失と、パフォーマンスエンジニアとしてのキャリアの低下を意味します。 しかし、この記事では、これらの質問に役立つチェックリストを作成することについて話します。

このチェックリストは、パフォーマンス テストのライフ サイクルに従って適応できるステップ バイ ステップのプロセスに似ています。 説明したシナリオでは、最初は正確なパフォーマンス結果が何を望むのか分からないかもしれませんが、異なる条件下でアプリケーションがどのように機能するのかについて明確な知識を持っているので、クライアントを常に責めることはできません。 優れたパフォーマンス テストは、明確に定義されたアンケートでこのあいまいさを管理できます。 そして、それはチェックリストの最初の項目、要件収集アンケートです。

要件収集アンケート

以下は、プロジェクトでフォローできるアンケート形式です。 これらの質問に対してできるだけ多くの回答を得る必要があります。 これらの質問について話し合う電話があれば、もっと良いでしょう。 アプリケーション設計者または開発者が、ユーザーとクライアントとの通話に参加していることを確認します。 追加の担当者を持つことは、洞察を提供し、これまで考慮しなかった質問を明らかにするのに役立ちます。 以下の質問は、より効率的で効果的なロード テストを作成するためのロードマップを提供します。

いいえ 話題
1 アプリケーション テスト対象とするアプリケーションの種類 (ウェブ アプリケーション/モバイル アプリケーションなど)。
2 アプリケーションアーキテクチャとテクノロジー/プラットフォーム。
3 使用される負荷分散技術。
4 クライアントとサーバー間の通信プロトコル (例: HTTP/S、FTP)。
5 パフォーマンス テストの目的。 監視対象のパフォーマンスメトリック (各アクションの応答時間、同時ユーザー数など)。
6 パフォーマンス テストに考慮する重要なシナリオ。
7 バックグラウンドでスケジュールされたジョブ/プロセスの詳細 (存在する場合)。
8 セッション管理に使用される技法と、サポートされる並列セッションの数。
9 お客様の SLA/要件 予想される同時ユーザー数と合計ユーザー数。 スコープ内のシナリオのユーザー配布。
10 PT のスコープ内のすべてのトランザクションに対する SLA (予想されるスループット、応答時間など)。
11 実行するパフォーマンス テストの種類 (ロード テスト、耐久テストなど)。
12 システム/環境 テスト環境の詳細(ウェブ/アプリ/DB、ノード数など) パフォーマンス テストの実行に推奨される運用環境に似ています。
13 本番環境とパフォーマンステスト環境の比較
14 他のアプリケーションとの対話を避けるために、パフォーマンス テストの実行中にアプリケーションを分離するかどうか。
15 組み込みのログメカニズムまたは監視メカニズムの詳細。
16 余人 アプリケーション パフォーマンスベースラインの結果。
17 現在のパフォーマンスの問題 (存在する場合)。

これらの質問に対する回答は、品質テスト戦略/テスト計画を作成するのに役立ちます。 クライアントがこれらすべての質問に対する回答を提供できない場合は、心配する必要はありません。 私たちは常にテストの下でアプリケーションを探索し、答えを見つけることができます。 たとえば、APM/log ツールが配置されている場合、運用システムから同時ユーザー、スループット、および応答時間を導き出すことができます。 あなたが尋ねることなく、あなたが必要なものを得ることを想定しないでください。

適切なパフォーマンス テスト ツールを見つける

パフォーマンス テストの場合は、最適なパフォーマンス テスト ツールを慎重に選択する必要があります。 このツールを完成して提案する前に考慮する必要がある要素はたくさんあります。 パフォーマンス テスト ツールを選択する際は、クライアントの予算が常に主要な要素であることを覚えておいてください。

コスト効率が高く、使いやすく、完全なパフォーマンスソリューションを提供できるパフォーマンステストツールを探しているなら 、LoadViewを試してみてください。 LoadView は、従来のロード テスト ツールと比較して、コストのかかる投資、時間のかかるセットアップ、またはスクリプト フレームワークに関する以前の知識を必要としません。 さらに、プラットフォームは、スピンアップロードインジェクタに20以上のグローバルな場所を提供するので、各テスト中に複数の場所からパフォーマンスをテストして測定できます。

すべての種類のパフォーマンス テストには時間と労力が必要です。 負荷テストを実行すると、潜在的な屈辱から組織を救うことができますが、JMeterのような無料のオープンソースツールでの同時テストは投資を正当化しません。 エンド ユーザーの観点から ウェブ サイトやアプリケーションのパフォーマンスを真に理解する場合、プロトコル ベースのテストでは十分ではありません。 また、クライアント側の対話と手順のパフォーマンスを測定する必要もあります。 ここでは、 他のパフォーマンス/ロード テスト ソリューションとの LoadView の比較 と、パフォーマンス テスト要件に対して LoadView を選択する必要がある理由を示します。

サイトやアプリケーションの読み込みが遅い場合、顧客はすぐにせっかちになり、サイト/アプリケーションが期待に応えなければ代替品を見つけることができます。 さまざまな理由でサイトやアプリケーションがどの程度処理できるかを知ることは非常に重要ですが、LoadView プラットフォームが支援できるいくつかの重要なシナリオがあります。

  • 適応性とスケーラビリティ: 複数のユーザーがサイトまたはアプリケーションにアクセスしたときに、サイトまたはアプリケーションの速度が低下する原因を特定する。
  • インフラ。 必要なハードウェアアップグレードを理解する 追加のハードウェアを実装し、それを維持するためのコストは、リソースの潜在的な無駄になる可能性があります。
  • パフォーマンス要件: サイトやアプリケーションは少数のユーザーを適切に処理できますが、実際の状況では何が起こりますか。
  • サードパーティサービス: 通常の、またはピーク時の負荷条件が表示されたときの外部サービスの動作を確認します。

パフォーマンス テスト計画/戦略

クライアント要件を収集し、適切なパフォーマンス テスト ツールを選択したら、テスト計画/テスト戦略を文書化する必要があります。 パフォーマンス アクティビティを開始する前に、クライアントからテスト計画のサインオフを取得してください。 これは非常に重要であり、後で不要な不具合を避けるのに役立ちます。 これらは、テスト計画に含める必要があるいくつかのポイントです。

  • パフォーマンス テストの目標: 私たちが達成しようとしていること。
  • プロジェクト スコープ: プロジェクトのスコープは何ですか、例:スクリプトの数、テストに必要な時間など
  • アプリケーション アーキテクチャ: アプリケーションの詳細なアプリサーバー、DBサーバー、建築図があれば含めることができます。
  • 環境の詳細: テストする環境の詳細。 パフォーマンス テスト用に分離された環境を持つことは常に良いことです。
  • インフラストラクチャのセットアップ: パフォーマンス テストの初期セットアップ (クラウド環境、ツールのインストールなど)。
  • パフォーマンス テスト アプローチ: どのようにテストを実行するつもりです。 少ないユーザー数のベースラインテストから始め、徐々にユーザーを増やし、ストレス、持久力などの異なるタイプのテストを実行できます。
  • 入退出条件: これは非常に重要です。 機能上の欠陥がゼロの場合は、常にパフォーマンステストを開始する必要があります。 パフォーマンス テストを停止できる場合と同じ方法で文書化します。
  • 欠陥管理. パフォーマンス テストに関連する不具合をログに記録するために、クライアントが同じツールとプラクティスに従う必要があります。
  • 役割と責任: パフォーマンステスト中のさまざまなアクティビティに関与するステークホルダーに関する詳細。
  • 前提とリスク: パフォーマンス テストのリスクとなる可能性のある目標がある場合は、それを文書化する必要があります。
  • テスト データ戦略: テスト データ戦略の詳細と、それを抽出する方法について説明します。
  • テスト計画のタイムラインと主要成果物. クライアントレビューのためのスクリプト作成、テスト実行、分析、および成果物のタイムライン。

実際のパフォーマンス テストは、手法の組み合わせに依存します。 期待される目標を達成するためには、さまざまなパフォーマンス テスト要件に対して別の戦略を準備する必要があります。 ユーザーロード、同時ユーザー、ワークロードモデルなど、負荷を計画する前に考慮する必要があるさまざまなメトリックがあります。 以前にワークロードモデリングに取り組んだのであれば、 リトルの法則について聞いたことがあるだろう。 必要な結果を得るためにテストを計画する前に、それを学習し、実装する必要があります。

リアルタイムパフォーマンススクリプト/シナリオ

パフォーマンス計画/戦略についてクライアントと合意したら、合意されたパフォーマンス テスト ツールを使用してスクリプト作成の準備を開始する必要があります。

次の箇条書きの項目は、品質の高いスクリプトを作成するために覚えておく必要がある点の一部です。

  • スクリプトを実行する際は、必ず文書化されたテスト ケースの手順に従ってください。
  • 1 人のユーザーに対して、リプレイを行い、相関要件を修正します。
  • 1 人のユーザーに対して、再生を行い、パラメータ化の要件を修正します。 パラメータ化は、ヘッダー、クッキー、および本文パラメータの任意の場所に指定できます。
  • スクリプトが単一のユーザー データで正常に実行されたら、異なるユーザーで複数の反復処理を実行します。 異なるユーザーデータに対して追加の相関/パラメータ化が必要になる場合があります。
  • 場合によっては、特定のユースケースを実現するために、コードブロックを記述する必要があります。 たとえば、ユーザーの特定の応答データを選択し、別の要求に対してそれを操作します。
  • ワークロード モデルに従って、スクリプトの待ち時間、ペース、エラー処理を追加します。
  • テキストチェック/画像チェックもスクリプトの非常に重要なステップです。

上記の手順に加えて、キャッシュ/クッキーのシミュレーションとネットワーク条件の要件があります。 優れたパフォーマンスエンジニアは、実行を開始する前に、これらすべての要因を考慮する必要があります。 また、パフォーマンス テスト エンジニアは、仮想ユーザーの行動の最も現実的なパターンを開発する必要があります。 これを行うには、要件収集アンケートを通じて正しい回答を得ることは重要です。

  • 営業時間ごとの平均数を想定して、アプリケーションを操作するユーザーの合計数を指定します。
  • ユーザーはどのような操作を実行し、どのくらいの頻度で実行しますか。
  • 負荷がピークに達している間にアプリケーションを使用しているユーザーの数

上記の質問に対する回答は、要件収集アンケートまたはAPMツールやGoogleアナリティクスなどのウェブ分析ツールを使用して収集された統計データを通じて得られます。 トランザクション分析により、重要なビジネス・トランザクションを見つけ、パフォーマンス・テストの実行に使用されるパフォーマンス・テスト・シナリオの設計が可能になります。

ワークロードモデリング

ワークロードモデルは、さまざまな方法で計画できます。 パフォーマンスエンジニアは、ワークロードモデルを選択する前に、「リトルの法則」の概念を学び、実践する必要があります。 既存のワークロード モデルの一部を次に示します。 ここでも、パフォーマンス エンジニアは、手持ちの要件に基づいてワークロード モデルを選択する必要があります。

ワークロード モデル 1. これは単純なモデルで、テストの進行状況に合ったユーザー数が継続的に増加します。 例: テストが完了するまで 1 秒あたり 1 人。

ワークロード モデル 2. このモデルでは、テストの全期間のステップのようにユーザー数が増加します。 たとえば、最初の 15 分は 100 ユーザー、次の 15 分は 200 などになります。 この種のテストは、持久力テスト用に計画できます。

ワークロード モデル 3. これは、最も一般的なパフォーマンス テスト モデルです。 ユーザー数は一定時間継続的に増加します(これをランプアップ期間と呼びます)。 その後、ユーザーは一定期間安定した状態になります。 その後、ユーザーはランプダウンを開始し、テストが終了します。 たとえば、1.5 時間のテストを計画している場合、ユーザーを増やすのに 15 分、ランプダウンに 15 分を提供できます。 定常状態は 1 時間になります。 結果を分析する際には、検討のために安定した状態のみを取ります。

ワークロード モデル 4. このモデルでは、ユーザー数が増加し、全体の期間で突然減少します。 このタイプのテストには、猿のテスト、スパイクテストなど、さまざまな名前があります。

パフォーマンス テストの包括的な目標と要件を確立する必要があります。 パフォーマンス テスト パラメーターと、各パラメーターの受け入れ条件を構成するパラメーターを定義します。 テスト要件も目的の結果もわからない場合、パフォーマンス テストは時間の無駄です。

データの収集

以下は、パフォーマンス ワークロードのモデル化中に観察する非常に重要なメトリックの一部です。

応答時間: 応答時間は、サーバーがクライアント要求に応答するのに要した時間です。 サーバーの応答時間に影響を与える要因はたくさんあります。 ロード テストは、応答時間を低下させている要因を見つけて排除するのに役立ちます。

平均応答時間: これは、ロード テストでの定常状態の期間全体の応答時間の平均値になります。

90 パーセンタイル応答時間: 90 パーセンタイル応答時間は、応答時間の 90% がその値を下回っていることを意味します。 たとえば、500 件の要求があり、それぞれ応答時間が異なる場合、90 パーセンタイルは、他のすべての値の 90% が百分位数の 90 未満である任意の値になります。 応答時間の 10% だけが 90 パーセンタイル値より大きくなります。 これは、要求の一部に応答時間が膨大で、平均応答時間の結果が歪んでいる場合に便利です。

1 秒あたりの要求数: この値は、APM ツールまたは運用ログの助けを借りて見つける必要があります。 同時ユーザーに基づいて、1 秒あたりのサーバーへの要求を計画できます。

メモリ使用率: これらは、ボトルネックを発見するのに役立つインフラストラクチャ側のメトリックです。 また、ワークロードを可能な限りリアルタイムに計画する必要があります。 継続的な要求でサーバーを砲撃していないことを確認してください。

CPU 使用率: メモリと同じで、パフォーマンス テストの実行中にこのメトリックを確認する必要があります。

エラー率: 渡された/エラーのトランザクション比率を追跡する必要があります。 エラー率は、渡されたトランザクションの 2% を超える値にすることはできません。 同時ユーザー数が増加するにつれてエラー率が増加している場合は、ボトルネックが発生する可能性があります。

同時ユーザー数: この値は、APM ツールまたは運用ログの助けを借りて見つける必要があります。 通常、この値は一般的な営業日に基づいて見つかります。

スループット: スループットは、同時ユーザーを処理するサーバーの容量を示します。 同時ユーザーとスループットの間には直接接続があります。 アプリケーションにアクセスするユーザー数が増加するにつれて、スループットが向上するはずです。 ユーザー数が増えるにつれてスループットが低下している場合は、ボトルネックが起こり得る可能性があります。

ユーザー負荷分布: ユーザー負荷分散は、ワークロードの設計時に考慮する必要がある重要な要素の 1 つです。 アプリケーションの 5 つの異なる機能を実行する 5 つのスクリプトがある場合は、実稼働または APM ツールに関する調査に基づいて、ユーザー負荷を可能な限り実際に分割する必要があります。

これらは、ワークロード モデルの設計時に留意すべき非常に重要なメトリックです。 クライアント アプリケーションのアーキテクチャと要件に応じて、他のメトリックもあります。

パフォーマンス テスト環境のチェックリスト (実行前)

以下のチェックリストの例は、通常、エンタープライズ レベルのエンド ツー エンドパフォーマンス テストが続き、膨大な数のシステムが含まれています。 小規模なパフォーマンス テストの環境チェックリストにも従うことをお勧めします。 アクティビティは、オンプレミスのクラウド上のアプリケーションとアプリケーションを比較すると大きな違いがあるので、アプリケーション環境に基づいて変化します。

パフォーマンス テスト チェックリスト

結論: 負荷テスト準備チェックリスト

ソフトウェアパフォーマンステストが成功しても、偶然に行われるわけではありません。 ソフトウェアを評価する前に、設計者、製品所有者、開発者、およびパフォーマンス テスト チームが協力して、パフォーマンス テスト要件に対処する必要があります。 LoadView プラットフォームの詳細な背景については、 テクニカル概要 の記事を読んで、パフォーマンス テストを最大限に活用する方法をご覧ください。 パフォーマンス テストは継続的なプロセスである必要があります。 ウェブ サイトや ウェブ アプリケーションが成長し始めたら、より大きなユーザーベースに対応するために変更を加える必要があります。 アプリケーションやテストでは、常に改善のチャンスがあります。

パフォーマンス テストのベスト プラクティスについて、この情報が得られたことを期待しています。 LoadViewソリューションの完全なデモンストレーションをご覧になる場合は、パフォーマンスエンジニアとデモ にサインアップ してください。 ロード テスト スクリプトとテスト構成の作成からテスト実行と結果の分析まで、プロセスの各部分をステップバイステップで実行します。

LoadView 無料試用 版にサインアップして、今すぐロード テストの実行を開始します。 私たちは始めるために無料のロードテストクレジットであなたに$ 20を与えます! ハッピーロードテスト!