目錄
在軟件消亡之前，如果沒有測試的結束點，那麼軟件測試就永無休止，永遠不可能結束。軟件測試的結束點，要依據自己公司具體情況來制定，不能一概而論！個人認爲測試結束點由以下幾個條件決定：
十個原則確定軟件測試結束的標準
1．基於“測試階段”的原則：
每個軟件的測試一般都要經過單元測試、集成測試、系統測試這幾個階段，我們可以分別對單元測試、集成測試和系統測試製定詳細的測試結束點。每個測試階段符合結束標準後，再進行後面一個階段的測試。舉個例子來說：單元測試，我們要求測試結束點必須滿足“核心代碼100％經過Code Review”、“功能覆蓋率達到100％”、“代碼行覆蓋率不低於80％”、“不存在A、B類缺陷”、“所有發現缺陷至少60％都納入缺陷追蹤系統且各級缺陷修復率達到標準”等等標準。集成測試和系統測試的結束點都制定相關的結束標準，當然也是如此。
2．基於“測試用例”的原則：
測試設計人員設計測試用例，並請項目組成員參與評審，測試用例一旦評審通過，後面測試時，就可以作爲測試結束的一個參考標準。比如說在測試過程中，如果發現測試用例通過率太低，可以拒絕繼續測試，待開發人員修復後再繼續。在功能測試用例通過率達到100%，非功能性測試用例達到95%以上，允許正常結束測試。但是使用該原則作爲測試結束點時，把握好測試用例的質量，非常關鍵。
3．基於“缺陷收斂趨勢”的原則：
軟件測試的生命週期中隨着測試時間的推移，測試發現的缺陷圖線，首先成逐漸上升趨勢，然後測試到一定階段，缺陷又成下降趨勢，直到發現的缺陷幾乎爲零或者很難發現缺陷爲止。我們可以通過缺陷的趨勢圖線的走向，來定測試是否可以結束，這也是一個判定標準。
4．基於“缺陷修復率”的原則：
軟件缺陷在測試生命週期中我們分成幾個嚴重等級，它們分別是：嚴重錯誤、主要錯誤、次要錯誤、一般錯誤、較小錯誤和測試建議6種。那我們在確定測試結束點時，嚴重錯誤和主要錯誤的缺陷修復率必須達到100%，不允許存在功能性的錯誤；次要錯誤和一般錯誤的缺陷修復率必須達到85%以上，允許存在少量功能缺陷，後面版本解決；對於較小錯誤的缺陷修復率最好達到60%~70%以上。對於測試建議的問題，可以暫時不用修改。
5．基於“驗收測試”的原則：
很多公司都是做項目軟件，如果這種要確定測試結束點，最好測試到一定階段，達到或接近測試部門指定的標準後，就遞交用戶做驗收測試。如果通過用戶的測試驗收，就可以立即終止測試部門的測試；如果客戶驗收測試時，發現了部分缺陷，就可以針對性的修改缺陷後，驗證通過後遞交客戶，相應測試也可以結束。
6．基於“覆蓋率”的原則：
對於測試“覆蓋率”的原則，個人覺的只要測試用例的“覆蓋率”覆蓋了客戶提出全部的軟件需求，包括行業隱性需求、功能需求和性能需求等等，只要測試用例執行的覆蓋率達到100%，基本上測試就可以結束。如“單元測試中語句覆蓋率最低不能小於80%”、“測試用例執行覆蓋率應達到100%”和“測試需求覆蓋率應達到100%”都可以作爲結束確定點。如果你不放心，非得要看看測試用例的執行效果，檢查是否有用例被漏執行的情況，可以對常用的功能進行“抽樣測試 ”和“隨機測試”。對於覆蓋率在單元測試、集成測試和系統測試，每個階段都不能忽略。
7．基於“項目計劃”的原則：
大多數情況下，每個項目從開始就要編寫開發和測試的Schedule，相應的在測試計劃中也會對應每個里程碑，對測試進度和測試結束點做一個限制，一般來說都要和項目組成員（開發，管理，測試，市場，銷售人員）達成共識，團隊集體同意後製定一個標準結束點。如果項目的某個環節延遲了，測試時間就相應縮短。大多數情況下是所有規定的測試內容和迴歸測試都已經運行完成，就可以作爲一個結束點。很多不規範的軟件公司，都是把項目計劃作爲一個測試結束點，但是如果把它作爲一個結束點，測試風險較大，軟件質量很難得到保證。
8．基於“缺陷度量”的原則：
這個原則也許大家用的不是很多，瞭解比較少。我們可以對已經發現的缺陷，運用常用的缺陷分析技術和缺陷分析工具，用圖表統計出來，方便查閱，分時間段對缺陷進行度量。我記得以前zhuzx在這個論壇上提出過缺陷分析技術這個問題，我不再重複講述。我們也可以把 “測試期缺陷密度”和 “運行期缺陷密度”作爲一個結束點。當然，最合適的測試結束的準則應該是“缺陷數控制在一個可以接受的範圍內”。比如說：一萬行代碼最多允許存在多少個什麼嚴重等級的錯誤，這樣比較好量化，比較好實施，成爲測試缺陷度量的主流。
9．基於“質量成本”的原則：
一個軟件往往要從“質量/成本/進度”三方面取得平衡後就停止。至於這三方面哪一項佔主要地位,就要看是什麼軟件了。比如說是：人命關天的航天航空軟件, 那還是質量重要些,就算多花點錢、推遲一下進度，也要測試能保證較高質量以後才能終止測試，發佈版本。如果是一般的常用軟件，由於利益和市場的原因，哪怕有bug，也必須得先推出產品，沒辦法呀。一般來說，最主要的參考依據是：“把找到缺陷耗費的代價和這個缺陷可能導致的損失做一個均衡”。具體操作的時候，可以根據公司實際情況來定義什麼樣的情況下算是“測試花費的代價最划算、最合理”，同時保證公司利益最大化。如果找到bug的成本比，用戶發現bug 的成本還高，也可以終止測試。
10．基於“測試行業經驗”的原則：
很多情況下，測試行業的一些經驗，也可以爲我們的測試提供借鑑。比如說測試人員對行業業務的熟悉程度，測試人員的工作能力，測試的工作效率等等都會影響到整個測試計劃的執行。如果一個測試團隊中，每個人都沒有項目行業經驗數據積累，拿到一個新的項目，自然是一頭霧水，不知道從何處開始，測試質量自然不會很高。因此通過測試者的經驗，對確認測試執行和結束點也會起到關鍵性的作用。
單元測試退出標準
1) 單元測試用例設計已經通過評審
2) 核心代碼100％ 經過Code Review
3) 單元測試功能覆蓋率達到100％
4) 單元測試代碼行覆蓋率不低於80％
5) 所有發現缺陷至少60％都納入缺陷追蹤系統且各級缺陷修復率達到標準
6) 不存在A、B類缺陷
7) C、D、E類缺陷允許存在
8) 按照單元測試用例完成了所有規定單元的測試
9) 軟件單元功能與設計一致
集成測試退出標準
1) 集成測試用例設計已經通過評審
2) 所有源代碼和可執行代碼已經建立受控基線，納入配置管理受控庫，不經過審批不能隨意更改
3) 按照集成構件計劃及增量集成策略完成了整個系統的集成測試
4) 達到了測試計劃中關於集成測試所規定的覆蓋率的要求
5) 集成工作版本滿足設計定義的各項功能、性能要求
6) 在集成測試中發現的錯誤已經得到修改，各級缺陷修復率達到標準
7) A、B類BUG不能存在
8) C、D類BUG允許存在,但不能超過單元測試總BUG的50％。
9) E類BUG允許存在
系統測試退出標準
1) 系統測試用例設計已經通過評審
2) 按照系統測試計劃完成了系統測試
3) 系統測試的功能覆蓋率達100％
4) 系統的功能和性能滿足產品需求規格說明書的要求
5) 在系統測試中發現的錯誤已經得到修改並且各級缺陷修復率達到標準
6) 系統測試後不存在A、B、C類缺陷
7) D類缺陷允許存在，不超過總缺陷的5％
8) E類缺陷允許存在，不超過總缺陷的10％
注：這只是一套比較理想化的退出標準，但在實際工作中不可能達到這種程度，尤其是測試覆蓋率和缺陷解決率不可能是100%。現在的軍方標準是達到99%。對於通用軟件來說就要根據公司實際情況了。