準則: 測試計劃
測試計劃必須涵蓋需求、風險、優先順序、策略和完成準則。這個準則詳細說明測試計劃的用途及其內容。
關係
相關元素
主要說明

概觀

測試計劃用來溝通測試作業的目的。這份文件要儘早建立,這一點很重要。在詳述階段的某次初期反覆中,及早產生這個構件,並不會太早。測試計劃的開發,也可能適合採用反覆方式,隨著資訊的取得而新增區段。

在清晰溝通測試範圍、測試需求、測試策略和資源需求時,應該要很小心。這項資訊會識別出測試工作的目的和界限、將測試的項目、測試的方式,以及測試所需要的資源。清楚闡述這項資訊有助於測試工作的檢視、意見回饋與核准。

專案剛開始時,便應該建立一份測試計劃來識別專案的整體預擬測試,稱為「主要測試計劃」。在規劃好每一次的反覆之後,也會建立一份更精確的「反覆測試計劃」(或依測試類型來組織的若干測試計劃),其中只包含反覆的相關資料(測試需求、測試策略、資源等)。如果這項資訊不會使反覆計劃難以管理或使用,您可以將它併入反覆計劃中。 

以下是部份可以更妥善地識別和溝通測試需求、測試風險和優先順序以及測試策略的準則。

識別測試需求

測試需求用來識別將測試的項目。它們是特定的測試目標。當衍生測試需求時,有些適用的一般規則:

  • 測試需求必須是可觀察、可測量的行為。如果測試需求無法觀察或測量,就無法評量它來判斷是否滿足需求。
  • 在系統的每個使用案例或增補需求和測試需求之間,並沒有一對一的關係。使用案例通常會有不只一項測試需求,有些增補需求會衍生一或多項測試需求,有些不會衍生任何測試需求(如行銷或套裝需求)。

測試需求可能衍生自許多來源,其中包括使用案例、使用案例模型、增補規格、設計需求、商業案例、使用者面談,以及軟體架構文件。所有這些都應該加以檢視,以便收集用來識別測試需求的資訊。

功能測試需求

功能測試需求,如名稱所示,是從測試目標功能行為的說明衍生而來。每個使用案例至少都應該衍生出一項測試需求。測試需求的詳細清單會包括每個使用案例事件流程的至少一項測試需求。

效能測試需求

效能測試需求是從測試目標的指定效能行為衍生而來。一般而言,效能是回應時間和/或資源使用情況的測量,這項測量是在各種狀況之下進行的,其中包括

  • 不同工作量和/或系統狀況
  • 不同使用案例
  • 不同配置

效能需求的說明在「增補規格」中。請檢視這些資料,並特別注意包括下列各項在內的陳述式:

  • 時間陳述式,如回應時間或計時概況
  • 說明在指示的時段內必須發生一些事件或使用案例的陳述式
  • 比較不同項目之行為的陳述式
  • 比較不同配置之應用程式行為的陳述式
  • 一時段內的作業可靠性(失敗的平均時間或 MTTF)
  • 配置或限制

您應該針對規格中的每一陳述式(反映了如上所述之資訊),衍生出至少一項測試需求。

可靠性測試需求

測試的可靠性需求衍生自多個來源,說明通常在「增補規格」、「使用者介面準則」、「設計準則」和「程式設計準則」中。

請檢視這些工作成果,並特別注意包括下列各項在內的陳述式:

  • 陳 可靠性或抵抗失敗、執行時期錯誤(如記憶體洩漏)的陳述式
  • 指出程式碼完整性和結構(符合語言和語法)的陳述式
  • 關於資源使用情況的陳述式

工作成果中反映了上述資訊的每個陳述式都應該衍生出至少一項測試需求。

成功的測試要求測試工作順利平衡各項因素,例如資源的限制和風險。為了完成這一點,您應該設定測試工作的優先順序,先測試最重要或風險最大的使用案例或元件。如果要設定測試工作的優先順序,請執行和使用風險評量和作業設定檔來作為建立測試優先順序的基礎。

