軟件測試的革命(2)

　　圖1：可理解性問題(基于Leffingwell和Widrig的觀點)

　　實際上，Leffingwell和Widrig并沒有真正地考慮到測試的問題。他們的主要目的是想讓需求具備很高的可理解性，以便于讓用戶和投資者能夠充份理解。他們沒有解決這樣的問題，即如何把規格說明提交給其他投資者和生命周期的其它階段。作為一種爭議，他們認為有必要保留一部份不明確性。而實際上，不明確的需求顯然會讓測試人員發瘋。

　　Marick提出的測試驅動型開發方法則走向另一個極端：測試代表了需求，測試的表現形式是一些可編譯、可執行的代碼。但是，如果測試(需求)的唯一表現形式是代碼的話，你就很難和商務人員/投資者/客戶進行有效溝通，甚至也很難和其他測試人員及開發人員進行溝通。所有這些人都認為測試的形式本該是數據和流程，所以如果要以那種方式來做的話，你的測試必須變得非常容易進行交流。

　　一些公司正致力于為這種隔閡提供解決之道。Rational正積極參與一個OMG團體關于UML測試預定義項目，該項目可以把測試表示為數據和可視化的流程，例如順序圖和活動圖。我們正在開發一些工具來對待以下三種表示方法，代碼，數據和流程，并取代類似的測試視圖。

　　在過去，我們制作了這些“實例化規格說明”，按照RUP的命名方法，可稱之為“用例實現”。“實例化規格說明”和“用例實現”的相似性可以通過援引最近的一個使用Agile方法的工作團體的報告來說明：

　　[一個參與者]提到，和他一起工作的人都很喜歡使用“測試第一”的開發方式。當測試框架被開發好以后，特別是當用于組織運行的測試腳本被定義好時，他們的工作變得更為容易。而用例在組織起來開發腳本時會有所幫助。他們的測試可以捕捉到用戶的需要。人們之所以喜歡這樣的方法，其原因是它提供了他們工作所需的結構。在Agile方法中，需求以“案例(story)”的形式存在。于是，測試腳本將以接口已明確定義好的形式把這些“案例”編織在一起。這意味著結對編程的人可以根據他們需要的順序相互測試接口[注5]。

　　類似地，OMG測試預定義工作組發現，將UML排列起來也很容易。你可以將一個用例實現轉成為測試，這只需增加兩件東西：驗證工作(例如，“現在用測試來檢查這個軟件中的條件。”)以及裁決(例如，通過、失敗，或者暫不決定)。這樣的信息在規格說明中隨處可以捕捉到，所以UML符號可以讓我們測試人員有了表達的手段。

　　于是，只需要額外做一點點努力，就可以使測試對客戶來說變得很容易理解：數據表和可視化流程。然后，當有軟件需要測試的時候，測試已準備就緒。這一實踐使測試驅動型開發在系統級測試上也具有實用的價值，因為在設計工件和測試設計工件之間確實沒有什么區別。僅僅只要增加驗證的注解以及進行裁決就可以了。在比較容易理解的可視化流程和數據的幫助下，你不再需要把系統設計從測試設計中分離出來。而且由于這些流程具有一個可執行的形式(生成的代碼)，因此可以把每一次創建作為測試來執行。這使整個團隊得到了解放，并成為Kent Beck和Erich Gamma所說的"受影響的測試(test infected)":

　　“...這是一種測試的類型，只要使用非常小的投入即可使你成為一個更快的、更多產的、更具預見性的、壓力更小的開發者。”

　　-Kent Beck和Erich Gamma《Test Infected: Programmers Love Writing Tests》[注6]

　　探索性學習

　　這第二種趨勢認識到了這樣的現實，即我們通常很難把問題描述得十分正確：需求在演變，我們需要簡化(扁平化)或者把著名的 “錯誤-代價”曲線顛倒過來。這里的核心思想是：我所說的每一項，不管是在產品、測試或者跟蹤排錯的第一步，都在運行軟件時通過探索性發現，才使得可視化 -可執行-設計-測試的整個過程和結果變得更為真實。

　　實時分析工具，例如Rational PurifyPlus就帶有制作精良的非常明確的實例，例如發現內存錯誤和性能上的瓶頸。你還可以用它們來支持更廣泛的探索，尤其是在由各種不同組件所構成的系統中。80%的企業級行為都是對某些組件的重新組裝，包括對遺留下來的成份進行更新或補充等等，而不是從頭開始設計。

原文轉自：http://www.uml.org.cn/Test/200412202.htm