讓我來驗證這個問題。我正在研究一個「經典」的ASP.NET應用程序（Web Forms），它不使用Model-View-Presenter，也不使用TDD編寫。它還使用了過時的數據訪問策略（手寫DAO層，調用存儲過程來填充和保存對象），儘管我強烈希望這樣做，但不太可能升級到ORM。brownfield ASP.NET應用程序的有用/現實代碼覆蓋率目標
自從我接手應用程序的開發以來，大多數新功能都是使用TDD實現的。這仍舊使舊代碼庫，DAL層和整個UI都未經測試。在確定應用程序距離神祕的70％代碼覆蓋率目標有多遠之前，我想弄清楚在確定代碼覆蓋範圍時通常包括哪些類型的代碼。
業務邏輯代碼顯然包含在內，但WebForms代碼如何？另外，數據訪問代碼如何？如上所述，我們的數據訪問層使用存儲過程來填充對象圖並將它們保存回數據庫。對象持久性和重新水化是應該包含的東西嗎？
我很抱歉，如果這個問題太開放了，我只是覺得有點不知所措，並且對如何讓這個brownfield應用程序變得更好而感到困惑。
謝謝！
不要爲代碼覆蓋率或任何其他代碼度量設置目標。通常情況下，硬目標的傷害比好的多。
如果你給其他開發者硬代碼度量目標，他們將只是遊戲目標如果他們不明白目標的潛在原因。
作爲一個平行的例子，你不會相信我職業生涯中見過多少「保持FxCopy開心」的代碼評論。
如果您設置一個硬性指標的測試覆蓋率，懶惰的開發人員可以編寫跳過null檢查等，因爲這降低了它們的覆蓋範圍，如果他們不寫相應的測試。最終結果是代碼質量較差。
相反，開發商誰瞭解TDD的好處並不需要的目標，因爲他們會做正確的事不管。
這並不意味着代碼覆蓋率度量是不相關的。這是非常相關的，但我認爲你應該有一條規則說，絕不能減少。
因此，定期測量它，並確保它只是上漲。這並不妨礙你有自己的個人目標，但不要設定一個硬性目標。
代碼覆蓋率與應用程序穩定性沒有高度相關性。錯誤報告的流入率（以及錯誤的嚴重程度）確實與應用程序的穩定性有很高的相關性。
當我談論代碼覆蓋率，我絕對包括一切，只是假設100％是不現實的。關於這個問題可能有很多不同的意見，所以它對我來說似乎很主觀。
如果我是你的位置，我會更擔心會擔心代碼覆蓋以前建造的手動和自動迴歸測試基地。
在棕色領域的項目中，可能不值得努力達到任何絕對閾值，無論是源代碼度量還是測試覆蓋率。在代碼質量方面，大多數建議的方法被稱爲the boy scout rule，即讓代碼（陣營）比您找到的要乾淨一點。這樣，代碼會逐漸改善。
在測試中，情況類似。核心功能在很長一段時間內得到了高效使用，因此該區域內的錯誤發生概率較低。 Research已經表明，與系統整體相比，最近的變化具有五倍的錯誤概率。所以我建議從開始最近更改了代碼。
您可以使用來自源代碼管理系統的信息來識別更改，比較最近生成的二進制文件和最新的生產版本。爲了進一步縮小範圍，您可以忽略單純來源於重構的更改。然後，您可以將測試集中在這些區域。這種方法的一個例子在this blog post中勾畫出來。由於該想法與實際測試方法無關，因此它甚至可以結合單元測試和手動迴歸測試的結果。