測試的革命
作者：Sam Guckenheimer
翻譯：Blueski
日期：2003-1-20
愛因斯坦在1915年發(fā)表了廣義相對論，當(dāng)時(shí)這還只是一項(xiàng)偉大的科學(xué)猜想。4年后，Arthur Eddington和一個(gè)英國科學(xué)家組成的小組完成了一項(xiàng)重要的實(shí)驗(yàn)，在實(shí)驗(yàn)中他們拍攝了在日蝕過程中Hyades星云的圖片， 該實(shí)驗(yàn)表明，因受日蝕影響，圖片中產(chǎn)生了很大的誤差幅度，由此證明了愛因斯坦關(guān)于空間的彎曲和光的重力效應(yīng)的預(yù)測。大眾媒體隨即 給予愛因斯坦和Eddington很高的榮譽(yù)。同時(shí)也因?yàn)樗麄儍扇硕际呛推街髁x者，所以被一起推崇為在這個(gè)飽受戰(zhàn)爭滄桑的世界上 的英雄。
雖然媒體顯得急不可待，但值得注意的是，廣義相對論在當(dāng)時(shí)的科學(xué)界仍受到廣泛的爭議。直到半個(gè)世紀(jì)以后，人們才終于迎來了具 有決定性的實(shí)驗(yàn)結(jié)果。當(dāng)時(shí)Thomas Kuhn寫下了《科學(xué)革命的結(jié)構(gòu)（The Structure of Scientific Revolutions）》一書，相對論被作為是革命性變革的完美例子– 一種新的觀念完全替代了一整套舊的信仰。
今年7月，我代表Rational Edge采訪了Cem Kaner。當(dāng)時(shí)他借用了Kuhn的結(jié)構(gòu)對目前軟件測試領(lǐng)域盛行的各種爭議和尚未確證的理論進(jìn)行了分類。
后來，Rational Edge發(fā)表了我和軟件測試方面的其他專家的一些訪談。有些讀者卻質(zhì)疑我的選擇，他們會問：“這和我現(xiàn)在做的主要工作有什么關(guān)系 ？”
因此，在本文中，我想把所有這些課題放在一起，并對自己關(guān)于未來測試領(lǐng)域的發(fā)展的前瞻進(jìn)行闡述。我可以斷言的是，測試人員、開發(fā) 人員、項(xiàng)目管理人員、公司管理人員和最終用戶們都期待著看到在這10年里軟件測試實(shí)踐方面將要發(fā)生的大變革。其原因很簡單，– 軟件質(zhì)量的低下已經(jīng)使美國經(jīng)濟(jì)蒙受巨大損失，NIST估計(jì)[注1] ，每年損失約600億美元，而Standish組織的數(shù)據(jù)則是2000億美元。所以改進(jìn)軟件質(zhì)量已成為取得高投資回報(bào)率（ROI ）的直接途徑，只有那些把握了軟件質(zhì)量的企業(yè)才會贏得勝利，其余的則將被人們所遺忘。
這些實(shí)踐和工具又是什么呢？我認(rèn)為隨著時(shí)間的發(fā)展，以下五種趨勢會得到發(fā)展和應(yīng)用。
1. 測試驅(qū)動型的軟件開發(fā)。在軟件生命周期的各個(gè)階段中，這些階段包括測試、需求分析、使用形像化符號進(jìn)行的規(guī)格說明，以及基于UM L和其它新標(biāo)準(zhǔn)的實(shí)踐；
2. 探索性學(xué)習(xí)和發(fā)現(xiàn)，這將成為迭代開發(fā)過程的一個(gè)組成部份；
3. 組件測試和易測試性設(shè)計(jì)，這將成為軟件開發(fā)不可分割的組成部份；
4. 更加重視適當(dāng)?shù)募寄艿膽?yīng)用，減少預(yù)先寫好的文檔，這將成為優(yōu)秀軟件過程的基本原則之一；
5. 使用自動化測試來取代目前嚴(yán)重影響測試效率的冗余繁復(fù)的人工過程。
下面讓我來對這些趨勢進(jìn)行說明。
測試驅(qū)動型開發(fā)
這一實(shí)踐在RUP過程中又稱為“測試第一的設(shè)計(jì)（test-first design）”，而在很多XP( eXtreme Programming)文章中則稱之為“測試第一的開發(fā)（test-first programming）”。這一設(shè)想的提出至今已有近十年了，但是直到最近才得以在開發(fā)這一層次上取得很大的支持，這要在很大 程度上感謝敏捷方法組織。他們的核心思想是，在你寫一行代碼之前，你要先寫一行對其失效所進(jìn)行的測試。在該測試的描述中應(yīng)包含一 個(gè)程序代碼實(shí)際運(yùn)行的實(shí)例。Martin Fowler將這樣的測試稱為“帶實(shí)例的規(guī)格說明（specification by example）”。
Brain Marick和其他一些敏捷測試的支持者已經(jīng)提出建議，要把測試驅(qū)動開發(fā)的概念擴(kuò)展到所有的層次，包括系統(tǒng)測試和產(chǎn)品級測試[注2] 。Marick很清晰地表述了他的觀點(diǎn)：“我并不想寫出一套用于捕捉用戶愿望的需求，取而代之的是，我要寫出一套測試，一旦這些 測試能夠通過，產(chǎn)品就能使她滿意。所以我放棄需求編寫的步驟，而直接把需求分析加入到測試的創(chuàng)建過程中去。” [注3]這些測試腳本就象是可執(zhí)行的規(guī)格說明，當(dāng)程序代碼通過了測試，那么這些程序代碼也將和規(guī)格說明保持一致。
如果你的代碼是使用Java，而且你的測試也在Java中測試，那么測試很可能會基于JUnit，你可能要么是 一個(gè)人，要么是編寫的兩人組中的一個(gè)，不管是哪一種情況，都很容易看到，這時(shí)Marick的方法是可行的。Marick相信這是 可伸縮的，可以適合于小團(tuán)體，或者在有一個(gè)用戶在場的條件下進(jìn)行“交談式測試的創(chuàng)建（conversational test creation）”的實(shí)踐。但是，如果有人要了解需求，這些需求卻是在測試設(shè)計(jì)中被捕捉的，而你并不在場，無法直接為他們進(jìn)行 解釋，這樣就存在明顯的問題。在這種前提下，我并不認(rèn)為測試一定要在程序語言中體現(xiàn)。即使對需求有了“精確”的表達(dá)，也不足以解 決可理解性的問題。對于這一問題，Leffingwell和Widrig有很好的描述 [注4]，下圖即是基于他們的觀點(diǎn)。
圖1：可理解性問題（基于Leffingwell和Widrig的觀點(diǎn)）
實(shí)際上，Leffingwell和Widrig并沒有真正地考慮到測試的問題。他們的主要目的是想讓需求具備很高的可理解性 ，以便于讓用戶和投資者能夠充份理解。他們沒有解決這樣的問題，即如何把規(guī)格說明提交給其他投資者和生命周期的其它階段。作為一 種爭議，他們認(rèn)為有必要保留一部份不明確性。而實(shí)際上，不明確的需求顯然會讓測試人員發(fā)瘋。
Marick提出的測試驅(qū)動型開發(fā)方法則走向另一個(gè)極端：測試代表了需求，測試的表現(xiàn)形式是一些可編譯、可執(zhí)行的代碼。但是，如 果測試（需求）的唯一表現(xiàn)形式是代碼的話，你就很難和商務(wù)人員/投資者/客戶進(jìn)行有效溝通，甚至也很難和其他測試人員及開發(fā)人員 進(jìn)行溝通。所有這些人都認(rèn)為測試的形式本該是數(shù)據(jù)和流程，所以如果要以那種方式來做的話，你的測試必須變得非常容易進(jìn)行交流。
一些公司正致力于為這種隔閡提供解決之道。Rational正積極參與一個(gè)OMG團(tuán)體關(guān)于UML測試預(yù)定義項(xiàng)目，該項(xiàng)目可以 把測試表示為數(shù)據(jù)和可視化的流程，例如順序圖和活動圖。我們正在開發(fā)一些工具來對待以下三種表示方法，代碼，數(shù)據(jù)和流程，并取代 類似的測試視圖。
在過去，我們制作了這些“實(shí)例化規(guī)格說明”，按照RUP的命名方法，可稱之為“用例實(shí)現(xiàn)”。“實(shí)例化規(guī)格說明”和“用例實(shí)現(xiàn) ”的相似性可以通過援引最近的一個(gè)使用Agile方法的工作團(tuán)體的報(bào)告來說明：
[一個(gè)參與者] 提到，和他一起工作的人都很喜歡使用“測試第一”的開發(fā)方式。當(dāng)測試框架被開發(fā)好以后，特別是當(dāng)用于組織運(yùn)行的測試腳本被定義好 時(shí)，他們的工作變得更為容易。而用例在組織起來開發(fā)腳本時(shí)會有所幫助。他們的測試可以捕捉到用戶的需要。人們之所以喜歡這樣的方 法，其原因是它提供了他們工作所需的結(jié)構(gòu)。在Agile方法中，需求以“案例(story)”的形式存在。于是，測試腳本將以接 口已明確定義好的形式把這些“案例”編織在一起。這意味著結(jié)對編程的人可以根據(jù)他們需要的順序相互測試接口 [注5]。
類似地，OMG測試預(yù)定義工作組發(fā)現(xiàn)，將UML排列起來也很容易。你可以將一個(gè)用例實(shí)現(xiàn)轉(zhuǎn)成為測試，這只需增加兩件東西：驗(yàn)證工 作（例如，“現(xiàn)在用測試來檢查這個(gè)軟件中的條件。”）以及裁決（例如，通過、失敗，或者暫不決定）。這樣的信息在規(guī)格說明中隨處 可以捕捉到，所以UML符號可以讓我們測試人員有了表達(dá)的手段。
于是，只需要額外做一點(diǎn)點(diǎn)努力，就可以使測試對客戶來說變得很容易理解：數(shù)據(jù)表和可視化流程。然后，當(dāng)有軟件需 要測試的時(shí)候，測試已準(zhǔn)備就緒。這一實(shí)踐使測試驅(qū)動型開發(fā)在系統(tǒng)級測試上也具有實(shí)用的價(jià)值，因?yàn)樵谠O(shè)計(jì)工件和測試設(shè)計(jì)工件之間確 實(shí)沒有什么區(qū)別。僅僅只要增加驗(yàn)證的注解以及進(jìn)行裁決就可以了。在比較容易理解的可視化流程和數(shù)據(jù)的幫助下，你不再需要把系統(tǒng)設(shè) 計(jì)從測試設(shè)計(jì)中分離出來。而且由于這些流程具有一個(gè)可執(zhí)行的形式（生成的代碼），因此可以把每一次創(chuàng)建作為測試來執(zhí)行。這使整個(gè) 團(tuán)隊(duì)得到了解放，并成為Kent Beck和Erich Gamma所說的”受影響的測試（test infected）”:
“…這是一種測試的類型，只要使用非常小的投入即可使你成為一個(gè)更快的、更多產(chǎn)的、更具預(yù)見性的、壓力更小的開發(fā)者。”
-Kent Beck和Erich Gamma《Test Infected: Programmers Love Writing Tests》[注6]
探索性學(xué)習(xí)
這第二種趨勢認(rèn)識到了這樣的現(xiàn)實(shí)，即我們通常很難把問題描述得十分正確：需求在演變，我們需要簡化（扁平化）或者把著名的“ 錯(cuò)誤-代價(jià)”曲線顛倒過來。這里的核心思想是：我所說的每一項(xiàng)，不管是在產(chǎn)品、測試或者跟蹤排錯(cuò)的第一步，都在運(yùn)行軟件時(shí)通過探 索性發(fā)現(xiàn)，才使得可視化-可執(zhí)行-設(shè)計(jì)-測試的整個(gè)過程和結(jié)果變得更為真實(shí)。
實(shí)時(shí)分析工具，例如Rational PurifyPlus就帶有制作精良的非常明確的實(shí)例，例如發(fā)現(xiàn)內(nèi)存錯(cuò)誤和性能上的瓶頸。你還可以用它們來支持更廣泛的探索，尤 其是在由各種不同組件所構(gòu)成的系統(tǒng)中。80%的企業(yè)級行為都是對某些組件的重新組裝，包括對遺留下來的成份進(jìn)行更新或補(bǔ)充等等， 而不是從頭開始設(shè)計(jì)。
在軟件運(yùn)行時(shí)你會發(fā)現(xiàn)很多新的信息，至少和設(shè)計(jì)時(shí)一樣多。這也是RUP強(qiáng)調(diào)要把可運(yùn)行的軟件作為每一次迭代的組成部份的緣故 。你發(fā)現(xiàn)的每一樣?xùn)|西都應(yīng)該是可視的，并且放在你用于設(shè)計(jì)的同樣的工件中。對運(yùn)行著的系統(tǒng)的跟蹤是一種UML的迭代，經(jīng)過驗(yàn)證和 裁決，可以轉(zhuǎn)化為一種可復(fù)用的測試。數(shù)據(jù)也值得進(jìn)行概括，并形成新的等價(jià)類的基礎(chǔ)，等等。
當(dāng)前，大多數(shù)探索性測試的提倡者，尤其是Kaner和Bach，都把這作為使用后即可放棄的行為[注7] 。但我認(rèn)為，我們一旦把所探索到的內(nèi)容無縫地加入到設(shè)計(jì)中去后，就會發(fā)現(xiàn)，這是高度可重用的。事實(shí)上，這是實(shí)時(shí)分析的一個(gè)新的應(yīng) 用：通過探索而發(fā)現(xiàn)的有價(jià)值的東西的捕獲和利用。
組件測試和易測試性設(shè)計(jì)
第三種趨勢是關(guān)于理解測試人員和開發(fā)人員的相對角色，并為每種角色分配合適的工具。Rational把提供組件測試和易測試 性設(shè)計(jì)作為一種最佳實(shí)踐，這已有很長的歷史。我認(rèn)為對這些做法的采納源自于對質(zhì)量的基本理解。當(dāng)前，太多的測試人員的行為都受限 于規(guī)格說明的模式，其中有很多浪費(fèi)。其實(shí)開發(fā)人員才有責(zé)任去保證所開發(fā)出來的軟件和規(guī)格要求相一致，他們應(yīng)該使用合適的工具和過 程來達(dá)到這樣的目的。
Boris Beizer描述了2種不同角色的區(qū)別：
獨(dú)立測試的目的是提供一種不同的觀察點(diǎn)，由此產(chǎn)生了不同的測試，并且在比開發(fā)人員所采用的開發(fā)環(huán)境更豐富的環(huán)境中執(zhí)行測試。 自我測試（self-testing）的目的是消除那些bug，這可以在相對更簡單、更明確的單元/組件環(huán)境，或者低層次的系統(tǒng) 測試中進(jìn)行，并且只需花費(fèi)較低的代價(jià)。[注8]
測試驅(qū)動型開發(fā)提供更大的能力。如果規(guī)格說明就是可執(zhí)行的測試，而測試進(jìn)行沒有產(chǎn)生別的問題，那么就可以認(rèn)為軟件和規(guī)格說明 相符。其它的單元測試過程也只是為了保證同樣的事情：就規(guī)格說明而言，不管它們是什么內(nèi)容，代碼總是與之相符合的。如果不符合， 那么就是開發(fā)人員的問題。Kent Beck非常清楚測試驅(qū)動型開發(fā)所帶來的效果：
如果測試驅(qū)動編碼的缺陷密度達(dá)到足夠低的話，那么專業(yè)測試的角色將不可避免地發(fā)生改變。以前的是“成人監(jiān)護(hù)”方式，而現(xiàn)在更類似 于一種擴(kuò)音器，它宣稱測試要更多地驗(yàn)證的是系統(tǒng)必須做什么。[注9]
這需要整個(gè)團(tuán)隊(duì)接受這樣的一個(gè)前提，即保證軟件符合規(guī)格說明是開發(fā)人員的職責(zé)。這使得測試者可以有更多精力用于發(fā)現(xiàn)和避免一 些別的問題，從客戶或者用戶的角度來看，這些問題的存在可能會使軟件所應(yīng)有的價(jià)值有所降低。Brian Marick針對這些冗長煩瑣做法的錯(cuò)誤性寫過一篇很著名的文章[注10]。那些文檔通常已說明了一個(gè)系統(tǒng)中的多于一半的錯(cuò)誤，他聲稱，因此你就需要專門有一個(gè)過程來讓你的測試人員用來發(fā)現(xiàn)這些問題。
易測試性的設(shè)計(jì)在這里具有重要的意義?，F(xiàn)在很多軟件已改用基于服務(wù)的構(gòu)架，這種構(gòu)架是基于組件的構(gòu)架的一種擴(kuò)展，隨之而來的 是新增加的復(fù)雜性，即組件可以在沒有警告的情況下發(fā)生改變，其可靠性的問題是極為嚴(yán)重的。大多數(shù)IT經(jīng)理會接受99%的可靠性， 我敢打賭，他們會認(rèn)為這一標(biāo)準(zhǔn)甚至已經(jīng)高于他們所用的買來或構(gòu)建的組件。但是，如果你構(gòu)建的系統(tǒng)有超過100個(gè)組件，每個(gè)組件具 有99%的可靠性，那么整個(gè)系統(tǒng)的可靠性是0.99的100次方，實(shí)際上僅有37%。順便提一下，這也是為什么那些有高可靠性要 求的市場，例如電信業(yè)，會要求“5個(gè)9”的可靠性，即99.999%。在這樣的情況下，你就可以使用100個(gè)組件，綜合起來仍有 99.9%的可靠性。
這一基本原理實(shí)際上要求軟件進(jìn)行易測試性的設(shè)計(jì)，就象30年前市場形成時(shí)硬件所做的一樣。 Bertrand Meyer是這一領(lǐng)域研究的領(lǐng)先者，他提出了按合約設(shè)計(jì)，其意思是把對類及調(diào)用該類的客戶端之間的關(guān)系的檢視作為一種正式的協(xié)議 ，這表達(dá)了每個(gè)團(tuán)體的權(quán)利和義務(wù)[注11]。Meyer的概念已被廣泛接受，其標(biāo)志之一就是合約設(shè)計(jì)的規(guī)格語言WSDL的誕生，該語言是Web Service標(biāo)準(zhǔn)的核心[注12]。
我認(rèn)為人們正越來越多地接受易測試性設(shè)計(jì)。易測試性已成為諸如Web Service等框架和標(biāo)準(zhǔn)的一個(gè)補(bǔ)充的組成部份。接口也正成為技術(shù)平臺和操作系統(tǒng)的一部份。一個(gè)比較簡單的例子是，J2EE和 .NET 中預(yù)定義開放式接口和API映射，可以允許工具來檢查在運(yùn)行時(shí)刻環(huán)境中發(fā)生了什么。另一個(gè)真實(shí)而有益的趨勢是人們正使用象Rat ional XDETM這樣的工具，通過設(shè)計(jì)模式的方法來構(gòu)建應(yīng)用–而易測試性已被置入在設(shè)計(jì)模式中。模式所構(gòu)造的組件包括外在的用于測試 的接口 — 即組件的一些適當(dāng)?shù)膅etter和setter方法。
易測試性設(shè)計(jì)的一個(gè)實(shí)用的法則是，你已在GUI和表示層的后面對業(yè)務(wù)邏輯或軟件的行為進(jìn)行了訪問。Bret Pettichord主張，易測試性設(shè)計(jì)應(yīng)該是關(guān)于可見性和控制的設(shè)計(jì)[注13] 。你通過較低層獲得其外在接口，從而得到所需要的可見性，在測試的時(shí)候，通過很多開放的接口來允許你直接看到軟件中的聲明。同樣 地，你需要接口來讓你能夠控制應(yīng)用，由此你才可以避免使用GUI，而是通過自動化框架來驅(qū)動應(yīng)用。
重視技能
第四種趨勢是增進(jìn)軟件測試專業(yè)技術(shù)知識的水準(zhǔn)。在.com流行的年代中有這樣的誤解，即使沒有很深的測試技術(shù)知識、業(yè)務(wù)應(yīng)用 方面的領(lǐng)域知識以及充份的培訓(xùn)，你也能有效地進(jìn)行測試。但當(dāng)你面對一個(gè)分布式的應(yīng)用–例如，一個(gè)特別的基于Web的應(yīng)用，就會 發(fā)生問題。Hung Nguyen關(guān)于基于Web應(yīng)用的測試論著是這種觀點(diǎn)最好的代表[注14] 。Nguyen認(rèn)為，測試人員應(yīng)該知道技術(shù)是如何對他們所看到的各種錯(cuò)誤產(chǎn)生影響的。他們需要對技術(shù)問題有所理解，例如配置的問 題，以及他們所檢查的技術(shù)本身內(nèi)含的問題。各種細(xì)節(jié)上的理解，例如了解應(yīng)用服務(wù)器中Bean和Container管理的持續(xù)性之 間的區(qū)別，可以直接影響到你發(fā)現(xiàn)特定缺陷的能力。
所以，現(xiàn)在的測試人員除了測試本身的技術(shù)以外，還需要理解開發(fā)技術(shù)和領(lǐng)域知識。例如，假設(shè)你在瀏覽器中看到一個(gè)錯(cuò) 誤：“404 - Page not found”這樣的錯(cuò)誤可能是錯(cuò)誤的鏈接所引起，也可能是因?yàn)槟承┓?wù)失效而產(chǎn)生。一個(gè)好的測試人員并不會在出錯(cuò)頁上就停下來， 他會進(jìn)一步診斷出錯(cuò)的原因。他不僅需要對該失效的服務(wù)具備足夠多的認(rèn)識和理解，而且他要通過查看其它使用該服務(wù)的頁面來驗(yàn)證自己 的猜測。這就是一種Bug隔離的重要技能。
另一種技能是成為一個(gè)很好的探索者。以前，測試方面的很多論述對計(jì)劃和腳本有很多要求，但現(xiàn)實(shí)情況下，一個(gè)好的測試人員就是 一個(gè)好的探索者。他們喜歡在測試過程中發(fā)現(xiàn)一些暗示，并知道怎么來進(jìn)行跟蹤。這樣的暗示有時(shí)很簡單，例如一個(gè)頁面要很長時(shí)間才能 加載。那么對于一個(gè)好的測試人員來說，他可能會想，這其中發(fā)生了什么？然后繼續(xù)了解要通過什么路徑可以進(jìn)一步發(fā)現(xiàn)答案。Jame s Bach所寫的一些內(nèi)容可能是在探索性測試方面最好的材料[注15]，其中有該課題的最佳練習(xí)。我認(rèn)為這顯然也是一個(gè)重要的技能，每個(gè)團(tuán)隊(duì)都需要這樣的技能。
我們在Rational學(xué)院的課程中已經(jīng)非常重視如何去應(yīng)用基本的軟件測試技術(shù)。可以和Florida Tech的Cem Kaner一起開始那些專為測試人員提供的軟件測試基本原理的新課程[注16] 。該課程并不專注于測試工具，而是專注于如何成為一名很好的軟件測試人員，尤其是當(dāng)你正在應(yīng)用迭代開發(fā)過程的時(shí)候。最后，測試人 員的生產(chǎn)能力和開發(fā)人員的生產(chǎn)能力是同樣重要的，只有富有經(jīng)驗(yàn)的測試人員才能使產(chǎn)品讓客戶獲得很高的投資回報(bào)率（ROI）。Ra tional已經(jīng)發(fā)現(xiàn)，一個(gè)更快、更經(jīng)濟(jì)、更高質(zhì)量的開發(fā)過程的關(guān)鍵就是迭代式開發(fā)過程。迭代式過程可以使測試在整個(gè)開發(fā)周期中 得以提前，從而可以更早地發(fā)現(xiàn)錯(cuò)誤，修改錯(cuò)誤也相對更加容易，其成本也相對更低。
但是，我認(rèn)為現(xiàn)在的測試人員還沒有得到很好的訓(xùn)練以勝任迭代開發(fā)過程中的測試工作要求，項(xiàng)目經(jīng)理也沒有得到很好的 訓(xùn)練以正確地認(rèn)識測試在迭代項(xiàng)目中所扮演的角色，開發(fā)人員也沒有得到很好的訓(xùn)練以得到他們需要了解的測試相關(guān)技術(shù)，例如基礎(chǔ)等價(jià) 類劃分。因此我們在RUP(Rational Unified Process)和Rational學(xué)院中增加了大量關(guān)于測試的材料。而且我們還將繼續(xù)擴(kuò)充這些材料以幫助測試人員、開發(fā)人員和 項(xiàng)目經(jīng)理們在迭代過程的協(xié)同工作中做得更好。
自動化測試
第五種趨勢是關(guān)于測試自動化方面。目前，為了實(shí)行測試自動化，測試人員和開發(fā)人員要花費(fèi)80%的精力來使（自動化 ）測試成為可能，而只有20%被用于使（自動化）測試變得更有意義。這一可怕的事實(shí)使很多人最終放棄了測試自動化。同樣，目前的 自動化軟件質(zhì)量(ASQ) 工具提供商正花費(fèi)80%的精力用于重復(fù)工作，他們必須重新創(chuàng)建一個(gè)基礎(chǔ)平臺來支持相應(yīng)的測試和排錯(cuò)工作，而僅有20%的精力來為 測試和開發(fā)人員提供可見的有價(jià)值的功能。
最近，Rational、IBM和其它一些公司開展了一個(gè)開發(fā)源碼的項(xiàng)目，其目標(biāo)就是要把這兩個(gè)百分?jǐn)?shù)顛倒過來。該項(xiàng)目被命名為 Hyades，取自Eddington用來校驗(yàn)愛因斯坦理論的星云的名字，并由Eclipse.org負(fù)責(zé)。它的目標(biāo)也包括加強(qiáng) 實(shí)驗(yàn)性觀察，測試過程及軟件度量，最終實(shí)現(xiàn)更具實(shí)用性的測試自動化。
對于使用Eclipse的開發(fā)人員和測試人員來說，Hyades既是一種集成測試及跟蹤，也是環(huán)境監(jiān)控程序。Eclipse 為整個(gè)測試過程提供了標(biāo)準(zhǔn)、工具和互操作性，以使測試能更早地移植到應(yīng)用生命周期中去。對ASQ提供商和集成商來說，Hyade s為自動化測試、跟蹤、預(yù)定義、監(jiān)控和資源管理提供了一個(gè)可擴(kuò)展的架構(gòu)和平臺。和目前的測試與跟蹤工具所不同的是，Hyades 將提供一個(gè)統(tǒng)一數(shù)據(jù)模型（實(shí)現(xiàn)了UML測試預(yù)定義），這是一種標(biāo)準(zhǔn)的用戶工作的流程，包括一套統(tǒng)一的API及相關(guān)工具，可以在排 列的目標(biāo)項(xiàng)之間連續(xù)地工作。
總結(jié)：測試實(shí)踐的大變革
Rational和一些競爭對手盡管自己也提供商業(yè)測試工具，為什么還要加入到象Hyades這樣的開放源碼項(xiàng)目 中去呢？ 我的很多同事也問過這樣的問題。其核心理由就是上面所說的80/20比例。所有人都很想改變這個(gè)比例。
80%的基礎(chǔ)平臺對用戶來說是不可見的，它難以分辨，也難以維護(hù)。每當(dāng)測試所用軟件的環(huán)境條件更新的時(shí)候，(新的編譯器，新的庫 文件，新的操作系統(tǒng)補(bǔ)丁，等等），測試工具就必須隨之更新。如果你是一位富有經(jīng)驗(yàn)的實(shí)時(shí)分析或自動化工具的用戶，你可能早已感受 到這種脆弱。你也許已經(jīng)不止一次在考慮要更換開發(fā)環(huán)境，因?yàn)橛行┕ぞ卟恢С忠恍┬碌陌姹?。這一維護(hù)成本給工具提供商帶來了巨大的 壓力，因此工具商們決定無償?shù)貫樾碌囊婀ぷ鳎⒎窒砥涑晒?，進(jìn)而滿足用戶的需要。Hyades項(xiàng)目必將為我們的用戶提供其價(jià)值 。
對Hyades來說，它是由一系列分散的努力所組成。在我所歸納的五種趨勢中，Hyades是其中的一個(gè)組成部份，它將同時(shí) 為測試人員和開發(fā)人員提供新的測試支持方式。這是一種技術(shù)，它可以在生命周期的一開始就推動測試，帶來工具方面更好的協(xié)同性，通 過改進(jìn)測試，新的效果會明顯地加入到軟件中去。它將為這10年里我能所能看到的在測試實(shí)踐上的改革提供有力的支持。我相信這種技 術(shù)，以及其它有類似目標(biāo)和基礎(chǔ)的技術(shù)，代表著我們產(chǎn)業(yè)的未來。我們這些已被卷入到Hyades項(xiàng)目中的人都有一種使命感，我們不 能辜負(fù)Hyades這一名稱：
讓我們描畫出金牛座的頭部–Hyades星云中的恒星，這對我們來說意義重大，這將帶給我們快樂，并使我們能夠 測量整個(gè)宇宙
