第06章軟件測試

第6章測試報告與測試評測6.1軟件缺陷和軟件缺陷種類6.2軟件缺陷的生命周期6.3分離和再現(xiàn)軟件缺陷6.4軟件測試人員需正確面對軟件缺陷6.5報告軟件缺陷6.6軟件缺陷的跟蹤管理6.7軟件測試的評測6.8測試總結報告6.1軟件缺陷和軟件缺陷種類6.1.1軟件缺陷的定義和描述軟件缺陷簡單說就是存在于軟件（文檔、數(shù)據(jù)、程序）之中的那些不希望，或不可接受的偏差，而導致軟件產(chǎn)生的質(zhì)量問題。

按照一般的定義，只要符合下面5個規(guī)則中的一個，就叫做軟件缺陷。軟件未達到軟件規(guī)格說明書中規(guī)定的功能；軟件超出軟件規(guī)格說明書中指明的范圍；軟件未達到軟件規(guī)格說明書中指出的應達到的目標；軟件運行出現(xiàn)錯誤；軟件測試人員認為軟件難于理解，不易使用，運行速度慢，或者最終用戶認為軟件使用效果不好。

軟件缺陷的基本描述是報告軟件缺陷的基礎部分，一個好的描述需要使用簡單、準確、專業(yè)的語言來抓住軟件缺陷的本質(zhì)，若描述的信息含糊不清，可能會誤導開發(fā)人員。軟件缺陷的有效描述規(guī)則：單一準確：每個報告只針對一個軟件缺陷；可以再現(xiàn)：提供出現(xiàn)這個缺陷的精確步驟，使開發(fā)人員看懂，可以再現(xiàn)并修復缺陷；完整統(tǒng)一：提供完整、前后統(tǒng)一的軟件缺陷的修復步驟和信息，如圖片信息、log文件等；短小簡練：通過使用關鍵詞，使軟件缺陷的標題描述短小簡練，又能準確描述產(chǎn)生缺陷的現(xiàn)象；特定條件：軟件缺陷描述不要忽視那些看似細節(jié)但又必要的特定條件（如特定的操作系統(tǒng)、瀏覽器），這些特定條件能提供幫助開發(fā)人員找到產(chǎn)生缺陷原因的線索；補充完善：從發(fā)現(xiàn)軟件缺陷開始，測試人員的責任就是保證子元件缺陷被正確地報告，并得到應有的重視，繼續(xù)監(jiān)視其修復的全過程；不作評價：軟件缺陷報告是針對軟件產(chǎn)品的，因此軟件缺陷描述不要帶有個人觀點，不要對開發(fā)人員進行評價。6.1.2軟件缺陷的種類.（1）功能不正常

簡單的說就是所應供應的功能，在使用上并不符合設計規(guī)格說明書中規(guī)定的要求，或是根本無法使用。這個錯誤常常會發(fā)生在測試過程的初期和中期，有許多在設計規(guī)格說明書中規(guī)定的功能無法運行，或是運行結果達不到預期設計。（2）軟件在使用上不方便只要是不知如何使用或難以使用的軟件，在設計上一定是除了問題。所謂好用的軟件就是使用上盡量方便，使用戶易于操作。（3）軟件的結構未做良好規(guī)劃

這里主要指的是軟件是以自頂向下的方式開發(fā)，還是以自底向上的方式開發(fā)的。如果是以自頂向下的結構所開發(fā)的軟件，在功能的規(guī)劃及組織上比較完整，相反的以自底向上的組合方式開發(fā)出來軟件功能較為分散。要根據(jù)具體情況，選擇合適的開發(fā)方式。（4）功能不充分

這個問題與功能不正常是不一樣的。這里所指的是軟件所提供的功能在運作上是正常的，可是對使用者而言是不完整的。即使軟件的功能運作結果符合設計規(guī)格的要求，系統(tǒng)測試人員在測試結果的判斷上，一定要從使用者的角度進行思考。（5）與軟件操作者的互動不良

