私の意見では、ストレステストの準備の最終段階を検討することを提案します。
スマッシュテストケース
システムのテストを計画する場合、アクションの詳細な計画が作成されます。 一連の手順を準備したら、もう一度それらを見て、1つの大きなシナリオを小さなシナリオに分割する価値があります。
銀行部門のいくつかの個人的なアカウントを取ります。 ストレステスト中に個人アカウントがどのように機能するかを確認します。 特定の手順があります。
- メインページを開きます。
- 個人アカウントページに移動します。
- ログインします。
- アカウントのステータスを確認してください。
- すべてのサービスの支払い。
- 任意のカードに転送します。
- ログアウトします。
最初に思い浮かぶのは、これら7つの簡単な手順を1つのシナリオに書き留めて実行することです。 ただし、このシーケンスを7つの単純なセットに分割できます。 その結果、多くのテストのかなり多数の組み合わせが得られます。
7つの異なるセットからのテストのおおよそのセット。
複数のセットを使用することで、さまざまな組み合わせで最も完全な方法で機能のストレステストを実行するのに役立つ複数のテストを作成できることを明確に確認できます。
このレベルの詳細により、Webシステムの状態の変化により迅速に対応できます。 たとえば、セットの1つが変更された場合、シーケンス全体ではなく、セットのみを再記録する必要があります。
自動化された機能テストを開発する場合、1つの大きなステップセットを小さな機能に分割するのが慣例です。 同じ原則がストレステストにも当てはまります。
1つのテストで異なるセットを使用する
テスト対象のシステムが大きいほど、使用できるオプションが増えます。 前のセクションでは、1つの大きなシーケンスを複数のセットに分割し、それらを異なるテストで使用する方法を検討しました。 しかし、数千人のユーザーに対してテストを実行する場合はどうすればよいでしょうか。
現実には、人々は一度に1セットの手順を実行することはできません。 各人は個人です。 もちろん、テストスイートは異なるユーザーグループで一致する場合がありますが、これらのグループはすべて一度に1つのサイトで動作するため、これは1つのテストです。
多くのユーティリティでは、同じテストで異なるセットを並行して実行できます。 「複雑な」セットを定義するだけでよく、それはより単純なセットで構成されます。 そして、1つのテストで複数の「複雑な」セットを使用します。
このような詳細とテストスイートの使用により、テスト済みのWebシステムを実際に使用する可能性に近づくことができます。 もちろん、セットに分割することなくテストを実行できます。 しかし、これが実際の使用履歴を反映していることを確認する方法。 Webシステムが不明であることを考慮すると、その構造とアーキテクチャがわからず、Webバージョンしか表示されないため、どのサーバーでどの操作を実行できるかが正確にわかりません。
実際の条件では、負荷はテスト全体と各ユーザーに同じシーケンスを使用したときに実行されたテストとは異なります。 このようなテスト組織は、Webシステムの実際の使用例を示していると思います。
この実行キットの編成により、特定のキットの実行を開始できる遅延を調整することもできます。 そして、これは私たちのテストのリアリズムへの別のプラスです。
ランニングセットに異なるボーレートを使用する
現在、膨大な数のデジタルデバイスとデータ転送の多くの方法により、データ転送速度の問題が発生する場合があります。 負荷テストやその他のソフトウェアシステム用の最新のユーティリティは、データ交換の速度を制限する機会を与えてくれます。 多くの人がこれが必要な理由を言うでしょう。データチャネルを使用するときのシステムの動作と、そこで興味のないものをチェックしました。
サーバーが10の同時接続のみをサポートする場合の状況を考慮することを提案します。 20人のユーザーが同時に作業します。 このユーザーまたはそのユーザーが作業を終了すると、ユーザーは接続を解放し、次のユーザーが接続を積極的に使用できるようになることを知っています。 一部のユーザーに対してデータ交換の速度を制限すると、データを受信する時間も長くなります。 このため、シナリオ全体の合計稼働時間を増やしています。
そのような「遅い」ユーザーが多数いる場合、サーバーのチャネル全体を使用します。つまり、新しいサーバーに接続しようとすると、接続タイムアウト後に拒否されます。 つまり、20人のユーザーのうち、一部のユーザーが完全に失敗する場合があります。
実際、これはサーバーのパフォーマンスの問題ではなく、クライアントが動作する速度で情報を処理しました。 しかし、その一方で、とにかく数人のユーザーが失われ、サーバーに接続できなくなります。 すべてのWebサーバーには、クライアントが接続キューで待機する時間を設定する設定があります。
高速チャネルがあった場合、サーバーは次のユーザー接続がタイムアウトする前に常に現在のユーザーとの作業を完了することができたため、この問題を発見することはできませんでした。
データ交換レートの値の変化を考慮して負荷テストを実行した場合にのみ、同様の状況を見つけることができました。
さまざまなデジタルデバイスでの使用を考慮に入れて、顧客がWebシステムの操作に関する完全な情報を提供することは常に優れています。 最大速度の設定でテストした場合に状況が発生する可能性がありますが、システムのほとんどのユーザーはモバイルデバイスを使用していることが判明したため、Webシステムとのデータ交換の速度は大幅に異なり、デバイスのタイプだけでなく、データ転送デバイスに対するユーザーの位置にも依存します。
おわりに
1つの大きなスクリプトを小さなセットに分割すると、スクリプトの特定のステップをすばやく変更する機会が与えられます。 スクリプトを完全に再記録する必要はありません。
詳細化により、異なるセットで多数のテストを作成できます。 これにより、Webシステムで実行される実際の負荷にテストが近づきます。
使用するチャネルの速度を正しく選択すると、システムが実際のユーザーデバイスでどのように機能するかがわかります。 本格的なデータ交換チャネルを使用して取得されたデータが、より少ない帯域幅のチャネルに正しく外挿できるとは限りません。
Webシステムで負荷テストを実行するために準備するために説明した手順が、テスト対象のシステムの実際の使用条件に最も近いテストを実装し、テストスイートをすばやく変更できるようになることを願っています。
あなたのテストと良い結果で頑張ってください。