給定軟件在哪里...該系統由幾個子系統組成每個子系統都包含一些組件每個組件都使用許多類來實現...我喜歡為每個子系統或組件編寫自動化測試。我沒有為組件的每個內部類編寫測試（除非每個類都有助于組件的公共功能，因此可以通過組件的公共API從外部進行測試/測試）。當我重構組件的實現時（作為添加新功能的一部分，我經常這樣做），因此，我不需要更改任何現有的自動化測試：因為這些測試僅取決于組件的公共API和公共API。通常是擴展而不是更改。我認為該政策與諸如Retesting Test Code這樣的文檔形成了鮮明對比，該文檔表示...“ ...單元測試...”“ ...系統中每個類的測試類...”“ ...測試代碼/生產代碼的比率...理想地被認為接近1：1的比率...”……我想所有這些我都不同意（或者至少不練習）。我的問題是，如果您不同意我的政策，您能解釋一下原因嗎？在什么情況下這種測試程度不夠？綜上所述：公共接口經過測試（和重新測試），并且很少更改（它們被添加但很少更改）內部API隱藏在公共API的后面，可以更改而無需重寫測試公共API的測試用例。腳注：我的一些“測試案例”實際上是作為數據實現的。例如，UI的測試用例由包含各種用戶輸入和相應的預期系統輸出的數據文件組成。測試系統意味著具有測試代碼，該代碼讀取每個數據文件，將輸入重放到系統中，并斷言它獲得了相應的預期輸出。盡管我很少需要更改測試代碼（因為通常添加而不是更改公共API），但我確實發現有時（例如每周兩次）需要更改一些現有數據文件。當我更好地更改系統輸出時（即新功能改進了現有輸出），可能會發生這種情況，這可能會導致現有測試“失敗”（因為測試代碼僅嘗試斷言輸出未更改）。要處理這些情況，請執行以下操作：重新運行自動測試套件，該套件帶有一個特殊的運行時標志，該標志指示它不聲明輸出，而是將新輸出捕獲到新目錄中使用可視化差異工具查看哪些輸出數據文件（即哪些測試用例）已更改，并驗證這些更改是否良好以及新功能的預期效果通過將新的輸出文件從新目錄復制到運行測試用例的目錄中來更新現有測試（覆蓋舊測試）腳注：“組件”是指“一個DLL”或“一個程序集”之類的東西，其大小足以在體系結構或系統的部署圖上可見，通常使用數十個或100個類來實現，并且因此與公共API只包含約1或接口少數......一些可能被分配到的開發商之一的團隊（其中不同的組件被分配到不同的團隊），并且將根據康威定律有相對穩定的公共API。腳注：文章《面向對象的測試：神話與現實》說：誤解：黑匣子測試就足夠了。 如果您使用類接口或規范仔細地進行了測試用例設計，則可以確信該類已被充分利用。白盒測試（查看方法的設計測試實現）違反了封裝的概念。現實：OO結構很重要，第二部分。許多研究表明，開發人員認為非常難以理解的黑盒測試套件僅在被測實現中使用了三分之一至一半的語句（更不用說路徑或狀態）。這有三個原因。首先，選擇的輸入或狀態通常使用正常路徑，但不強制所有可能的路徑/狀態。其次，僅憑黑盒測試無法揭示驚喜。假設我們已經測試了被測系統的所有指定行為。為了確信沒有未指明的行為，我們需要知道黑盒測試套件是否未行使系統的任何部分?？梢酝ㄟ^代碼檢測來獲取此信息的唯一方法。第三，我應該補充一點，我正在做白盒功能測試：我看到了代碼（在實現中），并且編寫了功能測試（驅動公共API）以行使各種代碼分支（功能實現的詳細信息）。