軟件測試的重要性

1、軟件測試的重要性前言：軟件迅猛發(fā)展凸現(xiàn)軟件測試問題隨著軟件業(yè)蓬勃發(fā)展，各種軟件需求紛繁而來，在潮起潮落的IT洪流中，軟件項目越來越凸現(xiàn)大型化、復(fù)雜化的發(fā)展趨勢。幾十人上百人的開發(fā)團(tuán)隊、成千上萬的模塊與接口、跨地域、跨系統(tǒng)的使用用戶等情況早已屢見不鮮，所有這些，對項目質(zhì)量管理提出了更高要求，如何滿足各方需求，做出更好的軟件系統(tǒng)？測試管理逐漸成了大家目光的焦點。軟件的質(zhì)量靠什么，靠管理、靠各個軟件過程的嚴(yán)密配合。但勿庸置疑，質(zhì)量的守護(hù)是靠測試。它就象一只看門狗，認(rèn)真守護(hù)著軟件質(zhì)量這個“家”。軟件測試的重要性測試是什么？測試就是對項目開發(fā)過程的產(chǎn)品（編碼、文檔等）進(jìn)行差錯審查，保證其質(zhì)量的一種過程。

2、軟件業(yè)的迅猛發(fā)展也就是近幾十年的過程，時間雖短，但許多誤解似乎已根深蒂固，對測試的偏見也是如此?！败浖闹攸c在于需求、在于分析、在于設(shè)計、在于開發(fā)，而測試，容易，沒什么技術(shù)含量，找一些用戶，對照需求盡力去測就行了；有時間多測點，沒時間就少測點?！边@種看法在許多項目經(jīng)理、軟件負(fù)責(zé)人的心中固守著，難以改變。這種觀念的結(jié)果有目共睹，是什么？很簡單，是大量軟件BUG、缺陷的“流失”，從測試人員手中悄然而過，流失到用戶手中，流失進(jìn)項目維護(hù)階段。隨之而來的，便是用戶無休止的抱怨、維護(hù)人員無休止的“救火”、維護(hù)成本無休止的增加。這是軟件人員的夢魘！惡夢總有醒來時，經(jīng)過無數(shù)教訓(xùn)的重?fù)?，在不堪回首而不得回首的?jīng)

3、歷中，軟件業(yè)的管理者發(fā)現(xiàn)：是他們錯了，軟件測試是不可忽視的。“所有這些問題，假如在項目中測試到的話，便不會有造成不可收拾的結(jié)果了?！比藗兘K于意識到測試簡單而純真的真諦。軟件測試軟件測試從直觀上來講是對測試對象進(jìn)行檢查、驗證，似乎很簡單，但實際不然，它是由許多處理環(huán)節(jié)構(gòu)成的。根據(jù)測試目標(biāo)、質(zhì)量控制的要求，它被劃分為以下各類環(huán)節(jié)（如下圖），并被設(shè)置了不同的準(zhǔn)入、準(zhǔn)出標(biāo)準(zhǔn)。測試的主要過程及活動如上圖所示，內(nèi)容一目了然，在此就不一一詳述了，只希望通過對測試重點問題、關(guān)注熱點的介紹，幫助大家對測試管理有一個總體的把握。       &

4、#160;                測試方式中普遍存在的問題與點評    談到測試，我們無法回避的是當(dāng)前軟件過程普遍存在的測試問題：1、 手工過多，缺少測試工具，自動化測試方式缺失。傳統(tǒng)的項目測試還是以手工為主，測試人員根據(jù)需求規(guī)格說明書的要求，與測試對象進(jìn)行“人機(jī)對話”。隨著軟件業(yè)的不斷發(fā)展及軟件規(guī)模的擴(kuò)大，這種測試的弊端日益明顯：· 大量的手工使項目人力成本、溝通成本居高不下；·

5、; 人工操作的低效率使項目耗時增加，帶來進(jìn)度風(fēng)險；· 人員素質(zhì)及其他不確定因素會影響手工測試的結(jié)果，導(dǎo)致差錯率的增加。· 在測試過程中，需要對測試案例庫進(jìn)行統(tǒng)一配置管理，項目規(guī)模的激增使手工管理案例庫的難度日益加大，尤其是在需求變更、回歸測試頻繁發(fā)生的時候。從古到今，當(dāng)生產(chǎn)率阻礙了生產(chǎn)力的發(fā)展的時候，必然會引入更高級的生產(chǎn)工具及方式。項目測試也是這個道理，引入工具，引入自動化測試及管理，是項目測試的一大趨勢。2、 缺乏文檔測試、檢查。文檔是項目的重要產(chǎn)品之一，產(chǎn)品需求、功能分析、架構(gòu)設(shè)計、詳細(xì)設(shè)計、用戶手冊、維護(hù)手冊等等，對于項目的測

