軟件質(zhì)量保證與測試第9章軟件質(zhì)量與軟件質(zhì)量管理SoftwareQualityAssuranceandTesting9.1軟件缺陷及分類

各種軟件缺陷

軟件當中可能會出現(xiàn)的缺陷，可以說是各式各樣，首先讓我們通過一些因缺陷引發(fā)的事故，來直觀的體驗一下軟件缺陷的外在表現(xiàn)和不良后果。

ATM機“紅包”2009年元旦剛過，在英國的曼徹斯特郡，有一臺ATM機，人們?nèi)″X的時候發(fā)現(xiàn)，實際出款額是取款額的2倍。許多人聞訊趕來排隊取款。6小時內(nèi)被取走了1萬英鎊。人們戲稱這是ATM機在發(fā)“新年紅包”

后經(jīng)查明，故障原因是ATM機程序缺陷。

各種軟件缺陷全球“千年蟲”問題

“千年蟲”可以說是計算機發(fā)展史上的一個經(jīng)典案例，這里呢我們多花點時間，來搞清楚“千年蟲”的前世今生，以及將來可能的“魅影重現(xiàn)”。

各種軟件缺陷全球“千年蟲”問題“千年蟲”問題是指在某些使用了計算機程序的智能系統(tǒng)（包括計算機系統(tǒng)、自動控制芯片等）當中，由于只使用兩位十進制數(shù)來表示年份，因此當系統(tǒng)涉及到跨世紀的日期處理運算時就會出現(xiàn)缺陷的結(jié)果，進而引發(fā)各種各樣的系統(tǒng)功能紊亂甚至崩潰。世界上第一臺電子計算機“ENIAC”1946年誕生于美國賓夕法尼亞大學，計算機系統(tǒng)中用兩位數(shù)表示年份時，實際上就是默認年份的前兩位為“19”，例如，“05”年，表達的就是1905年。

各種軟件缺陷全球“千年蟲”問題但是當時間跨越百年，到了2000年以后，那么“05”到底是“1905”年，還是“2005”年呢？此時含義就會出現(xiàn)混淆，而與之相關的計算就會出現(xiàn)缺陷。例如，一個人的出生年份在計算機系統(tǒng)中登記的是80年，現(xiàn)在是00年的，他現(xiàn)在的年齡應該是多大呢？如果沒有預防措施，而是按照年份相減的方式簡單計算的話，那么他的年齡就是-80歲，類似的還有，98年存錢，2000取錢，結(jié)果算出來的利息是負數(shù)等等。

各種軟件缺陷全球“千年蟲”問題簡單的說，千年蟲是計算機系統(tǒng)在日期處理上的一個缺陷，原因是僅采用2位數(shù)表示年份，當進入新的世紀時，就無法有效區(qū)分年份，而與之相關的計算就會出現(xiàn)紊亂和缺陷。

各種軟件缺陷00年=全球“千年蟲”問題廣泛地講，“千年蟲”還包括以下兩個方面的問題：一是在一些計算機系統(tǒng)中，對于閏年的計算和識別會出現(xiàn)問題，不能把2000年識別為閏年，即在該計算機系統(tǒng)的日歷中沒有2000年2月29日這一天，而是直接由2000年2月28日過渡到了2000年3月1日；還有就是在一些比較老的計算機系統(tǒng)中，在程序中使用了數(shù)字串99（或99/99等）來表示文件結(jié)束、永久性過期、刪除等一些特殊意義的自動操作，這樣當1999年9月9日（或1999年4月9日即1999年的第99天）來臨時，計算機系統(tǒng)在處理到內(nèi)容中有日期的文件時，就會遇到99或99/99等數(shù)字串，從而出現(xiàn)將文件誤認為已經(jīng)過期或者將文件刪除等錯操作，引發(fā)系統(tǒng)混亂甚至崩潰。

各種軟件缺陷全球“千年蟲”問題

據(jù)美國一家顧問公司估計，全球花在防備千年蟲發(fā)作上的費用高達6000億美元。

各種軟件缺陷

這一估算數(shù)字是否準確有待考證，但全球為此大費周章，花費巨額成本，卻是不爭的事實。下圖為當時的一些新聞報道。

全球“千年蟲”問題

各種軟件缺陷全球“千年蟲”問題

各種軟件缺陷

看到“千年蟲”的嚴重后果，我們不禁要問，一開始發(fā)明和使用計算機的專家學者為什么要設定成用兩位數(shù)來表示年份呢？原因很簡單，早期計算機存儲器的成本很高，如果用四位數(shù)字表示年份，就要多占用存儲器空間，就會使成本增加，因此為了節(jié)省存儲空間，計算機系統(tǒng)的編程人員采用兩位數(shù)字表示年份。全球“千年蟲”問題

各種軟件缺陷

隨著計算機技術(shù)的迅猛發(fā)展，雖然后來存儲器的價格降低了，但在計算機系統(tǒng)中使用兩位數(shù)字來表示年份的做法卻由于慣性而被沿襲下來，年復一年，直到新世紀即將來臨之際，大家才突然意識到用兩位數(shù)字表示年份將無法正確辨識公元2000年及其以后的年份。1997年，信息界開始拉起了“千年蟲”警鐘，并很快引起了全球關注。全球“千年蟲”問題

各種軟件缺陷

費盡周折，雖然有不少“千年蟲”發(fā)作的案例，但總體而言，全球還是平穩(wěn)度過了2000年。