下列各節說明如何判斷測試優先順序。

評量風險和建立測試優先順序

識別測試需求只是識別將測試之項目的一部分。您也應該設定測試項目的優先順序以及執行的順序。 執行這個步驟有許多原因,其中包括:

  • 確定測試工作的焦點在於最適當的測試需求
  • 確保儘早處理最關鍵、最重要或風險最大的測試需求
  • 確保任何相依性(如順序或資料)都會測試

評量風險和建立測試優先順序有三個步驟:

以下是這三個步驟的準則:

評量風險

建立測試優先順序是從風險的評量開始。因為失敗或很可能失敗而有最大風險的使用案例或元件,應該列入最先測試的使用案例。

首先,請識別和說明要用的風險強度指標,例如:

  • H - 高風險,無法容忍。在外嚴重曝光。公司承受大量財務損失、負債,或信譽受到無法復原的傷害。
  • M - 中等風險,可容忍,但令人不滿意。在外輕微曝光,公司可能承受財務損失,但負債或信譽受損有限。
  • L - 低風險,可容忍。很少曝光在外,或沒有曝光,公司的財務損失或負債很少或沒有。公司信譽不受影響。

識別風險強度指標之後,請列出測試目標中的每個使用案例或元件。請識別清單中每個使用案例或元件的風險強度指標,或證明您選取的值合理(用簡短的陳述式)。

您可以從三個角度評量風險:

  • 效果 - 指定的使用案例(需求等)失敗的影響或結果
  • 原因 - 從使用案例失敗所形成的不理想結果開始,檢查可能的原因
  • 可能性 - 使用案例失敗的可能性。

請選取一個角度,識別風險強度指標,並證明您的選擇合理。您不需要識別每個風險角度的指標。不過,建議您如果識別了低的指標,請嘗試從不同的風險角度評估這個項目,以確保項目確實是低風險。

以下是從這三個角度評量風險的詳細資料。

效果

如果要依效果來評量風險,請找出一個狀況、事件或動作,再嘗試判斷它的影響。請問下列問題:

「如果 ___________,會發生什麼?」

例如:

  • 「如果安裝新軟體時,系統用完磁碟空間,會發生什麼?」
  • 「如果在查詢交易期間網際網路連線中斷,會發生什麼?」
  • 「如果在採購交易期間網際網路連線中斷,會發生什麼?」
  • 「如果使用者輸入非預期的值,會發生什麼?」

以下是這些項目的證明矩陣樣本:

說明 風險緩和因素 證明
安裝期間磁碟空間不足 H 在安裝軟體時,使用者會得到產品的第一印象。任何不當的結果(如下列結果)都會讓使用者系統、已安裝軟體退化,使用者會產生負面的印象:
  • 局部安裝軟體(某些檔案、某些登錄項目),使已安裝的軟體陷入不穩定的狀況
  • 安裝中斷,使系統陷入不穩定的狀況
在查詢期間,網際網路連線中斷 L 連線中斷不會損壞資料或資料庫。但一般認為連線中斷會讓使用者有負面印象。
在採購期間,網際網路連線中斷 H 任何會造成下列結果的連線中斷或交易都不可接受,因為它們會增加額外負荷成本,減少利潤:
  • 資料庫毀損
  • 局部訂單
  • 失去資料或訂單
  • 多重訂單(重複)
輸入非預期的值 H 任何會造成下列結果的交易都不可接受:
  • 資料庫毀損
  • 資料不正確

原因

依原因來評量風險與依效果來評量風險剛好相反。首先是指出一個不當的事件或狀況,再識別出一組可能允許這個狀況存在的事件。請詢問一個類似下列的問題:

「怎麼可能 ___________ ?」

例如:

  • 「怎麼可能只有部分檔案在系統中,而不是所有已建立的登錄項目都在系統中?」
  • 「怎麼可能中央資料庫未適當反映交易?」
  • 「怎麼可能結算週期陳述式只反映資料庫中滿足所需準則的一部份記錄?」

