ロード テストの準備チェックリスト

ロード テストに関しては、”パフォーマンスの観点から、クライアントは アプリケーションとシステムで何をしたいのか” という数百万ドルの質問が常にあります。 私はあなたがその質問に対する簡単な答えを得ることは決してないだろうとかなり確信しています、そして私たちのほとんどは常にいくつかのことを仮定してパフォーマンステストを実行します、そしてそれはテストの重要な部分を見逃してしまい、不幸なクライアントに終わるかもしれません。 不幸なクライアントは、組織にとってビジネスの損失とパフォーマンスエンジニアとしてのキャリアの低下を意味します。 しかし、心配しないでください、この記事では、これらの質問に役立つチェックリストの作成について説明します。

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

要件収集アンケート

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

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

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

パフォーマンステスターは、最適なパフォーマンステストツールを慎重に選択する必要があります。 ツールを完成させて提案する前に考慮する必要がある多くの要因があります。 パフォーマンステストツールを選択する際には、クライアントの予算が常に主要な要因であることを忘れないでください。

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

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

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

• 適応性とスケーラビリティ。 複数のユーザーがアクセスしたときにサイトまたはアプリケーションの速度が低下する理由を特定する。
• インフラストラクチャ。 必要なハードウェアのアップグレード (ある場合) を理解する。 追加のハードウェアを実装して維持するコストは、リソースの浪費になる可能性があります。
• パフォーマンス要件。 サイトまたはアプリケーションは少数のユーザーを適切に処理できますが、実際の状況ではどうなりますか?
• 第三者のサービス。 外部サービスが通常の負荷状態またはピーク時の負荷状態を提示したときにどのように動作するかを確認します。

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

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

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

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

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

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

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

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

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

• アプリケーションを操作するユーザーの総数は、営業時間あたりの平均数を想定して何人ですか?
• ユーザーはどのようなアクションを実行し、どのくらいの頻度で実行しますか?
• 負荷のピーク時に何人のユーザーがアプリケーションを操作していますか?

上記の質問に対する回答は、要件収集アンケートまたは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 パーセンタイル値より高くなります。 これは、リクエストの一部に膨大な応答時間があり、平均応答時間の結果を歪めている場合に便利です。

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

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

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

エラー率: 合格/エラートランザクション比率を追跡する必要があります。 エラー率は、成功したトランザクションの 2% を超えてはなりません。 同時ユーザーの増加に伴いエラー率が増加している場合は、潜在的なボトルネックが存在する可能性があります。

同時ユーザー数: この値は、APMツールから、または本番ログを使用して見つける必要があります。 通常、この値は通常の営業日に基づいて見つかります。

スループット： スループットは、同時ユーザーを処理するためのサーバー容量を示します。 同時ユーザーとスループットの間には直接的な関係があります。 アプリケーションにアクセスするユーザー数が増えるにつれて、スループットが増加するはずです。 ユーザー数の増加に伴ってスループットが低下している場合は、ボトルネックを示している可能性があります。

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

これらは、ワークロード モデルを設計する際に留意する必要がある非常に重要なメトリックです。 他のメトリックがあり、クライアント アプリケーションのアーキテクチャと要件によって異なります。

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

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

結論: ロード テスト準備チェックリスト

ソフトウェアパフォーマンステストの成功は偶然ではありません。 アーキテクト、プロダクト所有者、開発者、およびパフォーマンス テスト チームは、ソフトウェアを評価する前に協力してパフォーマンス テスト要件に対処する必要があります。 LoadView プラットフォームの詳細な背景については、 技術概要 に関する記事を参照して、パフォーマンス テストを最大限に活用する方法を確認してください。 パフォーマンス テストは継続的なプロセスである必要があります。 Webサイトまたは ウェブ アプリケーションが成長し始めたら、より大きなユーザーベースに対応するために変更を加える必要があります。 アプリケーションやテストでは常に改善の可能性があります。

これにより、パフォーマンス テストのベスト プラクティスに関する優れた分析情報が得られることを願っています。 LoadView ソリューションの完全なデモンストレーションが必要な場合は、パフォーマンス エンジニアによる デモにサインアップ してください。 ロード テスト スクリプトやテスト構成の作成から、テストの実行や結果分析まで、プロセスの各部分を段階的に説明します。

または、 LoadView 無料試用版 にサインアップして、今すぐロード テストの実行を開始してください。 開始するための無料のロードテストを提供します! ハッピーロードテスト!