作業: 定義測試方法
這項作業說明如何定義測試策略以及所要採用的特定技術,並概述自動化測試架構。
目的

這項作業的目的如下:

  • 指出要採用來進行屬意的測試之每一種特定的技術
  • 概述每一種技術的工作,包括該技術可以支援的測試類型
  • 定義自動化測試系統的候選架構
關係
步驟
查驗測試動機及測試項目
目的:  考量任務、測試動機以及測試項目對即將展開的測試作業方式之影響。 

使用評估任務作為環境定義,檢查反覆的「測試計劃」,並瞭解已針對即將展開的測試作業指出的測試動機。您可能需要對「動機」來源做進一步的查驗 - 通常反覆式計劃會提供方法來找出其餘相關資訊。

針對每一個「動機」,考需要使用什麼樣的測試方法和相關聯的技術,才能處理每一個動機。同時也請檢查反覆式「測試計劃」,並瞭解測試項目。針對每一個決定要進行的測試項目,分別考量每一個「動機」,以及所延伸的方法和技術。如果您找不到測試項目的詳細資料,或是不熟悉測試項目,則和開發人員討論已決定的項目會有一些幫助,這項工作通常是從 軟體架構師或開發小組負責人開始。

將焦點集中在識別為合理地處理評估任務與動機時,所需要採用的最少技術組合。看看有什麼技術可以處理多個必要的測試層面。記下其他可能值得進一步探索的技術,不過要將這些技術列為額外的技術,而不是主要技術。

檢查軟體架構
目的:  考量軟體架構對測試方法的影響。 

研究「軟體架構」,以增進對架構的主要元素機制、主要視圖等等的瞭解。通常,「軟體架構」文件會提供充分的資訊,專注於可以在考慮測試方法時使用的正確詳細程度。若要澄清其中的資訊,或是若沒有這項文件時,最好能和開發人員討論架構方面的事項,這通常是直接和軟體架構師洽談,或是和其中一個開發小組負責人洽談。

專注於指出及討論主要機制,並進一步瞭解系統的這些層面。架構的每一種機制和主要特性,都很可能會形成測試作業的挑戰或限制。例如,分散式的架構可能需要將測試小組組織成小團隊,每一個小團隊負責一個架構層級。

雖然通常可以使用具創意的實作和執行策略來克服這些挑戰,但有時也可能需要開發小組修改軟體,才有辦法進行如 作業:定義可測試元素指出的測試。

考量測試方法的適當範圍及深度
目的:  考量測試方法在範圍及深度方面的完整性。 

考量測試方法需求已知的所有詳細資料,退後一步並從較高層的視景來考量測試方法,會很有幫助。哪些事情是測試方法沒有處理,但是卻應該處理的? 是否有哪些事情應該注意,但是卻沒有出現在任何記錄的資訊中?

依據您的經驗,審查測試方法的需求,以取得在專案生命週期的本階段中,適當的範圍和深度。考量有助於呈現出更完整的方法的其他需求。

識別可重複使用的現有測試技術
目的:  重複使用或改編現有的經過證實的適當測試技術。 

從您自己的經驗中,或從您可以取得的其他人的經驗,在現有的技術中,找出可以符合測試方法需求,或可以加以改編來符合測試方法需求的技術。

識別額外的技術
目的:  識別可以提供廣泛及充足的測試方法之技術。 

想要取得「完整」的測試方法並不是很實際的思考,如果您只有有限的時間和資源,則總是會有其他許多技術可以嘗試。

不過,很重要的一點是測試方法一定要足夠週詳和廣泛,才能有效評估所認同的品質。這項要求所需要的方法,必須能評估品質風險所涵蓋的足夠層面或是品質的角度,讓專案小組在評定認同的品質時,具有足夠的信心。

定義技術
目的:  概述每一種技術的工作,包括該技術可以支援的測試目標。 

概述每一種技術的工作。指出該技術可以支援的測試類型、目標和範圍、實作方法、測試準則、評量方法以及技術的自動化需求。

在許多情況下,您會在各個專案中重複使用相同的技術。在這種情況下,您只需要參考該技術的一般定義,或是複製現有的定義,再做適當的修訂即可。

針對每一種現有的或必要的技術:

定義目標和範圍 頁面頂端

許多技術都可以支援多種測試類型,因此請仔細思考每種技術需要支援哪些測試。如果這是第一次定義某種技術時,此動作可以協助您識別所需要的作業範圍。

仔細思考此項技術所代表的基礎目標和價值。

說明實作方法 頁面頂端

定義要如何實作技術。不能只是說「我們要進行系統效能測試」- 您需要仔細思考如何達成該目標。

您希望使用的某些技術可能極不符合經濟效益。在摘要說明您要如何實施此項技術時,您就可以對所涵蓋的底層機制,以及進一步貫徹該技術的實際性,取得整體瞭解。

識別適當的評估方法 頁面頂端

決定您要如何觀察及評估使用此技術實施的每項測試結果。請考量可供使用的不同測試準則 - 是否只有一種準則存在,或是有不同的方式可用來判斷每項測試的結果?

識別適用的自動化方法 頁面頂端

自動化在許多測試技術中,可扮演重要角色。在某些情況下,自動化方法比較不準確,它只能對進行手動測試提供支援。

想想會運用到該項技術的工作要用什麼方式實作、維護及管理,是最有效率。請維持開放的心胸,做寬廣及深度的思考,並盡可能考量愈多選項愈好。

識別適用的工具 頁面頂端

識別和此測試技術搭配使用的適當工具。請使用在前一個步驟識別使用自動化方法取得的成果。

請記得要考量工具種類的寬廣範圍;您的候選工具清單不只要包括執行測試的自動化工具。除了自動執行測試的工具外,請考量可以加強測試小組生產力的工具,這些是如透過使用「測試資料」管理、「測試結果」分析、偶發事件與「變更要求」報告工具等等,來減少重複性的人工作業。

概述自動化測試架構
目的:  定義自動化測試系統的候選架構。 

依據從類似的系統或類似的問題領域獲得的經驗,來開始定義自動化測試系統的候選架構。

建議您回顧開發軟體架構的相關資訊,將助於您執行這項作業。

定義測試資產配置管理策略
目的:  考量測試在配置管理方面的需求。 

如同在軟體開發專案期間所產生的許多其他工作成果,測試資產是配置管理及版本控制的候選項目。

特定的需求可以涵蓋從決定使用基本的備份及回復服務,到完整支援在多個位置,針對不同的應用程式版本,並列開發自動化測試 Script 的複雜作業。

想想您的配置管理需求,並開始概述實現那些需求所需要的可能底層機制。

調查可重複使用資產的可用性
目的:  減少重複使用現有的經過證實的資產之風險與努力。 

有時,從頭開始建置資產是較實際的做法,有時則不然。請嘗試在針對建立新的工作成果時,採行完全「自己動手」哲理,和建立精密且繁文縟節的圖書館員原則之間,取得平衡。

有時某個方法會比其他方法更理想,因此您必須要有足夠的彈性,才能充分取得這些方法帶來的好處。

擷取發現
目的:  記錄和測試方法相關的重要資訊。 

視包括團隊規模和組織文化在內的一些因素,在記錄您針對測試方法所做的決定方面,總是會有好的和壞的記錄方式。

您通常要考慮兩種對象:管理團隊會審查這項資訊,來提供核准及瞭解測試方法的隱含底層機制,而測試小組則會使用測試方法作為要執行的作業準則。請嘗試找出可以適當解決這兩種需求的媒體:也許可以考慮使用專案的企業內部網路網站。

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

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

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

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



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