《軟件測試基礎(chǔ)》課件-第1章

第1章軟件測試概論

1.1軟件1.2軟件過程1.3軟件質(zhì)量1.4測試與開發(fā)的關(guān)系1.5思考與習(xí)題

1.1軟件

1.1.1軟件發(fā)展史

軟件的發(fā)展經(jīng)歷了如下幾個階段：

第一階段從20世紀50年代初期至60年代中期，這一階段又稱為程序設(shè)計階段。此時硬件已經(jīng)通用化，而軟件的生產(chǎn)卻是個體化。軟件產(chǎn)品為專用軟件，規(guī)模較小，功能單一，開發(fā)者即為使用者，軟件只有程序，無文檔。軟件設(shè)計在人們的頭腦中完成，形成了“軟件等于程序”的錯誤觀念。第二階段從20世紀60年代中期至70年代末期，稱為程序系統(tǒng)階段。此時多道程序設(shè)計技術(shù)、多用戶系統(tǒng)、人機交互技術(shù)、實時系統(tǒng)和第一代數(shù)據(jù)庫管理系統(tǒng)的出現(xiàn)，催生了專門從事軟件開發(fā)的“軟件作坊”，軟件廣泛應(yīng)用，但軟件技術(shù)和管理水平相對落后，導(dǎo)致“軟件危機”出現(xiàn)。軟件危機主要表現(xiàn)在以下幾個方面：

(1)軟件項目無法按期完成，超出經(jīng)費預(yù)算，軟件質(zhì)量難以控制；

(2)開發(fā)人員和開發(fā)過程之間管理不規(guī)范，約定不嚴密，文檔書寫不完整，使得軟件維護費用高，某些系統(tǒng)甚至無法進行修改；

(3)缺乏嚴密、有效的質(zhì)量檢測手段，交付給用戶的軟件質(zhì)量差，在運行中出現(xiàn)許多問題，甚至產(chǎn)生嚴重的后果；

(4)系統(tǒng)更新?lián)Q代難度大。第三階段從20世紀70年代末期至80年代中期稱為軟件工程階段。微處理器的出現(xiàn)及分布式系統(tǒng)的廣泛應(yīng)用，使得計算機真正成為大眾化的東西。以軟件的產(chǎn)品化、系列化、工程化和標準化為特征的軟件產(chǎn)業(yè)發(fā)展起來，軟件開發(fā)有了可以遵循的軟件工程化的設(shè)計準則、方法和標準。1968年，北大西洋公約組織的計算機科學(xué)家在聯(lián)邦德國召開國際會議，會議討論了軟件危機問題，正式提出并使用“軟件工程”概念。這標志著軟件工程的誕生。第四階段從20世紀80年代中期至今，客戶端/服務(wù)器(C/S)體系結(jié)構(gòu)，特別是Web技術(shù)和網(wǎng)絡(luò)分布式對象技術(shù)的飛速發(fā)展，導(dǎo)致軟件系統(tǒng)體系結(jié)構(gòu)向更加靈活的多層分布式結(jié)構(gòu)演變，CORBA、EJB、COM/DCOM等三大分布式的對象模型技術(shù)相繼出現(xiàn)。

2006年提出的面向服務(wù)架構(gòu)(Service-OrientedArchitecture，簡稱SOA)作為下一代軟件架構(gòu)，是一種“抽象、松散耦合和粗粒度”的軟件架構(gòu)，根據(jù)需求通過網(wǎng)絡(luò)對松散耦合的粗粒度應(yīng)用組件進行分布式部署、組合和使用，主要用于解決傳統(tǒng)對象模型中無法解決的異構(gòu)和耦合問題。1.1.2軟件生命周期

軟件生命周期具有如下六個階段：

(1)問題的定義及規(guī)劃。此階段由軟件開發(fā)方與需求方共同討論，確定軟件的開發(fā)目標及其可行性。

(2)需求分析。在確定軟件開發(fā)可行的情況下，對軟件需要實現(xiàn)的各個功能進行詳細分析。需求分析階段作為一個很重要的階段，在整個軟件開發(fā)過程中是不斷變化和深入的，因此必須制定需求變更計劃來應(yīng)付這種變化，以保護整個項目的順利進行。

(3)軟件設(shè)計。此階段主要根據(jù)需求分析的結(jié)果，對整個軟件系統(tǒng)進行設(shè)計，如系統(tǒng)框架設(shè)計、數(shù)據(jù)庫設(shè)計等。軟件設(shè)計一般分為總體設(shè)計和詳細設(shè)計。

