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