6、試、上線、維護(hù)等過程起到至關(guān)重要的參考、指導(dǎo)作用，所以它們的質(zhì)量應(yīng)該是項目重點關(guān)注點之一。令人遺憾的是，許多軟件項目對于文檔的重視只停留在口頭上，“編碼第一”的觀念似乎根深蒂固。隨著需求不斷變更、補(bǔ)充，業(yè)務(wù)、技術(shù)人員忙于應(yīng)付，無法騰出精力來進(jìn)行文檔內(nèi)容的修改及完善，往往是將包含需求變更內(nèi)容的工作聯(lián)系單往需求文檔后一附了事，而不去更新需求與其他相關(guān)文檔；另一方面，項目變更管理還不夠完善，管理重點往往集中于開發(fā)，而輕視文檔質(zhì)量管理，未留出充分的文檔更新時間，導(dǎo)致文檔更新嚴(yán)重滯后于編碼進(jìn)度。為保證文檔質(zhì)量，必須定期進(jìn)行文檔測試，但測試要花成本，項目高層不愿意付此代價。文檔若可讀性低，便會影響用戶的理

7、解；若與編碼不一致，便起不到參考作用，編碼測試就沒有可靠的測試依據(jù)。路都看不清楚，怎么往前走呀？所以，強(qiáng)烈建議進(jìn)行文檔測試，并將其置于測試管理的首位。當(dāng)前文檔測試的方法沒有什么特別的形式，還缺乏測試工具支持，通常是通過靜態(tài)審查方式“走查”來進(jìn)行的，主要查看文檔的可讀性，內(nèi)容真實性、可靠性、全面性。另外，在項目里程碑時期召集相關(guān)領(lǐng)域?qū)＜覍χ匾臋n進(jìn)行集中審核，也是一種檢查方式。   3、 單元測試應(yīng)引入交叉測試方法；單元測試是對軟件基本組成單元進(jìn)行的測試，測試對象是軟件模塊。通常，單元測試是由開發(fā)人員來完成，而且往往是各人測各人的。這存在問題隱患。為什么呢，技術(shù)人員

8、是軟件模塊的制造者，自己來測自己的軟件的話，角色便從制造者變成了審查者，而前一個角色的目的是為了保證軟件正確，后一個角色的目的是為了發(fā)現(xiàn)更多的缺陷，讓一個人同時來扮演兩種目的不同的角色，好比讓他既當(dāng)裁判員又當(dāng)運動員，怎么能做好呢？解決方法通常有兩種，一種是：由測試人員來進(jìn)行單元測試，這種方式要求測試人員要有較高的軟件技術(shù)知識；另一種是：將軟件人員分組，在模塊開發(fā)告一段落時進(jìn)行交叉測試，這種方法只需要測試者了解被測方的軟件需求，不需要另外的知識培訓(xùn)，而且測試出發(fā)點較為客觀，所以被較普遍的推廣使用。4、 測試在開發(fā)基本完成才啟動；在傳統(tǒng)的瀑布型開發(fā)模式中，軟件測試位于編碼階段之后，是作為

9、一個獨立階段存在的，許多人便一刀切地認(rèn)為應(yīng)該將所有的測試工作在編碼完成后再開始。這個觀點要不得，原因有二：首先，若將測試工作細(xì)分，有許多工作是可以提前先期執(zhí)行的，如：需求書與設(shè)計書的學(xué)習(xí)、測試計劃的制定、測試人員的培訓(xùn)、測試腳本的建立、測試資源的搭建、測試模板的創(chuàng)建、測試工具的選擇等等，都是可以與其他階段并行處理的，這將大大縮短項目開發(fā)時間，為測試提供充分的時間保障，提高測試質(zhì)量。其次，軟件缺陷發(fā)現(xiàn)的越晚，修改、補(bǔ)救所耗費的成本越高。引用Boehm在Software Engineering Economics一書中的話“平均而言，如果在需求階段修證一個錯誤的代價是1，那么，在設(shè)計階段就是它的3

10、6倍，在編程階段是它的10倍，在內(nèi)部測試階段是它的2040倍，在外部測試階段是它的3070倍，而到了產(chǎn)品發(fā)布出去時，這個數(shù)字就是401000倍?！庇纱丝梢姡瑴y試目標(biāo)的最佳定位應(yīng)該是：在錯誤第一次出現(xiàn)的時候就捕捉到它。所以，在盡可能的情況下，測試越早展開越好。在項目的各個進(jìn)行階段，都有不同的項目產(chǎn)品產(chǎn)生，他們質(zhì)量的好壞，對后續(xù)開發(fā)影響重大，所以，現(xiàn)在國際上比較流行的做法是：將測試融合到各個開發(fā)環(huán)節(jié)中去，盡早測試。5、 測試案例、測試方案的重用率低下。傳統(tǒng)的測試過程，測試管理不嚴(yán)密，測試人員未建立完整的測試庫，未將測試案例、測試程序、測試方案進(jìn)行有效保存，等到回歸測試時，相關(guān)測試程序等往

