アカウント名:
パスワード:
クライアントからのリクエストをロードバランサー(のようなもの)で受け取ってそのロードバランサーから現行システムとリプレース用システムの両者にリクエストを再発行すれば、(テストツールを使わず・低予算で)実環境でテストができる
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
皆さんもソースを読むときに、行と行の間を読むような気持ちで見てほしい -- あるハッカー
なかなか実環境でテストができない (スコア:1, 興味深い)
これらのテストツールを使って、何をどこまで検証するの?
それと、顧客から性能保証を求められる場合にどうしてますか?
Re:なかなか実環境でテストができない (スコア:1, 興味深い)
クライアントからのリクエストをロードバランサー(のようなもの)で受け取って
そのロードバランサーから現行システムとリプレース用システムの
両者にリクエストを再発行すれば、
(テストツールを使わず・低予算で)実環境でテストができる
……と考えたことがあるんですが
そういうことをやったことがある方っていらっしゃいますか?
あと問題点ありますかね?
たとえばセッション管理でユニークIDを発行している場合など
現行用とリプレース用で同一IDを発行しないとまずそうだなぁとかいうのは
思いついたのですが、他にもあるのかな。
Re:なかなか実環境でテストができない (スコア:3, 興味深い)
そもそも、負荷分散装置とテストツールのどちらが安いか、って話もあるだろうし。
Re: (スコア:0)
何かトラブったらどうすんのよ。
Re: (スコア:0)
Re: (スコア:0)
どっか適当な画面を何個か選んで、ちょっと負荷かけてみるだけなんじゃないの。
実態とは違う環境で「この条件なら問題なく動きます」ての出して
お茶を濁すぐらいか。
Re:なかなか実環境でテストができない (スコア:1)
まぁ実際のところ、そこまで意識してお茶を濁そうとしなくとも、そもそも検証する側が
「負荷というもののなんたるか」を判って無くて、最初からお茶は濁っていた、という
ことになっているケースも多々あるんじゃないかな。
#要するに、不適切な負荷テストで品質を保証したつもりになっている