すべてのロード テストが同じではない
従来、ロード テストを考えるとき、完全に内部テストを意味します。 サイトまたはアプリケーションで多数の仮想ユーザーを送信し、その動作を確認します。 しかし、すべてがファイアウォールの背後で起こります。 呼び出しは家の中から来ています。
内部ロード テストでは、アプリケーションまたはサイトがトラフィックの増加にどの程度適切に処理するかを確認できます。 しかし、それは現実世界の状況を反映していません。 内部テストでは、環境全体を制御します。 運用環境は制御以外の何物でしかありません。 ユーザーは、さまざまな接続速度を扱いながら、さまざまなブラウザーやオペレーティング システムを使用して、さまざまな場所からサイトにアクセスします。
つまり、内部ロード テストのみを実行すると、運用環境に入ると厄介な驚きが発生する可能性があります。 これは、内部負荷テストが役に立たないというわけではありませんが、不完全です。
外部ロード テストを実行すると、ロード テストの精度が大幅に高くなります。
基本的な外部ロード テストの実行
予算と時間が少ない場合は、迅速かつ汚いオプションがあります。 無料のオンラインWebサイトのパフォーマンスツールを使用すると、世界中のサーバーからあなたのサイトにトラフィックを送信することができます。
このようなツールは、1 つの URL にトラフィックを送信することしかでき、完全なロード テストに必要な大量のトラフィックをシミュレートしません。 しかし、さまざまなプラットフォームを使用して世界中の特定の地域からアクセスしたときに、サイトやアプリケーションの読み込みに時間がかかりすぎるかどうかを知ることができます。 サイトが特定の Web ブラウザーでうまく機能しないことを発見すると、本番環境に移行する前に重大な問題を解決できます。
完全外部ロード テストの実行 
機能テストからテスト スクリプトを多数作成し、ロード テストに再利用できるとします。 また、最も忙しい日に予想されるユーザー数を知り、それよりもさらに重いトラフィックのテストをロードするのに十分賢いと仮定しましょう。
今必要なのは外部 負荷テストツールです。 これらのツールは、クラウドベースのサーバーを使用して、世界中のウェブサイトやアプリケーションに仮想トラフィックを送信したり、ターゲット顧客が居住する地域から仮想トラフィックを送信したりします。
LoadView のようなツールを使用すると、包括的な外部ロード テストを実行できます。 テストスクリプトを記録する 、顧客が使用するプラットフォームとブラウザを指定し (モバイルを忘れないでください!)、仮想訪問者の発信元となる世界の領域を選択します。 LoadViewなどのクラウドベースの SaaS ソリューションでは、使用するサーバー時間に対してのみお支払いください。 テストに存在する仮想ユーザーが多いほど、テストのコストが高くなります。
仮想トラフィックを軽視して数ドルを節約しないでください。 ブラックフライデーのような主要なショッピングの日にサイトが大幅に減速した場合、外部ロードテストは失われた収益や悪い宣伝よりも費用がかかります。
外部負荷テストを実行する頻度
外部ロード テストは、サーバーと接続速度だけではありません。 新しいコードは、エラーの雪崩を引き起こし、すべてが遅くなる可能性があります。 ベスト プラクティスには、更新またはリリースごとに外部負荷テストを実行する方法が含まれます。 少なくとも、ブラックフライデーからサイバーマンデーなど、大きな交通日の数ヶ月前に外部負荷テストを行う必要があるため、大事な日の前に発見した問題に対処する時間があります。