今のところ、私たちは現在のプロジェクトで毎日たくさんの月間ビルドを行っています。その日常的なビルドに伴うスモークテストはあまり複雑ではありません。メインクラスライブラリ（いくつかのnUnitテストを実行していますが、コードカバレッジはそれほどありません）をコンパイルしますビルドします。問題のアプリケーションは、いくつかのビジネスオブジェクト（LINQ-to-SQLを含む）を消費するASP.NETサイトです。どのように複雑な煙のテストが必要ですか？
特にASP.NETサイトで実行する必要があるより複雑なスモークテストはありますか？どのようにASP.NETサイトのスモークテストを開発するのですか？
単体テストと同様に、いくつかのサンプルデータを使用してステージングサーバーにサイトを起動するとよいでしょう。できるだけライブに近いように。次に、HTTPトラフィック生成スクリプトを使用して、ユーザートラフィックとセッションをシミュレートします。デバッグロギング、例外、およびその他のテストコードをバックエンドで監視できます。ここでパフォーマンス測定を行うこともできます。
ブラウザでそれを自分で再生すると、より強烈で反復的なバージョンと似ています。
パブリックリソースとその入力を定義（または検査）して、これを行うことができます。スクリプトは、バリデーションの問題、サイトフローの奇妙な置換、およびライブ設定でサイトのコンテキスト全体をテストするその他のものを試してみることができます。
ユニットテストから「実際のデータとトラフィックでうまくいきますか？」というテストが完了していない場合は、最終的にバグを後で修正するような頭のないチキンのように走り回ります。
煙のテストをしないでください。あなたはその言葉の語源を知っていますか？電子機器の「煙検査」は、電源を入れて煙が出ているかどうかを確認することです。
より包括的なユニットテストを行う必要があります。あなたに良いコードカバレッジを与えるのに十分です。これはすべてのビルドで何をすべきかです。また、デプロイメントを行い、いくつかの「インストール検証テスト」を実行する必要があります。
煙のテストは本質的に表面的でなければならない：それはコンパイルされるか？展開しますか？ウェルカムページが読み込まれますか？おそらく、この接続が機能するかどうかを調べるために、データベースに対してクエリを実行するテストページをロードしてください。それでおしまい。