所以我們已經在當前的項目上運行了很多月的每日構建。然而，與每日構建一起進行的煙霧測試並不是非常複雜 - 我們在我們的主類庫上進行了幾次nUnit測試（當然，這並沒有提供很好的代碼覆蓋率），並且我們確保編譯的東西並建立。有問題的應用程序是一個使用某些業務對象（包括LINQ到SQL）的ASP.NET網站。抽菸測試有多複雜？
是否有更復雜的煙霧測試，我們應該運行，特別是在ASP.NET網站上？我們如何爲ASP.NET網站開發煙霧測試？
除了單元測試之外，使用一些示例數據將站點啓動到登臺服務器可能也不錯。儘可能靠近生活。然後使用HTTP流量生成腳本來模擬用戶流量和會話。您可以監視後端的調試日誌記錄，異常和其他測試代碼。您也可以在這裏進行性能測量。
就像在瀏覽器中使用它的更強烈的迭代版本一樣。
您可以通過定義（或通過檢查）您的公共資源及其輸入來做到這一點。然後腳本可以嘗試並導致驗證問題，站點流程的奇怪變化以及在現場設置中測試網站整個上下文的其他內容。
如果測試不完整......從單元測試到「它與真實的數據和流量都不錯」，那麼您最終會像後來的無頭雞修復漏洞一樣四處亂跑。
你不應該做煙霧測試。你知道這個詞的詞源嗎？電子產品中的「煙霧測試」是當您打開電源並查看是否有煙霧冒出時。
你應該做更全面的單元測試;足以爲您提供良好的代碼覆蓋率。這就是你應該在每個構建中做的事情。您還應該嘗試進行部署，並運行一些「安裝驗證測試」。
從本質上來說，煙霧測試應該是膚淺的：是否編譯？部署？歡迎頁面是否加載？也許加載一個測試頁面，對數據庫進行查詢以查看該連接是否也可以工作。而已。