軟件測試的革命

MILY: 宋體; mso-ascii-font-family: Arial; mso-hansi-font-family: ˎ̥; mso-bidi-font-family: 宋體; mso-font-kerning: 0pt">愛因斯坦在1915年發表了廣義相對論，當時這還只是一項偉大的科學猜想。4年后，Arthur Eddington和一個英國科學家組成的小組完成了一項重要的實驗，在實驗中他們拍攝了在日蝕過程中Hyades星云的圖片，該實驗表明，因受日蝕影響，圖片中產生了很大的誤差幅度，由此證明了愛因斯坦關于空間的彎曲和光的重力效應的預測。大眾媒體隨即給予愛因斯坦和Eddington很高的榮譽。同時也因為他們兩人都是和平主義者，所以被一起推崇為在這個飽受戰爭滄桑的世界上的英雄。
　   雖然媒體顯得急不可待，但值得注意的是，廣義相對論在當時的科學界仍受到廣泛的爭議。直到半個世紀以后，人們才終于迎來了具有決定性的實驗結果。當時Thomas Kuhn寫下了《科學革命的結構（The Structure of Scientific Revolutions）》一書，相對論被作為是革命性變革的完美例子--一種新的觀念完全替代了一整套舊的信仰。
　   今年7月，我代表Rational Edge采訪了Cem Kaner。當時他借用了Kuhn的結構對目前軟件測試領域盛行的各種爭議和尚未確證的理論進行了分類。

　   后來，Rational Edge發表了我和軟件測試方面的其他專家的一些訪談。有些讀者卻質疑我的選擇，他們會問：“這和我現在做的主要工作有什么關系？”
　   因此，在本文中，我想把所有這些課題放在一起，并對自己關于未來測試領域的發展的前瞻進行闡述。我可以斷言的是，測試人員、開發人員、項目管理人員、公司管理人員和最終用戶們都期待著看到在這10年里軟件測試實踐方面將要發生的大變革。其原因很簡單，--軟件質量的低下已經使美國經濟蒙受巨大損失，NIST估計[注1]，每年損失約600億美元，而Standish組織的數據則是2000億美元。所以改進軟件質量已成為取得高投資回報率（ROI）的直接途徑，只有那些把握了軟件質量的企業才會贏得勝利，其余的則將被人們所遺忘。
　   這些實踐和工具又是什么呢？我認為隨著時間的發展，以下五種趨勢會得到發展和應用。
　   1.測試驅動型的軟件開發。在軟件生命周期的各個階段中，這些階段包括測試、需求分析、使用形象化符號進行的規格說明，以及基于UML和其它新標準的實踐；
　   2.探索性學習和發現，這將成為迭代開發過程的一個組成部分；
　   3.組件測試和易測試性設計，這將成為軟件開發不可分割的組成部分；
　   4.更加重視適當的技能的應用，減少預先寫好的文檔，這將成為優秀軟件過程的基本原則之一；
　   5.使用自動化測試來取代目前嚴重影響測試效率的冗余繁復的人工過程。
　   下面讓我來對這些趨勢進行說明。

　   測試驅動型開發

　   這一實踐在RUP過程中又稱為“測試第一的設計（test-first design）”，而在很多XP( eXtreme Programming)文章中則稱之為“測試第一的開發（test-first programming）”。這一設想的提出至今已有近十年了，但是直到最近才得以在開發這一層次上取得很大的支持，這要在很大程度上感謝敏捷方法組織。他們的核心思想是，在你寫一行代碼之前，你要先寫一行對其失效所進行的測試。在該測試的描述中應包含一個程序代碼實際運行的實例。Martin Fowler將這樣的測試稱為“帶實例的規格說明（specification by example）”。
　   Brain Marick和其他一些敏捷測試的支持者已經提出建議，要把測試驅動開發的概念擴展到所有的層次，包括系統測試和產品級測試[注2]。Marick很清晰地表述了他的觀點：“我并不想寫出一套用于捕捉用戶愿望的需求，取而代之的是，我要寫出一套測試，一旦這些測試能夠通過，產品就能使她滿意。所以我放棄需求編寫的步驟，而直接把需求分析加入到測試的創建過程中去。”[注3]這些測試腳本就象是可執行的規格說明，當程序代碼通過了測試，那么這些程序代碼也將和規格說明保持一致。
　   如果你的代碼是使用Java，而且你的測試也在Java中測試，那么測試很可能會基于JUnit，你可能要么是一個人，要么是編寫的兩人組中的一個，不管是哪一種情況，都很容易看到，這時Marick的方法是可行的。Marick相信這是可伸縮的，可以適合于小團體，或者在有一個用戶在場的條件下進行“交談式測試的創建（conversational test creation）”的實踐。但是，如果有人要了解需求，這些需求卻是在測試設計中被捕捉的，而你并不在場，無法直接為他們進行解釋，這樣就存在明顯的問題。在這種前提下，我并不認為測試一定要在程序語言中體現。即使對需求有了“精確”的表達，也不足以解決可理解性的問題。對于這一問題，Leffingwell和Widrig有很好的描述[注4]，下圖即是基于他們的觀點。