(4)程序編碼。此階段是將軟件設(shè)計的結(jié)果轉(zhuǎn)換成計算機可運行的程序代碼。程序編碼必須符合標準的編寫規(guī)范，以保證程序的可讀性、易維護性，提高程序的運行效率。

(5)軟件測試。在軟件設(shè)計完成后要經(jīng)過嚴密的測試，以發(fā)現(xiàn)軟件在整個設(shè)計過程中存在的問題并加以糾正。整個測試過程分為單元測試、組裝測試以及系統(tǒng)測試等階段。測試的方法主要有白盒測試和黑盒測試兩種。在測試過程中需要建立詳細的測試計劃并嚴格按照測試計劃進行測試，以減少測試的隨意性。

(6)運行維護。軟件維護是軟件生命周期中持續(xù)時間最長的階段。在軟件開發(fā)完成并投入使用后，由于多方面的原因，軟件有可能不適應(yīng)用戶的要求，要延續(xù)軟件的使用壽命，此時就必須對軟件進行維護。1.1.3軟件缺陷

1.軟件缺陷案例

讓我們回顧一些“臭名昭著”的軟件缺陷案例，它們都是由于軟件測試不充分而導(dǎo)致的嚴重問題。

1963年，由于用FORTRAN程序設(shè)計語言編寫的飛行控制軟件中的循環(huán)語句“DO5I=1，3”誤寫為“DO5I=1.3”，結(jié)果導(dǎo)致美國首次金星探測飛行失敗，造成價值約1000多萬美元的損失。

1979年，新西蘭航空公司的一架客機因計算機控制的自動飛行系統(tǒng)發(fā)生故障而撞在阿爾卑斯山上，機上257名乘客全部遇難。

1983年，美國科羅拉多河水泛濫，但由于計算機對天氣形勢預(yù)測有誤，水庫未能及時泄洪，以致造成嚴重的經(jīng)濟損失和人員傷亡。

1990年1月15日，通信中轉(zhuǎn)系統(tǒng)軟件發(fā)生故障，導(dǎo)致主干遠程網(wǎng)大規(guī)模崩潰，使數(shù)以千計的電信運營公司損失慘重。

1992年10月26日，倫敦救護中心的計算機輔助發(fā)送系統(tǒng)剛啟動就崩潰了，導(dǎo)致這個全世界最大的(每天要接運五千多名病人)救護機構(gòu)全部癱瘓。

1994年，美國迪士尼公司的“獅子王”軟件在少數(shù)系統(tǒng)中能正常工作，但在大眾使用的常見系統(tǒng)中無法正常運行。后來證實，這是由于迪士尼公司沒有對市場上投入使用的各種PC機型進行正確的測試。同年，英特爾奔騰浮點除法發(fā)生軟件缺陷，英特爾為處理軟件缺陷支付了4億多美元。

1996年6月4日，歐洲航空航天局耗資80億美元發(fā)射的阿里亞娜501火箭，在發(fā)射升空37秒后爆炸。原因是主發(fā)動機打火順序開始37秒后，制導(dǎo)信息由于慣性制導(dǎo)系統(tǒng)的軟件出現(xiàn)規(guī)格和設(shè)計錯誤而完全丟失。

臨近2000年時，計算機業(yè)界一片恐慌，導(dǎo)致這種現(xiàn)象發(fā)生的就是著名的“千年蟲”問題。其原因是在20世紀70年代，由于計算機硬件資源很珍貴，程序員為節(jié)約內(nèi)存資源和硬盤空間，在存儲日期數(shù)據(jù)時，只保留年份的后2位，如“1980”被存儲為“80”。當2000年到來時，問題出現(xiàn)了，計算機無法分清“00”是指“2000年”還是“1000年”。例如銀行存款的軟件在計算利息時，用日期“00”減去當時存款的日期，結(jié)果存款年數(shù)就變?yōu)樨摂?shù)，導(dǎo)致顧客反要付給銀行巨額的利息。為了解決“千年蟲”問題，花費了大量的人力、物力和財力。

2008年，我國舉辦了首次奧運會。2007年10月30日上午9時，北京奧運會門票面向境內(nèi)公眾銷售第二階段正式啟動，系統(tǒng)訪問流量猛增，官方票務(wù)網(wǎng)站流量瞬時達到每小時800萬次，超過了系統(tǒng)設(shè)計每小時100萬次的承受量，奧運門票系統(tǒng)訪問量超過原計劃的8倍，造成網(wǎng)絡(luò)擁堵，售票速度慢或暫時不能登錄系統(tǒng)的情況，直接造成公眾無法及時提交購票申請，北京奧運票務(wù)中心就此向廣大境內(nèi)公眾購票人發(fā)布了致歉信。

