軟件測試的革命

　   實際上，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]

文章來源于領測軟件測試網 http://www.kjueaiud.com/