作業: 建立測試實作的結構
這項作業說明如何定義測試套組實作的整體結構。
目的

這項作業的目的如下:

  • 建立測試套組實作將放在其中的結構
  • 指派測試套組實作區域及其內容的責任
  • 概述必要的測試套組
關係
角色主要: 其他的: 協助:
輸入強制: 選用: 外部:
輸出
步驟
檢查測試方法、目標測試項目及評量需求
目的:  瞭解如何評量測試方式,以及關於必須如何實作特定測試套組以便評量目標測試項目的隱含作用。 

您首先要審查測試計劃來判斷評量需求,請考慮如何利用所說明的測試方法來判斷測試範圍及軟體品質的評量。請考慮您必須處理的特定目標測試項目的任何特殊相關需求。

檢查可測試性機制和支援元素
目的:  瞭解可用的可測試性元素,以及瞭解它們所支援的機制和提供的好處。 

請審查使這個環境能夠進行測試的機制,以及識別實作這些機制的特定可測試性元素。其中包括審查各項資源,例如測試小組所開發的任何函數庫,以及開發小組所實作的 Stub 或 Harness。

可測試性的實現方式,是將開發可測試軟體以及定義適當支援測試的測試方法結合起來。因此,可測試性是測試小組資產開發的一個重要面向,就如同它是軟體開發工作的重要組成部分一樣。實現可測試性(有效測試軟體產品的能力)通常會涉及下列各項的組合:

  • 測試自動化工具所提供的可測試性啟用程式
  • 建立元件測試 Script 的特定技術
  • 將複雜度和測試 Script 中的基本測試程序化定義分開並封裝起來的函數庫,它提供一個集中的控制和修正點。

分析分送需求

現行測試套組有要分送的需求嗎? 若是如此,請使用支援分送的可測試性元素。這些元素通常是特定自動化支援工具用來分送測試套組的特性,請從遠端執行它,取回測試日誌和其他輸出,以便集中判斷結果。

分析並行需求

現行測試套組有要與其他測試套組同時執行的需求嗎? 若是如此,請使用支援並行的可測試性元素。這些元素通常是特定支援工具和公用程式函數的組合,使多個測試套組能夠同時在不同的實體機器上執行。並行需要謹慎的測試資料設計和管理,以確保不會出現非預期和不在計劃中的副作用,例如兩個更新相同資料記錄的並行測試。

建立起始測試套組結構
目的:  概述將實作的測試套組。 

請列舉一或多個(在執行時)會提供完整而有意義的結果值給測試小組的測試套組,以便後來能夠向關係人提出報告。請嘗試找到一個平衡點,以便既能提供夠詳細的特定資訊給專案小組,又不會詳細到泛濫而無法管理。

有了測試 Script 之後,您大概可以自行組合測試套組及其組成部分,之後,再將穩定測試套組的工作交給測試套組實作者來完成。

如果測試套組需要建立新測試 Script,您也應該提供一些您認為這個測試套組將會 參考之測試 Script(或其他測試套組)的指示。如果它們很容易列舉,請列舉它們。如果不容易,您可以只是提供簡要的說明來概述主要測試套組的預期內容涵蓋面,將確實應該併入哪些測試 Script 的戰術決策交給測試套組實作者。

改寫測試套組結構來反映小組組織和工具限制
目的:  修正測試套組結構來處理小組責任指派。 

您可能需要進一步細分或重組已識別的測試套組,以容納小組在操作的工作分解結構 (WBS)。這有助於降低測試套組開發期間可能出現存取衝突的風險。有時候,測試自動化工具會限制個人使用自動化資產的方式,因此,請依照需要來重組測試套組,以接納這個情況。

識別測試 Script 交互通訊機制
目的:  識別必須在測試 Script 之間共用或傳遞的測試資料和系統狀態。 

在大部分情況下,測試套組都可以依照特定順序來簡單呼叫測試 Script。 以在許多情況下,這都足以確保會在測試 Script 之間,傳遞正確的系統狀態。

不過,在系統的某些類別中,系統會產生動態執行時期資料,或因其中所進行的交易結果而衍生動態執行時期資料。例如,在訂單項目和分派系統中,每次輸入訂單時,系統都會產生唯一訂單號碼。如果要使自動化測試 Script 能夠分派訂單,在前面的訂單項目測試 Script 必須擷取系統所產生的唯一號碼,並將它傳給訂單分派測試 Script。

在這類情況中,您必須考慮適合使用哪些測試 Script 交互通訊機制。一般選擇方案包括傳遞參數、撰寫和讀取磁碟檔中的值,以及使用廣域執行時期變數。每個策略都有優缺點,使它或多或少適合各種特定狀況。

定義測試套組元素之間的起始相依性
目的:  識別和記錄測試套組元素之間的執行時期相依性。 

這主要是針對執行時期作業而關聯於測試腳 Script 的排序,測試套組可能也包括在內。在執行測試時,如果未建立正確的相依性,可能會出現失敗或報告異常資料的風險。

以視覺化方式建立實作架構的模型
目的:  利用圖解來記錄和說明如何實現測試實作。 

如果您可以存取 UML 建模或繪製工具,您可能會想建立測試實作模型的圖來描述自動化測試軟體的主要元素。您也可以依照類似的方式來圖解測試自動化架構的某些重要面向。

另一個方法是在測試小組很容易看見的白板上畫這些圖。

修正測試套組結構
目的:  進行必要的調整來維護測試實作的完整性。 

當專案進行時,測試套組很可能會改變:可能會加入新的測試 Script,也可能會更新、重新排序或刪除舊的測試 Script。這些變更都是維護測試套組時自然會有的一部分,您應該擁抱它們,而不是躲避它們。

如果您沒有積極維護測試套組,它們很快就會破壞,無法使用。如果將測試套組留給新的建置,測試套組可能要花很大的成本才能恢復,放棄它,再從頭建立一個新測試套組,會比較簡單。請參閱這一頁標頭表格中的詳細資訊:區段,以取得如何維護自動化測試套組的準則。

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

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

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

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

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

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



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