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

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

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

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

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

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

　　3.2.5 為效益而測試

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

　　3.2.6 缺陷的必然性

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

　　3.3 測試組織管理不專(zhuān)業(yè)

　　1、測試人員不獨立于開(kāi)發(fā)者，測試人員獨立于開(kāi)發(fā)者的程度將影響測試結果。

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

　　2、測試時(shí)間安排往往計劃不周，測試計劃有時(shí)受制于開(kāi)發(fā)計劃。

　　3、測試等級以及在那個(gè)等級上的測試時(shí)間往往選擇不當。

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

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

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

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

　　8、關(guān)鍵路徑概念在測試規劃時(shí)容易被項目經(jīng)理弱化。

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