然而時間永是流逝，用4位數(shù)表示年份，也不是一勞永逸的，類似的“萬年蟲”問題就在未來等著我們，因為當人類跨越10000萬年時，年份混淆就會“魅影重現(xiàn)”！我們再來看一下其他幾個軟件缺陷案例。美國火星氣候軌道探測器墜毀1998年12月11日，美國發(fā)射火星氣候軌道探測器。參與這個項目的一個NASA的工程小組使用的是英制單位，而沒有采用預定的公制單位，這造成探測器的推進裝置無法正常運作。正是因為這個缺陷，1999年探測器從距離火星表面130英尺的高度垂直墜毀。此項工程成本耗費3.27億美元，這還不包括損失的時間（該探測器從發(fā)射到抵達火星將近一年時間。）

各種軟件缺陷阿麗亞娜5型火箭處女秀發(fā)射悲劇1996年6月4日，阿麗亞娜5型運載火箭首次發(fā)射，原計劃將運送4顆太陽風觀察衛(wèi)星到預定軌道，但因軟件缺陷引發(fā)的問題導致火箭在發(fā)射39秒后偏軌，從而激活了火箭的自我摧毀裝置。阿麗亞娜5型火箭和其搭載的衛(wèi)星在瞬間灰飛煙滅。后來查明的事故原因是：阿麗亞娜5型的發(fā)射系統(tǒng)代碼直接重用了4型的相應代碼，而4型的飛行條件和5型的飛行條件截然不同。此次事故損失3.7億美元。

各種軟件缺陷

有問題的軟件、有缺陷的程序可能導致嚴重的后果，那么什么樣的程序是正確的呢？程序的正確性有不同的標準。按照由弱到強，我們可以這樣來描述程序的正確性

程序正確性程序正確性的不同標準程序編寫得無語法缺陷程序執(zhí)行中未發(fā)現(xiàn)明顯的運行缺陷程序中無不適當?shù)恼Z句程序運行時能通過典型的有效測試數(shù)據(jù)，而得到正確的預期結(jié)果程序運行時能通過典型的無效測試數(shù)據(jù)，而得到正確的結(jié)果程序運行時能通過任何可能的數(shù)據(jù)，并給出正確結(jié)果弱強程序正確性的標準不同，那么對應的要求就不同，例如程序編寫得無語法缺陷

——程序通過編譯即可達到

............程序運行時能通過任何可能的數(shù)據(jù)，并給出正確結(jié)果

——這樣的要求要達到很不容易！甚至可以說是無法保證到達！程序正確性的不同標準軟件缺陷的分類軟件中的缺陷，按照來源可以作如下分類：軟件需求缺陷功能和性能缺陷軟件結(jié)構(gòu)缺陷數(shù)據(jù)缺陷軟件實現(xiàn)和編碼缺陷軟件集成缺陷軟件系統(tǒng)結(jié)構(gòu)缺陷測試定義與測試執(zhí)行缺陷

為了分析軟件缺陷的來源，有人做了大量的統(tǒng)計工作。例如，對某一個包含有687,7000行代碼的軟件，在進行完單元測試、集成測試和系統(tǒng)測試之后，經(jīng)統(tǒng)計共發(fā)現(xiàn)缺陷1,6209個，平均每千行代碼有缺陷2.36個，將發(fā)現(xiàn)的缺陷進行分類，具體情況如下表。軟件缺陷的分類缺陷分類缺陷數(shù)百分比軟件需求缺陷13178.1功能和性能缺陷262416.2軟件結(jié)構(gòu)缺陷408225.2數(shù)據(jù)缺陷363822.4軟件實現(xiàn)和編碼缺陷16019.9軟件集成缺陷14559.0軟件系統(tǒng)結(jié)構(gòu)缺陷2821.7測試定義與測試執(zhí)行缺陷4472.8其他類型缺陷7634.7按照缺陷后果的嚴重程度：較小缺陷中等缺陷較嚴重缺陷嚴重缺陷非常嚴重缺陷最嚴重缺陷輕重軟件缺陷的分類注意：缺陷本身的大小與其所導致后果的嚴重程度并不成比例，例如1963年美國金星探測火箭的飛行控制軟件中，有一段FORTRAN語句，其中：DO5I=1，3被誤寫成：DO5I=1.3這里只是將“，”錯寫成“.”，結(jié)果這一疏忽竟造成極為嚴重的后果，火箭發(fā)射失敗，損失1千萬美元！軟件缺陷的分類本節(jié)內(nèi)容就講到這里，謝謝，再見！軟件質(zhì)量保證與測試第9章軟件質(zhì)量與軟件質(zhì)量管理SoftwareQualityAssuranceandTesting9.2程序中隱藏錯誤數(shù)量估計程序中隱藏錯誤數(shù)量估計

由于我們無法對軟件進行窮舉測試，所以即使是經(jīng)過測試的軟件，其中可能也會有隱藏的錯誤。那么一個經(jīng)過測試的軟件中究竟還隱藏有多少錯誤呢？這個問題無法準確回答，但是利用測試的統(tǒng)計數(shù)據(jù)，我們可以對軟件中隱藏的錯誤數(shù)量進行估計，當然這種估計是需要建立在合理的數(shù)學模型基礎上的。數(shù)學模型測試統(tǒng)計數(shù)據(jù)估算結(jié)果撒播模型法有一個實際問題，如何估計一個池塘中魚的總數(shù)？全部撈上來數(shù)一下嗎？這樣做成本太高，而且也沒有這個必要！

