作業: 定義測試細節
這項作業說明如何在目標測試項目主導的特定環境內詳述測試構想。
目的

這項作業的目的如下:

  • 定義在特定環境下實現測試構想所需的個別條件
  • 指出相關測試項目可能的觀察點和控制點
  • 指定可能的法則來輔助觀察點
  • 提供可消耗的資源來支援測試
關係
步驟
檢查目標測試項目和相關的測試構想清單
目的:  根據可能的「測試構想」來仔細瞭解「目標測試項目」。 

以「測試構想清單」為背景,檢查「目標測試項目」的相關資訊。 除了任何「增補規格」、「商業規則」及設計工作成果以外, 「使用案例」及相關的工作成果(例如,使用案例實現、使用案例分鏡腳本及使用案例情境)通常也適合做為起點。

由於資訊有限,您可能需要直接與開發人員討論「目標測試項目」。

選取一組「測試構想」來詳細說明
目的:  決定最有利於現況的一組可管理的測試來定義。 

審查「測試構想清單」,從中挑選您要設計詳細測試的許多測試構想。 在大多數情況下,您會根據時間限制、測試構想和目前測試週期的相關性、「目標測試項目」的完整性等來挑選一組測試構想。 視您的特殊情況而定,您挑選要轉入目前測試週期的測試構想的實際數量,依個案而有所不同。

第一次從特定的「測試構想清單」中設計時,建議您避免一次設計全部的測試構想。 相反地,請採取遞增和反覆方式來利用「測試構想清單」,將注意力集中在少數構想上, 表示您認為這些構想最可能為特定的測試週期產生有用的評估資訊。 這有助於降低在單一「目標測試項目」上投入太多時間的風險, 以至於疏忽其他項目,也避免浪費精力來設計後來證明沒有用的測試構想。

對於每一個測試構想,設計「測試」
目的:  對於從「測試構想清單」衍生的每一個測試,定義重要的特性。 

利用您截至目前為止已收集的資訊,找出並定義實現測試所需的重要特性來設計測試。 請注意,產生的測試設計可能有不同的記錄方式:
  • 習慣上,測試設計會記錄為工作成果:測試案例
  • 工作成果:工作量分析模型在概念上是一種特殊且較複雜的「測試案例」,與系統效能測試特別有關。
  • 視測試和專案文化的複雜性而定,測試也可能適合直接實現為工作成果:測試 Script, 如果您可以不必建立「測試案例」成果,則可以考慮這種作法。 如果採取這種方式,請以有用的資訊來充分解釋「測試 Script」,說明測試為何有用。 請利用這些註解當做非正式、內嵌的「測試案例」。

利用已收集的資訊,考量測試的每一個層面。

指出輸入、輸出及執行條件

以「黑箱」觀點看待測試,指出測試的重要公開特性。 指出需要輸入什麼來模擬測試及預期會產生什麼輸出。 也要舉出重要的執行條件 - 此步驟不需要解釋或瞭解執行條件的「如何」。

請注意,「輸入」和「預期輸出」可能只是簡單的資料類型值(例如 "A"、"1"),也可能是複雜的多維資料(例如聲音片段、物件),視特定的測試而定。 最好為特定的「輸入」或「預期輸出」定義背後的限定元,不要只是提供特的值。 這讓後續實作或執行測試的人一定可以瞭解「測試資料」背後的理由,讓他們在任何指定的執行情況下,可以選擇更換值和替代值來變化測試。

指出候選的觀察點

觀察點是執行測試期間的某個時刻,您想要觀察測試環境在此時刻的某些狀態層面。 在瞭解執行條件及輸入和預期輸出的情況下, 指出測試執行期間要觀察什麼特定點,並指出如何觀察資料。

指出候選的控制點

控制點是測試執行期間的某個時刻,您想要在此時刻上從測試的眾多控制流程中做出決策。 調查可用的「測試情境」,針對每一個情境,考量在哪些地方控制將採取不同的測試執行途徑。 核對所有不同的控制點,將控制點減少到目前測試週期所需的數量。

指定適當的測試法則

測試法則包含要測試的預期輸出值和可推測這些值的方法:特定的回應和憑以提供回應的媒介。 例如,若要驗證文書處理套件中使用的字型是否正確呈現,預覽列印可做為媒介來驗證字型呈現。 測試法則指定對照預期結果來驗證實際測試結果所需的格式和功能方面。

定義必要的資料來源、值及範圍
目的:  定義必要的「測試資料」值,包括此資料的適當來源。 

如先前所述,「測試資料」有多種外形和格式。

雖然資料相依性可能很複雜,請試著利用「領域專家」來指定適當的「測試資料」條件。 有些測試生產力工具提供的特性或功用可以簡單地產生「測試資料」集。

取得足夠可用的「測試資料」
目的:  取得並記錄足夠的有效「測試資料」來支援測試。 

在定義測試時,正確產生或校對適當的「測試資料」是其中一項最難鉅和浪費時間的作業。 在資料密集的系統種類中,情況更明顯。

建議將「測試資料」記錄在 Microsoft® Excel® 或其他具有列表資料管理介面的產品中, 例如 Microsoft® Access®。

維護可追蹤性關係
目的:  對受追蹤項目啟用影響分析以及執行評量報告。 

使用「測試計劃」中概述的「可追蹤需求」,視需要更新追蹤關係。

評估及驗證結果
目的:  驗證作業已適當完成,並且產生可接受的工作成果。 

現在您已經完成工作了,這時最好驗證該項工作確實具有足夠的價值,而不只是花費在大量紙上作業。您應該評估您的工作是否具有適當的品質,並且該工作的完成狀態可以讓團隊的其他成員用作他們的後續工作之輸入。請盡可能使用 RUP 提供的檢查清單,來驗證品質和完成狀態都「夠好」。

請邀請執行下游作業而必須以您的工作成果作為輸入的人參與審查您的暫時性工作。請在您仍有時間採取動作來處理他們關心的問題時執行這個動作。您同時也應該將您的工作和關鍵的輸入工作成果做評估,以確定您已經正確且適當地重新呈現那些工作成果。 在這個基礎上,邀請輸入工作成果的作者審查您的工作,會有助於您評估您的工作成果。

切記,RUP 是一套反覆式流程,且工作成果大多會隨著時間演進。因此,通常並不需要(通常是缺乏生產力)對只會在緊跟在後的後續工作中用到一部分,或甚至於完全用不到的工作,做出完整的工作成果。這是因為和工作成果相關的狀況極可能會變動,因此在建立工作成果所做的假設狀況就變成不正確,導致浪費許多人力物力以及成本高昂的重做。同時也要避免浪費太多時間在呈現方式上,而導致損害內容本身的價值。在呈現方式佔極大的重要性,並且可以提交專案就具有商業價值的專案環境中,您可以考慮將呈現工作交給管理資源來做。



內容
多次出現的項目
事件驅動
持續進行中
選用
規劃
可重複的
詳細資訊