今天看了一篇文章,覺得說的很有道理,現摘錄如下:
80% 的軟體缺陷常常生存在軟體 20% 的空間裡。這個原則告訴我們，如果你想使軟體測試有效地話，記住常常光臨其高危多發 「 地段 」 。在那裡發現軟體缺陷的可能性會大的多。這一原則對於軟體測試人員提高測試效率及缺陷發現率有著重大的意義。聰明的測試人員會根據這個原則很快找出較多的缺陷而愚蠢的測試人員卻仍在漫無目的地到處搜尋。
80-20 原則的另外一種情況是，我們在系統分析、系統設計、系統實現階段的複審，測試工作中能夠發現和避免 80% 的軟體缺陷，此後的系統測試能夠幫助我們找出剩餘缺陷中的 80% ，最後的 5% 的軟體缺陷可能只有在系統交付使用後使用者經過大範圍、長時間使用後才會曝露出來。因為軟體測試只能夠保證盡可能多地發現軟體缺陷，卻無法保證能夠發現所有的軟體缺陷。
80-20 原則還能反映到軟體測試的自動化方面上來，實踐證明 80% 的軟體缺陷可以借助人工測試而發現， 20% 的軟體缺陷可以借助自動化測試能夠得以發現。由於這二者間具有交叉的部分，因此尚有 5% 左右的軟體缺陷需要通過其他方式進行發現和修正。
為效益而測試
為什麼我們要實施軟體測試，是為了提高專案的質量效益最終以提高專案的總體效益。為此我們不難得出我們在實施軟體測試應該掌握的度。軟體測試應該在軟體測試成本和軟體質量效益兩者間找到乙個平衡點。這個平衡點就是我們在實施軟體測試時應該遵守的度。單方面的追求都必然損害軟體測試存在的價值和意義。一般說來，在軟體測試中我們應該盡量地保持軟體測試簡單性，切勿將軟體測試過度複雜化，拿物理學家愛因斯坦的話說就是： keep it ****** but not too ****** 。
缺陷的必然性
軟體測試中，由於錯誤的關聯性，並不是所有的軟體缺陷都能夠得以修復。某些軟體缺陷雖然能夠得以修復但在修復的過程中我們會難免引入新的軟體缺陷。很多軟體缺陷之間是相互矛盾的，乙個矛盾的消失必然會引發另外乙個矛盾的產生。比如我們在解決通用性的缺陷後往往會帶來執行效率上的缺陷。更何況在缺陷的修復過程中，我們常常還會受時間、成本等方面的限制因此無法有效、完整地修復所有的軟體缺陷。因此評估軟體缺陷的重要度、影響範圍，選擇乙個折中的方案或是從非軟體的因素（比如提公升硬體效能）考慮軟體缺陷成為我們在面對軟體缺陷時乙個必須直面的事實。
軟體測試必須有預期結果
沒有預期結果的測試是不可理喻的。軟體缺陷是經過對比而得出來的。這正如沒有標準無法進行度量一樣。如果我們事先不知道或是無法肯定預期的結果，我們必然無法了解測試正確性。這很容易然人感覺如盲人摸象一般，不少測試人員常常憑藉自身的感覺去評判軟體缺陷的發生，其結果往往是把似是而非的東西作為正確的結果來判斷，因此常常出現誤測的現象。
軟體測試的意義 - 事後分析 (個人覺得這一點非常重要)
軟體測試的目的單單是發現缺陷這麼簡單嗎？如果是 「 是 」 的話，我敢保證，類似的軟體缺陷在下一次新專案的軟體測試中還會發生。古語說得好， 「 不知道歷史的人必然會重蹈覆轍 」 。沒有對軟體測試結果進行認真的分析，我們就無法了解缺陷發生的原因和應對措施，結果是我們不得不耗費的大量的人力和物力來再次查詢軟體缺陷。很可惜，目前大多測試團隊都沒有意識到這一點，測試報告中缺乏測試結果分析這一環節。
結論：
軟體測試是乙個需要 「 自覺 」 的過程，作為乙個測試人員，遇事沉著，把持尺度，從根本上應對軟體測試有著正確的認識，希望本文對讀者對軟體測試的認識有所幫助
軟體測試中8020原則
80 的軟體缺陷常常生存在軟體20 的空間裡。這個原則告訴我們，如果你想使軟體測試有效地話，記住常常光臨其高危多發 地段 在那裡發現軟體缺陷的可能性會大的多。這一原則對於軟體測試人員提高測試效率及缺陷發現率有著重大的意義。聰明的測試人員會根據這個原則很快找出較多的缺陷而愚蠢的測試人員卻仍在漫無目的到...
軟體測試中的80 20原則
80 的軟體缺陷常常生存在軟體 20 的空間裡。這個原則告訴我們，如果你想使軟體測試有效地話，記住常常光臨其高危多發 地段 在那裡發現軟體缺陷的可能性會大的多。這一原則對於軟體測試人員提高測試效率及缺陷發現率有著重大的意義。聰明的測試人員會根據這個原則很快找出較多的缺陷而愚蠢的測試人員卻仍在漫無目的...
軟體測試的原則
1 測試用例中乙個必需部分是對預期輸出或者結果進行定義 2 程式設計師應當避免測試自己編寫的程式 3 編寫軟體的組織不應當測試自己編寫的軟體 4 應當徹底檢查每個測試的執行結果 5 測試用例的編寫不僅應當根據有效的和預料到的輸入情況，而且也應當根據無效和未預料到的輸入情況 6 檢查程式是否 未做其應...