以下是這些項目的證明矩陣樣本:

說明 風險緩和因素 證明
遺漏 / 應用程式檔案和登錄項目 H 致使應用程式無法使用(系統可能也無法使用)。安裝是使用者第一次見到應用程式。如果安裝因任何原因而失敗,使用者都會認為軟體不好。

可能原因包括:

  • 安裝流程未正確安裝所有檔案和更新登錄
  • 安裝流程因使用者介入(取消或結束)而中止
  • 安裝流程因軟體/硬體介入而中止(磁碟空間不足、不支援配置等)
  • 安裝流程因不明狀況而中止
  • 使用者刪除檔案/登錄項目

在這些原因中,安裝流程只無法偵測和處理最後一個原因。

局部訂單 H 無法完成局部訂單,造成收入損失和客戶流失。

可能原因包括:

  • 網際網路連線因使用者動作(切斷數據機連線、關閉 PC 等)而中斷
  • 網際網路連線因 IP 而中斷
  • 網際網路因員工動作(切斷數據機連線、關閉伺服器電源等)而中斷
毀損資料/資料庫 H 無論如何都不能容忍資料毀損。

可能原因包括:

  • 寫入資料庫的交易因使用者介入而未完成/確定
  • 寫入資料庫的交易因網際網路連線中斷而未完成/確定
  • 使用者在交易中輸入無效的資料
  • 資料庫存取方法/公用程式
  • 未適當移入資料庫(在最初建立實例時)
訂單重複 H 訂單重複會使公司因為出貨、處理和重新進貨而增加額外負荷,降低利潤。

可能原因包括:

  • 因使用者介入,使用者輸入訂單兩次,未確認輸入,而重複將訂單寫入資料庫的交易
  • 因非使用者介入(網際網路連線中斷所造成的回復流程,還原資料庫),而重複將訂單寫入資料庫的交易
訂單資料不正確 H 任何無法完成或引起其他額外成本的訂單都不可接受。

可能原因包括:

  • 訂單交易因使用者介入而未完成/確定
  • 訂單交易因網際網路連線中斷而未完成/確定
  • 使用者輸入無效的資料
陳述式反映的記錄數目錯誤 H 商業決策和應收帳款有賴於這些報告的準確度。

可能原因包括:

  • 搜尋/選取準則不正確
  • SQL 陳述式不正確
  • 資料庫資料毀損
  • 資料庫資料不正確

可能性

依可能性來評量風險是用來判斷使用案例(或實作使用案例的元件)失敗的可能性。可能性通常是以外部因素為基礎,例如:

  • 失敗率
  • 變更率
  • 複雜度
  • 來源 / 創始者

請注意,當使用這個風險角度時,風險強度指標會關聯於失敗的可能性,而不是如同依效果和原因來評量風險一樣,關聯於失敗對組織的效果或影響。

在這些因素和失敗的可能性之間,存在著相互關係,識別如下:

外部因素 機率
失敗發現率
失敗的可能性會隨著失敗發現率或密度的增加而增加。 問題往往會聚集起來,因此,當使用案例或元件的問題數目(密度)增加時,找到其他問題的可能性也隨之增加。當利用這個因素來評量風險時,也應該考量舊版的發現率和密度,因為先前的發現率或密度高,表示出現其他失敗的可能性也高。
變更率 失敗的可能性會隨著使用案例或元件變更率的增加而增加。因此,當變更數目增加時,帶來問題的可能性也會增加。每次程式碼有了變更,都會有「注入」另一個問題的風險。
複雜度 失敗的可能性會隨著使用案例或元件複雜度測量的增加而增加。
來源 / 創始者 對於程式碼的來源和作者的瞭解和經驗,可能會增加或減少失敗的可能性。
使用協力廠商元件通常會減少失敗的可能性。不過,只有在協力廠商元件已認證過(透過正式的測試或經驗,符合您的需求)的情況下,才是如此。
實作者的知識和技術越好,失敗的可能性也會越低。不過,例如在多重角色中使用新工具、技術或動作之類的因素,即使是最好的小組成員,失敗的可能性也會增加。



