作業: 定義可測試性元素
這項作業說明如何指定可支援和推動測試的元素。
規範: 測試
目的

這項作業的目的如下:

  • 指出支援目標測試項目所需的元素
  • 指定在每一個「測試環境配置」中推動測試所需的測試實作基礎架構的實體元素。
  • 定義必須符合才能實際測試軟體的軟體設計需求
關係
步驟
對於每一個必要的目標測試項目,指出與測試機制的關係
目的:  瞭解目標測試項目所需的測試機制支援。

對於每一個目標測試項目,審查測試機制的清單並指出可提供支援的項目。 分析選定的測試機制提供完整測試解決方案的可能性,以及如何修改才會更合適。 如果找不到適合的機制或修改工作太龐大,請定義新的測試機制,試著在具體性和可重複使用性之間取得平衡。

指出系統的動態元素和事件
目的:  瞭解系統的動態和執行時期層面。 

利用可用的軟體需求和設計資訊,指出系統的動態元素和事件。 利用使用案例、設計、實作及部署模型,您可以指定相關的項目,例如控制類別、程序、執行緒及事件。 可著手研究的項目包括以 <<control>> 為模板的類別、使用案例實現及流程架構觀點中的元素, 或以 <<process>> 或 <<thread>> 為模板的實作模型。

至於測試環境加諸的限制,請定義實體需求。

指出系統界限和介面
目的:  以服務提供者的角度瞭解系統的責任,以用戶端的角度瞭解系統的相依性。 

另一組適合檢查的元素是系統的「介面」,尤其是與系統界限外部的參與者有關的介面。 利用「設計模型」和「實作模型」,尋找以 <<interface>> 模板來定義的元素。 也要檢查模型中是否存在以 <<boundary>> 為模板的類別。

身為測試人員,最好跨越這些系統界限來探索,以瞭解用戶端和服務提供者對於相關系統的期望。 這樣可以更完整地瞭解介面驗證及需要測試和模擬這些介面的測試基礎架構有何需求。

指出測試基礎架構元素
目的:  定義測試工作中可推動必要測試的基本元素。 

為了成功完成反覆式測試工作,必須指定和維護適當的基礎架構。 缺乏以基礎架構來維護,測試工作會很快變得難以掌控和不能使用。 測試基礎架構很明顯與自動化測試工作有關,但也是手動測試工作的考量重點。

請考量系統的動態元素和事件;這些項目在個別測試的實作上有何相依性? 儘量切斷每個測試之間的相依性,利用一般的控制點來間接地管理。 一般可探索的相依性領域包括測試導覽、測試資料用法及系統狀態變更。

利用您已收集的資訊,考量什麼需求會主導測試基礎架構,以及需要什麼工具才能成為成功的測試方法。

子主題:

輔助一般測試情境 頁面頂端

對於遵循的情境或程序,有些測試在執行時會有通用的結構,但對於不同的測試目標項目,仍然需要執行多次相同的程序。 以測試自動化為例,最好建立一般的測試 Script 或公用程式函數, 在許多不同的情況下重複使用,以有效率的方式來處理這些常見的測試情境。 需要改變測試情境時,這提供一個集中修改的位置。 例如,在適當類型的介面元素上進行標準界限測試,驗證 UI 元素是否遵守 UI 設計標準。

輔助測試資料相依關係 頁面頂端

要在特定的測試環境配置下進行測試時,使用的測試資料值有可能發生衝突。 當多位測試團隊成員共用環境時,這個問題將更惡化。 請考慮採取資料驅動方法來切斷測試資料值和測試 Script 之間的關聯,並為測試資料提供一個集中收集和修改的位置。 這樣有兩個主要的好處;讓所有測試團隊成員看到測試資料,避免在測試資料用法上發生衝突, 且在需要更新測試資料時,有一個集中修改的位置。

輔助測試狀態相依性 頁面頂端

大多數測試在執行前會要求系統必須處於一定的狀態,且在完成時應該讓系統恢復到特定的已知狀態。 一般的相依性會涉及安全性權限(函數或資料)、動態或依環境而定的資料(例如系統日期、序號、使用者 ID 偏好等)、資料有效期限(例如安全密碼、產品期限等). 有些測試彼此高度依賴;例如,一項測試可能建立唯一的序號,但隨後有一項測試可能需要分派相同的序號。

常見的解決方案是利用測試套組,以正確的系統狀態順序來排列相依的測試。 然後,可以利用適當的系統回復和設定公用程式來隔開測試套組。 對於自動化測試,有些解決方案可能會採用集中式的動態系統資料儲存體,並在測試 Script 內利用變數來參照集中的資訊。

輔助衍生測試資料值 頁面頂端

測試有時需要從執行時期系統狀態的一或多個層面來計算或導出適當的資料值。 這適用於輸入和預期結果的測試資料值。請考量開發公用程式來計算求出的資料值,簡化測試執行並排除人為錯誤可能造成的不正確性。 可能的話,請開發這些公用程式在手動或自動化測試工作中使用。

輔助一般測試導覽路徑 頁面頂端

對於測試自動化,您應該考量隔離一般導覽順序,並以集中的公用程式函數或測試 Script 來實作。 然後,在許多位置上就可以重複使用這些一般導覽順序,在後來需要變更導覽時有一個集中修改的位置。 這些一般的導覽輔助作法只是在應用程式中導覽;除了驗證起始狀態和結束狀態,本身通常不執行任何測試。

指出測試特有的設計需求
目的:  指出測試規範的需求,可能在軟體工程流程、軟體架構及相對應的設計和實作上施加限制。 