一個好的軟件必須與操作者之間正?；印Ｔ诓僮髡呤褂密浖倪^程中，軟件必須很好的響應操作者。（6）使用性能不佳所測試的軟件功能正常，但是使用性能不佳，如速度慢等，這樣的問題通常是由于開發(fā)人員采用了錯誤的解決方案，或是運用了不使用的算法所導致的。（7）未做好錯誤處理

軟件除了避免出錯之外，還要做好錯誤處理，許多軟件之所以會產(chǎn)生錯誤是因為程序本身不知道如何處理所遇到的錯誤。（8）邊界錯誤

緩沖區(qū)溢出問題在這幾年來已成為網(wǎng)絡攻擊的常用方式，而這個錯誤就屬于邊界錯誤的一種。簡單地說，程序本身無法處理超越邊界所導致的錯誤。這個問題除了編程語言所提供的函數(shù)有問題之外，有許多的情形是開發(fā)人員在聲明變量或是使用邊界范圍時不小心引起的。（9）計算錯誤只要是計算機程序就免不了包括數(shù)學計算。軟件之所以會出現(xiàn)計算錯誤，大部分出錯原因在于采用了錯誤的數(shù)學運算公式或未將累加器初始化為0。（10）使用一段時間所產(chǎn)生的錯誤

這個問題就是程序剛開始運行時很正常，但在運行了一段時間后卻出現(xiàn)問題。最典型的例子就是數(shù)據(jù)庫的查找功能。有一些軟件在剛開始使用時，所提供的信息查找功能運作良好，可是在使用了一段時間后卻發(fā)現(xiàn)，進行信息查找所需的時間越來越長，原因是因為采用了順序查找的方式。（11）控制流程的錯誤

控制流程的好壞，考驗著開發(fā)人員對軟件開發(fā)的態(tài)度及設計的程序是否嚴謹，軟件在狀態(tài)間的轉變是否合理，要根據(jù)流程進行控制。（12）在大數(shù)據(jù)量壓力之下所產(chǎn)生的錯誤

程序在處于大數(shù)據(jù)量狀態(tài)下如果運行不正常的話，就是屬于這種軟件錯誤。大數(shù)據(jù)量壓力測試對于server級的軟件是必須要進行的一項測試，因為server級的軟件對穩(wěn)定度的要求遠比其他的軟件高。讓程序處理超過10萬筆的數(shù)據(jù)信息，然后再來觀察程序運行的結果。（13）在不同硬件環(huán)境下產(chǎn)生的錯誤

如果所開發(fā)的軟件與硬件設備有直接的關系，這樣的問題就會相當多，如有的軟件在特殊品牌的服務器上運行就會出錯。（14）版本控制不良所產(chǎn)生的錯誤

出現(xiàn)這樣的問題屬于項目管理的疏忽，如一個軟件被反應有安全上的漏洞，后來軟件公司也很快將這個問題的修改版提供給用戶，但是推出新版本的時候，卻忘記將這個已解決掉的問題加入新版本內(nèi)。（15）軟件文檔的錯誤

如用戶手冊、說明文檔等內(nèi)容錯誤，還有軟件使用接口上的錯誤文字或錯誤用語等。6.1.3軟件缺陷的屬性.（1）缺陷標識：標記某個缺陷的唯一標識，一般由缺陷跟蹤管理系統(tǒng)自動生成。（2）缺陷描述與缺陷注釋：指對缺陷的發(fā)現(xiàn)過程所進行的詳細描述和對缺陷的一些輔助說明信息。（3）缺陷類型：一般包括功能缺陷、用戶界面缺陷、文檔缺陷、軟件配置缺陷、性能缺陷、系統(tǒng)/模塊接口缺陷等。（4）缺陷嚴重程度：主要考慮缺陷對用戶使用造成的惡劣后果的嚴重性。一般分為：

