目錄
十個原則確定軟體測試結束的標準
單元測試退出標準
整合測試退出標準
系統測試退出標準
在軟體消亡之前，如果沒有測試的結束點，那麼軟體測試就永無休止，永遠不可能結束。軟體測試的結束點，要依據自己公司具體情況來制定，不能一概而論！個人認為測試結束點由以下幾個條件決定：
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%。對於通用軟體來說就要根據公司實際情況了。
軟體測試結束的標準是什麼？？
1 單元測試用例設計已經通過評審 2 核心 100 經過code review 3 單元測試功能覆蓋率達到100 4 單元測試 行覆蓋率不低於80 5 所有發現缺陷至少60 都納入缺陷追蹤系統且各級缺陷修復率達到標準 6 不存在a b類缺陷 7 c d e類缺陷允許存在 8 按照單元測試用例完成了所...
你的愛情標準是什麼
我一直在想，假如查爾斯王子只是乙個普通的男人，那個19歲的黛安娜還會在明知他另有所愛的情況下嫁給他嗎？在黛安娜一段公開的錄影中，她曾經說大婚那一天 我的心像死一樣平靜，我 感覺自己像待宰的羔羊。她其實是可以不必那麼可憐的，沒有人把她送到案板上，是她自己願意的 如果她不肯，誰還會強迫她站在教堂上對乙個...
位元幣的標準是什麼
眾所知周，roger ver是位元幣現金的忠實支持者。為了從實際行動上對位元幣現金表示支援，他最近將其 bitcoin.com中的位元幣以bitcoin core btc 顯示，而位元幣現金則是以bitcoin bch 這種方式顯示。除此之外，還將 購買bch 的選項放在了 購買btc 之上。中提到...