尤其,在考量測試自動化時,測試實作和評量需求很可能施加一些限制,約束開發團隊執行軟體工程流程的作法,以及軟體的架構和設計。 請注意,不可妨礙軟體開發團隊的核心開發工作及測試團隊執行必要測試的能力。 關於如何向開發團隊表達測試團隊的需求,以及尋求可行的解決方案來滿足所有規範的需求,請參閱作業:取得測試性意見來取得相關資訊。

利用已收集的資訊,考量測試工作在開發工作上提出的需求。

子主題:

指定測試介面 頁面頂端

考量找到的介面;測試工作是否還有其他需求必須納入軟體設計中且後續會出現在實作中? 在某些情況下,特別需要其他介面來支援測試工作,或現有的介面需要其他操作模式或修改的訊息簽章(變更輸入和傳回參數)。

關於目標部署環境(記錄在測試環境配置中)和開發排程本身,請指定測試工作上的限制和相依性。 這些相依性可能要求提供 Stub,以模擬無法取得或做為測試的成本太高的環境元素,或製造機會來儘早測試局部完成之系統的元件。

指定內建測試函數 頁面頂端

有些測試有潛在的價值,但成本太高而不值得以真正的黑箱測試來實作。 再者,在高度可靠的環境中,必須能夠儘快測試和隔離錯誤,才能快速解決問題。 在這些情況下,直接在可執行的軟體本身內建測試應該很有用。

達到這個目的有各種不同的方法;其中兩種最常見的方法是納入內建的自我測試,由軟體利用重複的處理週期來執行自我整合性測試, 以及納入診斷常式,在軟體收到診斷事件訊息時或在系統已設定為啟用診斷常式時執行。

指定測試設計限制 頁面頂端

開發團隊的一些設計和實作選項可能允許或禁止測試。 雖然其中有些選項絕對有必要,但仍有許多較小的決策(尤其在實作領域中)不會太影響開發團隊,但對於測試團隊的影響很大。

值得考量的方面包括:採用標準、正式的通訊協定;使用測試自動化工具可辨識的 UI 實作元件; 遵守 UI 設計規則,包括 UI 元素的命名;一致地使用 UI 導覽慣例。

定義軟體追蹤需求
目的:  指定支援測試實作和執行所需的軟體功能的需求。 

利用先前在作業上執行的工作,定義在軟體設計和實作中應該考量的特定測試需求和限制。

必須清楚向開發團隊解釋為何要在軟體中內建特定測試功能的理由。 主要理由通常分為下列幾個範圍:

  • 經由在目標測試項目和手動或自動化測試之間提供介面來實作測試 - 手動和自動。 這通常是測試自動化的重大考量,可以協助克服測試自動化工具存取軟體應用程式來輸入和輸出資訊時的限制。
  • 由開發的軟體本身來執行內建的自我測試。
  • 隔離目標測試項目和其餘開發和測試的系統。

軟體內建的特定測試功能,必須在內建測試功能的價值與實作和測試成本之間取得平衡。 內建的測試功能包括產生審核日誌、自我診斷功能及用來查詢內部變數值的介面。

另一種常用的測試專用功能是在整合工作期間,需要提供 Stub 給尚未實作或納入的元件或子系統。 Stub 有兩種主要的實作樣式:

  • 除了提供特定的預定值做為輸入或回覆值以外,只是「虛擬的」且無其他功能的 Stub 和驅動程式。
  • 更聰明且可以「模擬」或接近更複雜的行為的 Stub 和驅動程式。

第二種 Stub 也是一種功能很強的作法,可以將元件或元件群組與系統的其餘部分隔開,更有彈性地實作和執行測試。 如稍早對於特定測試功能的描述,在複雜 Stub 的價值和 Stub 實作與測試成本之間必須考量平衡關係。 請慎用第二種樣式,有兩項理由:首先,需要投入更多資源來實作,其次,很容易疏忽 Stub 的存在,後來忘記移除。

依據特定測試需求,將發現結果直接記錄在設計和實作模型上,或利用一或多個測試介面規格。

定義測試基礎架構
目的:  指定支援測試實作和執行所需的測試基礎架構的需求。 

利用先前在作業上執行的工作,定義支援測試實作和執行所需的測試基礎架構。

切記您在定義基礎架構的實作特性;主要目標是定義將實作該基礎架構的各個解決方案部分。

子主題:

測試自動化元素 頁面頂端

測試自動化基礎架構的重要需求或特性包括:

  • 導覽模型:一般方法是來回、分段或混合方法。其他替代方案包括使用 Action-Word 架構或畫面導覽表格。
  • 外部資料存取:在外部從測試指令中存取資料的方法
  • 錯誤報告和回復:一般錯誤處理常式和「測試套組」回復執行 wrapper
  • 安全和存取設定檔:自動化測試執行使用者 ID
  • 軟體執行自我測試的能力

將您的決策當做定義記錄在「測試自動化架構」的實作區段、 當做流程指引記錄在一或多個「測試規範」中,或做為「測試 Script」、「測試套件」或測試程式庫公用常式。 如需進一步的建議,請參閱工作成果:測試自動化架構

手動測試元素 頁面頂端

手動測試基礎架構的重要需求或特性包括:

  • 測試資料儲存庫:存放測試資料定義的一般儲存庫。
  • 還原和回復:將測試環境配置還原或回復到已知狀態的方法。
  • 隔離目標測試項目和其餘開發和測試的系統。

將您的決策當做流程指引記錄在一或多個工作成果:專案特定準則中。

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

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

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

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



詳細資訊