致命：系統(tǒng)主要功能完全喪失，用戶數(shù)據(jù)受到破壞，系統(tǒng)崩潰、懸掛、死機或者危及人身安全。嚴重：系統(tǒng)的主要功能部分喪失，數(shù)據(jù)不能保存，系統(tǒng)的次要功能完全喪失，系統(tǒng)所提供的功能或服務受到明顯的影響。一般：系統(tǒng)的次要功能沒有完全實現(xiàn)，但不影響用戶的正常使用。較?。菏共僮髡卟环奖慊蛴龅铰闊挥绊懝δ艿牟僮骱蛨?zhí)行。（5）缺陷產(chǎn)生可能性：指某缺陷發(fā)生的頻率，一般分為：總是、通常、有時、很少等。（6）缺陷的優(yōu)先級：處理和修正軟件缺陷的先后順序，即哪些缺陷需要優(yōu)先修正，哪些缺陷可以稍后修正。一般分為：最高優(yōu)先級、高優(yōu)先級、正常排隊、低優(yōu)先級等。軟件缺陷的優(yōu)先級在項目期間是會發(fā)生變化的。最高優(yōu)先級：指的是一些關鍵性錯誤，缺陷導致系統(tǒng)幾乎不能使用或者測試不能繼續(xù)，需立即修復；高優(yōu)先級：缺陷嚴重，影響測試，需要優(yōu)先考慮修復；正常排隊：缺陷需要正常排隊，等待修復，在產(chǎn)品發(fā)布之前必須修復；低優(yōu)先級：缺陷可以在開發(fā)人員有時間的時候被修正。（7）缺陷狀態(tài)：描述缺陷通過一個跟蹤修復過程的進展情況。一般分為：激活或打開：問題還沒有解決，存在源代碼中，確認“提交的缺陷”，等待處理，如新報的缺陷；已修正或修復：已被開發(fā)人員檢查、修復過的缺陷，通過單元測試，認為已經(jīng)解決但還沒有被測試人員驗證；關閉或非激活：測試人員驗證后，確認缺陷不存在后的狀態(tài)；重新打開：重新認定缺陷需要修復的狀態(tài)；推遲：這個軟件缺陷可以在下一個版本中解決；保留：由于技術原因或第三方軟件的缺陷，開發(fā)人員不能修復的缺陷；不能重現(xiàn)：開發(fā)不能再現(xiàn)這個軟件缺陷，需要測試人員檢查缺陷再現(xiàn)的步驟；需要更多信息：開發(fā)能再現(xiàn)這個軟件缺陷，但開發(fā)人員需要一些信息。（8）軟件缺陷的起源：指缺陷引起的故障或事件第一次被檢測到的階段。分為：需求(54%)、設計(25%)、編碼(15%)、測試、用戶使用階段等；（9）軟件缺陷的來源：指引起軟件缺陷產(chǎn)生的地方。分為：需求說明書、設計文檔、系統(tǒng)集成接口、數(shù)據(jù)流、程序代碼。（10）缺陷根源：產(chǎn)生軟件缺陷的根本因素，一般為：測試策略，過程、工具和方法，團隊/人，缺乏組織和通信，硬件，軟件，工作環(huán)境。6.2軟件缺陷的生命周期軟件缺陷的生命周期是指的是一個軟件缺陷從被發(fā)現(xiàn)、報告到這個缺陷被修復、驗證直至最后關閉的完整過程。下面是一個最簡單的軟件缺陷生命周期的例子，系統(tǒng)地表示軟件缺陷從被發(fā)現(xiàn)起經(jīng)歷的各個階段：當軟件缺陷首先被軟件測試人員發(fā)現(xiàn)時，被測試人員登記下來，并指定程序員修復，該狀態(tài)稱為打開狀態(tài)；一旦程序修復人員修復的代碼，指定回到測試人員手中，軟件缺陷就進入了解決狀態(tài)；

然后測試人員執(zhí)行回歸測試，確認軟件缺陷是否得以修復，如果驗證已經(jīng)修復，就把軟件缺陷關掉，軟件缺陷進入最后的關閉狀態(tài)。

