你的組織測試工作管理的怎么樣？測試管理中可能存在的問題及分析(4)

　　3.2.3 測試是“泛型概念”(全程測試)

　　如果單純的只將程序設計階段后的階段稱之為軟件測試的話，需求階段和設計階段的缺陷產生的放大效應會加大。這非常不利于保證軟件質量。需求缺陷、設計缺陷也是軟件缺陷，記住“軟件缺陷具有生育能力”。軟件測試應該跨越整個軟件開發流程。需求驗證(自檢)和設計驗證(自檢)也可以算作軟件測試(建議稱為：需求測試和設計測試)的一種。軟件測試應該是一個泛型概念，涵蓋整個軟件生命周期，這樣才能確保周期的每個階段禁得起考驗。同時測試本身也需要有第三者進行評估(信息系統審計和軟件工程監理)，即測試本身也應當被測試，從而確保測試自身的可靠性和高效性。

　　3.2.4 軟件缺陷具有空間聚集性(80-20 原則)

　　80%的軟件缺陷常常生存在軟件20%的空間里。這個原則告訴我們，如果你想使軟件測試有效地話，記住常常光臨其高危多發“地段”。在那里發現軟件缺陷的可能性會大的多。這一原則對于軟件測試人員提高測試效率及缺陷發現率有著重大的意義。聰明的測試人員會根據這個原則很快找出較多的缺陷而愚蠢的測試人員卻仍在漫無目的地到處搜尋。

　　80-20 原則的另外一種情況是，我們在系統分析、系統設計、系統實現階段的復審，測試工作中能夠發現和避免80%的軟件缺陷，此后的系統測試能夠幫助我們找出剩余缺陷中的80%，最后的5%的軟件缺陷可能只有在系統交付使用后用戶經過大范圍、長時間使用后才會曝露出來。因為軟件測試只能夠保證盡可能多地發現軟件缺陷，卻無法保證能夠發現所有的軟件缺陷。

　　3.2.5 為效益而測試

　　為什么我們要實施軟件測試，是為了提高項目的質量效益最終以提高項目的總體效益。為此我們不難得出我們在實施軟件測試應該掌握的度。軟件測試應該在軟件測試成本和軟件質量效益兩者間找到一個平衡點。這個平衡點就是我們在實施軟件測試時應該遵守的度。單方面的追求都必然損害軟件測試存在的價值和意義。一般說來，在軟件測試中我們應該盡量地保持軟件測試簡單性，切勿將軟件測試過度復雜化。

　　3.2.6 缺陷的必然性

　　軟件測試中，由于錯誤的關聯性，并不是所有的軟件缺陷都能夠得以修復。某些軟件缺陷雖然能夠得以修復但在修復的過程中我們會難免引入新的軟件缺陷。很多軟件缺陷之間是相互矛盾的，一個矛盾的消失必然會引發另外一個矛盾的產生。比如我們在解決通用性的缺陷后往往會帶來執行效率上的缺陷。更何況在缺陷的修復過程中，我們常常還會受時間、成本等方面的限制因此無法有效、完整地修復所有的軟件缺陷。因此評估軟件缺陷的重要度、影響范圍，選擇一個折中的方案或是從非軟件的因素(比如提升硬件性能)考慮軟件缺陷成為我們在面對軟件缺陷時一個必須直面的事實。

　　3.3 測試組織管理不專業

　　1、測試人員不獨立于開發者，測試人員獨立于開發者的程度將影響測試結果。

　　人很容易用自己已經非常仔細地做過測試來欺騙自己，開發人員做測試容易受到個人的習慣性想法的影響，程序中可能包含由于程序員對問題的敘述或說明的誤解而產生的錯誤。如果是這種情況，當開發人員測試自己的程序時，往往還會帶著同樣的誤解致使問題難以發現。開發和測試是兩種不同的活動，開發人員對自己的程序進行一定的審查、調試是必要的，但是一般情況下還需要另外的專業測試者進行測試。不過，由于有的企業中，人力有限，或者認為沒有足夠的資源或理由支持一支測試隊伍，有時不得不由開發人員測試;那么，開發者對自己的程序的測試需要注意許多問題，或者應由另外的開發者對自己的程序進行測試。

　　2、測試時間安排往往計劃不周，測試計劃有時受制于開發計劃。

　　3、測試等級以及在那個等級上的測試時間往往選擇不當。

　　4、測試輔助設備和測試工具將影響開發者的測試效率及測試徹底性。

　　5、測試策略文檔的普遍缺失。

　　6、測試范圍的確認經常被其他文檔或經驗所取代。

　　7、測試任務應該像BUG 一樣有明確的分級，不同類型的測試應該有相應的測試用例集合與之對應。

　　8、關鍵路徑概念在測試規劃時容易被項目經理弱化。

原文轉自：http://www.uml.org.cn/Test/201307104.asp