11、往已不知所終，無處可尋了；即使能找到這些程序、案例，可往往因為回歸測試過于頻繁、項目期限日益迫近，已經(jīng)沒有時間余量來修改、完善這些程序及案例，只能憑借經(jīng)驗、記憶及技術(shù)人員的口述對程序修改過的地方草草重測一遍而已，缺乏正規(guī)化的測試過程，造成測試的虎頭蛇尾。正常的測試案例使用方式如上圖，測試設(shè)計階段，相關(guān)測試設(shè)計人員會對測試對象進(jìn)行了解、分析，為保證測試順利進(jìn)行，保證測試覆蓋盡量多的測試對象，會設(shè)計測試案例、測試方案，在測試期間進(jìn)行使用；測試發(fā)現(xiàn)錯誤時，軟件技術(shù)人員會根據(jù)測試的缺陷反饋結(jié)果及技術(shù)人員的軟件修改信息對測試程序進(jìn)行修改，完畢后再進(jìn)行回歸測試。6、 測試人員素質(zhì)低，缺乏相關(guān)知識

12、培訓(xùn)。項目管理人員對測試存有偏見，對于測試的重要性認(rèn)識不足，導(dǎo)致其嚴(yán)重忽略測試人員的選拔和知識培訓(xùn)。許多軟件項目讓軟件用戶或新招收的技術(shù)人員來完成測試工作，他們認(rèn)為測試人員的工作很簡單，就是技術(shù)人員讓測什么就測什么，它基本是一個動手不動腦的工作。這樣做的后果進(jìn)一步導(dǎo)致了測試工作的無序和混亂，測試過程缺乏計劃性，測試人員缺乏技術(shù)能力，缺乏對架構(gòu)的了解，相關(guān)素質(zhì)的缺失使他們成為技術(shù)人員的附庸。測試對于他們來說，是一種枯燥的“手眼”式的工作，他們唯一渴望的，是將無聊的測試盡快完成，從而遠(yuǎn)遠(yuǎn)的逃離。這樣的測試結(jié)果可想而知。其實，軟件工程對測試人員的素質(zhì)要求是很嚴(yán)格的，比如：要有相關(guān)計算機(jī)知識背景、具備

13、軟件工程基本知識、熟悉項目編程語言、熟悉項目技術(shù)架構(gòu)及需求內(nèi)容、工作有責(zé)任感、獨立分析能力及團(tuán)隊精神等等。真正規(guī)范的軟件項目對于測試人員的要求是不會低于技術(shù)人員的，而且會為測試人員提供進(jìn)一步的知識培訓(xùn)機(jī)會，以應(yīng)對各種項目的復(fù)雜情況。7、 測試進(jìn)度的錯誤估算。在項目開發(fā)中，領(lǐng)導(dǎo)為督促測試的進(jìn)程，往往會讓項目組匯報工作進(jìn)度，了解已經(jīng)完成的工作占比，從而對工作進(jìn)度做出判斷。我對這種工作方式完全擁護(hù)，只是覺得這種方式還有不足。測試進(jìn)程不是簡單的11過程，不能武斷地認(rèn)為“我用8天干完了80的工作，那么，剩余工作便能在2天內(nèi)干完”。著名的Pareto80/20規(guī)律告訴我們：測試發(fā)現(xiàn)的所有錯誤中的

14、80很可能集中在20的程序模塊中，另外20很可能集中在80的程序模塊中。所以，沒有對測試對象認(rèn)真分析的基礎(chǔ)，單憑工作完成數(shù)量而對工作進(jìn)度做出的的判斷往往是錯誤的。我認(rèn)為，“工作實際進(jìn)度工作完成量占比測試對象的錯誤占比分析”才是一個較合理的測試進(jìn)度估算方式。   測試新思路：項目的開發(fā)風(fēng)險來自于對需求的誤解，來自于設(shè)計與開發(fā)過程及產(chǎn)品的缺陷，只有盡早發(fā)現(xiàn)這些缺陷，才能降低并控制項目風(fēng)險?；谶@種思想，軟件業(yè)出現(xiàn)了一些新的測試思路，主要有二：1、測試驅(qū)動開發(fā)（Test-Driven Development，簡稱TDD）。這種測試思想被最近流行的XP（Extreme Progra