發(fā)現(xiàn)—打開：測試人員找到并登記軟件缺陷，并將軟件缺陷提交給開發(fā)人員。打開—修復：開發(fā)人員再現(xiàn)、修復缺陷，然后提交測試人員去驗證。在許多情況下，軟件缺陷生命周期的復雜程度僅為軟件缺陷被打開、解決和關閉。然而，在有些情況下，生命周期變得更復雜一些，如圖6-1所示。圖6-1復雜的軟件缺陷生命周期通常，軟件缺陷生命周期有兩個附加狀態(tài).（1）審查狀態(tài)：指項目管理員或者委員會決定軟件缺陷是否應該修復。從審查狀態(tài)可以直接進入關閉狀態(tài)；（2）推遲狀態(tài)：審查可能認定軟件缺陷應該在將來的某一時間考慮修復，但是在該版本軟件中不修復。從推遲狀態(tài)可以進入打開狀態(tài)。6.3分離和再現(xiàn)軟件缺陷測試人員要想有效報告軟件缺陷，就要對軟件缺陷以明顯、通用和再現(xiàn)的形式進行描述。分離和再現(xiàn)軟件缺陷是考驗軟件測試人員專業(yè)技能的地方，測試人員應該設法找出縮小問題范圍的具體步驟。對測試人員有利的情況是，若建立起絕對相同的輸入條件時，軟件缺陷就會再次出現(xiàn)，不存在隨機的軟件缺陷。如果找到的軟件缺陷要采取繁雜的步驟才能再現(xiàn)，或者根本無法再現(xiàn)，碰到這種情況，可采取如下的方法來分離和再現(xiàn)軟件缺陷：（1）確保所有的步驟都被記錄：測試人員應該記下測試過程中所做的每一件事：每一個步驟、每一次停頓、每一件工作，確保導致軟件缺陷所需的全部細節(jié)再現(xiàn)；（2）注意時間和運行條件上的因素：軟件缺陷是否僅在某個特定時刻出現(xiàn)，也許取決于輸入的速度等；測試工作中看到軟件缺陷時網(wǎng)絡是否繁忙；測試的時序等，這些時間和運行條件上的因素，直接影響軟件缺陷的分離和再現(xiàn)；（3）注意軟件的邊界條件、內(nèi)存容量和數(shù)據(jù)溢出的問題；（4）注意事件發(fā)生次序?qū)е碌能浖毕荩籂顟B(tài)缺陷僅在某些特定軟件狀態(tài)中才能顯現(xiàn)出來，這類缺陷主要是與事件發(fā)生的次序相關，而不是事件發(fā)生的時間；（5）考慮資源依賴性和內(nèi)存、網(wǎng)絡、硬件共享的相互作用，考慮這些影響有利于分離軟件缺陷；（6）不要忽視硬件：在測試過程中應注意硬件對軟件的影響，測試人員必須設法在不同硬件上運行軟件，看是否能夠再現(xiàn)軟件缺陷。6.4正確面對軟件缺陷在軟件測試過程中，軟件測試人員必須確保測試過程發(fā)現(xiàn)的軟件缺陷得以關閉。軟件測試人員需要從綜合的角度考慮軟件的質(zhì)量問題，對找出的軟件缺陷保持一種平常心態(tài)。1.并不是測試人員辛苦找出的每個軟件缺陷都是必須修復的

測試是為了證明程序有錯，而不是證明程序沒錯。不管測試計劃多么完善和執(zhí)行測試多么努力，也不能保證所有軟件缺陷發(fā)現(xiàn)了就能修復。有些軟件缺陷可能會完全被忽略，還有一些可能推遲到軟件后續(xù)版本中修復。有些軟件缺陷不被修復的原因如下。（1）沒有足夠的時間（2）不算真正的軟件缺陷（3）修復的風險太大（4）不值得修復

2.發(fā)現(xiàn)的缺陷的數(shù)量說明不了軟件的質(zhì)量

缺陷數(shù)量大，只能說明測試的方法好，不能簡單的否認軟件的質(zhì)量，還要看缺陷的類型。

3.不要指望找出軟件中所有的缺陷

當缺陷足夠少的時候，就可以停止測試了。6.5報告軟件缺陷6.5.1報告軟件缺陷的基本原則在軟件測試過程中，對于發(fā)現(xiàn)的大多數(shù)軟件缺陷，要求測試人員簡捷、清晰地把發(fā)現(xiàn)的問題報告給判斷是否進行修復的小組，使其得到所需要的全部信息，然后才能決定怎么做。報告軟件缺陷的基本原則如下。1．盡快報告軟件缺陷

