私は最近、ソフトウェアスケーラビリティテストのパターンを特定することにかなり関心を持っています。さまざまなソフトウェアソリューションの性質上、スケーラビリティテストソフトウェアの問題には、ソフトウェアを設計し実装するのと同じくらい多くの良い解決策があるようです。私にとっては、これは広く使われているこのタイプのテストのパターンをいくつか蒸留することができることを意味します。ソフトウェアのスケーラビリティテストのパターンはよくわかっていますか？
あいまいさを解消する目的で、私はスケーラビリティテストのwikipedia definitionを使用していると前もって言います。
徹底的な説明で特定のパターン名を提案する回答に最も関心があります。
私が知っているすべてのテストシナリオでは、テスト対象の処理エージェントを対象とする1人または複数のリクエスタに対していくつかの要求を生成するテストと同じ基本構造を使用しています。 Kurtの答えは、このプロセスの優れた例です。一般的に、テストを実行していくつかのしきい値を見つけ、正確な平均データを構築するために、いくつかの代替構成（ノードの削減、ハードウェアの変更など）を実行します。
リクエスタは、要求を生成するソフトウェアのマシン、ネットワークカード、特定のソフトウェアまたはスレッドです。それは何らかの方法で処理できるリクエストを生成することだけです。
処理エージェントは、実際に要求を処理して結果を返すソフトウェア、ネットワークカード、マシンです。
は、しかし、あなたが結果をやっていることは、あなたがやっているテストの種類を決定し、それらは：
負荷/性能テスト：これは、使用中の最も一般的なものです。結果は、さまざまなレベルまたはさまざまな構成でどれだけ処理されたかを確認するために処理されます。 Kurtが上で探していることは、この場合の例です。
バランステスト：スケーリングの一般的な方法は、プロセスエージェントに要求を送るロードバランシングエージェントを使用することです。設定は負荷テストと同じですが、目的は要求の配布を確認することです。いくつかのシナリオでは、処理エージェント全体にわたる要求の均等（または許容値に近い）バランスが達成されていることを確認する必要があります。また、特定のリクエスタの最初の要求を処理したプロセスエージェント後続のすべてのリクエストを処理します（Webファームはこのように一般的に必要です）。
データの安全性：このテストでは、結果が収集され、データが比較されます。あなたがここで探しているのは、書き込みを妨げるロック問題（SQLデッドロックなど）、またはデータ変更が許容時間内に使用中のさまざまなノードまたはリポジトリに複製されることです。
境界テスト：これは、パフォーマンスの処理ではなく、エフェクトのパフォーマンスの保存量が目標であることを除いて、負荷テストと同様です。たとえば、データベースを使用している場合、I/Oパフォーマンスが許容レベルを下回る前にいくつの行/テーブル/列を持つことができますか。
私はまた、The Art of Capacity Planningをこの本の優れた本としてお勧めします。
もう1つのタイプのテストをRobertのリストに追加できます：soak testing。適切に重いテスト負荷を選んで長時間実行します。通常、パフォーマンステストが1時間続く場合は、夜間、1日中、または1週間中に実行します。正確さとパフォーマンスの両方を監視します。このアイデアは、メモリリーク、パックラッピング、時折のデッドロック、再構築が必要なインデックスなど、時間の経過とともにゆっくりと発生するあらゆる種類の問題を検出することです。
これはスケーラビリティとは異なりますが、重要です。あなたのシステムが開発拠点を離れて生きていくと、より多くの負荷とリソースを追加するだけでなく、時間次元でも「水平」に大きくなるわけではありません。数週間、数ヶ月または数年のうちに、それは開発中に行われていない。
Robert、私は、スケーラビリティテストが通常どのように実行されるかをKurtの答えが表すことに同意します。あなたの答えは、私が探していたもののラインに沿ってもう少しです。 –