例如:

  • 安裝新軟體
  • 「在歷史上,我們曾在用來實作使用案例 1、10 和 12 的元件中找到許多問題,且我們的客戶在使用案例 14 和 19 中也要求了許多變更。」

以下是這些項目的證明矩陣樣本:

說明 風險緩和因素 證明
安裝新軟體 H 我們正在撰寫我們自己的安裝公用程式。

致使應用程式無法使用。安裝是使用者第一次見到應用程式。如果安裝因任何原因而失敗,使用者都會認為軟體不好。

安裝新軟體 L 我們正在使用在商業上成功的安裝公用程式。

安裝失敗致使應用程式無法使用,但所選安裝公用程式的供應商,其產品佔有巿場的最大額份,且已投入營運達四年之久。我們對他們的評估表明產品符合我們的需要,且客戶對他們的産品、供應商及他們的服務和支援層次感到滿意。

使用案例 1、10、12 中的高失敗發現率/問題密度。 H 由於先前的高失敗發現率/問題密度,使用案例 1、10 和 12 被視為高風險。
使用案例 14 和 19 中的變更要求。 H 這些使用案例的大量變更增加了在程式碼中注入問題的可能性。

決定作業設定檔

評量風險和建立測試優先順序的下一步驟是判斷測試目標的作業設定檔。

首先,請識別和說明要用的作業設定檔強度指標,例如:

  • H - 使用頻率非常高,每個期間會使用許多次,或會有許多參與者或使用案例使用它。
  • M - 常用,每個期間會使用若干次,或會有若干參與者或使用案例使用它。
  • L - 不常用,或只有少數參與者或使用案例會使用它。

您選取的作業設定檔指標,應該以使用案例或元件的執行頻率為基礎,其中包括:

  • 單一參與者(或使用案例)在給定期間執行使用案例(或元件)的次數
  • 執行使用案例(或元件)的參與者(或使用案例)數目

一般而言,使用案例或元件的使用次數越多,作業設定檔的指標也越高。

在識別要用的作業設定檔強度指標之後,請列出測試目標中的每個使用案例或元件。請判斷清單中每個項目的作業設定檔指標,以及您證明指標值合理的陳述。這項評量可以使用工作量分析文件的資訊(請參閱工作成果:工作量分析文件)。

範例:

  • 安裝新軟體
  • 從線上型錄訂購項目
  • 在下單之後,客戶在線上查看他們的訂單
  • 選取項目的對話框
說明 作業設定檔因素 證明
安裝新軟體 H 執行一次(通常如此),但許多使用者都會執行它。不過,在未安裝時,應用程式無法使用。
從型錄訂購項目 H 這是使用者最常執行的使用案例。
客戶查詢訂單 L 少數客戶在下單之後,會查詢他們的訂單
選取項目的對話框 H 客戶利用這個對話框來下單,庫存職員利用這個對話框來補貨。

建立測試優先順序

評量風險和建立測試優先順序的最後一個步驟是建立測試優先順序。

首先,請識別和說明要用的測試優先順序強度指標,例如:

  • H - 必須測試
  • M - 應該測試,只有在測試好所有 H 項目之後,才進行測試
  • L - 可以測試,但並不是等到所有 H 和 M 項目都測試好之後

在識別要用的測試優先順序強度指標之後,請列出測試目標中的每個使用案例或元件。請判斷清單中每個項目的測試優先順序,以及您證明合理的陳述。以下是用來判斷測試優先順序指標的一些準則。

當判斷每個項目的測試優先順序指標時,請考慮下列各點:

  • 您先前所識別的風險強度指標值
  • 您先前所識別的作業設定檔強度值
  • 參與者說明(參與者有經驗嗎?能夠接受暫行解決方法嗎?等等。)
  • 合約義務(如果未交付使用案例或元件,測試目標可接受嗎?)