軟件缺陷發(fā)現(xiàn)得越早，留下的修復時間就越多。2．有效地描述軟件缺陷一個好的描述需要使用簡單、準確、專業(yè)的語言來抓住軟件缺陷的本質(zhì)。3．在報告軟件缺陷時不做任何評價

軟件缺陷報告中應不帶有傾向性以及個人觀點。4．補充和完善軟件缺陷報告

優(yōu)秀的測試人員發(fā)現(xiàn)并隨時記錄許多軟件缺陷，還應繼續(xù)監(jiān)視其修復的全過程。以上概括了報告測試錯誤的規(guī)范要求，測試人員應該牢記上面這些關于報告軟件缺陷的原則。這些原則幾乎可以運用到任何交流活動中，盡管有時難以做到，然而，如果希望有效地報告軟件缺陷，并使其得以修復，這些是測試人員要遵循的基本原則。6.5.2IEEE軟件缺陷報告模板ANS/IEEE829—1998標準定義了一個稱為軟件缺陷報告的文檔，用于報告“在測試期間發(fā)生的任何異常事件”。簡言之，就是用于登記軟件缺陷。模板標準如圖6-3所示。圖6-3IEEE軟件缺陷報告模板6.6軟件缺陷的跟蹤管理6.6.1軟件缺陷跟蹤管理系統(tǒng)軟件缺陷跟蹤管理系統(tǒng)（DefectTrackingSystem）是用于集中管理軟件測試過程中所發(fā)現(xiàn)缺陷的數(shù)據(jù)庫程序，可以通過添加、修改、排序、查尋、存儲操作來管理軟件缺陷。

在測試工作應用軟件缺陷管理系統(tǒng)有以下優(yōu)點：

1.保持高效率的測試過程軟件測試人員可以隨時向內(nèi)部數(shù)據(jù)庫添加新發(fā)現(xiàn)的缺陷，而且如果遺漏某項缺陷的內(nèi)容，數(shù)據(jù)庫系統(tǒng)將會及時給出提示，保證軟件缺陷報告的完整性和一致性。

2.提高軟件缺陷報告的質(zhì)量為了提高報告的效率，數(shù)據(jù)庫的很多字段內(nèi)容可以直接選擇，不必手工輸入。同時，系統(tǒng)可以在測試工具和測試流程上，保證不同測試技術背景的測試成員書寫結構一致的軟件缺陷報告。

3.實施實時管理，安全控制通過方便的數(shù)據(jù)庫查詢和分類篩選，便于迅速定位缺陷和統(tǒng)計缺陷的類型。通過權限設置，保證只有適當權限的人才能修改或刪除軟件缺陷，保證的測試的質(zhì)量。

