只要一提到關于軟件質量的問題，會有人問到這個問題。有些學生想知道進行多少測試才行。對于那些認為測試只是在浪費時間或吹毛求疵的學生，我會給他們一個機會讓他們以測試工作量小（有時甚至是沒有）的策略來完成他們的軟件工程的課程項目 。

　　我的學生經常向我說起他們的模塊和類編寫得多么巧妙，他們是如何認真地遵守了建模原則。有許多學生還使用了UML（Unified Modeling Language，統一建模語言）圖來幫助自己進行開發。這些做法都很好，但測試絕不僅僅是保證你的源代碼與你的模型相匹配那么簡單。有不少對自己的編程技巧很自信的學生交上來的作業經常存在著一些功能方面的小毛病。雖然那些小毛病一般不至于引發致命錯誤或崩潰（這在開發工作中經常會遇到），但在集成和軟件的運行方面經常出問題。也是說，這些學生沒能做到讓他們的軟件按照顧客希望的那樣工作。

　　如果你對這種場景很熟悉，說明你已經了解了軟件測試的價值。軟件測試的形式有很多，目的都是保證和控制軟件的質量。在什么時候選擇什么技術進行測試是軟件測試學需要解決的根本問題。

　　提示 如果你還沒有過從測試入手進行軟件開發或是與一位專業軟件測試人員合作的經歷，我建議你趕快去找一位這方面的專業人士。他們對軟件的故障往往有著超常的洞察力，很少有開發人員能做到像他們一樣。不要因為他們指出了你代碼中的缺陷而感到羞愧--那是他們的工作，而且他們都精于此道！

　　1、測試與調試

　　有不少人把“測試”和“調試”混為一談。雖然它們的目標是同一個--找出缺陷，但它們并不是一回事。調試是一種交互式的過程，是通過分析源代碼的內部工作情況去尋找源代碼邏輯中的缺陷。測試是通過執行源代碼去發現其中隱藏著的缺陷，不需要分析源代碼的內部工作情況。

　　2、測試驅動開發

　　測試驅動開發（test-driven development）通常與敏捷編程技術相關。事實上，測試驅動開發在采用極限編程（extreme programming，XP）方法的軟件公司里為常見。這聽起來有點兒唬人，我可以向你透露一個關于XP的秘密：你不必采用XP方法也可以進行敏捷編程。

　　因為反對者不負責任的言辭，有不少人對敏捷編程技術持很深的懷疑態度。傳統的軟件工程方法學在理論和實踐方面的成功是有目共睹的，人們把它奉為“金科玉律”也情有可原，但僅憑一知半解把敏捷開發技術與偷工減料和質量低劣等同起來是毫無道理的，因為事實完全不是這樣。

　　敏捷開發技術的核心概念是大限度地減少軟件開發過程中的不必要環節，重視與顧客的交流，只在需要的時候才編寫需要的功能，把工作的重點放在滿足客戶此時此刻的需求上。敏捷開發技術圍繞著顧客展開，具體過程并不是它關心的焦點。敏捷開發技術可以全面推廣，也可以有選擇地在小范圍應用。換句話說，在轉向敏捷開發技術的時候，軟件公司應該根據自己的具體情況摸著石頭過河，而不是一下扎進自己不熟悉的技術中，那會讓它們的開發人員感到難以適應。欲速則不達，有不少軟件公司是因為在接納敏捷開發技術方面太過急于求成才會陷入困境。正是因為這類負面案例時有發生，才會有人反對或懷疑敏捷開發技術 。如果想了解關于敏捷開發技術與傳統方法孰優孰劣之爭的更多情況，請訪問Agile Alliance網站www.agilealliance.org。

　　在各種敏捷開發技術當中，有用的要屬測試驅動開發技術了。測試驅動開發技術的基本思路很簡單：從整個解決方案的一個基本模塊開始，編寫測試，運行測試，編寫解決方案，用測試來驗證它確實能夠解決問題。這個過程聽起來不難理解，但在實踐中往往會變得相當復雜。在編寫代碼之前先編寫測試讓人有一種本末倒置的感覺--如果某個東西不存在，我們該如何去測試它呢？這么做真的有用嗎？先行開發有關測試可以讓你把精力集中到你的軟件設計方案而不是代碼上。我將解釋一個典型的測試驅動開發過程，讓大家看看測試驅動開發技術是如何緊扣設計方案并“驅動”程序員編寫出源代碼的。我知道這聽起來有點兒奇怪，但我希望大家能給我個機會來證明它是有道理的。

　　測試驅動開發活動從整個系統的一個簡單模塊開始。用一個簡單的類圖把系統里的各個基本類以及它們之間的關系畫出來。在這個類圖中，除了一個暫定的類名外，各個類的代碼塊部分可以是空白。我說“暫定”是因為這通常是采用傳統方法的程序員感到困惑的地方。在敏捷開發技術里，沒有什么是固定不變的，什么東西都允許修改。簡單地說，只要能把顧客需要的軟件交付給顧客，做什么都行。

　　設計好初的類關系框圖之后，把它復制下來放在旁邊，它是所謂的“域模型”（domain model）；它確定了整個系統中類的初始布局。接下來創建用例圖（use case diagram）和輔助用例場景（用例及各種執行順序的文本描述）。然后每個都用一個順序圖來擴充，這制定出了所引用的類需要的函數。

　　等每一個類都大致成形之后，可以開始編寫測試了。是的，雖然那些類還都不存在，你仍然可以為它們編寫測試。這些測試包括對域模型中的每一個類進行集成測試、系統測試和接口測試（它們都屬于黑盒測試）。

　　注解 黑盒測試是在不了解系統內部構造的情況下進行的測試。白盒測試是在了解系統內部結構的情況下對其行為進行的測試。

　　絕大多數以敏捷開發技術開發的項目而言，從這個過程的第一遍循環里學到的東西是在這個時候融合到設計方案的相關部分（用例圖、順序圖，等等）中并根據具體情況做出調整的。

　　注解 有些敏捷程序員還會使用健壯性圖（robustness diagram）給這個過程增加一個建模步驟。這種做法與ICONIX過程很相似。關于ICONIX過程的更多信息請參考Agile Development with ICONIX Procress 一書。

　　這些修改包括：新類的發現、對現有類的重新組織以及定義某個類的方法和屬性等。換句話說，在編寫代碼之前編寫測試可以幫助你驗證你的設計方案。這真的很酷：等你完成了你的設計并開始編寫源代碼的時候，你已經完成了測試！只需運行測試來證明你的代碼的工作情況符合設計要求行了。當然，如果需要改變測試或改變設計方案，你隨時都可以這樣做；這正是敏捷開發技術的魅力所在。