以設計求質量--啟用經濟高效的全面組件測試

引言
全面單元測試是保證軟件開發過程質量的關鍵策略，但迄今為止并沒有為人們廣泛接受。本文考查了妨礙全面單元測試的"攔路石"，并介紹了來自 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的不同輸入，它們必須返回正確的結果。這聽起來像一種復雜的"字母湯"烹飪法，難道不是嗎？

另外，即使是在完成對單個組件的測試之后，仍然要應對許多挑戰。在場景測試當中，為了測試一個給定序列的調用，必須將兩個或更多的組件進行同時測試。如果客戶端軟件還沒有完成，開發人員就必須花時間來創建一個模擬的客戶端以驅動特定的場景。根據一些軟件開發團隊的報告，他們為了創建這些測試工具所花費的時間占據總開發時間的一半以上，而這些測試工具幾乎不具有重用性。

具有 Rational QualityArchitect 的組件測試
Rational QualityArchitect 為我們提供了開啟經濟高效的全面單元測試之門的鑰匙：它充分利用了軟件開發人員在開發過程的早期創建工件（即可視模型），來生成測試工具。開發人員可以用IBM Rational Rose產生可視化的模型，一旦開發人員知道各個組件所必須執行的行為，他們就可以在一個模型之中將該行為記錄下來。由于這些模型是用來為組件自動生成代碼的，所以在這個意義上，開發人員能夠使用 IBM Rational Rose 來生成的可視模型顯得功能特別強大。這也正是 Rational QualityArchitect 作為Rational Rose Enterprise 包中的一個組件的原因。

對于單元測試來說，開發人員必須完成以下三個目標：

• 測試單個的軟件組件的單個方法。
• 依次測試多個組件中的多個方法。
• 為不完整或未完成的組件生成存根，以使一個組件的測試不依賴于其他組件的存在。

這三種測試中的每一種又由兩部分組成：

• 驅動測試過程的測試工具或框架代碼
• 測試用例數據

這就是需要做的全部工作。是不是很簡單？為了闡述更具體一點，讓我們來看一個例子。假設我要測試一個 Enterprise JavaBean（EJB）組件。我需要做兩項工作：

• 首先，創建所有要連接到服務器（EJB 就駐留在其中）的測試代碼（A），然后實例化 bean，調用 bean 的操作并驗證返回的結果。
• 接下來，創建用來調用單個操作的測試數據（B）。

雖然創建測試數據很具挑戰性，但實際上創建測試代碼更加費時，且很枯燥。

記住，可視模型中已經包含了創建測試代碼所需的全部信息?？梢暷Ｐ桶私M件及其操作的結構描述，還有操作的參數及返回的值類型。在設計階段或在基于現有組件的逆向工程階段，可視模型是由分析師創建還是由開發人員創建并不重要。創建測試框架代碼所需的全部輸入已經"各就各位"。

這時該輪到 Rational QualityArchitect 接管我的工作了。通過分析可視模型中給出的組件結構，Rational QualityArchitect 可以生成測試單個組件或涉及到多個組件的一系列操作所需的全部代碼。QualityArchitect 甚至可以在真正的組件被部署之前生成存根組件作為占位符來運行。

測試代碼只是解決方案的一半。我還需要測試數據。這里，QualityArchitect 使開發人員的工作容易得多。由于不必再為創建測試代碼的繁瑣過程所困擾，我可以將注意力集中在創建我們感興趣的和有意義的測試數據上。QualityArchitect 甚至可以在不需要特殊的測試用例時，幫助生成隨機的測試數據。當需要特定的測試數據時，QualityArchitect 可以提供一個簡單的像電子數據表一樣的界面來輸入數據。

節省成本，節省時間，沒有返工
在沒有 Rational QualityArchitect 時，全面單元測試過程中的早期測試是那樣的費時和低效，以致于很多公司都放棄了這項工作，盡管它的價值是顯而易見的。有了 Rational QualityArchitect，使我們能夠進行早期測試，因為 QualityArchitect 自動生成了測試工具和存根--且隨著模型在開發過程當中的不斷演進，測試工具和存根的生成也不是一次性的而是增量式的。對一個從事單元測試工作的開發人員來說，Rational QualityArchitect 實際上消除了創建一次性的測試代碼的耗時耗力工作，現在所要做的只是向一個電子數據表中輸入數據這樣簡單的工作。

更重要的是，在開發過程的最早幾個階段，所有這些測試都是在可視化模型以外完成的。通過利用用于測試操作的現有資產，Rational QualityArchitect 使得軟件開發團隊能夠采用以設計求質量的方法，而又不占用過多的軟件基礎開發時間。

盡管在軟件業中召回事件不常發生，但存在缺陷的軟件系統與存在缺陷的汽車一樣具有破壞性，其所造成的后果可能比后者更加嚴重。在軟件項目中采用以設計求質量的方法，這一目標值得我們為之奮斗。早期的測試可能為一個汽車制造商節省 1.14 億美元，它也會為軟件系統開發公司帶來類似的成本節省。波音公司已經證實可以利用計算機設計來安全地測試整個飛機。Rational QualityArchitect 確保您能夠在復雜的軟件系統中實現同樣的目標。

原文轉自：http://www.anti-gravitydesign.com