4.利用該系統(tǒng)還有利于項目組成員間協(xié)同工作缺陷跟蹤管理系統(tǒng)可以作為測試人員、開發(fā)人員、項目負責人、缺陷評審人員協(xié)同工作的平臺，同時也便于及時掌握各缺陷的當前狀態(tài)，進而完成對應狀態(tài)的測試工作。軟件缺陷跟蹤管理系統(tǒng)可以通過添加、修改、排序、查尋、存儲操作來管理軟件缺陷。缺陷跟蹤管理系統(tǒng)在實現(xiàn)技術層面上來看是一個數(shù)據(jù)庫應用程序。它包括前臺用戶界面、后臺缺陷數(shù)據(jù)庫以及中間數(shù)據(jù)處理層。圖6-4所示的是一個軟件缺陷數(shù)據(jù)庫跟蹤系統(tǒng)。缺陷跟蹤管理系統(tǒng)的實現(xiàn)原理圖6-4軟件缺陷數(shù)據(jù)庫跟蹤系統(tǒng)通過使用軟件缺陷跟蹤數(shù)據(jù)庫，不但可以進行查詢，還可以找出發(fā)現(xiàn)的軟件缺陷類型，發(fā)現(xiàn)軟件缺陷的速度，以及多少軟件缺陷已經(jīng)得到了修復，能夠提取各種實用和關心的數(shù)據(jù)，可以顯示測試工作的成效和項目的進展情況。測試人員或者項目管理員可以看出數(shù)據(jù)中是否有趨勢顯示需要增加測試的區(qū)域，或者測試工作是否符合預先所制定的測試計劃的進程等。6.6.2手工報告和跟蹤軟件缺陷顯然，在軟件測試工作中，每個測試用例的結果都必須進行記錄。如果使用軟件缺陷數(shù)據(jù)庫跟蹤系統(tǒng)，那么測試工具將自動記錄軟件缺陷的相關信息。如果測試是采用手工記錄和跟蹤軟件缺陷，那么有關軟件缺陷的信息可以直接記錄在相應的文檔中。圖6-5所示的是根據(jù)ANS/IEEE829—1998標準設計的軟件缺陷報告文檔。圖6-5軟件缺陷報告文檔錯誤報告分析（一）冗長混亂的錯誤報告錯誤報告分析（二）含糊不清的錯誤報告

錯誤報告分析（三）優(yōu)秀的錯誤報告

6.7軟件測試的評測

軟件測試評測是軟件測試的一個階段性結論，是用所生成的軟件測試評測報告來確定軟件測試是否達到完全成功的標準。軟件測試評測的目的：一是量化測試進程，判斷軟件測試進行的狀態(tài)，決定什么時候軟件測試可以結束；二是為最后的測試和軟件質(zhì)量分析報告生成所需的量化數(shù)據(jù)，如缺陷清除率、測試覆蓋率等。6.7軟件測試的評測測試的評測主要方法包括覆蓋評測和質(zhì)量評測：覆蓋評測：對測試完全程度的評測，它建立在測試覆蓋基礎上，測試覆蓋是由測試需求和測試用例的覆蓋或已執(zhí)行代碼的覆蓋表示的。質(zhì)量評測：對測試對象的可靠性、穩(wěn)定性以及性能的評測。質(zhì)量建立在對測試結果的評估和對測試過程中確定的缺陷及缺陷修復的分析基礎上。6.7.1覆蓋評測覆蓋評測指標是用來度量軟件測試的完全程度的，所以可以將覆蓋用做測試有效性的一個度量。最常用的覆蓋評測是基于需求的測試覆蓋和基于代碼的測試覆蓋，它們分別是指針對需求和代碼的設計/實施標準而言的完全程度評測。1．基于需求的測試覆蓋基于需求的測試覆蓋在測試過程中要評測多次，并在測試過程中，每一個測試階段結束時給出測試覆蓋的度量。例如，計劃的測試覆蓋、已實施的測試覆蓋、已執(zhí)行成功的測試覆蓋等?；谛枨蟮臏y試覆蓋率通過以下公式計算：基于需求的測試覆蓋率=（T(p,i,x,s)/RfT）%其中，T是用測試過程或測試用例表示的已計劃的、已實施的或成功的測試需求數(shù)，RfT是測試需求的總數(shù)。在制定測試計劃活動中，將計算計劃的測試覆蓋，其計算方法如下：

計劃的測試覆蓋率=（Tp/RfT）%

其中，Tp是用測試過程或測試用例表示的計劃測試需求數(shù)。RfT是測試需求的總數(shù)。在實施測試過程中，計算測試覆蓋時使用以下公式：

已執(zhí)行的測試覆蓋率=Ti/RfT%

其中，Ti是用測試過程或測試用例表示的已執(zhí)行的測試需求數(shù)。RfT是測試需求的總數(shù)。在執(zhí)行測試活動中，確定成功的測試覆蓋率評測通過以下公式計算：成功的測試覆蓋率=Ts/RfT%

其中：Ts是用完全成功、沒有出現(xiàn)缺陷或意外結果的測試過程或測試用例表示的已執(zhí)行測試需求數(shù)。RfT是測試需求的總數(shù)。