15、mming）極限編程方式所大力提倡。它的基本思想是，通過測試來為編程做指導(dǎo)，在某個要開發(fā)的需求對象明確之后，在編碼之前，先進(jìn)行相關(guān)測試代碼（測試代碼的內(nèi)容和需求規(guī)格說明書描述是相同的，有人把它稱為“可執(zhí)行的需求規(guī)格說明書”）的編寫工作，完成之后針對測試代碼進(jìn)行編程，然后再用測試程序?qū)﹂_發(fā)代碼進(jìn)行測試，驗證其正確性，若程序通過了測試，就說明它是符合需求規(guī)格說明書要求的。周而復(fù)始，通過這樣的過程，開發(fā)進(jìn)程得以層層深入，直到開發(fā)完成。而這時單元測試也基本完成了。這種測試方式的最大的好處是，盡早地發(fā)現(xiàn)設(shè)計、開發(fā)中存在的問題，避免傳統(tǒng)開發(fā)模式中的“測試過程中發(fā)現(xiàn)代碼不能滿足需求而導(dǎo)致的大量返工”。降低項

16、目風(fēng)險；同時可以盡早地將“半成品”展示給客戶，使客戶對需求進(jìn)行驗證、補(bǔ)充及完善，另外測試代碼的表達(dá)方式相對準(zhǔn)確、無二義性，可以降低因需求理解錯誤而導(dǎo)致的項目風(fēng)險。2、迭代測試。這種測試是IBM所推崇測試方式之一，它從迭代式開發(fā)模式演變而來。在迭代開發(fā)模式中，每個迭代都包含需求、設(shè)計、編碼、集成、測試等過程。在每一次迭代完成之后，便會開始新的迭代過程。通過一次次迭代的累進(jìn)，系統(tǒng)會增量式集成一些新的功能，直至整個系統(tǒng)功能的完成。其中，每個迭代周期的測試工作由兩方面內(nèi)容構(gòu)成：· 對當(dāng)前迭代周期產(chǎn)品的增量測試。· 對前迭代周期已完成功能的回歸測試。隨著迭代周期的

17、累進(jìn)，測試工作內(nèi)容隨之不斷變化。早期迭代測試重點在于新功能的測試，后期迭代測試重點在于累積功能的回歸測試。有的人不喜歡XP編程的開發(fā)方式，認(rèn)為其沒有明確的階段性劃分，不利于計劃管理，模式過于靈活，不好掌握。迭代式開發(fā)模式為這些人提供了新的選擇。這種開發(fā)方式繼承了瀑布式開發(fā)模式的優(yōu)點全面、嚴(yán)謹(jǐn)、有計劃性、易管理，更重要的是，這種模式將測試工作分布到每個迭代周期中，使測試工作提前進(jìn)行，從而使將發(fā)現(xiàn)軟件缺陷的周期提前，大大降低軟件風(fēng)險及開發(fā)成本。測試過程的衡量測試過程在不斷地改進(jìn)，但效果如何，如何來衡量測試的效果呢？我們需要引入一把尺子，一個度量標(biāo)準(zhǔn)，這樣才能把握測試過程的改進(jìn)方向。那么，怎樣來收集

18、數(shù)據(jù)，如何來度量？這是我們長久以來一直困惑的地方。我們不妨借助“他山之石”來想想辦法，CMMI是當(dāng)今國際流行的軟件過程衡量模型，它在這方面是有自己的獨到之處的：1、 面向全局。CMMI的測試度量面向的不僅僅是測試過程的改進(jìn)，測試效果的加強(qiáng)，它面向的是整個開發(fā)過程，并始終將質(zhì)量監(jiān)督放在工作首位。比如，它度量工作產(chǎn)品規(guī)模（例如代碼行數(shù)），度量工作量和成本（例如人工小時數(shù)）。我們從中搜集的數(shù)據(jù)對整個開發(fā)過程的改進(jìn)都有指導(dǎo)作用。更高的起點可使我們避免項目管理改進(jìn)過程中常見的“頭痛醫(yī)頭、腳痛醫(yī)腳”毛病。2、 建立度量數(shù)據(jù)庫，從而對搜集的數(shù)據(jù)、分析的方式及結(jié)果進(jìn)行完整、規(guī)范的保存。這個數(shù)據(jù)庫面向的是軟件開發(fā)過程的持續(xù)改進(jìn)，它的數(shù)據(jù)是可復(fù)用的，可供多個項目參考使用，不隨當(dāng)前項目的結(jié)束而消失，而是會作為歷史信息持續(xù)保存，從而為測試及其他軟件過程的改進(jìn)提供更客觀、更全面的度量數(shù)據(jù)。3、 關(guān)注度