2.軟件缺陷概念

軟件缺陷是指軟件系統(tǒng)或系統(tǒng)部件中那些導(dǎo)致系統(tǒng)或部件不能實現(xiàn)其功能的問題或差錯。通常認為，符合下面4個規(guī)則之一的就是軟件缺陷。

(1)軟件未達到軟件規(guī)格說明書中規(guī)定的功能；

(2)軟件出現(xiàn)了產(chǎn)品說明書中指明不會出現(xiàn)的錯誤；

(3)軟件功能超出了產(chǎn)品說明書中指明的范圍；

(4)軟件測試人員認為軟件難于理解，不易使用，運行速度慢，或者最終用戶認為軟件使用效果不好。

3.軟件缺陷分類

按照CMM5中定義的規(guī)范，軟件缺陷分為多個等級，分別為致命、嚴重、一般和提示。

(1)致命。致命性漏洞主要為：內(nèi)存泄漏、用戶數(shù)據(jù)丟失或被破壞、系統(tǒng)崩潰/死機/凍結(jié)、模塊無法啟動或異常退出、嚴重的數(shù)值計算錯誤、功能設(shè)計與需求嚴重不符、其它導(dǎo)致無法測試的錯誤和造成系統(tǒng)不穩(wěn)定等情況。

(2)嚴重。嚴重性漏洞主要為：功能未實現(xiàn)、功能嚴重錯誤、系統(tǒng)刷新錯誤、語音或數(shù)據(jù)通信錯誤、輕微的數(shù)值計算錯誤、系統(tǒng)所提供的功能或服務(wù)受明顯的影響但不會影響到系統(tǒng)穩(wěn)定性。

(3)一般。一般性漏洞主要為：操作界面錯誤(包括數(shù)據(jù)窗口內(nèi)列名定義、含義是否一致)、邊界條件下錯誤、提示信息錯誤(包括未給出信息、信息提示錯誤等)、長時間操作無進度提示、系統(tǒng)未優(yōu)化(性能問題)、光標跳轉(zhuǎn)設(shè)置不好、鼠標(光標)定位錯誤等。

(4)提示。提示性漏洞主要為：界面格式等不規(guī)范、輔助說明描述不清楚、操作時未給出用戶提示、可輸入?yún)^(qū)域和只讀區(qū)域沒有明顯的區(qū)分標志、個別不影響產(chǎn)品理解的錯別字、文字排列不整齊等一些小問題及建議。1.1.4三種糾錯技術(shù)

糾錯先要查錯。查錯的工作量通常占整個糾錯的90%以上。下面介紹幾種常用的查明程序錯誤時可能采用的工具和手段，這些方法能明顯提高查錯的效率。

1)插入打印語句

在程序中插入暫時性的打印語句，是一種十分常見的查錯技術(shù)。這類打印語句的作用主要是顯示程序的中間結(jié)果或有關(guān)變量的內(nèi)容。插入打印語句適用于任何高級語言編寫的程序。

2)設(shè)置斷點

查錯的基本技術(shù)之一，就是在程序的可疑區(qū)設(shè)置斷點。每當程序執(zhí)行到設(shè)置的斷點時，就會暫停執(zhí)行，以便糾錯者觀察變量內(nèi)容和分析程序的運行狀況。

3)掩蔽部分程序

對可疑程序進行檢查時，常常要讓程序反復(fù)執(zhí)行。如果整個程序較長，可疑區(qū)僅占其中的一小部分，則每次運行整個程序必將浪費許多時間和精力。在這種情況下，往往將不需要檢查的程序掩蔽起來，只讓可疑的部分程序反復(fù)運行。

掩蔽無關(guān)程序可使用下述方法：

(1)在要掩蔽的語句行加上注釋符。

(2)把要掩蔽的程序段置入“常假”的選擇結(jié)構(gòu)中，使其無法執(zhí)行。

1.2軟件過程

1.2.1RUP

1．RUP各個階段

