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

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

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

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

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

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

一個好的軟件必須與操作者之間正常互動。在操作者使用軟件的過程中，軟件必須很好的響應操作者。（6）使用性能不佳所測試的軟件功能正常，但是使用性能不佳，如速度慢等，這樣的問題通常是由于開發人員采用了錯誤的解決方案，或是運用了不使用的算法所導致的。（7）未做好錯誤處理

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

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

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

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

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

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

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

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

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

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

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

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

2.發現的缺陷的數量說明不了軟件的質量

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

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

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

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

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

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

在測試工作應用軟件缺陷管理系統有以下優點：

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

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

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

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

錯誤報告分析（三）優秀的錯誤報告

6.7軟件測試的評測

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

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

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

已執行的測試覆蓋率=Ti/RfT%

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

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

在執行測試過程中，經常使用兩個測試覆蓋度量指標，一個是確定已執行的測試覆蓋率，另一個是確定成功的測試覆蓋率，即執行時未出現失敗的測試覆蓋率。

2．基于代碼的測試覆蓋

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

其中：Ie是用代碼語句、代碼分支、代碼路徑、數據狀態判定點或數據元素名表示的已執行代碼數。TIic是代碼的總數。

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

測試覆蓋的評測提供了對測試完全程度的評價，而在測試過程中對已發現缺陷的評測提供了最佳的軟件質量指標。

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

缺陷發現率是將發現的缺陷數量作為時間的函數來評測，即創建缺陷趨勢圖，如圖6-6所示。

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

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

缺陷消耗可使用下面公式計算：表6-3顯示了一個項目的各個缺陷損耗值，它們依據的是經過缺陷潛伏期加權的已發現的缺陷數。

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

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

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

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

動態監測：在測試執行過程中，實時獲取并顯示正在執行的各測試用例的狀態。

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

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

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

追蹤報告：測試