在執(zhí)行測試過程中，經(jīng)常使用兩個測試覆蓋度量指標，一個是確定已執(zhí)行的測試覆蓋率，另一個是確定成功的測試覆蓋率，即執(zhí)行時未出現(xiàn)失敗的測試覆蓋率。

2．基于代碼的測試覆蓋

基于代碼的測試覆蓋評測是測試過程中已經(jīng)執(zhí)行的代碼的多少，與之相對應的是將要執(zhí)行測試的剩余代碼的多少。許多測試專家認為，一個測試小組在測試工作中所要做的最為重要的事情之一就是度量代碼的覆蓋情況。基于代碼的測試覆蓋率通過以下公式計算：基于代碼的測試覆蓋率=Ie/TIic%

其中：Ie是用代碼語句、代碼分支、代碼路徑、數(shù)據(jù)狀態(tài)判定點或數(shù)據(jù)元素名表示的已執(zhí)行代碼數(shù)。TIic是代碼的總數(shù)。

很明顯，在軟件測試工作中，進行基于代碼的測試覆蓋評測這項工作極有意義，因為任何未經(jīng)測試的代碼都是一個潛在的不利因素。在一般情況下，代碼覆蓋運用于較低的測試等級時最為有效，例如單元和集成級。6.7.2質(zhì)量評測

測試覆蓋的評測提供了對測試完全程度的評價，而在測試過程中對已發(fā)現(xiàn)缺陷的評測提供了最佳的軟件質(zhì)量指標。

常用的測試有效性度量是圍繞缺陷分析來構造的。缺陷分析就是分析缺陷在與缺陷相關聯(lián)的一個或者多個參數(shù)值上的分布。缺陷分析提供了一個軟件可靠性指標，這些分析為揭示軟件可靠性的缺陷趨勢或缺陷分布提供了判斷依據(jù)。對于缺陷分析，常用的主要缺陷參數(shù)有以下4個。狀態(tài)：缺陷的當前狀態(tài)（打開的、正在修復的或關閉的等）。優(yōu)先級：表示修復缺陷的重要程度和應該何時修復。嚴重性：表示軟件缺陷的惡劣程度，反映其對產(chǎn)品和用戶的影響等。起源：導致缺陷的原因及其位置，或排除該缺陷需要修復的構件。缺陷分析通常用以下4類形式的度量提供缺陷評測。缺陷發(fā)現(xiàn)率；缺陷潛伏期；缺陷密度；整體軟件缺陷清除率。1．缺陷發(fā)現(xiàn)率

缺陷發(fā)現(xiàn)率是將發(fā)現(xiàn)的缺陷數(shù)量作為時間的函數(shù)來評測，即創(chuàng)建缺陷趨勢圖，如圖6-6所示。

圖6-6缺陷發(fā)現(xiàn)率xy2．缺陷潛伏期測試有效性的另外一個有用的度量是缺陷潛伏期，通常也稱為階段潛伏期。缺陷潛伏期是一種特殊類型的缺陷分布度量。在實際測試工作中，發(fā)現(xiàn)缺陷的時間越晚，這個缺陷所帶來的損害就越大，修復這個缺陷所耗費的成本就越多。表6-1顯示了一個項目的缺陷潛伏期的度量。

表6-2顯示了一個項目的缺陷分布情況（按缺陷造成階段和缺陷發(fā)現(xiàn)階段）。按照缺陷產(chǎn)生階段和缺陷發(fā)現(xiàn)階段統(tǒng)計了一個項目的缺陷分布情況后，根據(jù)軟件開發(fā)生命周期的各個階段缺陷潛伏期度量的加權值，可以對缺陷的發(fā)現(xiàn)過程有效性和修復軟件缺陷所耗費的成本等進行評測。這里采用了一個缺陷損耗的概念，缺陷損耗是使用階段潛伏期和缺陷分布來度量缺陷消除活動的有效性的一種度量。

缺陷消耗可使用下面公式計算：表6-3顯示了一個項目的各個缺陷損耗值，它們依據(jù)的是經(jīng)過缺陷潛伏期加權的已發(fā)現(xiàn)的缺陷數(shù)。

