在回答這個問題之前，我們首先理清思路，測試的質量首先就體現在缺陷的質量上面。就是發現了多少缺陷，缺陷的嚴重程度如何，缺陷發現的早晚，缺陷的分布等待，作為測試的結果直接向客戶表明了測試的質量。然而測試的質量又有什麽所決定呢？是測試用例，測試用例的覆蓋率，測試用例的精細度，深度，直接決定了能發現缺陷的多少。所以，要在未發布之前預估缺陷的遺留情況，就要檢查測試用例的覆蓋情況。

1. 根據測試用例和SRS中功能點的一一對應關系，還有概要設計、詳細設計中的對應關系，這個跟著矩陣，檢查是否所有的功能點都被覆蓋到了。

2. 覆蓋到功能點包括起碼幾個方面，1是正面的用例，2是負面的測試用例，3是所有的分支路徑和錯誤處理是否都做了。

3. 對於有些需求，比如性能需求可能沒有在功能測試用例涉及到，而性能需求也沒有專門的收集，這就需要專門的收集，並且細化測試。因為很可能所有的功能都滿足了，但是性能並不滿足。系統並發用戶使用並沒有測試。這是很容易遺漏的，在項目快收尾階段仍然需要檢查一下是否所有的非功能點都測試過了。

4. 通過以上分析，如果發現有沒有覆蓋到得，覆蓋不足的就是可能有缺陷遺留的地方。

以上總體是為了保證：所有系統該實現的功能都得到實現了，同時系統沒有去做任何不該做的事情。

然而，並非通過以上途徑就可以確保能夠發現所有改發現的缺陷了。我們還可以通過比較分析當前的缺陷數據和歷史相關數據來檢查：

1. 如果這個被測系統有之前的版本的測試數據，那我們可以比較以前的這個版本所有的缺陷，看看以前一共多少個模塊，平均每個模塊發現了多少缺陷，然後客戶又發現了多少缺陷。而我們現在這些相應的模塊發現了多少缺陷。為什麽比以前多，為什麽比以前少，等等，很多可以比較的地方

2. 類比同類產品的測試，比如都是j2ee，同樣類型的系統，平均每kloc代碼一共發現多少缺陷？平均每kloc代碼一共能寫出多少測試用例？平均每個功能點能寫出多少測試用例，發現多少bug？而我們目前寫了多少測試用例，發現了多少bug？那些模塊發現的多或者少？然後檢查原因，到底是為什麽？因為這些都是可能存在缺陷遺漏的地方。

3. 對於不同的測試人員，做數據的比較，看誰發現的多，誰發現的少，誰發現的某種類型的缺陷多，或者少？因為常常是某些測試人員之容易看到某類型的缺陷，而遺漏另外一些類型的缺陷。

4. 對本被測系統的缺陷庫做分析統計，各種類型的缺陷比例各是多少？這個比例是否符合歷史數據的比例？分析統計以前產品的遺留缺陷比例，然後對比當前的產品。

5. 分析本公司，或者本測試團隊以前的所有的非測試用例找到的缺陷，還有產品發布後被客戶提出的缺陷。這些缺陷往往是我們團隊自身固有的問題導致的盲區，這些缺陷類型和特點需要在本次測試中專門關註。

6. 分析測試方案、測試用例、開發的詳細設計、概要設計的評審文檔，以及相應的評審數據，發現的缺陷比例是否合理，以此判斷分析是否評審的到位，如果評審不到位，則測試用例可能質量不夠高，有遺漏，則測試就可能會少發現缺陷，這些地方需要認真檢查。

7.具體的缺陷遺留比例可以根據上面提到的各項數據對比分析來確定，比如同類型，同代碼量的軟件應該能寫1000個測試用例，發現2000個bug，而我們發現了1800個bug，則可以懷疑我們還遺留200個缺陷，但是，這只是懷疑，還需要分析是否由於開發團隊的成熟導致的確只有1800個bug。這都是需要進一步分析論證的。

以上通過各種方式和角度的數據統計和對比，學習以前的經驗，借此發現系統可能存在的潛在問題。然而可能還會發現不全，我們有以下手段可以應對：

1. 找經驗相對比較豐富的測試人員，或者非本項目的測試人員來對本系統做隨機測試。雖說是隨機，但是，其實因為都是有經驗的人員，而且對相關的系統都很熟悉，測試目的還是非常強的，同時這個測試過程，需要有本系統的測試人員陪同講解，類似於配對開發而言的配對測試一樣。

2. 問開發人員，他們懷疑他們的系統什麽地方可能會有缺陷，然後專門去測試這些地方

3. 如果開發有單元測試，這時候我們可以分析單元測試的結果，看看單元測試的覆蓋率，是語句覆蓋還是判定覆蓋，邏輯覆蓋，等等，如果某些重要的功能點的覆蓋率不夠，我們可以專門去從單元測試和集成測試外加系統測試的高度做相應的測試，力圖將這幾個重點模塊的測試覆蓋率達到最高。如果之前沒有單元測試，這時候也可以分析代碼，測試重要的判斷點。

總結：基本上我能想到的就是以上這些從測試角度，不涉及開發而談的方法，判斷分析出系統潛在的有問題的地方，以及相應的補救措施。但是需要說明這些方法必須在整個測試過程中實施，而不是快要交付之前才開始檢查，這是團隊管理人員，在項目計劃中必須預留相應的時間和人力貫徹執行的。

在軟件發布之前如何預估殘留缺陷？