在軟件消亡之前，如果沒有測試的結束點，那么軟件測試永無休止，永遠不可能結束。軟件測試的結束點，要依據(jù)自己公司具體情況來制定，不能一概而論!個人認為測試結束點由以下幾個條件決定：

　　1.基于“測試階段”的原則：

　　每個軟件的測試一般都要經(jīng)過單元測試、集成測試、系統(tǒng)測試這幾個階段，我們可以分別對單元測試、集成測試和系統(tǒng)測試制定詳細的測試結束點。每個測試階段符合結束標準后，再進行后面一個階段的測試。舉個例子來說：單元測試，我們要求測試結束點必須滿足“核心代碼經(jīng)過Code Review”、“功能覆蓋率達到”、“代碼行覆蓋率不低于80%”、“不存在A、B類缺陷”、“所有發(fā)現(xiàn)缺陷至少60%都納入缺陷追蹤系統(tǒng)且各級缺陷修復率達到標準”等等標準。集成測試和系統(tǒng)測試的結束點都制定相關的結束標準，當然也是如此。

　　2.基于“測試用例”的原則：

　　測試設計人員設計測試用例，并請項目組成員參與評審，測試用例一旦評審通過，后面測試時，可以作為測試結束的一個參考標準。比如說在測試過程中，如果發(fā)現(xiàn)測試用例通過率太低，可以拒絕繼續(xù)測試，待開發(fā)人員修復后再繼續(xù)。在功能測試用例通過率達到，非功能性測試用例達到95%以上，允許正常結束測試。但是使用該原則作為測試結束點時，把握好測試用例的質(zhì)量，非常關鍵。

　　3.基于“缺陷收斂趨勢”的原則：

　　軟件測試的生命周期中隨著測試時間的推移，測試發(fā)現(xiàn)的缺陷圖線，首先成逐漸上升趨勢，然后測試到一定階段，缺陷又成下降趨勢，直到發(fā)現(xiàn)的缺陷幾乎為零或者很難發(fā)現(xiàn)缺陷為止。我們可以通過缺陷的趨勢圖線的走向，來定測試是否可以結束，這也是一個判定標準。

　　4.基于“缺陷修復率”的原則：

　　軟件缺陷在測試生命周期中我們分成幾個嚴重等級，它們分別是：嚴重錯誤、主要錯誤、次要錯誤、一般錯誤、較小錯誤和測試建議6種。那我們在確定測試結束點時，嚴重錯誤和主要錯誤的缺陷修復率必須達到，不允許存在功能性的錯誤;次要錯誤和一般錯誤的缺陷修復率必須達到85%以上，允許存在少量功能缺陷，后面版本解決;對于較小錯誤的缺陷修復率好達到60%~70%以上。對于測試建議的問題，可以暫時不用修改。

　　5.基于“驗收測試”的原則：

　　很多公司都是做項目軟件，如果這種要確定測試結束點，好測試到一定階段，達到或接近測試部門指定的標準后，遞交用戶做驗收測試。如果通過用戶的測試驗收，可以立即終止測試部門的測試;如果客戶驗收測試時，發(fā)現(xiàn)了部分缺陷，可以針對性的修改缺陷后，驗證通過后遞交客戶，相應測試也可以結束。

　　6.基于“覆蓋率”的原則：

　　對于測試“覆蓋率”的原則，個人覺的只要測試用例的“覆蓋率”覆蓋了客戶提出全部的軟件需求，包括行業(yè)隱性需求、功能需求和性能需求等等，只要測試用例執(zhí)行的覆蓋率達到，基本上測試可以結束。如“單元測試中語句覆蓋率低不能小于80%”、“測試用例執(zhí)行覆蓋率應達到”和“測試需求覆蓋率應達到”都可以作為結束確定點。如果你不放心，非得要看看測試用例的執(zhí)行效果，檢查是否有用例被漏執(zhí)行的情況，可以對常用的功能進行“抽樣測試 ”和“隨機測試”。對于覆蓋率在單元測試、集成測試和系統(tǒng)測試，每個階段都不能忽略。

　　7.基于“項目計劃”的原則：

　　大多數(shù)情況下，每個項目從開始要編寫開發(fā)和測試的Schedule，相應的在測試計劃中也會對應每個里程碑，對測試進度和測試結束點做一個限制，一般來說都要和項目組成員(開發(fā)，管理，測試，市場，銷售人員)達成共識，團隊集體同意后制定一個標準結束點。如果項目的某個環(huán)節(jié)延遲了，測試時間相應縮短。大多數(shù)情況下是所有規(guī)定的測試內(nèi)容和回歸測試都已經(jīng)運行完成，可以作為一個結束點。很多不規(guī)范的軟件公司，都是把項目計劃作為一個測試結束點，但是如果把它作為一個結束點，測試風險較大，軟件質(zhì)量很難得到保證。

　　8.基于“缺陷度量”的原則：

　　這個原則也許大家用的不是很多，了解比較少。我們可以對已經(jīng)發(fā)現(xiàn)的缺陷，運用常用的缺陷分析技術和缺陷分析工具，用圖表統(tǒng)計出來，方便查閱，分時間段對缺陷進行度量。我記得以前zhuzx在這個論壇上提出過缺陷分析技術這個問題，我不再重復講述。我們也可以把 “測試期缺陷密度”和 “運行期缺陷密度”作為一個結束點。當然，合適的測試結束的準則應該是“缺陷數(shù)控制在一個可以接受的范圍內(nèi)”。

　　比如說：一萬行代碼多允許存在多少個什么嚴重等級的錯誤，這樣比較好量化，比較好實施，成為測試缺陷度量的主流。

　　9.基于“質(zhì)量成本”的原則：

　　一個軟件往往要從“質(zhì)量/成本/進度”三方面取得平衡后停止。至于這三方面哪一項占主要地位，要看是什么軟件了。比如說是：人命關天的航天航空軟件， 那還是質(zhì)量重要些，算多花點錢、推遲一下進度，也要測試能保證較高質(zhì)量以后才能終止測試，發(fā)布版本。如果是一般的常用軟件，由于利益和市場的原因，哪怕有bug，也必須得先推出產(chǎn)品，沒辦法呀。一般來說，主要的參考依據(jù)是：“把找到缺陷耗費的代價和這個缺陷可能導致的損失做一個均衡”。具體操作的時候，可以根據(jù)公司實際情況來定義什么樣的情況下算是“測試花費的代價劃算、合理”，同時保證公司利益大化。如果找到bug的成本比，用戶發(fā)現(xiàn)bug 的成本還高，也可以終止測試。

　　10.基于“測試行業(yè)經(jīng)驗”的原則：

　　很多情況下，測試行業(yè)的一些經(jīng)驗，也可以為我們的測試提供借鑒。比如說測試人員對行業(yè)業(yè)務的熟悉程度，測試人員的工作能力，測試的工作效率等等都會影響到整個測試計劃的執(zhí)行。如果一個測試團隊中，每個人都沒有項目行業(yè)經(jīng)驗數(shù)據(jù)積累，拿到一個新的項目，自然是一頭霧水，不知道從何處開始，測試質(zhì)量自然不會很高。因此通過測試者的經(jīng)驗，對確認測試執(zhí)行和結束點也會起到關鍵性的作用。