Visual Studio の Web および負荷テスト機能は、実際にはテスターではなく開発者を対象としています。Microsoft の専門家からのデモがあり、私が尋ねたところ、彼はこれを確認しました。
いくつかの用途では簡単で簡単です (たとえば、URL のリストだけでテストできる場合、または Web サイトがたまたま記録と再生の方法でテストできる場合)。 :
- ユーザ認証
- 多くのクライアント側の処理 (テストでこれの一部を模倣する必要がある場合があります)
- フレームまたはページごとの複数の非同期リクエスト
- 古いスタイルの ASP の部分的なページ更新 (天国は禁じられています)
それからあなたは傷の世界にいます。
組み込みの抽出および検証機能は非常に弱く、動的テスト (実行時に何を行うかを決定する) のサポートは豊富ではなく基本的です。 テスト内で遭遇する、または実行したい多くのことに対して、すぐに使用できるサポートはありません。また、彼らがどのバグを修正するかについて非常にうるさくてけちであることも助けにはなりません。バグが明白であっても、それがクラッシュでなければ、それを報告する意味はほとんどないように思われます。
とはいえ、プログラミング スキルがあり、http、html、javascript、および Web アプリで使用するその他の特定の Web テクノロジを十分に理解している場合は、テスト フレームワークが非常に拡張可能で広く開かれているため、かなりクールなことを行うことができます。あなたが想像できるどんなC#の魔法にも。しかし、すでに支払った製品で他の誰かの仕事を終わらせているように感じることがあります.
「隠しフィールド」が見つからないという問題は、Web 全体で最も一般的な問題のようであり、多くの場合、簡単な修正はありません。テスト記録を行うと、Visual Studio は、ページに存在していたすべての隠しフィールドを記録します。結果のテストを実行すると、これらの非表示フィールドの 1 つがページに存在しなくなった理由はさまざまです。レコーディングで ajax リクエストが欠落している可能性があります。たぶん、ページはjavascriptで何かをします(VSはjavascriptを実行しません)。別のユーザー アカウント、以前のアクション、時刻、または制御できないその他の要因に基づいて、ページ コンテンツに微妙な違いがある可能性があります。ウェブサイトやアプリが非常に静的である場合、テストはより簡単になります。しかし、非常に動的な場合は、難しい課題に直面する可能性があります。
私の経験を要約すると、3 つの優れたサードパーティ ライブラリを活用し、95 のクラスと約 2700 行のコード (非常に豊富で強力な抽出および検証ルールを含む) で構成される独自のサポート ライブラリを作成した後、ほとんどの私が以前につまずいた大きな困難
しかし、VS を与えられて「いくつかの負荷テストを書く」ように言われた貧しい孤独なテスターを気の毒に思います。