作業: 實作測試套組
這項作業說明如何識別應該一起執行的測試。
目的

這項作業的用途是執行下列動作:

  • 將要執行的測試集合組合起來,以擷取值的測試記錄
  • 操作有利的測試組合來形成適當的測試涵蓋面寬度和深度
關係
角色主要: 其他的: 協助:
輸入強制: 選用: 外部:
輸出
步驟
檢查候選的測試套組
目的:  瞭解測試套組,選取將實作的候選測試套組

開始時,請檢視任何現有的測試套組概要,判斷哪些測試套組是適合目前實作的候選項。請利用反覆測試計劃、測試觀念清單及任何其他測試定義工作成果來作為決策基礎。

檢查相關的測試和目標測試項目
目的:  瞭解規劃的測試和目標測試項目之間的關係

請針對您為了實作而選取的每個測試套組,識別哪些目標測試項目和相關聯的測試是要併入測試套組範圍的候選項。

識別測試相依性
目的:  識別測試關聯於其他各項測試的任何相依性,以及關聯於系統狀態的任何相依性

開始時,請先考量測試環境配置及特定系統啟動狀態。請設想會有哪些特定設定需求,如相依資料庫的起始資料集。當多個測試套組都將使用目標環境配置時,請識別可能需要針對每個測試套組來管理的任何配置設定,如影像顯示器的畫面解析度或區域作業系統設定。

現在,請確定測試之間的任何特定關係。請尋找「在執行測試套組所包含的某項測試時,會產生另一項測試要用來作為前置條件的系統狀態變更」的相依性。

識別了相關的相依性之後,請判斷各項相依測試的正確執行順序。

識別重複使用的機會
目的:  重複使用現有的資產及合併新資產來改進測試套組的可維護性 

維護測試套組(尤其是自動化測試套組)的主要挑戰之一,是確保可以輕易進行不間斷的變更。在可能而且有用的情況下,維護一個集中修正點來處理多個位置所用的元素,是很好的想法。當相同元素很可能改變時,尤其如此。

測試本身會形成自然的模組單元,將測試組合到測試套組中,通常會跨越多項測試來識別重複的流程元素,如果這些元素合併起來,會更容易維護。請找機會識別有可能重構成標準常式來協助進行維護的任何一般測試機制。

套用必要的基礎架構公用程式
目的:  將支援測試所需要的複雜實作細節分解出來,成為簡化的公用程式函數

大部分測試工作都需要使用一或多個會產生、收集、診斷、轉換和比較測試執行期間所用之資訊的「公用程式」。這些公用程式通常會簡化手動執行時複雜、費力又容易出錯的作業。這個步驟與在測試套組內套用現有的公用程式函數以及識別所需要的新公用程式相關。

簡化這些公用程式的介面,將儘可能多的複雜度封裝在公用程式的私密實作內,是一個很好的想法。將公用程式開發成可供手動和自動測試工作依需要來重複使用,也是一個很好的想法。

我們建議您不要隱藏這些公用程式內之個別測試的特性資訊:相反地,請將公用程式限制於複雜的資訊收集機制,或比較實際值和預期結果等,但可能的話,請傳入每項個別測試的特定特性,如同從控制測試或測試套組中輸入,以及傳回個別的實際結果,如同輸出到控制測試或測試套組。

判斷回復需求
目的:  在不需要完整重新執行測試套組的情況下,便能夠回復測試套組

請判斷在執行期間,當測試套組失敗時,測試套組內適合用來進行回復的點。當測試套組將包含大量測試或長時間執行(通常是自動式)時,這個步驟特別重要。雖然回復點在自動化測試套組中被視為一項需求,但在手動執行的測試套組中,回復點的考量也很重要。

除了回復點或重新啟動點之外,當採用自動化測試套組時,您也可以考慮自動化測試套組回復。自動回復的方法有兩種:1) 基本回復,現有的測試套組可以從某項測試的次要錯誤中自行回復,通常會在測試套組的下一項測試回復執行,或 2) 複雜回復,在測試失敗之後加以清除,重設適當的系統狀態,其中包括重新啟動作業系統和還原資料(必要的話)。如同第一個方法,測試套組接著也會判斷失敗的測試,選取下一項要執行的測試。

實作回復需求
目的:  實作和驗證回復程序能依照需要來運作

依所需要的複雜程度而定,可能需要花一些工夫來實作和穩定回復處理。您必須提供一些時間來模擬許多可能的失敗(及少數不太可能發生的失敗),證明回復處理能夠運作。

當進行自動化回復時,上一步驟所概述的方法會有它的長處和弱點。您應該仔細考慮複雜自動化回復的成本,起始開發和後續維護工作等方面都包括在內。有時手動回復就非常好了。

使測試套組穩定
目的:  解決關聯於系統狀態及測試執行順序的任何相依性問題

可能的話,您應該花一些時間,利用一或多項試用的測試執行作業來穩定測試套組。 當不相干的測試之間耦合性過於緊密,相關的測試之間內聚力太低時,實現穩定性的困難會相對於測試套組的複雜度而成等比例增加。

當在給定測試套組內同時執行若干項測試時,可能會發生錯誤,但獨立執行個別測試時,就不會出現這個情況。這些錯誤通常都很難追蹤和診斷,當它們出現在很長的自動化測試執行途中,尤其如此。如果可行的話,您不妨每當新增其他測試時,都定期重新執行測試套組。這可以協助您將少量潛在的候選測試隔離出來,以便診斷它們來找出問題。

維護可追蹤性關係
目的:  使追蹤項目能夠執行影響分析和評量報告

使用「測試計劃」中概述的「可追蹤需求」,視需要更新追蹤關係。測試套組可以追蹤到定義好的測試案例或測試觀念。您可以選擇性地將它們追蹤到使用案例、軟體規格文件、實作模型元素,以及測試涵蓋面的一或多項測量。

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

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

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

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



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