建立測試優先順序的策略包括:

  • 利用每個項目的最高評量因素(風險、作業設定檔等)值來作為整體優先順序。
  • 識別一個評量因素(風險、作業設定檔等)作為最重要的項目,再利用這個因素值來作為優先順序。
  • 利用評量因素的組合來識別優先順序。
  • 使用加權綱目,其中的個別因素已經過加權,它們的值和優先順序是根據加權來計算。

範例:

  • 安裝新軟體
  • 從線上型錄訂購項目
  • 在下單之後,客戶在線上查看他們的訂單
  • 選取項目的對話框

利用最高評量值判斷優先順序時的優先順序:

項目 風險 作業設定檔 參與者 合約 優先順序
安裝新軟體 H H L H H
訂購型錄中的項目 H H H H H
客戶查詢 L L L L L
選取項目的對話框 L H L L H

利用單一因素(風險)的最高評量值判斷優先順序時的優先順序:

項目 風險 作業設定檔 參與者 合約 優先順序
安裝新軟體 H H L H H
訂購型錄中的項目 H H H H H
客戶查詢 L L L L L
選取項目的對話框 L H L L L

利用加權值計算優先順序時的優先順序:

(附註:在下列矩陣中,H = 5、M = 3 和 L = 1。總加權值大於 30 是高優先順序的測試項目,20 和 30 之間的值(頭尾包括在內)是中等優先順序,低於 20 的值是低優先順序)。

項目 風險 (x 3) 作業設定檔 (x 2) 參與者 (x 1) 合約 (x 3) 加權值 優先順序
安裝新軟體 5 (15) 5 (10) 1 (1) 5 (15) 41 H (2)
訂購型錄中的項目 5 (15) 5 (10) 5 (5) 5 (15) 45 H (1)
客戶查詢 1 (3) 1 (2) 1 (1) 1 (3) 9 L (4)
選取項目的對話框 1 (3) 5 (10) 1 (1) 1 (3) 17 L (3)

測試策略

測試策略說明特定測試工作的一般方法和目標。

好的測試策略應該包含:

測試類型和目標 到頁面頂端

清楚指出所實作的測試類型及測試目標。明確指出這項資訊,可以減少混淆,儘可能避免誤解(特別是因為某些測試看起來可能很類似)。目標應該清楚說明為什麼執行測試。

範例:

「功能測試。功能測試的焦點在於從使用者介面執行測試目標所實作的下列使用案例。」

「效能測試。系統效能測試的焦點在於測量使用案例 2、4 和 8 - 10 的回應時間。這些測試將使用一個參與者的工作量,執行這些使用案例時,測試系統不會有任何其他工作量。」

「配置測試。將實作配置測試來識別和評估三個不同配置的測試目標行為,比較效能特性和我們的基準性能測試配置。」

測試階段

清楚說明將執行測試的階段。以下識別執行一般測試的階段:

  測試階段
測試類型 單元 整合 系統 驗收
功能測試

(配置、功能、安裝、安全、容量)

X X X X
效能測試

(個別元件的效能評估)

X X (X)

選用,或當系統效能測試彰顯問題之時

 
效能測試

(負荷、壓力、競用)

    X X
可靠性

(完整性、結構)

X X (X)

選用,或當其他測試彰顯問題之時

 

技術

這項技術應該說明如何實作和執行測試。其中包括將測試的項目、測試執行期間將採取的主要動作,以及用來評估結果的方法。

範例:

功能測試:

  • 每個使用案例事件流程都將識別一組代表性的交易,每項交易都代表執行使用案例時參與者所採取的動作。
  • 每項交易都將開發至少兩個測試案例;一個測試案例反映正面狀況,一個反映負面(不可接受的)狀況。
  • 在第一個反覆中,將依照下列方式來測試使用案例 1 - 4 和 12:
    • 使用案例 1:
      • 使用案例 1 開始於參與者已登入應用程式,在主視窗,終止於使用者指定了 SAVE 之時。
      • 將利用 Rational Robot 來實作和執行每個測試案例。
      • 將利用下列方法來進行每個測試案例的驗證和評量:
        • 測試 Script 執行狀況(各個測試 Script 都已順利執行且符合需要嗎?)
        • 將利用 Window Existence 或 Object Data 驗證方法(在測試 Script 中實作)來確認在測試執行期間會顯示主要視窗,且測試目標會擷取/顯示指定的資料。
        • 測試之前,要檢查測試目標的資料庫(使用 Microsoft Access),測試之後,再檢查一次,以確認測試期間所執行的變更會精確反映在資料中。

效能測試:

  • 每個使用案例都會使用 Rational Suite PerformanceStudio (vu Script) 和 Rational Robot (GUI Script) 來實作和執行工作量分析文件中所識別的一組代表性交易。
  • 至少有三個工作量會反映在測試 Script 和測試執行排程中,其中包括:
    • 壓力工作量:750 個使用者(15 % 管理人員、50 % 銷售、35 % 行銷)
    • 尖峰工作量:350 個使用者(10 % 管理人員、60 % 銷售、30 % 行銷)
    • 名義工作量:150 個使用者(2 % 管理人員、75% 銷售、23 % 行銷)
  • 用來執行每項交易的測試 Script 都將包括用來擷取回應時間的適當計時器,如總交易時間(依照工作量分析文件所定義)和主要交易作業或流程時間。
  • 測試 Script 將執行工作量一小時(除非工作量分析文件另有說明)。
  • 每個(工作量)測試執行狀況的驗證和評量都會包括:
    • 利用狀態直方圖來監視測試執行狀況(以確認測試和工作量的執行符合預期和需要)
    • 測試 Script 執行狀況(各個測試 Script 都已順利執行且符合需要嗎?)
    • 利用下列報表來擷取和評估所識別的回應時間:
      • 效能百分位
      • 回應時間


完成準則

說明完成準則有兩個目的:

  • 識別可接受的產品品質
  • 識別測試工作何時已實作完成

完成準則的清楚陳述式應該包括下列各項:

  • 將測量的功能、行為或狀況
  • 測量方法
  • 要測量的準則或相符度

範例 1

  • 已執行所有規劃好的測試案例
  • 所有識別的問題已得出解決方案的共識
  • 已重新執行所有規劃好的測試案例,所有已知的問題已依照共識獲得處理,未發現任何新問題

範例 2

  • 已執行所有高優先順序的測試案例。
  • 所有識別的問題已得出解決方案的共識。
  • 已解決所有嚴重性 1 或 2 的問題(狀態 = 固定或延緩)。
  • 已重新執行所有高優先順序的測試案例,所有已知的問題已依照共識獲得處理,未發現任何新問題。

範例 3

  • 已執行所有規劃好的測試案例。
  • 所有識別的問題已得出解決方案的共識。
  • 已解決所有嚴重性 1 或 2 的問題(狀態 = 已驗證或延緩)。
  • 已重新執行所有高優先順序的測試案例,所有已知的問題已依照共識獲得處理,未發現任何新問題。

特殊考量

本節應該識別可能影響測試策略所說明之測試工作的任何影響或相依性。影響可能包括:

  • 人力資源(例如,支援/參與測試時,非測試資源的可用性或需求)
  • 限制(如設備限制或可用性,或需要/欠缺特殊設備)
  • 特殊需求,如測試排程或存取系統

範例:

  • 測試資料庫需要資料庫設計者/管理者支援建立、更新和重新整理測試資料。
  • 系統效能測試會使用現有網路的伺服器(支援非測試資料流量)。測試必須排在若干小時之後,以確保網路上沒有非測試的資料流量。
  • 測試目標必須使舊版系統同步(或模擬同步),才能實作和執行完整的功能測試