一項測試包含涵蓋率和品質兩個重要的基準值。
測試涵蓋率是測試完整性的測量基準值,且以測試的涵蓋率為基礎,以測試需求和測試案例的涵蓋率來表示,或以執行的程式碼涵蓋率來表示。
品質是代表測試目標(系統或測試中應用程式)的可靠性、穩定性及效能的一種測量基準值。品質主要是評估測試結果和分析測試期間發現的變更要求(問題)。
涵蓋率測量值可以回答此問題:「測試有多完整?」常見的涵蓋率測量基準值以軟體需求和程式碼的涵蓋率為基礎。基本上,測試涵蓋率是關於一項需求(以需求為基礎)或程式碼設計和實作準則
(以程式碼為基礎)的任何完整性測量基準值,例如驗證使用案例(以需求為基礎)或執行所有程式行(以程式碼為基礎)。
任何妥善規劃的測試作業至少會以一套測試涵蓋率策略為基礎。涵蓋率策略可指出測試的一般用途,以引導測試案例的設計。涵蓋率策略可能只是表示驗證所有效能。
只要需求經過妥善分類,則以需求為基礎的涵蓋率策略,應該足以求得一個測試完整性的基準值。 比方說,如果已確定所有效能測試需求,則可以從測試結果推導出測量基準值;例如已驗證 75% 的效能測試需求。
如果採用以程式碼為基礎的涵蓋率,則以測試已執行多少程式碼做為測試策略。對於安全第一的系統,這種測試涵蓋率策略非常重要。
這兩種測量基準值可以手動導出(利用以下兩節的方程式),或使用自動化測試工具來計算。
以需求為基礎的測試涵蓋率(在測試生命週期中測量多次),定義了測試生命週期中截至某個里程碑 為止所完成的測試涵蓋率,例如,規劃、實作、執行及成功的測試涵蓋率。
測試涵蓋率 = T(p,i,x,s) / RfT
其中:
T 是測試數(規劃、實作、執行或成功),以測試程序或測試案例表示。
RfT 是「測試需求」總數。
-
在「規劃測試」作業中,採用下列方式計算測試涵蓋率,以測得規劃的測試涵蓋率:
測試涵蓋率(規劃)= Tp / RfT
其中:
Tp 是規劃的測試數,以測試程序或測試案例表示。
RfT 是「測試需求」總數。
-
在「實作測試」作業中,由於已實作測試程序(測試 Sript),測試涵蓋率採用下列方程式來計算:
測試涵蓋率(實作)= Ti / RfT
其中:
Ti 是實作的測試數,以測試程序數或測試案例數表示(具有相對應的測試 Script)。
RfT 是「測試需求」總數。
-
在「執行測試」作業中,使用兩種測試涵蓋率測量基準值,一種表示執行測試所獲得的測試涵蓋率,第二種表示成功測試涵蓋率(順利執行且沒有瑕庛或非預期結果等錯誤的測試)。
可採用下列方程式計算出這些涵蓋率基準值:
測試涵蓋率(執行)= Tx / RfT
其中:
Tx 是執行的測試數,以測試程序或測試案例表示。
RfT 是「測試需求」總數。
-
成功測試涵蓋率(執行)= Ts / RfT
其中:
Ts 是執行的測試數,以順利完成且零錯誤的測試程序或測試案例表示。
RfT 是「測試需求」總數。
將上述比例轉換成百分比,可以表達下列以需求為基礎的測試涵蓋率:
已涵蓋 x% 的測試案例(上述方程式的 T(p,i,x,s))且成功率達到 y%
您可以把這句有意義的測試涵蓋率陳述式和已定義的成功準則做一個比對。如果沒有達到準則的標準,則可根據此陳述式來預測剩餘多少測試工作量。
以程式碼為基礎的測試涵蓋率可衡量測試期間已執行多少程式碼,藉此和還剩多少程式碼要執行做個比較。程式碼涵蓋率可以根據控制流程(陳述式、分支或路徑)或資料流程。
-
在控制流程涵蓋率中,目的是測試程式行、分支條件、程式碼路徑或軟體控制流程的其他元素。
-
在資料流程涵蓋率中,目的是測試資料狀態在軟體操作過程中保持有效;例如,資料元素在使用之前已定義。
以程式碼為基礎的測試涵蓋率採用下列方程式計算:
測試涵蓋率 = Ie / TIic
其中:
Ie 是執行的項目數,以程式碼陳述式、程式碼分支、程式碼路徑、資料狀態決策點或資料元素名稱表示。
TIic 是程式碼中的項目總數。
將此比例轉換成百分比,可以表達下列以程式碼為基礎的測試涵蓋率陳述式:
已涵蓋 x% 的測試案例(上述方程式的 I)且成功率達到 y%
您可以把這句有意義的測試涵蓋率陳述式和已定義的成功準則做一個比對。如果沒有達到準則的標準,則可根據此陳述式來預測剩餘多少測試工作量。
雖然評估測試涵蓋率可以導出測試工作完整度的測量基準值,但根據經驗顯示,若能早在測試期間發現瑕庛並加以評估,所呈現的軟體品質也就愈高。此品質認知可以用來推測整個軟體系統的整體品質。
「認知性軟體品質」是評估軟體達成需求的一種測量基準值,就此而論,瑕庛可視為一種變更要求,表示測試目標無法達到軟體需求。
問題評估採取的方法從簡單的問題計數到精確的統計模型都有。
精確評估採用測試過程中問題的到達率或發生率的相關假設。一般模型假設比率符合波氏分佈。問題率的實際數據會依模型來調整。求出的評估值可預估目前的軟體可靠性,並預測在繼續測試和排除問題的情況下,可靠性將有何變化。這項評估稱為軟體可靠性成長模型,值得仔細研究。由於這種評估缺乏工具支援,請審慎權衡使用這種方式的成本與效益。
問題分析牽涉到在一項問題的相關屬性上分析一或多個值的問題分佈情形。問題分析可顯示出軟體的可靠性。
在問題分析中,通常會分析四個主要的問題屬性:
-
狀態 - 問題的現行狀態(提出、正在修正、結束等)。
-
優先順序 - 正在解決和已解決的問題的相對重要性。
-
嚴重性 - 這項問題對於使用者、組織、第三方等的相對影響程度。
-
來源 - 導致這項問題的錯誤起源是什麼及出處,或修正什麼元件將可排除這項問題。
在建立「問題趨勢」圖或報告時,您可以採用以時間為函數的方式來報告錯誤計數。在「問題密度報告」上,也可以顯示為一或多個問題屬性的函數,例如嚴重性或狀態。這幾種分析可以提供未來可能的問題趨勢 或分佈景況,進而顯示出軟體的可靠性。
例如,問題發生率最後一定會隨著不斷測試和修正而遞減。在無法接受軟體品質的那一點,可以建立問題或不良品質臨界點。問題計數也可以根據「實作」模型的原點來報告,以利偵測「弱點模組」、「熱點」,以及一再修正的軟體部份(表示基本設計尚有諸多缺點)。
只有已確認的問題才會納入這種分析內。並非所有報告的問題都代表實際的陷點;有些可能是來自專案範圍外的功能強化要求,或只是說已報告明過的問題。不過,仍然值得查看並分析為何報告這麼多問題,包括重複或未確認的問題。
Rational Unified Process 建議根據多項報告種類來進行問題評估,如下所示:
-
「問題分佈(密度)報告」能以時間為函數來顯示問題計數。
-
「問題存在期間報告」是特殊類型的問題分佈報告。問題存在期間報告顯示一個問題處於特定狀態的時間長短,例如「提出」。在任何存在期間種類中,問題亦可依其他屬性來排序,例如「擁有者」。
-
「問題趨勢報告」是以時間為函數,顯示各種狀態的問題計數。趨勢報告分為累加型或非累加型兩種。
這些報告大多很適合用來評估軟體品質。在搭配測試結果和進度報告
(顯示從測試中應用程式的許多反覆和測試週期中完成的測試結果)一起分析時最有用。常見的測試準則包括在特定種類中,例如嚴重性類別,對於提出的問題容忍數的陳述式,經由評估問題分佈,很容易查明。將這項分佈依測試動因來排序或分組,可以專注於評估重要的關切議題。
通常需要配合工具支援才能有效產生這種報告。
問題狀態和優先順序的比較
對每一個問題指定優先順序。優先順序分為四級通常就已足夠,例如:
-
緊急優先順序(立即解決)
-
高優先順序
-
正常優先順序
-
低優先順序
附註:成功測試的準則可以表示為問題在這些優先順序等級上的分佈情形。例如,成功測試準則的門檻可能是「沒有優先順序 1 的問題,提出的優先順序 2 問題少於五個」。應該產生如下的問題分佈圖。
很明顯不符合準則。根據測試準則的要求,此圖需要加入過濾條件,只顯示提出的問題。
問題狀態和嚴重性的比較
「問題嚴重性報告」顯示每一個嚴重性類別各有多少問題;例如,嚴重錯誤、未執行主要功能、輕微干擾。
實作模型中的問題狀態和位置的比較
「問題來源報告」顯示「實作」模型元素之間的問題分佈情形。
「問題存在期間分析」能適當反映出測試和問題排除作業的成效。比方說,如果大多數未解決的老問題皆處於尚待驗證狀態,可能表示未投入足夠的資源來重新測試。
「問題趨勢報告」顯示問題率,且特別能顯示出測試的整體狀態。 問題趨勢在測試週期內有其既定的起伏型樣。在整個週期的初期,問題率會急劇攀升,隨即達到尖峰,然後就開始緩慢下降。
為了找出問題,可以根據這個趨勢來檢視專案排程。比方說,在為期四週的測試週期期間,如果問題率到了第三週仍然很高,很顯然專案已失控。
這項簡單的趨勢分析假設問題一經發現立即修正,並於後續的建構版本中測試修正結果,因此,問題結束率和問題發現率應該會呈現相同的變化曲線。萬一事與願違,則表示問題解決流程有問題;可能是修正問題的資源或重新測試和驗證修正結果的資源不足所致。
此報告反映的趨勢顯示在專案初期,新的問題會很快發現和提出,然後隨著時間遞減。提出問題的趨勢類似於發現問題的趨勢,但稍微落後。結束問題的趨勢會隨著修正和驗證提出的問題而遞增。這些趨勢線代表一次成功的工作成果。
如果趨勢過度偏離以上的情形,則可能指出發生問題,並指示在特定的開發或測試工作上何時該投入更多資源。
搭配測試涵蓋率的測量基準值時,對於以何者做為測試完整性準則的標準,問題分析可以提供絕佳的評估。
使用一些測量基準值來評估測試目標的效能表現,以及注專於擷取這些表現的相關數據,例如回應時間、計時測寫、執行流程、運作可靠性及限制。基本上,「評估測試」作業會評估這些測量基準值,但在「執行測試」作業中,還會使用其他效能測量基準值來評估測試進度與狀態。
主要的效能測量基準值包括:
-
動態監視 - 即時擷取和顯示在測試執行期間執行的每一個測試 Script 的狀態和概況。
-
回應時間與產量報告 - 對特定參與者和使用案例的測試目標建立的回應時間和產量測量。
-
百分位報告 - 資料收集值的百分位測量和計算。
-
比較報告 - 不同測試執行的兩組(或更多)資料之間的差異或趨勢。
-
追蹤報告 - 參與者(測試 Script)與測試目標之間的訊息和互動細節。
動態監視提供在測試執行期間的即時畫面和報告,通常以直方圖或曲線圖表示。報告中會顯示測試 Script 的現行狀態、概況及進度,以監視或評估效能測試執行。
例如,在上一個直方圖中,有 80 個測試 Script 在同一個使用案例上執行。在此圖中,14 個測試 Script 是「閒置」狀態,12 個是「查詢」、34 個是「SQL 執行」、4 個是「SQL 連接」、16
個是「其他」狀態。隨著測試進行,您應該會看到每一種狀態的 Script 數目改變。顯示的輸出通常是一個正常執行且正在執行的測試執行。然而,如果測試 Script
在測試執行期間停留在某一個狀態或沒有變化,可能表示測試執行有問題,或需要實作或評估其他效能測量基準值。
顧名思義,「回應時間與產量報告」就是測量和計算有關時間和產量(已處理的交易數)的效能表現。這些報告顯示的圖形通常是回應時間(或交易數)在 Y 軸,事件在 X 軸。
除了顯示實際的效能表現之外,計算和顯示統計資訊通常也很有價值,例如資料值的平均差和標準差。
「百分位報告」會針對收集的資料類型來顯示母體百分位值,提供另一種效能統計計算結果。
必須比較兩個效能測試執行的結果,才能評估不同測試執行之間的變化在效能表現上產生的影響。請利用「比較報告」來顯示兩組資料的差異(各代表不同的測試執行)或許多測試執行之間的趨勢。
如果可接受效能表現,或當效能監視指出可能的瓶頸時(例如,測試 Script
長時間處於特定狀態),追蹤報告應該是最有效的報告。「追蹤和測寫報告」顯示較低層次的資訊。這些資訊包括參與者和測試目標之間的訊息、執行流程、資料存取,以及函數和系統呼叫。
|