|
作者：Robin F. Goldsmith ，Dorothy Graham 編譯：Blueski 雖然大多數人都認同模型的重要性，但在開發周期中，測試模型并沒有受到應有的關注。V模型是最廣為人知的測試模型，不過很多測試人員仍對V模型不是很了解。V模型還受到很多質疑，其中Brian Marick（《The Craft of Software Testing9 (Prentice Hall, 1995)》一書的作者就曾對V模型提出過一些中肯的批評。在本系列的第二篇中，我們討論了X模型，該模型覆蓋了Marick的意見，并由此形成了一個相適的測試模型，而在第一篇中，我們已經討論了V模型。在第三篇文章中，我們將V模型和X模型相結合，提出了前置測試模型，該模型沿用了前者的長處，同時又盡量彌補了前者的不足。在本文中，我們將說明實行“測試驅動開發”所能帶來的益處。 前置測試的計劃
圖1 一個復雜的文檔計劃結構 從圖中可以看到，該標準將測試計劃分為多個不同的層次，其中也包括個人文檔部分，這些文檔可以作為整個較大規模的文檔，即單獨的測試計劃（例如單元測試計劃）的組成部分。而主測試計劃則最終可以成為項目計劃的一個組成部分。 我們將逐層往下看，并探討一下這些層次是否真的對我們的工作有幫助。 主測試計劃組合了一整套的測試計劃，該計劃主要考慮的是，系統作為一個整體時必須正常運作。通常，在一個分計劃（詳細計劃）中應描述相應的單元測試、集成測試、特殊測試及系統測試。其中，特殊測試是一種綜合性的測試，而并不是被應用所驅動的那種測試，可以是諸如壓力測試、安全性測試或者可用性測試等等。相應地，在各分測試計劃中，分別組合了各自的一套性能或功能，以確保相關的單元測試、集成測試、特殊測試及系統測試內容能夠正常運作。對于每一個性能和功能來說，一份測試設計說明可以對如何驗證其正常運作進行了描述。每一份測試用例的設計說明都要標明相關性能或功能是如何工作的。 測試計劃結構帶來了很多的益處。雖然很多測試人員認為IEEE標準提供了大量冗余的文檔，這些文檔并沒有太多價值，但我們并不這么認為。我們并不反對象X模型中所提倡的寫完即交付的測試計劃文檔，但我們更提倡記錄重要的測試計劃信息，并將其作為容易記憶的內容，進行充分的共享與重復利用，以及對其進行持續改進。 對很多人來說，測試計劃主要是對測試用例的收集整理，但收集起來后文檔可能會變得很大，很難進行管理。其實從圖中可以看到，標準結構可以幫助組織和管理測試用例，由此也體現了該結構所具有的直接的價值。 我們應提前定義好可重用的測試設計說明，確定如何在通用的情形下進行測試。這些說明可以防止大量的重復工作，使我們能順利開展可靠的測試，而不至于造成時間上的延誤。同樣地，該結構可以幫助我們定義好可重用的測試用例及可選擇的資源分配。另外，該結構和測試設計說明將有助于在必要的時候重復創建測試用例。 前置內容的優先級劃分 前置測試可以從2個途徑來改進測試。其一，傳統方法一般會把風險定位到每一個測試上，由于沒有對比，因此每一項測試都成了高風險。有了前置測試計劃結構后，就可以很快地揭示可選項，這樣即可從選項中區分其優先級別。其二，我們可以排除那些常用的評定測試風險等級的技術，顯然，對于那些被忽略的測試，不會有風險加到這些測試上面，但忽略這些測試本身常常就是最大的風險。相應地，前置風險分析可以使我們確定傳統方法所忽視的緊要的風險，然后定義好有關的測試以避免這些風險的出現。當我們在各個不同層次上使用前置測試計劃的時候，其中最重要的任務就是在主測試計劃中列入項目級風險的識別及其處理的優先級排定。特別要指出的是，這一前置技術可以幫助我們預見到很多常見的突發事件。其實每個開發人員都能列舉出很多使項目停頓的意想不到的事件，而且這些事件往往是發生在項目實施的前后。 在和一個項目團隊協同工作時，我們總是可以發現他們一直在試圖使用前置風險分析方法來確定大量潛在的突發事件，而有關的報告指出，傳統的項目和測試計劃往往會忽視多達75%的突發事件。 一旦我們確定了風險，并對風險劃分了優先級別，我們就可以定義哪些系統部分需要優先進行測試。這些部分往往和組織中原先計劃好的次序有所不同。然而通常的開發計劃的目的是要開發整個程序，所以常常會以工作執行順序來做計劃，而前置測試模型定義了出現在高風險區的系統的部件--單元或集成的測試。讓測試驅動開發，就要優先對這些部分進行開發。 優先創建并測試這些高風險的部分可以幫助開發人員在付出額外勞動之前就能抓住問題所在。如果能對特殊測試給予應有的重視，則效果將會更好。特殊測試還有益于詳細測試的結果一致性，這比在系統測試 (例如負載測試和安全性測試）中進行更好，另外風險分析還可以避免忽略其它的測試（例如培訓、文檔和操作示范程序的測試）。這樣，每一次創建可以包含傳統方法需要同時通過單元、集成和系統測試后才能包含的成分。 一個基本的A-B-C例子 但是，我們的風險分析揭示，B和C之間的集成會產生最大的風險。因此，B程序和C程序應該首先創建并優先進行單元測試。由于在B和C中發現的問題可能會影響到A，所以在A開發之前發現這些問題可以有助于避免A中某些部分的重寫。 下一個高風險是A程序中的通訊能力。在傳統方式的開發計劃中，我們會將A作為一個整體進行開發，然后進行單元測試，但作為一個整體來看，A可能很龐大，比較難以進行測試，查找問題與修改錯誤。因此我們可以將A分成為2個單元，其中一個專門處理通訊功能，另一個則處理剩余的其它功能，這樣我們就可以更快地針對通訊能力進行測試，同時，其它的問題也相對更容易被發現和修改。 接著，我們需要對A程序的2個組成部分進行集成測試，以確保這2個部分能正確地組合在一起。最后，既然B-C以及A的內部組成部分的集成測試已經完成，我們可以引入并處理第三個風險，即對全部3個程序的集成所進行的測試。 需要注意的是，前置測試模型并沒有規定測試要按怎樣的特定順序來進行。它可以指導我們基于每個項目的特殊性來排定開發和測試的計劃，由此可以快速而低成本地達到項目的預期結果：高質量的軟件。 使用過前置測試模型的開發人員可以很快地想起該方法曾幫助他們避免問題的固有優越性。他們也知道這些問題常常就是項目延期、超預算的主要原因。當項目經理和開發人員意識到前置測試是如何幫助他們認識到那些風險及其規避方法的時候，他們將欣然接納具備如此多的內在價值的前置測試所帶給他們的滿意成果。 |
