軟體測試人員的職責是根據一定的方法和邏輯，尋找或發現軟體中的缺陷，並通過這一過程來證明軟體的質量是優秀還是低劣。所以，怎樣發現缺陷，成為大部分測試人員關注的焦點。在軟體測試過程中，軟體測試人員一般需確保測試過程中發現的軟體缺陷得以關閉。但在實際測試工作中，軟體測試人員需要從綜合的角度來考慮軟體質量，對找出的缺陷保持一種平常心。這就需要明確以下幾個原則：
1、並不是測試人員發現的每個缺陷都是必須修復的。
測試是為了發現程式錯誤，而不能保證程式沒有錯誤。不管測試計畫和執行多麼努力，也不是所有缺陷發現了就能修復。有些軟體缺陷可能會完全被忽略，還有一些可能推遲到後續版本中修復。
一般不修復軟體缺陷原因如下：
沒有足夠的時間。在任何乙個專案中，通常是軟體功能較多，而程式設計人員和測試人員較少，並且可能在專案進度中沒有為開發和測試留出足夠的時間。在實際開發過程中，經常出現客戶對軟體的完成提出乙個最後期限，在此時間點之前，必須按時完成軟體。這就導致了時間的有限性和任務緊迫性，在此壓力下就有可能忽略一些缺陷。
不算真正的缺陷。在某些特殊場合，錯誤理解、測試錯誤或設計說明書變更，會使測試人員把一些軟體缺陷不作為缺陷來處理。
修復的風險太大。這種情況比較常見，軟體本身是脆弱而複雜的，修復乙個缺陷，常常可能導致其它更嚴重問題的出現。在緊迫的產品發布進度壓力下，修改軟體缺陷必須評估其影響程度和風險，以決定是否可修改。
2、發現缺陷的數量說明不了軟體的質量
軟體中不可能沒有缺陷，發現很多的缺陷對於測試工作來說，是很正常的事。缺陷的數量大，只能說明測試的方法很好，思路很全面，測試工作卓有成效。但以此來否認軟體的質量，還是不具客觀性的。
如果測試中發現的缺陷，大部分都是提示性錯誤、文字錯誤等，或錯誤的等級很低，而且這些缺陷的修復幾乎不會影響到執行指令的部分。但對於軟體的基本功能和效能，發現的缺陷很少，通常這樣的測試證明了「軟體的質量是穩定的」，因而屬於良好軟體的範疇。這樣的軟體只要處理好發現的缺陷，基本就可以發行使用了。而進行完整的回歸和大規模測試，就是增加軟體開發的成本，浪費商機和時間。
發過來，如果在測試過程中發現的缺陷較少，但這些缺陷都集中的功能沒有實現、效能未達標、經常引起宕機或系統崩潰等現象，而且出現機率大，多數使用者使用過程中都會發現這樣的問題。那這樣的軟體就不能隨便就發布，因為發布風險太大了！
***********************************=分割線******************************==
軟體缺陷分析
alan 缺陷分析本質上是對缺陷中包含的資訊項進行收集，彙總，分類之後使用統計方法 或者分析模型 得出分析結果。缺陷分析得出的結果可以用來度量軟體開發過程中各階段中工作產品的質量，了解缺陷集中的區域，明晰缺陷發展趨向。對於軟體過程的改進，軟體產品的發布來說具有十分重要的參考價值 在我們提交缺陷報告的...
軟體缺陷分析
我在marvell實習了一年多，期間主要做的軟體缺陷分析的工作，比如軟體缺陷的度量，風險分析等，結果一年多的不斷學習，我覺得這件事是非常的有意義，然後，國內很少有公司會選擇在這一塊投入，主要原因是這個過程需要長期的投入才能見成效，其次，風險也比較大。我主要會做一些軟體缺陷的分類統計，和缺陷累積量的 ...
18 軟體缺陷
定義 缺陷就是軟體的問題，最終表現為沒有滿足使用者的需求。軟體測試缺陷 1 軟體未達到規格說明書表明的功能 2 軟體出現了規格說明說中指明不會出現的錯誤。3 軟體功能超出了規格說明書指明的範圍 4 軟體未達到規格說明書雖未指明但應該達到的目標 5 軟體測試人員或使用者覺得不好。示例 1 計算器說明書...