全面單元測試是保證軟件開發過程質量的關鍵策略，但迄今為止并沒有為人們廣泛接受。本文考查了妨礙全面單元測試的"攔路石"，并介紹了來自 IBM Rational 軟件公司旨在克服這些攔路石的新技術。
去年春天，我的一位同事獲悉他的汽車由于某些部件的缺陷，正在被召回。事實證明，這對他來說僅僅是稍微不便。他把車開到經銷商那里，人家免費為他更換了有缺陷的部件，不到幾個小時，他就拿回了車。除了在經銷商那里浪費了幾個小時的工作時間之外，他并沒有受到什么損失。但從汽車制造商的角度講，問題要嚴重得多。這次召回涉及到的車主有 16500 人之多，給制造商造成的損失超過 1.14 億美元。這真是一筆不小的費用！
由此不難得出結論，只要制造商能在產品生產的早期發現部件的缺陷，就能節省一大筆費用。即便是在所有的汽車都已經裝配好但還沒有交付的時候發現缺陷，節省的費用也是很可觀的。另外還可以避免由于客戶的信任度受損和同行的惡意攻擊而造成的尷尬局面。我們不妨設想一下，如果制造商能在設計圖紙時就發現這一缺陷，那他們節省的費用又該有多少呢？
以設計求質量及全面單元測試
以設計求質量的產品生產方法包括一系列的策略、過程和實踐，借助于它們，在開發過程的早期就能夠滿足質量要求。這種方法既不是新生事物，也不是無的放矢。比如，這種方法曾被用于制造波音 777 飛機。這種飛機的超過 90％ 的測試都是根據計算機設計模型來完成的。在組裝第一架飛機之前，實際上只造了一個樣機，這樣一來，就節省了幾百萬美元。
Steve McConnell 在他 1997 年出版的《軟件項目生存指南》（Software Project Survival Guide）一書中驗證了以設計示質量方法：在編碼以前修復缺陷比在產品交付時或交付后要少花 50－200 倍的代價。這是個發人深省的數字且在業界引起了廣泛的注意。然而，并不是所有的人都遵循以設計求質量的方法，而且事實上多年以來我們一直沒有這樣做，這究竟是為什么呢？這些問題很復雜--以設計求質量是一個涉及范圍很廣的話題，根本不可能在短短一篇文章之中將它討論清楚。但我們可以通過探討軟件開發相關的以設計求質量的一個方面，即全面的組件測試，作為一個"敲門磚"來理解該方法，以及為什么采用該方法會有如此巨大的阻力。
為全面單元測試掃清障礙
盡管所有的軟件開發人員都承認全面單元測試會帶來極大利益，但實際上全面單元測試遠遠沒有得到普及，尤其是對于中間層組件測試和缺少圖形用戶界面的組件測試。為何會出現這種情況呢？因為這些工作既費時又乏味。在過去，克服這些障礙經常是得不償失。一個主要的問題在于，大多數測試是為特定組件而量身訂做的，重用更是機會渺茫。由于開發團隊的時間壓力很大，因此他們為了趕進度而不得不將精力集中在開發應用程序本身上。通常，開發人員認為，對于每個項目如果都從頭構建測試工具和存根，項目結束后再"扔掉"它們。這個過程是一種浪費。所以，他們寧愿將有限的資源都用在編寫組件代碼上面，而不是花在測試上面。
所幸的是，現在我們終于可以擺脫這項困擾。IBM Rational 剛剛引進了一種新技術，使我們能夠進行經濟高效的全面組件測試。IBM Rational 公司一直致力于為軟件開發人員提供各種工具，以幫助他們在更短的時間內交付高質量的軟件產品，Rational QualityArchitect 正是其中的一部分。Rational QualityArchitect 通過利用能夠自動生成測試代碼的可視模型，簡化了組件測試。開發人員可以集中精力來創建所需的測試用例，而不用花費時間來編寫容易出錯并且不可重用的測試代碼。
沒有 Rational QualityArchitect 的組件測試
為了更好的理解為何這一新產品會使全面組件測試更加容易實現，讓我們先來看一看沒有 Rational QualityArchitect 的組件測試將面臨哪些挑戰。
圖 1 所示為四個未經測試的組件。假設現在組件 B 已經可以測試了，而其他的組件（A、C 和 D）還沒有準備好測試，即使準備好了，它們之中可能包含一些缺陷，影響測試結果，并且使尋找組件B中的錯誤更加困難。由于這些原因，開發人員通常會編寫他們自己的測試驅動程序和存根，而事后就將它們"扔掉"。
圖 1：用于測試的四個組件
現在來考慮一下開發測試驅動程序的復雜度。一個模擬組件 A 行為的的測試驅動程序必須驅動組件 B、對其進行調用、提供一組輸入，以及記錄組件B的響應。同時，組件 B 所依賴的組件 C 和組件 D 的所有功能必須由存根來提供，并且根據組件B的不同輸入，它們必須返回正確的結果。這聽起來像一種復雜的"字母湯"烹飪法，難道不是嗎？
另外，即使是在完成對單個組件的測試之后，仍然要應對許多挑戰。在場景測試當中，為了測試一個給定序列的調用，必須將兩個或更多的組件進行同時測試。如果客戶端軟件還沒有完成，開發人員就必須花時間來創建一個模擬的客戶端以驅動特定的場景。根據一些軟件開發團隊的報告，他們為了創建這些測試工具所花費的時間占據總開發時間的一半以上，而這些測試工具幾乎不具有重用性。
文章來源于領測軟件測試網 http://www.kjueaiud.com/