軟體開發和使用的歷史已經留給了我們很多由於軟體缺陷而導致的巨大財力、物力損失的經驗教訓。這些經驗教訓迫使我們這些測試工程師們必須採取強有力的檢測措施來檢測未發現的隱藏的軟體缺陷。
生產軟體的最終目的是為了滿足客戶需求，我們以客戶需求作為評判軟體質量的標準，認為軟體缺陷（ software bug ）的具體含義包括下面幾個因素：
☆ 軟體未達到客戶需求的功能和效能；
☆ 軟體超出客戶需求的範圍；
☆ 軟體出現客戶需求不能容忍的錯誤；
☆ 軟體的使用未能符合客戶的習慣和工作環境。
考慮到設計等方面的因素，我們還可以認為軟體缺陷還可以包括軟體設計不符合規範，未能在特定的條件（資金、範圍等）達到最佳等。可惜的是，我們中的很多人更傾向於把軟體缺陷看成執行時出現問題上來，認為軟體測試僅限於程式提交之後。
在目前的國內環境下，我們幾乎看不到完整準確的客戶需求說明書，加以客戶的需求時時在變，追求完美的測試變得不太可能。因此作為乙個優異的測試人員，追求軟體質量的完美固然是我們的宗旨，但是明確軟體測試現實與理想的差距，在軟體測試中學會取捨和讓步，對軟體測試是有百益而無一弊的。
下面是一些軟體測試的常識，對這些常識的理解和運用將有助於我們在進行軟體測試時能夠更好的把握軟體測試的尺度。
☆ 測試是不完全的（測試不完全）
很顯然，由於軟體需求的不完整性、軟體邏輯路徑的組合性、輸入資料的大量性及結果多樣性等因素，哪怕是乙個極其簡單的程式，要想窮盡所有邏輯路徑，所有輸入資料和驗證所有結果是非常困難的一件事情。我們舉乙個簡單的例子，比如說求兩個整數的最大公約數。其輸入資訊為兩個正整數。但是如果我們將整個正整數域的數字進行一番測試的話，從其數目的無限性我們便可證明是這樣的測試在實際生活中是行不通的，即便某一天我們能夠窮盡該程式，只怕我們乃至我們的子孫都早已作古了。為此作為軟體測試，我們一般採用等價類和邊界值分析等措施來進行實際的軟體測試，尋找最小用例集合成為我們精簡測試複雜性的一條必經之道。
☆ 測試具有免疫性（軟體缺陷免疫性）
軟體缺陷與病毒一樣具有可怕的 「 免疫性 」 ，測試人員對其採用的測試越多，其免疫能力就越強，尋找更多軟體缺陷就更加困難。由數學上的概率論我們可以推出這一結論。假設乙個 50000 行的程式中有 500 個軟體缺陷並且這些軟體錯誤分布時均勻的，則每 100 行可以找到乙個軟體缺陷。我們假設測試人員用某種方法花在查詢軟體缺陷的精力為 x 小時 /100 行。照此推算，軟體存在 500 個缺陷時，我們查詢乙個軟體缺陷需要 x 小時，當軟體只存在 5 個錯誤時，我們每查詢乙個軟體缺陷需要 100x 小時。實踐證明，實際的測試過程比上面的假設更為苛刻，為此我們必須更換不同的測試方式和測試資料。該例子還說明了在軟體測試中採用單一的方法不能高效和完全的針對所有軟體缺陷，因此軟體測試應該盡可能的多採用多種途徑進行測試。
☆ 測試是 「 泛型概念 」 （全程測試）
我一直反對軟體測試僅存在於程式完成之後。如果單純的只將程式設計階段後的階段稱之為軟體測試的話，需求階段和設計階段的缺陷產生的放大效應會加大。這非常不利於保證軟體質量。需求缺陷、設計缺陷也是軟體缺陷，記住 「 軟體缺陷具有生育能力 」 。軟體測試應該跨越整個軟體開發流程。需求驗證（自檢）和設計驗證（自檢）也可以算作軟體測試（建議稱為：需求測試和設計測試）的一種。軟體測試應該是乙個泛型概念，涵蓋整個軟體生命週期，這樣才能確保週期的每個階段禁得起考驗。同時測試本身也需要有第三者進行評估（資訊系統審計和軟體工程監理），即測試本身也應當被測試，從而確保測試自身的可靠性和高效性。否則自身不正，難以服人。
另外還需指出的是軟體測試是提高軟體產品質量的必要條件而非充分條件，軟體測試是提高產品質量最直接、最快捷的手段，但決不是乙個根本手段。
☆ 80-20 原則
80% 的軟體缺陷常常生存在軟體 20% 的空間裡。這個原則告訴我們，如果你想使軟體測試有效地話，記住常常光臨其高危多發 「 地段 」 。在那裡發現軟體缺陷的可能性會大的多。這一原則對於軟體測試人員提高測試效率及缺陷發現率有著重大的意義。聰明的測試人員會根據這個原則很快找出較多的缺陷而愚蠢的測試人員卻仍在漫無目的地到處搜尋。
80-20 原則的另外一種情況是，我們在系統分析、系統設計、系統實現階段的複審，測試工作中能夠發現和避免 80% 的軟體缺陷，此後的系統測試能夠幫助我們找出剩餘缺陷中的 80% ，最後的 5% 的軟體缺陷可能只有在系統交付使用後使用者經過大範圍、長時間使用後才會曝露出來。因為軟體測試只能夠保證盡可能多地發現軟體缺陷，卻無法保證能夠發現所有的軟體缺陷。
80-20 原則還能反映到軟體測試的自動化方面上來，實踐證明 80% 的軟體缺陷可以借助人工測試而發現， 20% 的軟體缺陷可以借助自動化測試能夠得以發現。由於這二者間具有交叉的部分，因此尚有 5% 左右的軟體缺陷需要通過其他方式進行發現和修正。
☆ 為效益而測試
為什麼我們要實施軟體測試，是為了提高專案的質量效益最終以提高專案的總體效益。為此我們不難得出我們在實施軟體測試應該掌握的度。軟體測試應該在軟體測試成本和軟體質量效益兩者間找到乙個平衡點。這個平衡點就是我們在實施軟體測試時應該遵守的度。單方面的追求都必然損害軟體測試存在的價值和意義。一般說來，在軟體測試中我們應該盡量地保持軟體測試簡單性，切勿將軟體測試過度複雜化，拿物理學家愛因斯坦的話說就是： keep it ****** but not too ****** 。
☆ 缺陷的必然性
軟體測試中，由於錯誤的關聯性，並不是所有的軟體缺陷都能夠得以修復。某些軟體缺陷雖然能夠得以修復但在修復的過程中我們會難免引入新的軟體缺陷。很多軟體缺陷之間是相互矛盾的，乙個矛盾的消失必然會引發另外乙個矛盾的產生。比如我們在解決通用性的缺陷後往往會帶來執行效率上的缺陷。更何況在缺陷的修復過程中，我們常常還會受時間、成本等方面的限制因此無法有效、完整地修復所有的軟體缺陷。因此評估軟體缺陷的重要度、影響範圍，選擇乙個折中的方案或是從非軟體的因素（比如提公升硬體效能）考慮軟體缺陷成為我們在面對軟體缺陷時乙個必須直面的事實。
☆ 軟體測試必須有預期結果
沒有預期結果的測試是不可理喻的。軟體缺陷是經過對比而得出來的。這正如沒有標準無法進行度量一樣。如果我們事先不知道或是無法肯定預期的結果，我們必然無法了解測試正確性。這很容易然人感覺如盲人摸象一般，不少測試人員常常憑藉自身的感覺去評判軟體缺陷的發生，其結果往往是把似是而非的東西作為正確的結果來判斷，因此常常出現誤測的現象。
☆ 軟體測試的意義 - 事後分析
軟體測試的目的單單是發現缺陷這麼簡單嗎？如果是 「 是 」 的話，我敢保證，類似的軟體缺陷在下一次新專案的軟體測試中還會發生。古語說得好， 「 不知道歷史的人必然會重蹈覆轍 」 。沒有對軟體測試結果進行認真的分析，我們就無法了解缺陷發生的原因和應對措施，結果是我們不得不耗費的大量的人力和物力來再次查詢軟體缺陷。很可惜，目前大多測試團隊都沒有意識到這一點，測試報告中缺乏測試結果分析這一環節。
結論：軟體測試是乙個需要 「 自覺 」 的過程，作為乙個測試人員，遇事沉著，把持尺度，從根本上應對軟體測試有著正確的認識，希望本文對讀者對軟體測試的認識有所幫助。
這些軟體測試行業的內幕你知道多少
能做，和能做好，中間差了很多，如何高效 全面的測試出軟體中的bug，這是值錢的地方。如果說軟體測試無非就是寫幾個測試用例，再去執行，再把bug彙總。那麼，程式設計師無非也就是寫幾行 實現需求。產品經理無非也就是提出需求，讓技術實現。運營無非就是打廣告而已。ui無非就是做介面的。軟體測試的起源要追溯到...
sizeof,你知道多少
今天去參加面試，筆試的第一道題就是這個sizeof的用法，考了六七個，平時覺得很熟，真拿來考到迷糊了。有必要再總結一下。題是這樣的 在32位作業系統環境下，請問以下sizeof的值各是多少。一 int p 10 sizeof p 這個就簡單，int型變數p佔4個位元組，答案就是4.二 char p ...
Java Enum，你知道多少？
引用的列舉型別 public enum state 遍歷 for state s state.values 可以使用switch 列舉變數把列舉值作為case條件。enumsetstateset enumset.allof state.class for state s stateset enumm...