RUP中的軟件生命周期在時間上被分解為4個順序的階段，分別是初始階段、細化階段、構(gòu)建階段和交付階段。每個階段結(jié)束于一個主要的里程碑；每個階段本質(zhì)上是兩個里程碑之間的時間跨度。在每個階段的結(jié)尾執(zhí)行一次評估以確定這個階段的目標是否已經(jīng)滿足，如果評估結(jié)果滿意，則允許項目進入下一個階段。其中每個階段又可以進一步分解迭代。一個迭代是一個完整的開發(fā)循環(huán)，產(chǎn)生一個可執(zhí)行的產(chǎn)品版本，作為最終產(chǎn)品的一個子集，產(chǎn)品增量式地發(fā)展，從一個迭代過程到另一個迭代過程，直到成為最終的系統(tǒng)。如圖1.1所示，RUP可用二維坐標來描述。橫軸通過時間組織，是過程展開的生命周期特征，體現(xiàn)開發(fā)過程的動態(tài)結(jié)構(gòu)，用來描述它的術(shù)語主要包括周期、階段、迭代和里程碑；縱軸以內(nèi)容來組織，體現(xiàn)開發(fā)過程的靜態(tài)結(jié)構(gòu)，用來描述它的術(shù)語主要包括活動、產(chǎn)物、工作者和工作流。圖1.1RUP的過程圖

1)初始階段

初始階段的目標是為系統(tǒng)建立商業(yè)案例并確定項目的邊界。為了達到該目標必須識別所有與系統(tǒng)交互的外部實體，并在較高層次上定義交互的特性。這包括識別出所有用例并描述幾個重要的用例。本階段具有非常重要的意義，在這個階段中所關(guān)注的是整個項目進行中的業(yè)務(wù)和需求方面的主要風險。對于建立在已有系統(tǒng)基礎(chǔ)上的開發(fā)項目來講，初始階段可能很短。在初始階段應(yīng)該取得如下成果：

(1)藍圖文檔，即關(guān)于項目的核心需求、關(guān)鍵特性、主約束的總體藍圖。

(2)初始的用例模型(約占總體的10%～20%)。

(3)初始的項目術(shù)語表。

(4)初始的商業(yè)案例，包括商業(yè)環(huán)境、驗收標準等。

(5)初始的風險評估。

(6)項目計劃。

(7)一個或多個原型。

2)細化階段

細化階段的目標是分析問題領(lǐng)域，建立堅實的體系結(jié)構(gòu)基礎(chǔ)，制定項目計劃，消除項目中風險最高的因素。為了達到該目標，必須在理解整個系統(tǒng)的基礎(chǔ)上，對體系結(jié)構(gòu)作出決策，包括其范圍、主要功能和諸如性能等非功能需求，同時為項目建立支持環(huán)境，包括創(chuàng)建開發(fā)案例，創(chuàng)建模板、工作準則并準備工具。細化階段的成果包括：

(1)用例模型。所有的用例和參與者都已被識別出，并完成大部分的用例描述。

(2)補充非功能性要求以及與特定用例沒有關(guān)聯(lián)的需求。

(3)軟件體系結(jié)構(gòu)的描述。

(4)可執(zhí)行的軟件原型。

(5)修訂過的風險清單和商業(yè)案例。

(6)整個項目的開發(fā)計劃，該開發(fā)計劃應(yīng)體現(xiàn)迭代過程和每次迭代的評價標準。

(7)更新的開發(fā)案例。

(8)初步的用戶手冊。

3)構(gòu)建階段

在構(gòu)建階段，組件和應(yīng)用程序的其余功能被開發(fā)并集成為產(chǎn)品，所有的功能都被徹底地測試。從某種意義上說，構(gòu)建階段是一個制造過程，其重點為管理資源及控制運作，從而降低成本、加速進度和優(yōu)化質(zhì)量。

構(gòu)建階段的成果是可以交付給最終用戶的產(chǎn)品，它至少包括：

(1)集成于適當操作系統(tǒng)平臺上的軟件產(chǎn)品。

(2)用戶手冊。

(3)當前版本的描述。

4)交付階段

交付階段的重點是確保軟件對最終用戶是可用的。交付階段可以跨越幾次迭代，包括為發(fā)布做準備的產(chǎn)品測試，基于用戶反饋的少量的調(diào)整。在這一階段，用戶反饋應(yīng)主要集中在產(chǎn)品調(diào)整、設(shè)置、安裝和可用性問題。

2.?RUP核心工作流

1)商業(yè)建模

商業(yè)建模工作流描述了如何為新的目標組織開發(fā)一個構(gòu)想，并基于這個構(gòu)想在商業(yè)用例模型和商業(yè)對象模型中定義組織的過程、角色和責任。

2)需求

需求工作流的目標是描述系統(tǒng)應(yīng)該做什么，并使開發(fā)人員和用戶就這一描述達成共識。為了達到該目標，要對需要的功能和約束進行提取、組織、文檔化，最重要的是理解系統(tǒng)所解決問題的定義和范圍。

