我的公司有一個規則，通過單元或集成測試達到75％的測試覆蓋率。由於整個系統的複雜性，開發人員傾向於編寫集成測試（例如，使用針對正在運行的應用程序的selenium webdriver），而不是承擔嘲笑依賴服務/類的負擔。集成測試vs測試覆蓋
我不是一個朋友，不知道對我的測試中的測試覆蓋數據實際上意味着：
在我看來，測試應明確預期的行爲和測試。如果一個i-測試深入到應用程序中，通過許多服務，可能直到數據庫層再返回，它將覆蓋很多行，但是絕對不清楚這種覆蓋行的預期行爲是什麼。因此，覆蓋率數據的質量是可疑的恕我直言，甚至更糟 - 增加維護工作量。
POV是否正確？談到與管理層的討論時，我該如何備份它？
關於測試覆蓋率的盲目百分比規則並不十分理想。集成測試就是一個很好的例子。如果有什麼事情發生，你能準確地說出什麼事了嗎如果您有多個集成點（例如，單個請求遇到數據庫，Web服務併發送電子郵件）會怎麼樣？那裏有太多的測試真的有意義。
如果不測試所有可能的結果，您是否可以擁有100％的覆蓋率？你能寫10,000個測試，但仍然無法覆蓋一個軟件中最重要的類？盲目的指標很糟糕，並沒有真正的質量結果。
通常，進行更小，更離散的測試更有價值。我們通過剔除集成點並在測試中嘲笑它們來做到這一點。然後你可以設置場景，「如果數據庫這樣做，那麼我的代碼就是這樣做的。」這種類型的問題在內存中解決起來要比設置數據庫在可重複的基礎上執行確切的事情容易得多。你將如何自動化一個服務器斷開連接的集成測試？這非常困難。刪除處理該特定SQL異常的數據庫非常容易且可重複。
我完全同意：問題在於我們沒有清晰的界面，對「集成點」沒有清晰的概念（我最近學到了一個術語，我非常喜歡它，因爲它專注於i測試的真正目標。）問題仍然是如何說服管理層（它發明並推廣了當前的設置） – Bastl
我通常會發現管理層必須教授測試指標。根據我的經驗，管理者「已經遠離了舊的方式」去了解他們的目標真的在問，測試數量和測試覆蓋率對測試質量沒有任何影響，這意味着人類代碼評估，爲此，請坐下來，向他們解釋這些概念，甚至更好地展示他們！如果你不在鼓勵這種雙向對話的地方工作，那麼就出去吧。 –
如果您在截止日期之前達不到測試覆蓋率的75％，或者即使達到了測試覆蓋率，如果其他測試覆蓋率達到25％，那麼您的公司將不會專注於獲得缺陷不太明顯的產品而是專注於測試覆蓋率的百分比。儘管您使用硒或任何所謂的方法，但可靠地解釋了您的方法。
如何計算非檢測代碼的代碼覆蓋率？ – edutesoy
@edutesoy我不知道：我認爲標準LOC與在測試執行過程中被觸及的代碼行進行比較。但說實話，我並不清楚測試覆蓋的實際工作原理。 – Bastl