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

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

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

要件収集アンケート

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

いいえ	話題	問
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を与えます! ハッピーロードテスト!