3)分析設(shè)計

分析設(shè)計工作流是將需求轉(zhuǎn)化成系統(tǒng)的設(shè)計，為系統(tǒng)開發(fā)一個健壯的結(jié)構(gòu)，使其與實現(xiàn)環(huán)境相匹配。設(shè)計活動以體系結(jié)構(gòu)設(shè)計為中心，其結(jié)果是一個設(shè)計模型和一個可選的分析模型。設(shè)計模型是源代碼的抽象，由設(shè)計類和一些描述組成。設(shè)計類被組織成具有良好接口的設(shè)計包和設(shè)計子系統(tǒng)，而描述則體現(xiàn)了類的對象如何協(xié)同工作實現(xiàn)用例的功能。

4)實施

實施工作流的目的包括以層次化的子系統(tǒng)形式定義代碼的組織結(jié)構(gòu)，以組件的形式(源文件、二進制文件、可執(zhí)行文件)實現(xiàn)類和對象，將開發(fā)出的組件作為單元進行測試，集成單元使其成為可執(zhí)行的系統(tǒng)。

5)測試

測試可通過可靠性、功能性和系統(tǒng)性的三維模型來進行。測試工作流要驗證對象間的交互作用，驗證軟件中所有組件的正確集成，檢驗所有的需求已被正確的實現(xiàn)，識別并確認缺陷在軟件部署之前被提出并處理。RUP提出的迭代方法是在整個項目中進行測試的，從而盡可能早地發(fā)現(xiàn)缺陷，從根本上降低了修改缺陷的成本。

6)部署

部署工作流的目的是成功地生成版本并將軟件分發(fā)給最終用戶。部署工作流描述了那些與確保軟件產(chǎn)品對最終用戶具有可用性相關(guān)的活動，它包括：軟件打包、生成軟件本身以外的產(chǎn)品、安裝軟件、為用戶提供幫助。在有些情況下，還可能包括計劃和生成beta測試版、移植現(xiàn)有的軟件和數(shù)據(jù)以及正式驗收。

7)配置和變更管理

配置和變更管理工作流描繪了如何在多個成員組成的項目中控制大量的軟件產(chǎn)物。配置和變更管理工作流提供了準則來管理演化系統(tǒng)中的多個變體，跟蹤軟件創(chuàng)建過程中的版本。工作流描述了如何管理并行開發(fā)、分布式開發(fā)，如何自動化創(chuàng)建工程，同時也闡述了對產(chǎn)品修改的原因、時間、人員進行記錄，依靠程序員主動、開放、高效的面對面交流來達成對需求、目標、設(shè)計實現(xiàn)的理解。

8)項目管理

軟件項目管理平衡各種可能產(chǎn)生沖突的目標，管理風險，克服各種約束并成功交付使用戶滿意的產(chǎn)品。其目標包括：為項目的管理提供框架，為計劃、人員配備、執(zhí)行和監(jiān)控項目提供實用的準則，為管理風險提供框架等。

9)環(huán)境

環(huán)境工作流的目的是向軟件開發(fā)組織提供軟件開發(fā)環(huán)境，包括過程和工具。環(huán)境工作流集中于配置項目過程中所需要的活動，同樣也支持開發(fā)項目規(guī)范的活動，提供了逐步的指導(dǎo)手冊并介紹了如何在組織中實現(xiàn)過程。

3.用例驅(qū)動為核心

開發(fā)軟件系統(tǒng)的目的是要為該軟件系統(tǒng)的用戶服務(wù)。因此，要創(chuàng)建一個成功的軟件系統(tǒng)，必須明白此軟件的用戶需要什么?！坝脩簟边@個術(shù)語所指并不僅僅局限于人，還包括其它軟件系統(tǒng)。一個用例就是系統(tǒng)向用戶提供一個有價值的結(jié)果的某項功能。用例是軟件的功能性需求。所有用例結(jié)合起來就構(gòu)成了“用例模型”，該模型描述系統(tǒng)的全部功能。用例模型取代了系統(tǒng)的傳統(tǒng)的功能規(guī)范說明。功能規(guī)范說明描述為“需要該系統(tǒng)做什么？”，而用例驅(qū)動則是“需要該系統(tǒng)為每個用戶做什么？”因此，用例模型是從用戶的利益角度出發(fā)進行考慮，設(shè)計人員創(chuàng)建一系列用例模型，開發(fā)人員審查每個后續(xù)模型，以確保它們符合用例模型。測試人員將測試軟件系統(tǒng)的實現(xiàn)，以確保實現(xiàn)模型中的組件正確實現(xiàn)了用例。這樣，用例不僅啟動了開發(fā)過程，而且與開發(fā)過程結(jié)合在一起。1.2.2敏捷過程