如在驗收測試期間，發(fā)現(xiàn)了9個缺陷，在這9個缺陷中，有6個是在項目的需求階段造成的，因為在驗收測試期間發(fā)現(xiàn)的這些缺陷可以在此之前的7個階段中的任何一個階段被發(fā)現(xiàn)，所以，我們將在驗收測試階段之前，一直保持隱藏狀態(tài)的需求缺陷加權值為7。這樣，在驗收測試期間發(fā)現(xiàn)的需求缺陷的加權數(shù)值為42（即6×7=42）。

一般而言，缺陷損耗的數(shù)值越低，說明缺陷的發(fā)現(xiàn)過程越有效（最理想的數(shù)值應該為1）。作為一個絕對值，缺陷損耗幾乎沒有任何意義，但是當用缺陷損耗來度量測試有效性的長期趨勢時，它就會顯示出自己的價值。3．缺陷密度軟件缺陷密度是一種以平均值估算法來計算出軟件缺陷分布的密度值。程序代碼通常是以千行為單位的，軟件缺陷密度是用下面公式計算的。圖6-7顯示了一個項目的各個模塊中每千行代碼的缺陷密度。圖6-7各個模塊中每千行代碼的缺陷密度缺陷密度這種度量方法存在的主要問題是：所有的缺陷并不都是均等構造的。各個軟件缺陷的惡劣程度，及其對產(chǎn)品和用戶的影響的嚴重程度，以及修復缺陷的重要程度有很大差別。

解決方法：對缺陷進行“分級、加權”處理，給出軟件缺陷在各嚴重性級別或優(yōu)先級上的分布作為補充度量，這樣將使這種評測更加充分，更有實際應用價值。例如，圖6-8所示的缺陷分布圖表示軟件缺陷在各優(yōu)先級上所應體現(xiàn)的分布方式。圖6-8各優(yōu)先級上軟件缺陷分布圖.4．軟件缺陷清除率的估算方法

為了估算軟件缺陷清除率，首先需引入幾個變量。F：描述軟件規(guī)模用的功能點；D1：軟件開發(fā)過程中發(fā)現(xiàn)的所有軟件缺陷數(shù)；D2：軟件分布后發(fā)現(xiàn)的軟件缺陷數(shù)；D：發(fā)現(xiàn)的總軟件缺陷數(shù)。由此可得到D=D1+D2的關系。對于一個軟件項目，則可用如下的幾個公式，從不同角度來估算軟件的質(zhì)量：·質(zhì)量（每個功能點的缺陷數(shù)）=D2/F·軟件缺陷注入率=D/F·整體軟件缺陷清除率=D1/D例如，假設有100個功能點，而軟件開發(fā)過程中發(fā)現(xiàn)20個軟件缺陷，提交后又發(fā)現(xiàn)了3個軟件缺陷。則F=100,D1=20,D2=3,D=D1+D2=23·質(zhì)量（每個功能點的缺陷數(shù)）=D2/F=3%·軟件缺陷注入率=D/F=23%·整體軟件缺陷清除率=D1/D=86.96%軟件缺陷評測用來度量測試的有效性，以及通過生成的各種度量來評估當前軟件的可靠性，并且在預測繼續(xù)測試并排除缺陷時可靠性如何增長方面是有效的。但是，這些度量本身是不充分的，在評測中需要用覆蓋評測度量做補充，當與測試覆蓋評測結合起來時，缺陷分析可提供出色的評估，測試完成的標準也可以建立在此評估基礎上。6.7.3性能評測主要的性能評測包括以下幾點。

動態(tài)監(jiān)測：在測試執(zhí)行過程中，實時獲取并顯示正在執(zhí)行的各測試用例的狀態(tài)。

響應時間和吞吐量：測試對象針對特定測試用例的響應時間或吞吐量的評測。

百分比報告：已收集數(shù)據(jù)類型的百分比計算與評測。

比較報告：代表不同測試執(zhí)行情況的兩個（或多個）數(shù)據(jù)集之間的差異或趨勢。

追蹤報告：測試