軟件測試的革命(3)

　　在軟件運行時你會發現很多新的信息，至少和設計時一樣多。這也是RUP強調要把可運行的軟件作為每一次迭代的組成部份的緣故。你發現的每一樣東西都應該是可視的，并且放在你用于設計的同樣的工件中。對運行著的系統的跟蹤是一種UML的迭代，經過驗證和裁決，可以轉化為一種可復用的測試。數據也值得進行概括，并形成新的等價類的基礎，等等。

　　當前，大多數探索性測試的提倡者，尤其是Kaner和Bach，都把這作為使用后即可放棄的行為[注7]。但我認為，我們一旦把所探索到的內容無縫地加入到設計中去后，就會發現，這是高度可重用的。事實上，這是實時分析的一個新的應用：通過探索而發現的有價值的東西的捕獲和利用。

　　組件測試和易測試性設計

　　第三種趨勢是關于理解測試人員和開發人員的相對角色，并為每種角色分配合適的工具。Rational把提供組件測試和易測試性設計作為一種最佳實踐，這已有很長的歷史。我認為對這些做法的采納源自于對質量的基本理解。當前，太多的測試人員的行為都受限于規格說明的模式，其中有很多浪費。其實開發人員才有責任去保證所開發出來的軟件和規格要求相一致，他們應該使用合適的工具和過程來達到這樣的目的。

　　Boris Beizer描述了2種不同角色的區別：

　　獨立測試的目的是提供一種不同的觀察點，由此產生了不同的測試，并且在比開發人員所采用的開發環境更豐富的環境中執行測試。自我測試(self- testing)的目的是消除那些bug，這可以在相對更簡單、更明確的單元/組件環境，或者低層次的系統測試中進行，并且只需花費較低的代價。[注8]

　　測試驅動型開發提供更大的能力。如果規格說明就是可執行的測試，而測試進行沒有產生別的問題，那么就可以認為軟件和規格說明相符。其它的單元測試過程也只是為了保證同樣的事情：就規格說明而言，不管它們是什么內容，代碼總是與之相符合的。如果不符合，那么就是開發人員的問題。Kent Beck非常清楚測試驅動型開發所帶來的效果：

　　如果測試驅動編碼的缺陷密度達到足夠低的話，那么專業測試的角色將不可避免地發生改變。以前的是“成人監護”方式，而現在更類似于一種擴音器，它宣稱測試要更多地驗證的是系統必須做什么。[注9]

　　這需要整個團隊接受這樣的一個前提，即保證軟件符合規格說明是開發人員的職責。這使得測試者可以有更多精力用于發現和避免一些別的問題，從客戶或者用戶的角度來看，這些問題的存在可能會使軟件所應有的價值有所降低。Brian Marick針對這些冗長煩瑣做法的錯誤性寫過一篇很著名的文章[注10]。那些文檔通常已說明了一個系統中的多于一半的錯誤，他聲稱，因此你就需要專門有一個過程來讓你的測試人員用來發現這些問題。

　　易測試性的設計在這里具有重要的意義?，F在很多軟件已改用基于服務的構架，這種構架是基于組件的構架的一種擴展，隨之而來的是新增加的復雜性，即組件可以在沒有警告的情況下發生改變，其可靠性的問題是極為嚴重的。大多數IT經理會接受99%的可靠性，我敢打賭，他們會認為這一標準甚至已經高于他們所用的買來或構建的組件。但是，如果你構建的系統有超過100個組件，每個組件具有99%的可靠性，那么整個系統的可靠性是0.99的100次方，實際上僅有 37%。順便提一下，這也是為什么那些有高可靠性要求的市場，例如電信業，會要求“5個9”的可靠性，即99.999%。在這樣的情況下，你就可以使用 100個組件，綜合起來仍有99.9%的可靠性。

　　這一基本原理實際上要求軟件進行易測試性的設計，就象30年前市場形成時硬件所做的一樣。 Bertrand Meyer是這一領域研究的領先者，他提出了按合約設計，其意思是把對類及調用該類的客戶端之間的關系的檢視作為一種正式的協議，這表達了每個團體的權利和義務[注11]。Meyer的概念已被廣泛接受，其標志之一就是合約設計的規格語言WSDL的誕生，該語言是Web Service標準的核心[注12]。

　　我認為人們正越來越多地接受易測試性設計。易測試性已成為諸如Web Service等框架和標準的一個補充的組成部份。接口也正成為技術平臺和操作系統的一部份。一個比較簡單的例子是，J2EE和.NET 中預定義開放式接口和API映射，可以允許工具來檢查在運行時刻環境中發生了什么。另一個真實而有益的趨勢是人們正使用象Rational XDETM這樣的工具，通過設計模式的方法來構建應用--而易測試性已被置入在設計模式中。模式所構造的組件包括外在的用于測試的接口 -- 即組件的一些適當的getter和setter方法。

原文轉自：http://www.uml.org.cn/Test/200412202.htm