傳統(tǒng)計劃驅(qū)動的開發(fā)方法往往不能獲得良好的效果，并且由于過分強調(diào)過程控制，因此在開發(fā)過程中產(chǎn)生大量的文檔，給開發(fā)人員帶來很多額外的工作量，因此被稱為重量級方法。這種方法使程序員花費大量的開發(fā)時間在開發(fā)文檔的撰寫和維護上，而真正花在代碼上的時間較少，并且由于依賴過程控制，而不是程序員自我管理，導(dǎo)致開發(fā)過程管理復(fù)雜且低效，極大地阻礙了軟件開發(fā)效率。

1.敏捷開發(fā)簡介

2001年是全球軟件行業(yè)具有歷史意義的一年，就在這一年，“敏捷聯(lián)盟”成立了，并發(fā)表了對傳統(tǒng)軟件開發(fā)過程具有顛覆意義的《敏捷宣言》:“通過開發(fā)軟件和幫助別人開發(fā)軟件，我們找到了一些更好的開發(fā)軟件的方式。通過這一工作，我們得出了這些價值：

●個體和交互勝過過程和工具；

●可以工作的軟件勝過面面俱到的文檔；

●客戶合作勝過合同談判；

●響應(yīng)變化勝過遵循計劃。

2.敏捷開發(fā)的特征

敏捷方法具有如下兩個主要特征：

(1)開發(fā)采用適應(yīng)性方法，經(jīng)過多次小型迭代開發(fā)過程逐步逼近實際需求，從而為客戶提供實際需要的軟件。

(2)以人為本。傳統(tǒng)計劃驅(qū)動方法企圖以文檔、過程為核心，從而抹殺人的重要性。

3.敏捷開發(fā)的價值與局限

敏捷方法拋棄了繁瑣的文檔管理，依靠程序員主動、開放、頻繁的面對面的高效交流來達成對需求、目標、設(shè)計實現(xiàn)的理解。敏捷方法拋棄了機械、嚴格的過程控制，依賴程序員和開發(fā)團隊的高標準自我要求：嚴格的自律，團隊合作精神，個人高度自覺的主動性，責任感。

敏捷方法的高效和高質(zhì)量實際上是以程序員的高素質(zhì)和開發(fā)團隊的高度合作的開發(fā)文化為基礎(chǔ)的。因此敏捷方法的實施前提是必須找到愿意并有能力實施敏捷方法的團隊。XP的創(chuàng)始人Beck也曾建議有些情況是不適合采用XP方法的。

1.3軟件質(zhì)量

1.3.1概述

軟件質(zhì)量具有多種定義。ANSI/IEEEStd729—1983定義軟件質(zhì)量為“與軟件產(chǎn)品滿足規(guī)定的和隱含的需求的能力有關(guān)的特征或特性的全體”。CMM對質(zhì)量的定義是：①一個系統(tǒng)、組件或過程符合特定需求的程度；②一個系統(tǒng)、組件或過程符合客戶或用戶的要求或期望的程度。M.J.Fisher定義軟件質(zhì)量為“所有描述計算機軟件優(yōu)秀程度的特性的組合”。

因此，軟件質(zhì)量是一個復(fù)雜的多層面概念。

軟件質(zhì)量框架是由“質(zhì)量特性—質(zhì)量子特性—度量因子”構(gòu)成的3層結(jié)構(gòu)模型，如圖1.2所示。圖1.2軟件質(zhì)量框架1.3.2CMM/CMMI

1.?CMM

CMM是卡耐基—梅隆大學(xué)軟件工程研究院受美國國防部委托制定的軟件過程改良和評估模型，也稱為SEISW-CMM。該模型于1991年發(fā)布，其核心是把軟件開發(fā)視為一個過程，進行過程的監(jiān)控和研究。CMM提供了一個軟件過程改進的框架，這個框架與軟件生命周期無關(guān)，與所采用的開發(fā)方法無關(guān)。

CMM為軟件企業(yè)的過程能力提供了一個階梯式的進化框架，該框架共有5級，分別是初始級、可重復(fù)級、已定義級、已管理級和優(yōu)化級。第一級實際上是一個起點，任何準備按CMM體系進化的企業(yè)都自然處于這個起點上，并通過這個起點向第二級邁進。除第一級外，每一級都設(shè)定了一組目標，如果達到了這組目標，則表明達到了這個成熟級別，可以向下一個級別邁進，如表1.1所示。