我們先來看一種簡單的對程序中隱藏錯誤數(shù)量進行估計的方法，這種方法基于撒播模型。撒播模型（SeedingModels）

一種簡單的方法是：撒一網(wǎng)，捕撈上來Nt尾魚，做上標記，放回到池塘中，等待其與未做標記的魚充分混合，幾天以后，再從池塘中任意撈出一些魚的樣本，得到帶標記的魚nt尾，無標記者n尾。撒播模型法Nt①②③

nt{n有等比關系式N

根據(jù)等比關系：

變形得

Nt*n+Nt*nt=nt*Nt+nt*N

化簡后可得到池塘中魚總數(shù)N：

得出的N不含做上標記的魚的數(shù)量。當魚的總數(shù)遠大于做標記的魚的數(shù)量時，做標記的

魚的數(shù)量對于估算值可忽略不計。

撒播模型法

如果設

N表示含有做上標記的魚的總數(shù)量

等比關系式變?yōu)?/p>

變形得

N*nt=Nt*n+Nt*nt

兩邊同時除以nt后可得

與前面的結(jié)果只是形式不一樣，實質(zhì)上是一樣的。撒播模型法模仿上述方法，假設在開始測試以前，軟件中的錯誤數(shù)為N，首先，往程序中人為插入NS個錯誤，經(jīng)過一段時間的測試工作以后，發(fā)現(xiàn)的錯誤可以分為兩類，一類屬于人為插入的錯誤ns，另一類是軟件中原來就有的錯誤n，則軟件中錯誤數(shù)的估算值為：撒播模型法軟件×N×Ns軟件×N×Ns測試{×n×ns

基于撒播模型，對程序中隱藏的錯誤數(shù)量進行估計，這一方法在應用時存在兩個實際困難：人為植入錯誤較為困難不同的錯誤被發(fā)現(xiàn)的難易程度不一樣，被插入的錯誤并不一定能代表各種可能的錯誤，估算結(jié)果不一定準確。撒播模型法

例如，在開始測試前，我們往程序中人為插入10個錯誤，這些錯誤都是已知類型的常見錯誤，經(jīng)過一段時間的測試工作以后，這10個錯誤都被發(fā)現(xiàn)了，這樣一來，根據(jù)算式，則軟件中隱藏的錯誤數(shù)估算值為0，這顯然有一定的局限性。撒播模型法{ns=10Ns=10總數(shù)=已發(fā)現(xiàn)數(shù)隱藏數(shù)為0第二種方法叫

Hyman分別測試法。什么是分別測試法呢，為了幫助大家理解，我們先來做一個類比。

張三和李四兩人都到某個城市游玩，他們每人各自隨機選取了3個景點參觀游覽，如果他們各自選取的

3個景點重合度高說明什么問題？重合度低又說明什么問題呢？Hyman分別測試法景點

經(jīng)過分析我們不難得知，如果他們各自隨機選取的3個景點重合度高，則說明他們可以選擇的余地小，也就是總的景點數(shù)量少。

極端情況下，如果這個城市只有3個景點，那么他們的選擇一定是完全重合的！

重合度低，則說明總的景點數(shù)多，他們可以選擇的余地大。Hyman分別測試法與此類似，Hyman分別測試法由兩個測試員同時互相獨立地測試同一程序的兩個副本，用t表示測試時間，記t=0時，程序中原有錯誤總數(shù)是B0；記t=t1時，Hyman分別測試法B1:第一個人發(fā)現(xiàn)的錯誤B2

:第二個人發(fā)現(xiàn)的錯誤bc:兩人都發(fā)現(xiàn)的錯誤b1:第二個人發(fā)現(xiàn)的不在B1中的錯誤顯然：B2=bc+b1B1B2bcb1

B0Hyman分別測試法B1B2bcb1

站在第一個人的角度，以B0為樣本空間，他的錯誤發(fā)現(xiàn)率為B1/B0，以B2為樣本空間，他的錯誤發(fā)現(xiàn)率為bc/B2，同一個人的錯誤發(fā)現(xiàn)率相等，所以有：

B0變形后可得：

站在第二個人角度的計算過程類似，結(jié)果是一樣的。第三種方法叫回歸分析。有變量X和Y，假設我們事先并不知道它們之間的定量關系，但有幾組已知數(shù)據(jù)，X=1時Y=2，X=3時Y=6，X=5時Y=10，根據(jù)這些數(shù)據(jù)，我們很容易推出Y=2X。這就是一種最為簡單的線性回歸分析?；貧w分析（regressionanalysis）指的是確定兩個或兩個以上變量間定量關系的一種統(tǒng)計分析方法。

回歸分析

回歸分析包括兩大步驟。

先要得到回歸函數(shù)，并畫出回歸曲線。

即根據(jù)已知數(shù)據(jù)，確定變量之間的函數(shù)關系，并畫出回歸曲線圖。

回歸分析{X=x1，x2，x3，......Y=y1，y2，y3，......

例如，已知軟件項目A在不同的測試時間點上的幾組累計錯誤數(shù)，如下表和右圖中的數(shù)據(jù)點所示。

測試時間累計的錯誤數(shù)項目A

回歸分析測試時間累計錯誤數(shù)t1y1t2y2t3y3t4y4

根據(jù)這些離散的點，可以借助數(shù)學工具，進行擬合，得出測試時間和累計的錯誤數(shù)之間的函數(shù)關系，并進而畫出曲線圖。測試時間累計的錯誤數(shù)項目A

回歸分析

得出回歸函數(shù)，畫出回歸曲線之后，回歸分析的第二個步驟就是預測任何時刻的錯誤數(shù)。此時只需要把測試時間參數(shù)代入回歸函數(shù)即可算出總的錯誤數(shù)，然后總的錯誤數(shù)減去已經(jīng)發(fā)現(xiàn)的錯誤數(shù)，就可估算得出軟件中隱藏的錯誤數(shù)。

回歸分析

設有兩個軟件項目A和B，根據(jù)它們各自幾組在不同的測試時間點上的累計錯誤數(shù)數(shù)據(jù)，擬合得出回歸曲線如右圖所示。項目A和B，哪一個的質(zhì)量更好呢？由回歸曲線不難發(fā)現(xiàn)，在任一測試時間點上，項目B累計的錯誤數(shù)都多于A，在這一意義上我們可以說項目A的質(zhì)量好于項目B。測試時間累計的錯誤數(shù)項目A項目B

回歸分析本節(jié)內(nèi)容就講到這里，謝謝，再見！軟件質(zhì)量保證與測試第9章軟件質(zhì)量與軟件質(zhì)量管理SoftwareQualityAssuranceandTesting9.3軟件質(zhì)量軟件質(zhì)量的基本概念

ISO8402-1994《質(zhì)量管理和質(zhì)量保證術(shù)語》中對質(zhì)量所下的定義是:質(zhì)量是反映實體(產(chǎn)品、過程或活動等)滿足明確和隱含需要的能力的特性總和。國標《GB/T16260-2006軟件工程產(chǎn)品質(zhì)量》中對質(zhì)量的定義為：

實體特性的總和，表明實體滿足明確或隱含要求的能力。軟件質(zhì)量的基本概念實體（entity,item）:是“可單獨描述和研究的事物”，實體可以是活動或過程，可以是產(chǎn)品，可以是組織、體系或人，也可以是上述各項的任何組合。需求(requirements):包括“明確需要”和“隱含需要”。為使“需求”可以實際運用，一般應將其轉(zhuǎn)化為質(zhì)量要求。所謂質(zhì)量要求，是指“對需要的表述或?qū)⑿枰D(zhuǎn)化為一組對實體特性的定量或定性的規(guī)定要求，以使其實現(xiàn)并進行考核”。軟件質(zhì)量的基本概念

軟件質(zhì)量，就是軟件符合明確敘述的功能和性能需求、文檔中明確描述的開發(fā)標準、以及所有專業(yè)開發(fā)的軟件都應具有的和隱含特征相一致的程度。軟件質(zhì)量的基本概念

軟件產(chǎn)品質(zhì)量可以通過測量內(nèi)部屬性，也可以通過測量外部屬性或者通過測量使用質(zhì)量的屬性來進行度量評價。內(nèi)部質(zhì)量是基于內(nèi)部視角的軟件產(chǎn)品特性的總體。外部質(zhì)量是基于外部視角的軟件產(chǎn)品特性的總體。使用質(zhì)量是基于用戶觀點的軟件產(chǎn)品用于指定的環(huán)境和使用條件時的質(zhì)量。軟件產(chǎn)品質(zhì)量生存周期模型軟件質(zhì)量的基本概念軟件質(zhì)量又可以分為設計質(zhì)量和符合質(zhì)量：設計質(zhì)量：是指設計者為一件軟件產(chǎn)品規(guī)定的特征。符合質(zhì)量：是指軟件符合設計規(guī)格的程度。QA和QC：QA即英文QUALITYASSURANCE的簡稱，中文意思是質(zhì)量保證。QC即英文QUALITYCONTROL的簡稱，中文意義是質(zhì)量控制。相關概念QA和QC

QA和QC的主要區(qū)別是：QA是保證產(chǎn)品質(zhì)量符合規(guī)定,QC是建立體系并確保體系按要求運作,以提供內(nèi)外部的信任。同時QC和QA又有相同點：QC和QA都要進行驗證，如QC按標準檢測產(chǎn)品就是驗證產(chǎn)品是否符合規(guī)定要求,QA進行內(nèi)審就是驗證體系運作是否符合標準要求；又如QA進行產(chǎn)品稽核和可靠性檢測,就是驗證產(chǎn)品是否已按規(guī)定進行各項活動,是否能滿足規(guī)定要求,以確保交付的產(chǎn)品都是合格和符合相關規(guī)定的。確認和驗證（V&V）：確認validation是通過檢查和提供客觀證據(jù)證實某一規(guī)定預期用途的特殊需求已經(jīng)滿足。

驗證Validation是通過檢查和提供客觀證據(jù)證實規(guī)定的需求已經(jīng)滿足。這兩者很相似，也很容易混淆，但有差別！相關概念確認和驗證（V&V）：驗證就是要用證實我們是不是在按照已經(jīng)定好的標準正確的制造產(chǎn)品。這里強調(diào)的是過程的正確性，標準是事先已經(jīng)明確定好的。確認就是要證實我們是不是制造了正確的產(chǎn)品。這里強調(diào)的是結(jié)果的正確性，正確的產(chǎn)品可能只有一個預期的目標，而沒有既定的嚴格規(guī)范的標準。換句話說，驗證要保證“做得正確”，而確認則要保證“做的東西正確”。相關概念確認和驗證的區(qū)別

軟件質(zhì)量特性軟件質(zhì)量特性，反映了軟件的本質(zhì)，軟件基本的質(zhì)量特性包括：功能性（Functionality）可靠性(Reliability)易使用性(Usability)效率(Efficiency)可維護性(Maintainability)可移植性(Portability)軟件質(zhì)量特性可以進一步細分，如圖所示1.性能(Performance)是指系統(tǒng)的響應能力，即要經(jīng)過多長時間才能對某個事件作出響應，或者在某段時間內(nèi)系統(tǒng)所能處理的事件個數(shù)；2.可用性(Availability)是指系統(tǒng)能夠正常運行的時間比例；3.可靠性(Reliability)是指系統(tǒng)在應用或者錯誤面前，在意外或者錯誤使用的情況下維持軟件系統(tǒng)功能特性的能力；4.健壯性(Robustness)是指在處理或者環(huán)境中系統(tǒng)能夠承受的壓力或者變更能力；軟件質(zhì)量特性5.安全性(Security)是指系統(tǒng)向合法用戶提供服務的同時能夠阻止非授權(quán)用戶使用的企圖或者拒絕服務的能力；6.可修改性(Modification)是指能夠快速地以較高的性能價格比對系統(tǒng)進行變更的能力；7.可變性(Changeability)是指體系結(jié)構(gòu)擴充或者變更成為新體系結(jié)構(gòu)的能力；8.易用性(Usability)是衡量用戶使用軟件產(chǎn)品完成指定任務的難易程度；軟件質(zhì)量特性9.可測試性(Testability)是指軟件發(fā)現(xiàn)故障并隔離定位其故障的能力特性，以及在一定的時間或者成本前提下進行測試設計、測試執(zhí)行能力；10.功能性(Functionability)是指系統(tǒng)所能完成所期望工作的能力；11.互操作性(Inter-Operation)是指系統(tǒng)與外界或系統(tǒng)與系統(tǒng)之間的相互作用能力。軟件質(zhì)量特性本節(jié)內(nèi)容就講到這里，謝謝，再見！軟件質(zhì)量保證與測試第9章軟件質(zhì)量與軟件質(zhì)量管理SoftwareQualityAssuranceandTesting9.4軟件質(zhì)量模型和質(zhì)量度量軟件質(zhì)量模型

質(zhì)量模型是一組特性及特性之間的關系，它提供規(guī)定質(zhì)量需求和評價質(zhì)量的基礎。簡單地說，軟件質(zhì)量模型就是軟件質(zhì)量評價的指標體系。三個質(zhì)量站在不同的角度，軟件的質(zhì)量可以分為：內(nèi)部質(zhì)量：產(chǎn)品內(nèi)在屬性的總和，決定了產(chǎn)品在特定條件下使用時，滿足明確和隱含要求的能力。外部質(zhì)量：產(chǎn)品在特定條件下使用時，滿足明確或隱含要求的程度。使用質(zhì)量：特定用戶使用的產(chǎn)品滿足其要求,以在特定的使用周境下達到有效性、生產(chǎn)率、安全性和滿意度等特定目標的程度。三個質(zhì)量內(nèi)部質(zhì)量外部質(zhì)量使用質(zhì)量三個質(zhì)量

內(nèi)部質(zhì)量和外部質(zhì)量都是軟件產(chǎn)品自身的特性，一般可用同一個質(zhì)量模型。使用質(zhì)量是用戶使用軟件產(chǎn)品滿足其要求的程度。有代表性的使用質(zhì)量模型如下：使用質(zhì)量有效性生產(chǎn)率安全性滿意度三個質(zhì)量

下面我們重點講內(nèi)部質(zhì)量和外部質(zhì)量的軟件質(zhì)量模型。

關于軟件質(zhì)量模型，業(yè)界已經(jīng)有很多成熟的模型定義如下列所示：JimMcCall軟件質(zhì)量模型（1977年）BarryW.Boehm軟件質(zhì)量模型（1978年）FURPS/FURPS+軟件質(zhì)量模型R.GeoffDromey軟件質(zhì)量模型ISO/IEC9126軟件質(zhì)量模型（1993年）ISO/IEC25010軟件質(zhì)量模型（2011年）軟件質(zhì)量模型McCall軟件質(zhì)量模型

JimMcCall的軟件質(zhì)量模型，也被稱為GE模型（GeneralElectricsModel）。其最初起源于美國空軍，主要面向的是系統(tǒng)開發(fā)人員和系統(tǒng)開發(fā)過程。McCall試圖通過一系列的軟件質(zhì)量屬性指標來彌補開發(fā)人員與最終用戶之間的鴻溝。McCall軟件質(zhì)量模型

McCall質(zhì)量模型使用3種視角來定義和識別軟件產(chǎn)品的質(zhì)量，它們是：1.產(chǎn)品修正Productrevision(abilitytochange).2.產(chǎn)品轉(zhuǎn)移Producttransition(adaptabilitytonewenvironments).3.產(chǎn)品運行Productoperations(basicoperationalcharacteristics).如下圖所示：McCall軟件質(zhì)量模型ISO/IEC25010軟件質(zhì)量模型（2011年）第二個是ISO/IEC25010軟件質(zhì)量模型。這一軟件質(zhì)量模型包含8個特征，并且被進一步分解為可以度量的內(nèi)部和外部多個子特征。這一軟件質(zhì)量度量模型由三層組成：高層（toplevel）：軟件質(zhì)量需求評價準則（SQRC）中層（midlevel）：軟件質(zhì)量設計評價準則（SQDC）低層（lowlevel）：軟件質(zhì)量度量評價準則（SQMC）ISO/IEC25010軟件質(zhì)量模型軟件質(zhì)量模型的應用質(zhì)量模型是面向所有軟件的，因此它的質(zhì)量屬性是面面俱到的。但是對于一個具體的軟件產(chǎn)品或軟件項目來說，對其進行質(zhì)量度量和評價時，可以根據(jù)實際情況和需要，側(cè)重于某些方面或者特性，質(zhì)量模型中的質(zhì)量特性、子特性、度量元等不一定都要涉及，也就是說要根據(jù)軟件產(chǎn)品本身的特點、領域、規(guī)模等因素來選擇質(zhì)量特性、子特性，甚至于可以建立自己的質(zhì)量模型。軟件質(zhì)量模型的應用在ISO/IEC25010軟件質(zhì)量模型中，低層：軟件質(zhì)量度量評價準則（SQMC）就是由使用單位自行制定的，而不是千篇一律、一概而論的。軟件質(zhì)量的度量

了解了軟件質(zhì)量模型之后，我們再來看如何對軟件質(zhì)量進行度量。軟件質(zhì)量特性度量方法有兩類：預測型和驗收型。預測度量是利用定量或定性的方法，估算軟件質(zhì)量的評價值，以得到軟件質(zhì)量的估算值。驗收度量是在軟件開發(fā)各階段的檢查點，對軟件的質(zhì)量進行確認性檢查并得到具體評價值。簡單的說一個是事先預測估算，一個是事后檢查評價。度量的目的認知：認知和理解產(chǎn)品，建立不同產(chǎn)品之間或者同一產(chǎn)品不同版本之間可以進行比較的基線；評估：評估質(zhì)量目標的實現(xiàn)情況，以及技術(shù)和過程的改進對產(chǎn)品質(zhì)量的影響；度量的目的預測：是在有限資源條件下，建立成本、進度和質(zhì)量目標計劃的基礎。也可根據(jù)度量的實證，預測軟件生產(chǎn)和產(chǎn)品的趨勢，估計分析風險，做出設計/成本權(quán)衡；改進：幫助識別問題根源，判斷可以改進的機會，交流改進的目標和理由，提高產(chǎn)品質(zhì)量等。度量方式有兩種第一種叫做尺度度量，這是一種定量度量。它適用于一些能夠直接度量的特性，例如，出錯率。第二種叫做二元度量，這是一種定性度量。它適用于一些只能間接度量的特性，例如，可使用性、靈活性等等。填具體的數(shù)據(jù)值尺度度量檢查表（定量指標）尺度度量檢查表（定量指標）如：模塊A的環(huán)路復雜度為4；整個軟件的模塊平均復雜度為3.8。二元度量檢查表（定性指標）填定性結(jié)論，如：是/否不同質(zhì)量度量之間的關系過程質(zhì)量外部測度內(nèi)部質(zhì)量屬性外部質(zhì)量屬性使用質(zhì)量屬性過程質(zhì)量過程過程測度內(nèi)部測度使用質(zhì)量測度軟件產(chǎn)品產(chǎn)品的使用使用周境影響影響依賴依賴

如前所述，軟件質(zhì)量分為內(nèi)部質(zhì)量、外部質(zhì)量和使用質(zhì)量，另外還有一個軟件過程質(zhì)量，這些質(zhì)量度量之間的關系如圖所示：依賴影響不同質(zhì)量度量之間的關系

從圖中可以看出：軟件過程質(zhì)量是其它質(zhì)量的基礎，其它質(zhì)量都直接或間接依賴于軟件過程質(zhì)量，所以要想提高軟件產(chǎn)品的質(zhì)量，關鍵必須要對整個軟件過程進行嚴格的質(zhì)量管理和控制，以過程質(zhì)量來保證產(chǎn)品質(zhì)量。本節(jié)內(nèi)容就講到這里，謝謝，再見！軟件質(zhì)量保證與測試第9章軟件質(zhì)量與軟件質(zhì)量管理SoftwareQualityAssuranceandTesting9.5軟件質(zhì)量管理概念

質(zhì)量管理是指確定質(zhì)量方針、目標和職責，并通過質(zhì)量體系中的質(zhì)量策劃、控制、保證和改進來使其實現(xiàn)的全部活動。

軟件質(zhì)量管理可以說是一個體系，用于實現(xiàn)對一個軟件的質(zhì)量進行全面把控。由來

20世紀70年代中期，美國國防部曾專門研究軟件工程做不好的原因，發(fā)現(xiàn)70%的失敗項目是因為管理中存在的瑕疵引起的，而并非技術(shù)性的原因，進而得出一個結(jié)論，即管理是影響軟件研發(fā)項目全局的因素，而技術(shù)只影響局部。

軟件項目失敗的主要原因有：需求定義不明確；缺乏一個好的軟件開發(fā)過程；沒有一個統(tǒng)一領導的產(chǎn)品研發(fā)小組；子合同管理不嚴格；沒有經(jīng)常注意改善軟件過程；對軟件構(gòu)架很不重視；軟件界面定義不善且缺乏合適的控制等等。在關系到軟件項目成功與否的眾多因素中，軟件度量、工作量估計、項目規(guī)劃、進展控制、需求變化和風險管理等都是與工程管理直接相關的因素。由此可見，軟件工程中管理的意義至關重要。由來

軟件質(zhì)量管理中的質(zhì)量，通常指產(chǎn)品的質(zhì)量，但廣義的質(zhì)量管理還包括工作的質(zhì)量。軟件產(chǎn)品質(zhì)量是指軟件滿足明確和隱含需要的能力的特性總和。而工作質(zhì)量則是產(chǎn)品質(zhì)量的保證，它反映了與產(chǎn)品質(zhì)量直接有關的工作對產(chǎn)品質(zhì)量的保證程度。軟件質(zhì)量管理工作是一個系統(tǒng)過程，在實施過程中必須遵循與軟件項目質(zhì)量要求相應的標準，執(zhí)行相應的過程，符合相應的規(guī)范。工作內(nèi)容

簡單說來，軟件質(zhì)量管理通常分為兩大工作：

1、產(chǎn)品質(zhì)量管理：如軟件測試2、過程質(zhì)量管理：包括ISO9000、CMMI、TQC等，具體工作是軟件質(zhì)量保證（過程策劃和檢查），軟件配置管理（配置審計和版本控制等）、人員培訓等。工作內(nèi)容

從工作環(huán)節(jié)來說，軟件質(zhì)量管理工作包括：質(zhì)量規(guī)劃、質(zhì)量檢驗、質(zhì)量控制、質(zhì)量評價、質(zhì)量信息管理等。

工作環(huán)節(jié)

質(zhì)量管理

在國際標準《ISO/IEC12207：2008系統(tǒng)與軟件過程——軟件生存期過程》中和軟件質(zhì)量管理有關的過程包括：軟件質(zhì)量保證過程軟件驗證過程軟件確認過程軟件評審過程軟件問題解決過程主要過程和活動

軟件質(zhì)量保證是建立一套有計劃，系統(tǒng)規(guī)范的方法，來確保軟件質(zhì)量標準、軟件過程步驟、軟件工程方法和實踐能夠正確地被軟件項目所采用，從而保證軟件質(zhì)量。軟件質(zhì)量保證的目的是使軟件過程對于管理者來說是可見的。它通過對軟件產(chǎn)品和活動進行評審和審計來驗證軟件是合乎標準的。軟件質(zhì)量保證人員在項目一開始時就應參與制定計劃、建立標準，并進行檢查監(jiān)督。軟件質(zhì)量保證過程

軟件質(zhì)量保證的目的是確保工作過程和產(chǎn)品遵循既定的要求和已經(jīng)制定的計劃。應取得的成果包括：①制定出實施質(zhì)量保證的策略；②得到實施軟件質(zhì)量保證的相關數(shù)據(jù)并予以維護；③識別了出現(xiàn)的問題或不符合要求的現(xiàn)象，并做了記錄；④產(chǎn)品過程和活動對于適用標準、規(guī)程和要求的遵循狀況得到了驗證。軟件質(zhì)量保證過程

軟件質(zhì)量保證過程包括以下4項活動：①過程實施②產(chǎn)品保證③過程保證④質(zhì)量體系保證軟件質(zhì)量保證過程

軟件質(zhì)量保證中的質(zhì)量包括“需求質(zhì)量”、“設計質(zhì)量”、“開發(fā)質(zhì)量”、“測試質(zhì)量”四個方面。

過程可以分為“質(zhì)量計劃”、“質(zhì)量標準”、“質(zhì)量檢查”、“質(zhì)量報告”、“質(zhì)量驗收”５個環(huán)節(jié)。軟件質(zhì)量保證過程

質(zhì)量保證的實施有５個步驟：

1.目標（Target）：以用戶要求和開發(fā)方針為依據(jù)，對質(zhì)量需求準則、質(zhì)量設計準則的各質(zhì)量特性設定質(zhì)量目標。

2.計劃（Plan）：設定適合于被開發(fā)軟件的評測檢查項目（質(zhì)量評價準則）；研討實現(xiàn)質(zhì)量目標的方法或手段。

3.開發(fā)（Do）：編寫開發(fā)高質(zhì)量的規(guī)格說明和程序；并在接受質(zhì)量檢查前先做自我檢查。軟件質(zhì)量保證過程

4.檢查（Check）：以計劃階段設定的質(zhì)量評價準則進行檢查和評價，結(jié)果用質(zhì)量圖的形式表示出來。

5.改進（Action）：對評價發(fā)現(xiàn)的問題進行改進活動，如果實現(xiàn)并達到了質(zhì)量目標就轉(zhuǎn)入下一個工程階段。

重復從“計劃”到“改進”的過程，直到整個軟件項目完成。軟件質(zhì)量保證過程

軟件質(zhì)量保證過程

軟件質(zhì)量保證過程實施的５個步驟如圖所示。軟件質(zhì)量保證活動概覽圖軟件驗證過程

軟件驗證過程的目的在于：證實軟件過程或項目的每一個軟件工作產(chǎn)品或服務均能正確的反映規(guī)定的需求?！?guī)定的需求滿足軟件驗證過程

軟件驗證應取得的成果包括：制定并實施了驗證策略；識別了所有要求的軟件工作產(chǎn)品的驗證標準；執(zhí)行了要求的驗證活動；識別了缺陷并做了記錄；驗證活動的結(jié)果可以為客戶及其他相關方所使用。軟件驗證過程

軟件驗證過程包括過程實施和驗證兩個活動。驗證又包括五項任務：需求驗證、設計驗證、代碼驗證、集成驗證、和文檔驗證。軟件確認過程

軟件確認和軟件驗證略有不同，軟件確認過程的目的是：證實軟件工作產(chǎn)品預期的的使用需求已得到滿足。

→滿足軟件確認過程

軟件確認包括以下五項任務：①為分析測試結(jié)果準備選擇的測試需求、測試用例和測試規(guī)格說明；②確保這些測試需求、測試用例和測試規(guī)格說明能反映特定的預期用途的特殊要求；③實施上述兩項任務的測試；④確認軟件產(chǎn)品滿足它的預期用途；⑤適當時在目標環(huán)境的選定區(qū)域中測試軟件產(chǎn)品。軟件問題解決過程

軟件問題解決過程的目的是所有發(fā)現(xiàn)的問題得到澄清分析并為其解決而得到管理和控制，應取得的成果包括：制定問題管理策略；問題得到記錄識別和分類；為獲得可接受的解決方案，已將問題做了分析和評估；實施問題解決方案；跟蹤問題，直至結(jié)束；確保知道所有已報告問題的狀態(tài)。軟件問題解決過程

當發(fā)現(xiàn)軟件產(chǎn)品或活動當中的問題包括不符合項時，應編寫問題報告，用其描述所發(fā)現(xiàn)的每一個問題。從發(fā)現(xiàn)問題開始，到問題及其原因的調(diào)查分析和解決，應當形成一個閉環(huán)，及發(fā)現(xiàn)的每一個問題都應當被解決。但解決問題的方式不止一種，一般而言問題應當徹底解決，但有些問題經(jīng)過權(quán)衡并對解決方案進行評審通過后，可以只是采取某些補救措施來解決。本節(jié)內(nèi)容就講到這里，謝謝，再見！軟件質(zhì)量保證與測試第9章軟件質(zhì)量與軟件質(zhì)量管理SoftwareQualityAssuranceandTesting9.6軟件質(zhì)量管理體系

軟件質(zhì)量保證是確保軟件產(chǎn)品從誕生到消亡為止的所有階段的質(zhì)量的活動，既有和一般產(chǎn)品質(zhì)量保證相同的共性，也有作為軟件這種特定產(chǎn)品進行質(zhì)量保證的特性。因此我們來學習一下通用質(zhì)量標準體系ISO9000和軟件過程能力成熟度模型CMM。

軟件質(zhì)量管理體系

質(zhì)量保證標準，誕生于美國軍品使用的標準。二次世界大戰(zhàn)后，美國國防部吸取二次世界大戰(zhàn)中軍品質(zhì)量優(yōu)劣的經(jīng)驗和教訓，決定在軍火和軍需品訂貨中實行質(zhì)量保證，即供方在生產(chǎn)所訂購的貨品中，不但要按需方提出的技術(shù)要求保證產(chǎn)品實物質(zhì)量，而且要按訂貨時提出的且已寫入合同中的質(zhì)量保證條款要求去控制質(zhì)量，并在提交貨品時提交控制質(zhì)量的證實文件。這種辦法促使承包商進行全面的質(zhì)量管理，取得了極大的成功。

質(zhì)量管理體系的誕生

1978年以后，質(zhì)量保證標準被引用到民品訂貨中來，英國制訂了一套質(zhì)量保證標準，即BS5750。隨后歐美很多國家，為了適應供需雙方實行質(zhì)量保證標準并對質(zhì)量管理提出的新要求，在總結(jié)多年質(zhì)量管理實踐的基礎上，相繼制訂了各自的質(zhì)量管理標準和實施細則。

質(zhì)量管理體系的誕生

ISO為了適應國際貿(mào)易往來中民品訂貨采用質(zhì)量保證作法的需要成立了ISO/TC176國際標準化組織質(zhì)量管理和質(zhì)量保證技術(shù)委員會，該技術(shù)委員會在總結(jié)和參照世界有關國家標準和實踐經(jīng)驗的基礎上，通過廣泛協(xié)商，于1987年發(fā)布了世界上第一個質(zhì)量管理和質(zhì)量保證系列國際標準—ISO9000系列標準。該標準的誕生是世界范圍質(zhì)量管理和質(zhì)量保證工作的一個新紀元，對推動世界各國工業(yè)企業(yè)的質(zhì)量管理和供需雙方的質(zhì)量保證，促進國際貿(mào)易交往起到了很好的作用。

質(zhì)量管理體系的誕生

ISO在1994年提出ISO9000質(zhì)量管理體系這一概念，指“由ISO/TC176國際標準化組織質(zhì)量管理和質(zhì)量保證技術(shù)委員會制定的所有國際標準”。該標準可幫助組織實施并有效運行質(zhì)量管理體系，是質(zhì)量管理體系通用的要求和指南。我國在90年代將ISO9000系列標準轉(zhuǎn)化為國家標準，隨后，各行業(yè)也將ISO9000系列標準轉(zhuǎn)化為行業(yè)標準。

ISO9000質(zhì)量管理體系

ISO9000質(zhì)量管理體系標準是一套系統(tǒng)、科學、嚴密的質(zhì)量管理的方法，它吸納了當今世界上最先進的質(zhì)量管理理念，為各類組織提供了一套標準的質(zhì)量管理模式。

ISO9000質(zhì)量管理體系ISO9000：2008標準族的核心標準為下列四個:ISO9000：2008《質(zhì)量管理體系一基礎和術(shù)語》ISO9001：2008《質(zhì)量管理體系一要求》ISO9004：2008《質(zhì)量管理體系一業(yè)績改進指南》ISO19011：2002《質(zhì)量和環(huán)境管理體系審核指南》ISO9000質(zhì)量管理體系ISO9000質(zhì)量體系認證

企業(yè)