過去10個月，我一直在windows窗體應用程序和ASP.Net應用程序中工作。我一直想知道如何以完整的應用程序對所有場景進行適當的單元測試。我有關於他們的以下問題 -單元測試巨大的應用程序 - 經過驗證的方法？
如果你想知道如何測試整個應用程序，它不是一個單元測試，因爲談論的.Net應用程序時，該單元是一個類或方法。我猜您混亂的事實，自動化事情您創建一個測試單元（你做單元測試的測試單位，但你也可以做集成測試與檢驗單位...）引起。你可能會談論自動化集成測試或驗收測試（這不應該是自動的）。
測試模型，如V模型定義至少三個測試階段：
單元測試
測試單個功能或系統的特徵 。它基於 單位（類或方法）的技術規格，你是 建築物。它可以通過 自動通過測試單位的使用。另外，我覺得應該 使用CI Server（持續集成） 這裏，因爲如果你的單位不正確地整合， 出現問題最有可能出現在這個階段。
集成測試
一旦你證明自己的所有 「單位」（類或方法）的作品 獨立，你現在試着檢查 整個系統工作爲一體。所以，你做 一個集成測試，看看這些單位爲了工作 正確共同實現 系統的目的，這 檢查。您應該嘗試自動化集成測試 以及。你可以使用這樣的工具，如 StoryTeller。
用戶驗收測試
用戶驗收測試必須被 由用戶進行的，所以沒有 自動化這裏。當然，你可以 創建並加載該用戶 將驗證數據，因此 測試的部分自動化的，但不是 結果。沒有機器人應該永遠給你最後的話，系統是 工作，只有用戶。
現在，爲您解答：
什麼是執行單元測試和編寫測試用例標準的機制是什麼？
您應該使用的.Net測試單元用於這一目的。爲了測試用戶交互（您可以測試用戶與屏幕的交互），您可以使用外部應用程序（請查看下面的鏈接）。有些機器人可能會爲您自動執行這些測試。
該方法是否根據應用程序性質而改變，如Windows窗體，Web應用程序等？
確實。例如，批量應用程序可以通過單獨使用測試單元進行單元測試。批處理系統的測試案例也可能更爲寬鬆，但需要更多數據輸入來檢查所有約束。
確保我們覆蓋所有場景的最佳方法是什麼？任何暢銷書籍？
我不知道這有使確保你覆蓋每一個場景一個真正的方法，但你應該做的是定義你對測試的內容。就像我之前說過的，你應該根據技術規範進行單元測試，所以如果你的規範寫得很好，你應該能夠清楚地識別測試用例。如果您覺得需要針對未指定的內容進行測試，那麼您應該在改進您的設計技巧。
流行的工具進行單元測試？
List of unit testing frameworks
希望這有助於。
您需要編寫測試程序中對象和功能的單元測試。 這意味着測試來測試類中的每個函數，然後測試整個類的功能，然後測試庫中的功能。本質上，您正在爲應用程序中的每個級別從頂級庫到函數編寫測試。這確保瞭如果您更改任何代碼，它仍然可以按預期工作。
NUnit的是一種流行的單元測試框架，但VS爲您提供了內置的單元測試標準（可能是VS2008只，但可以肯定VS2005確實太）
覆蓋所有場景簡直就是編寫測試覆蓋的情況下，所有已知的可能性，你不能涵蓋所有情況，但你可以覆蓋主要的情況，通常情況下都很好，因爲你知道預期的產出，並且可以對此進行測試。
如果您已經開發了10個月的應用程序，那麼根本不可能單元測試它，因爲每個定義的單元測試只涉及一次測試一個單元（類或甚至方法） 。
此時，使用諸如FitNesse或StoryTeller等工具可以更好地編寫自動化的驗收測試。
我推薦一本關於這個主題的非常好的書：Working Effectively with Legacy Code Michael Feathers。我發現它對於類似的傳統項目非常有用。
遺留代碼的主要問題是沒有「標準」的方式來進行單元測試:-(標準的「測試驅動開發」是爲新項目發明的，在那裏你開始編寫代碼和單元測試，因此您可以從第1天起將您的單元測試套件與您的代碼一起增長，並始終保持代碼的全部（或大部分）代碼。
但實際情況是，大部分現實生活項目都涉及傳統代碼，沒有一個單元測試（實際上，Feathers定義的舊代碼是「沒有單元測試的代碼」）。本書提供了一些有用的建議，當你需要觸摸你幾乎不瞭解的代碼時該怎麼做，或者修改1000行的怪物方法並確保在le因爲你的修改得到單元測試正確。在這種情況下，編寫單元測試通常是非常困難的，因爲代碼沒有設計爲可測試的。因此，經常需要重構它才能進行測試，但是如果沒有進行單元測試，這是有風險的......仍然有辦法擺脫這種陷阱，本書向他們展示了這些陷阱。一般而言，您不應該以覆蓋整個代碼庫爲目標（除非您有項目經理願意接受在接下來的幾個月或幾年內不會生成任何新功能; - ）。您只有有限的時間從單元測試中獲得最大的收益。因此，您必須首先關注代碼中最關鍵的部分。這些通常是最經常修改的和/或發現最多錯誤的那些（當然有相關性）。您也可以提前知道即將發佈的功能需要擴展代碼的特定部分，因此您可以通過爲其創建單元測試來準備該方法。這樣，隨着時間的推移，你會開始在代碼中增長一點「安全島」，這些代碼更好地用單元測試覆蓋。維護和重構是在這些景點更容易，當你添加更多的單元測試，島嶼慢慢長大......
注意的是，在開始這些「安全孤島」不傾向於表現出非常「系統性」的格局發生。代碼中最關鍵，最經常修改的部分通常是相當隨機地分發的。只是在很晚的階段，當被測試的島嶼開始增長和合並時，是否值得更系統地覆蓋特定的模塊。例如。如果你看到在這個特定的模塊中單元測試的代碼覆蓋率增長了60％以上，你可以決定通過它併爲其餘代碼部分添加測試。
執行單元測試和編寫測試用例的標準機制是什麼？ 有許多.NET測試框架。我會建議你給NUnit或MbUnit。
MbUnit的本配備了測試運行，這樣有可能使事情變得更容易。我更喜歡集成的方法，我可以直接從Visual Studio運行所有測試，但這需要一些重要的設置。當使用測試運行器（如MbUnit附帶的Gallio）時，您將在Visual Studio項目的外部運行單元測試。單元測試本身應該位於他們自己的項目中，通常是夾具形式。內部的測試可以用不同的風格命名，但關鍵是儘可能描述。 例如：
void when_my_class_is_sent_a_user_it_should_save_it()
也很受歡迎
[MethodName_StateUnderTest_ExpectedBehavior]
是否改變的方法根據應用程序的性質，如Windows窗體，Web應用程序等？ 該方法確實根據應用性質而改變。幸運的是，網頁表單和獲勝表單非常相似。不幸的是，它們都是在沒有考慮測試的情況下設計的，並傾向於難以正確測試的代碼。
什麼是確保我們覆蓋所有場景的最佳方法？ 測試驅動設計（您編寫測試，然後編寫代碼使其通過）。代碼覆蓋率也是一個有用的指標。
任何暢銷書籍？ 單元測試的藝術：在.NET中使用由羅伊Osherove ，單元測試與NUnit的
執行單元測試熱門工具的例子在C＃中？ 如上所述，NUnit & MbUnit。還有MSTest（與VS2008捆綁在一起），xUnit和其他一些軟件。雖然強烈建議你使用NUnit或MbUnit。
非常好的解釋。謝謝。 – NLV 2010-03-18 05:06:35
我的意思是說，我需要單元測試我在過去10個月中創建的所有應用程序:) – NLV 2010-03-17 14:58:11