完整生命週期型物件導向測試方法

The Full Life Cycle Object-Oriented Testing (FLOOT) Method

 

作者:Scott W. Ambler, Senior Consultant, Ronin International, Inc.

譯者:王舜民

 

完整生命週期型物件導向測試 (Full-Lifecycle Object-Oriented Testing,以下簡稱 FLOOT) 方法論是一個驗證 (verify) 及確認 (validate) 物件導向軟體的測試技術集合。1說明了FLOOT的生命週期,並列出多種軟體開發各階段所需要的測試技術 (1詳述)。列出這個測試技術清單的目的並不是要你全部做到,只是想讓它清楚一點,讓你能選擇更多對你有幫助的技術。

FLOOT雖然按開發階段的分類方式來呈現 (1) ,但其實並不需要這樣,瞭解這點是很重要的:FLOOT所包含的測試技術也適用於漸進式 (evolutionary) 及敏捷式 (agile) 開發過程,我以「傳統」方式來呈現FLOOT的原因是想突顯「事實上在軟體開發的各個階段你都可以進行測試,而不是只有在寫程式碼的時候」的意涵。

 

1. FLOOT 的生命週期

 

 

1. 測試技術清單

測試技術

描述

黑箱測試

(Black-box testing)

給予受測項目適當的輸入,並驗證受測項目是否有產生預期結果的測試技術。

邊界值測試

(Boundary-value testing)

以受測項目應能處理的罕見或極端狀況進行測試。

類別測試

(Class testing)

確保某個類別和它的實例 (物件) 能根據定義運作的動作。

類別整合測試

(Class-integration testing)

確保所有類別和它們的實例所形成的軟體能根據定義運作的動作。

程式審查

(Code review)

一種審查對象為程式碼的技術審查方式。

元件測試

(Component testing)

確認某個元件能根據定義運作的動作。

覆蓋度測試

(Coverage testing)

確保每一行程式都至少被執行過一次的動作。

設計審查

(Design review )

一種審查對象為設計模型 (design model) 的技術審查方式。

繼承迴歸測試

(Inheritance-regression testing)

將父類別的測試案例 (test case) 直接或間接地在特定的子類別上執行之動作。

整合測試

(Integration testing)

驗證軟體的各個部分能否搭配在一起運作的測試。

方法測試

(Method testing)

驗證某個方法 (成員函數) 能否根據定義運作的測試。

模型審查

(Model review)

一種由和模型開發非直接相關的人員所進行的審查,審查方式從正規的技術審查到非正規的演練 (walkthrough) 都有。

路徑測試

(Path testing)

確保程式碼所有的邏輯路徑都至少被演練過一次的動作。

雛型審查

(Prototype review )

利用一個如同真實系統的雛型與使用者一起演練某些使用案例的過程。雛型審查的主要目的,是為了測試雛型的設計是否符合使用者的需求。

用程式證明

(Prove it with code)

以某個模型產出為基礎,實際建置出軟體來證明該模型是可行的。這是確認一個模型是否有真的反映出需要什麼,或該建置什麼的最好方法。

迴歸測試

(Regression testing)

確保應用程式在變更發生之後,先前測試過的行為仍能如預期地正常運作之動作。

壓力測試

(Stress testing)

確保系統在大量的交易、使用者、工作量….等情況下仍能如預期地正常運作的動作。

技術審查

(Technical review)

由你的一群同事 (peers) 對你的應用程式之設計進行嚴格檢查的一種品質保証技術。審查的焦點一般是放在正確性 (accuracy)、品質、可用性 (usability) 及完整性 (completeness) 上。這過程常會稱為演練、檢視 (inspection) 或同仁審查 (peer review)

使用情境測試

(Usage scenario testing)

一種由一到多個人,藉由扮演整個使用情境的方式來確認某個模型正確性的測試技術。

使用者介面測試

(User interface testing)

使用者介面測試用來確保介面的設計有依循公認的使用者介面標準,且符合先前定義的使用者介面需求。此測試通常也稱為圖形使用者介面測試  (graphical user interface testing)

白箱測試

(White-box testing)

驗証特定的程式碼能否按定義正常運作。此測試也稱為透明箱測試 (clear-box testing)

 

 

在這裡分享一些和測試有關的個人哲學:

 

1.        目的是為了找出缺陷 測試的主要目的是去確認你正在測試的東西之正確性。換句話說,成功的測試是去找出錯誤 (bug)

 

2.        你可以確認所有產出的正確性: 如你在這篇文章所看到的,你可以測試所有的產出,而不只是你的程式碼而已。你至少可以審查你的模型及文件,然後在缺陷變成程式碼前找出它們並修正它們。

 

3.        時常並及早測試 變動成本呈指數上昇的可能性,會促使你儘可能地提早進行測試。

 

4.        測試建立信心 :在 Extreme Programming Explained 一書中,Kent Beck從一個有趣的觀察中發現,當你有一個完整的測試系列 (test suite,指一組測試案例),並儘可能地時常執行它時,它會給你繼續向前進的勇氣。許多人害怕去變更他們的程式碼,是因為他們擔心這樣會破壞程式原本的功能,但若有一個完整的測試系列在被破壞的地方時,你將會發現它,然後修正它。

 

5.        對有風險的產出做測試 :風險愈高的東西,愈需要被審查與測試。換句話說,你應該花費許多努力在航空交通管制系統的測試上,至於像 “Hello World” 這樣的應用程式,就不用花那麼多力氣做測試了。

 

6.        一個測試比上千個宣稱有價值 :你可以跟我說你的應用程式是可以運作的,但在你給我看你的測試結果之前,我是不會相信你的。

 

 

這篇文章摘錄自 The Object Primer 第三版,這本書將會在2003年秋天時出版。

 

 

其他相關的文章

 

l         檢查變更成本 (解釋完整生命週期型物件導向測試為何如此重要)

l         Building Object Applications That Work 這本書是最早介紹完整生命週期型物件導向測試的概念 ,然後在 Process Patterns 一書逐步發展成型,並再一次出現在  The Object Primer 這本書。

 

 

讓我們幫你

 

Ronin International, Inc.  持續輔導為數眾多的組織學習並充滿希望地採用敏捷 (agile) 技術及理論,我們提供相關的諮詢及訓練。除此之外,我們也擁有數個可能對你有價值的網站,如 Agile ModelingAgile Database Techniques UML Modeling Style GuidelinesEnterprise Unified Process (EUP) 等。