1)初始級

在這個階段，軟件開發(fā)過程表現(xiàn)得非常隨意，偶爾會出現(xiàn)混亂的現(xiàn)象，只有很少的工作過程是經(jīng)過嚴格定義的，開發(fā)成功往往依靠的是某個人的智慧和努力。此時的軟件機構(gòu)基本沒有健全的軟件工程管理制度，其軟件過程完全取決于項目組的人員配備，具有不可預(yù)測性。人員變了過程也隨之改變。如果一個項目碰巧由一個杰出的管理者和一支有經(jīng)驗、有能力的開發(fā)隊伍承擔，則這個項目可能是成功的。但是，更常見的情況是，由于缺乏健全的管理和周密的計劃，延期交付和費用超支的情況經(jīng)常發(fā)生，結(jié)果大多數(shù)行動只是應(yīng)付危機，而不是完成事先計劃好的任務(wù)。

2)可重復(fù)級

這一階段已經(jīng)建立了基本的項目管理過程，只需按部就班地設(shè)計功能、跟蹤費用，根據(jù)項目進度表進行開發(fā)。對于相似的項目，可以重用以前已經(jīng)開發(fā)成功的部分。處于2級成熟度的軟件機構(gòu)，針對所承擔的軟件項目已建立了基本的軟件管理控制制度。通過對以前項目的觀察和分析，可以提出針對現(xiàn)行項目的約束條件。項目負責人跟蹤軟件產(chǎn)品開發(fā)的成本和進度以及產(chǎn)品的功能和質(zhì)量，并且識別出為滿足約束條件所應(yīng)解決的問題。此時，軟件的需求是條理化，而且其完整性是受控制的。軟件機構(gòu)已經(jīng)制定了項目標準，并且能確保嚴格執(zhí)行這些標準。項目組與客戶及承包商已經(jīng)建立起一個穩(wěn)定的、可管理的工作環(huán)境。

3)已定義級

在這一階段，軟件開發(fā)的工程活動和管理活動都是文檔化、標準化的，是被集成為一個有組織的標準開發(fā)過程。所有項目的開發(fā)和維護都在這個標準基礎(chǔ)上進行定制。處于3級成熟度的軟件機構(gòu)，有一個固定的過程小組從事軟件過程工程活動。過程小組可以利用過程模型進行過程例化活動，從而獲得一個針對某個特定的軟件項目的過程實例，并投入過程運作而開展有效的軟件項目工程實踐。同時，過程小組還可以推進軟件機構(gòu)的過程改進活動。在該軟件機構(gòu)內(nèi)實施了培訓(xùn)計劃，能夠保證全體項目負責人和項目開發(fā)人員具有完全承擔任務(wù)所要求的知識和技能。

4)已管理級

這一階段已經(jīng)對軟件開發(fā)過程和產(chǎn)品質(zhì)量的測試細節(jié)有了很好的歸納，產(chǎn)品和開發(fā)過程都可以定量地分解和控制。

處于4級成熟度的軟件機構(gòu)的過程能力可以概況為：軟件過程是可度量的，軟件過程在可度量的范圍內(nèi)運行。這一級的過程能力允許軟件機構(gòu)在定量的范圍內(nèi)預(yù)測過程和產(chǎn)品質(zhì)量趨勢，在發(fā)生偏離時可以及時采取措施予以糾正，并且可以預(yù)期軟件產(chǎn)品是高質(zhì)量的。

5)優(yōu)化級

這一階段通過建立開發(fā)過程的定量反饋機制，不斷產(chǎn)生新的思想，采用新的技術(shù)來優(yōu)化開發(fā)過程。處于5級成熟度的軟件機構(gòu)，可以通過對過程實例性能的分析和確定產(chǎn)生某一缺陷的原因，來防止再次出現(xiàn)這種類型的缺陷。通過對任何一個過程實例的分析所獲得的經(jīng)驗教訓(xùn)都可以成為該軟件機構(gòu)優(yōu)化其過程模型的有效依據(jù)，從而使其它項目的過程實例得到優(yōu)化。這樣的軟件機構(gòu)可以通過從過程實施中獲得的定量的反饋信息，在采用新思想和新技術(shù)的同時測試它們，從而不斷地改進和優(yōu)化軟件過程。

處于5級成熟度的軟件機構(gòu)的過程能力可以概況為：軟件過程是可優(yōu)化的。這一級的軟件機構(gòu)能夠持續(xù)不斷地改進其過程能力，既對現(xiàn)行的過程實例不斷地改進和優(yōu)化，又借助于所采用的新技術(shù)和新方法來實現(xiàn)未來的過程改進。

