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