現在、WebTest を使用してシステムをテストしています。ユーザーは投票できますが、再度ログインして投票を変更することはできません。
WebTest は CSV ファイルからのユーザー名のリストを使用し、すべてのアカウントにはテスト用のデフォルト パスワードがあります。
同時に多くのユーザーが同時にログインしたときに Web サイトがどのように反応するかを知りたくないので、負荷テストをどのようにパラメーター化するのだろうかと思います。
アイデア?ソリューション?
現在、WebTest を使用してシステムをテストしています。ユーザーは投票できますが、再度ログインして投票を変更することはできません。
WebTest は CSV ファイルからのユーザー名のリストを使用し、すべてのアカウントにはテスト用のデフォルト パスワードがあります。
同時に多くのユーザーが同時にログインしたときに Web サイトがどのように反応するかを知りたくないので、負荷テストをどのようにパラメーター化するのだろうかと思います。
アイデア?ソリューション?
私は、4 時間にわたって最大 20 万人のユーザーがログインするソリューションをテストしました。
リストから次のログインを可能にする特定のデータベース プロシージャを呼び出すために、負荷テストをコード化された Web テストに変換しました。
この手順でテーブルにインデックスを保存し、新しいログインが発行されるたびにインデックスを 1 つ上に移動しました。
このストアド プロシージャは非常に単純ですが、データベースの同時実行保護を使用して、一時テーブルに格納されているとおりにユーザーが確実に割り当てられるようにします。
多くの仮想ユーザーが同じスレッドを共有するため、負荷テスト コードにスレッド ブロック呼び出し (データベースまたはファイル IO) を配置しないことが理想的です。ただし、実際には、呼び出した単純なストアド プロシージャでは問題なく動作しました。