2.?CMMI

CMMI是SEI于2000年發(fā)布的CMM的新版本。CMMI(CapabilityMaturityModelIntegration，能力成熟度模型集成)將各種能力成熟度模型，包括SoftwareCMM、SystemsEng-CMM、PeopleCMM和AcquisitionCMM等，整合到同一架構(gòu)中去，由此建立包括軟件工程、系統(tǒng)工程和軟件采購等在內(nèi)的模型集成，以解決除軟件開發(fā)以外的軟件系統(tǒng)工程和軟件采購工作中的需求。1.3.3質(zhì)量與測試

軟件測試和軟件質(zhì)量是分不開的。測試是手段，質(zhì)量是目的。軟件測試作為一種輔助而且必需的手段，客觀反映某個時間段內(nèi)的軟件質(zhì)量。測試人員執(zhí)行軟件測試，發(fā)現(xiàn)軟件BUG，反饋給開發(fā)人員進行修改，然后經(jīng)過再次測試，以確認該BUG已被解決。測試人員重復(fù)此過程直至軟件符合最終用戶需求。在BUG產(chǎn)生之前，BUG的具體數(shù)量、位置、出現(xiàn)時間等都是未知數(shù)，測試人員根本就不知道。

測試可以發(fā)現(xiàn)BUG，但不能避免BUG的產(chǎn)生。QA團隊對項目進行近似完全的控制，通過建立標準和方法論，有條理地仔細監(jiān)視和評價軟件開發(fā)過程，對發(fā)現(xiàn)的軟件缺陷提出解決建議，執(zhí)行某些測試，從而從源頭上防止BUG的出現(xiàn)。實現(xiàn)軟件質(zhì)量保證主要有兩種途徑：一種是通過貫徹軟件工程各種有效的技術(shù)方法和措施使得盡量在軟件開發(fā)期間減少錯誤；另一種是通過分析和測試軟件來發(fā)現(xiàn)和糾正錯誤。

軟件測試屬于軟件控制，作為軟件質(zhì)量的重要保證，其和質(zhì)量保證有如下4點區(qū)別，如表1.2所示。通過實施CMM/CMMI，有助于改進軟件產(chǎn)品的質(zhì)量，改進項目滿足預(yù)定目標能力，減少開發(fā)成本和周期，降低項目風險，提高組織過程能力，提高市場占有率。實施不同等級的CMM/CMMI，對于按照每功能點來計算的軟件缺陷率的降低具有顯著的作用，如表1.3所示。

CMM/CMMI基于過程的軟件質(zhì)量管理主要包括質(zhì)量保證和質(zhì)量控制兩大方面。軟件質(zhì)量保證是由(相對)獨立的質(zhì)量管理人員在項目的整個開發(fā)周期中對項目所執(zhí)行的過程和產(chǎn)生的工作產(chǎn)品進行監(jiān)督和檢查，確保其符合預(yù)定的要求。軟件質(zhì)量保證的目的是確保過程得到有效的執(zhí)行及推進過程改進，并就項目過程的執(zhí)行情況和所構(gòu)造的產(chǎn)品向管理者提供適當?shù)目梢曅?。軟件質(zhì)量控制是指為評價和驗證已開發(fā)的產(chǎn)品而執(zhí)行的活動和技術(shù)，包括驗證產(chǎn)品是否滿足質(zhì)量要素的要求，以及產(chǎn)品(包括生命周期的工作產(chǎn)品)是否具有接受的質(zhì)量。軟件質(zhì)量控制所采取的主要技術(shù)是軟件測試。通過軟件測試，來驗證產(chǎn)品是否符合技術(shù)文檔預(yù)期的特性、功能和性能等要求，并識別產(chǎn)品的缺陷。

雖然目前在CMM/CMMI中沒有明確軟件測試作為一個獨立的過程域，但是在CMM/CMMI很多地方都涉及了軟件測試內(nèi)容。CMMI和軟件測試最主要的區(qū)別在于：CMMI是對于軟件過程的改進(包括軟件測試過程)；而軟件測試是針對項目結(jié)果的驗證，在測試時是從側(cè)面改進軟件質(zhì)量的。例如，在CMMI的“確認”和“驗證”兩個過程域中，CMMI列出了以下實踐。

1.4測試與開發(fā)的關(guān)系

1．測試與開發(fā)各階段的關(guān)系

圖1.3給出了軟件測試與軟件開發(fā)各階段的關(guān)系，軟件測試在開發(fā)階段具有如下作用。