軟件測試的科學(xué)和藝術(shù).doc

軟件測試的科學(xué)和藝術(shù)收藏此頁 打印作者：（來自ITPUB）2007-08-23 內(nèi)容導(dǎo)航：微軟的測試人員 第1頁： 微軟的測試人員 第2頁： 測試時應(yīng)考慮的幾個問題 第3頁： 關(guān)于Bug 第4頁： 軟件測試方法和輔助工具 一、微軟的測試人員 微軟的軟件測試人員分為兩類:測試工具軟件開發(fā)工程師（Software Development Engineer in Test, 簡稱SDE/T) 和軟件測試工程師(Software Test Engineer，簡稱STE)。 測試工具軟件開發(fā)工程師:負(fù)責(zé)寫測試工具代碼，并利用測試工具對軟件進(jìn)行測試；或者開發(fā)測試工具為軟件測試工程師服務(wù)。產(chǎn)品開發(fā)后的性能測試(Performance Test) 、提交測試(Check-in Test) 等過程，都有可能要用到SDE/T 開發(fā)的測試工具。由于SDE/T和SDE 的工作都是寫代碼，具有相通的地方，所以兩者之間互相轉(zhuǎn)換的情況比較多。但需注意的是，兩者寫出來的代碼用途是不一樣的，SDE 寫的是產(chǎn)品的代碼，而SDE/T 寫的代碼只用于測試產(chǎn)品。 軟件測試工程師:負(fù)責(zé)理解產(chǎn)品的功能要求，然后對其進(jìn)行測試，檢查軟件有沒有錯誤(Bug)，決定軟件是否具有穩(wěn)定性(Robustness) ，并寫出相應(yīng)的測試規(guī)范和測試用例。除此之外，在一個軟件產(chǎn)品的研發(fā)和銷售過程中，還會需要負(fù)責(zé)給產(chǎn)品打補(bǔ)丁(Service Pack)的快速修正工程師（Quick Fix Engineer) ，通常曲SDE 來擔(dān)任，通過電話方式向用戶提供售后技術(shù)支持的支持工程師(Support Engineer)，銷售和市場(Sales and Marketing)人員，研究員和研究工程師(Researchers & Research SDE) 。在進(jìn)行產(chǎn)品開發(fā)的時候，主要是由前面三類人員(項(xiàng)目經(jīng)理、開發(fā)人員及測試人員)組成產(chǎn)品開發(fā)團(tuán)隊來進(jìn)行的。在微軟內(nèi)部，軟件測試人員與軟件開發(fā)人員的比率一般為1.5-2.5 左右，這可能遠(yuǎn)遠(yuǎn)超出了大家對測試人員的理解，但微軟軟件開發(fā)的實(shí)踐過程已經(jīng)證明了這種人員結(jié)構(gòu)的合理性。下圖中顯示了上述兩個產(chǎn)品的微軟軟件開發(fā)人員的一般配置圖。 下面以微軟Exchange2O0O 和Windows2000 為例介紹一下微軟產(chǎn)品團(tuán)隊的人員結(jié)構(gòu)(這里只分析三類主要的人員，即項(xiàng)日經(jīng)理、開發(fā)人員及測試人員)，如下表所示。二、測試時應(yīng)考慮的幾個問題 （1）測試最重要的一件事就是要考慮到所有的出錯可能性。同時，還要做一些不是按常規(guī)做的、非常奇怪的事。 說起來可能不太好聽，測試的過程就像黑客(Hacker) 的攻擊過程那樣。可以這么說，像黑客這樣的人是最好的軟件安全測試員。他們專門找軟件的漏洞，從而破壞這個軟件，這樣就可以修復(fù)這些漏洞來保證軟件的性能。如果找不到這種漏洞，那就說明該軟件質(zhì)量己經(jīng)很好了。 (2) 除了漏洞之外，測試還應(yīng)該考慮性能(Performance) 問題，也就是一定要保證軟件運(yùn)行得很好，非常快，沒有內(nèi)存泄漏，不會出現(xiàn)那種越來越慢的情況。 我們可以在不關(guān)機(jī)的情況下，與其他軟件一起持續(xù)運(yùn)行一個多月，看看是否會出現(xiàn)越來越慢的情況(當(dāng)然必須保證其他軟件是沒有問題的)。我們在做IE 的時候，就是讓它72 小時連續(xù)不停地打開不同的網(wǎng)頁，處理幾萬個不同的網(wǎng)頁，而且速度不能減慢。有許多軟件，當(dāng)只有一兩個人用的時候，可能感覺不到什么問題，而當(dāng)幾百個用戶一起用的時候，有的網(wǎng)站就出現(xiàn)各種各樣的異常，這就是測試工作還比較欠缺的緣故。 (3) 另外，測試還要考慮軟件的兼容性(Compatibility) 。一般來說，一個軟件是由許多小軟件構(gòu)成的，如果其中一個小軟件與它的前一版本不兼容，那么這個軟件就會出現(xiàn)錯誤。這種錯誤需要通過測試來發(fā)現(xiàn)和解決。 許多人認(rèn)為寫代碼的人一定能找出錯誤來。其實(shí)開發(fā)人員在寫代碼的時候，如果有錯誤，他可以意識到了，可是寫出來的錯誤，他不一定能想得到。我自己也編過程序，在編程序的時候很自信，覺得不會有錯，可事實(shí)上，即使是我編的小程序也有錯誤，但要自己找出來，卻要費(fèi)很大勁。因?yàn)槲乙恢闭J(rèn)為自己不應(yīng)該出錯，但常常錯誤就出現(xiàn)在我認(rèn)為最有把握的地方。我是學(xué)數(shù)學(xué)的，是一個很細(xì)心的人，可是-樣還是會出錯，但要找出自己的錯誤卻要花費(fèi)很長的時間。后來我寫的代碼讓我的師弟幫我看，結(jié)果他很快就找到許多問題，可是我自己花一個月時間可能都找不到。所以，開發(fā)人員和測試人員完全不一樣，開發(fā)人員確實(shí)可以找到一些Bug，但是有更多的Bug 是他意識不到的。在一般的開發(fā)團(tuán)隊中，并不需要測試人員定位Bug 的具體位置，所以，對測試人員的要求并不高。只要你愿意學(xué)，測試工作是非常容易做的。但是，我當(dāng)年所在的IE 團(tuán)隊(IE 4.0)就不同，因?yàn)楫?dāng)時正在與另一個公司的產(chǎn)品競爭，所以微軟就要求盡量找到一流的開發(fā)人員和一流的測試人員，盡快開發(fā)出新產(chǎn)品，打敗對手。所以，當(dāng)時對我們測試人員的要求非常嚴(yán)格，不僅要找出Bug，而且要定位引起此Bug 的代碼行。然后將這些信息交給開發(fā)人員，后者就可以很快更正，省去了他們找錯誤出處的時間。因此，當(dāng)時IE 的開發(fā)速度非?？?，一年之內(nèi)就發(fā)布了一個新版本，而且?guī)缀跻塾腥魏未驜ug，大大超越了競爭對手。三、關(guān)于Bug Bug 的定義很廣泛，在軟件使用過程中所出現(xiàn)的任何一個可疑問題，或者導(dǎo)致軟件不能符合設(shè)計要求或滿足消費(fèi)者需要的問題都是Bug，即使這個Bug 在實(shí)踐中是可行的。有時候，Bug 并不是程序錯誤。例如，軟件沒有按照一般用戶的使用習(xí)慣來運(yùn)行，此時也可以把這個問題看成是該軟件的一個Bug。通常，對Bug 的跟蹤過程如圖所示。 首先，測試人員根據(jù)測試結(jié)果來報告他發(fā)現(xiàn)的所有Bug 。通常，這項(xiàng)工作還需要用戶的參與。微軟在正式發(fā)布一個軟件之前，經(jīng)常要依次發(fā)布Alpha 測試版、Beta 測試版讓用戶試用，以便用戶能夠反饋出相關(guān)Bug 的信息。但是，現(xiàn)在隨著微軟測試隊伍的擴(kuò)大及測試水平的提高，越來越多的 Bug 都是我們內(nèi)部的測試人員自己發(fā)現(xiàn)的，很少出現(xiàn)外部用戶所反饋的Bug 沒有被測試人員發(fā)現(xiàn)的情況。 然后，開發(fā)經(jīng)理根據(jù)這些Bug 的危害性對它們進(jìn)行排序，確定Bug 的優(yōu)先級，并安排給相關(guān)的開發(fā)工程師。 接著，開發(fā)人員根據(jù)Bug 的輕重緩急依次修復(fù)各個Bug 。最后，測試人員再對開發(fā)人員已經(jīng)修復(fù)的Bug 進(jìn)行驗(yàn)證，確認(rèn)Bug 是否已經(jīng)被徹底更正。 微軟開發(fā)一個產(chǎn)品經(jīng)常會遇到幾十萬條Bug 。隨著測試人員越來越多，測試工作也越來越完善。但是，如何快速有效地追蹤并修復(fù)Bug，仍然是擺在軟件測試人員面前的一個主要困難。測試產(chǎn)品和追蹤Bug 時最重要的是問題的定義，要清楚需要解決什么樣的問題，確定Bug 的主次關(guān)系，挑選出最主要的問題，并先解決它們。例如，有些Bug 可能會導(dǎo)致死機(jī)或程序崩潰，這時就要先修復(fù)它們，而另一些Bug 可能對軟件的運(yùn)行影響不大，或者出現(xiàn)的機(jī)會很少，就可以考慮以后再修復(fù)。 可以說，沒有任何一個產(chǎn)品沒有Bug，也永遠(yuǎn)不可能找出并修復(fù)所有的Bug。在修復(fù)了舊的Bug 的同時，往往又會生新的Bug。 根據(jù)微軟的經(jīng)驗(yàn)，每修復(fù)三到四個Bug 一般就會產(chǎn)生一個新的Bug。 這個過程就類似于數(shù)學(xué)中的“極限”的定義，盡管我們知道某個極限值為0，但是它永遠(yuǎn)也不可能達(dá)到0。這也就產(chǎn)品的Bug 永遠(yuǎn)也修復(fù)不完的原因。因此，我們在修復(fù) Bug 時要注意，一定要記住用戶最需要的是什么，然后優(yōu)先盡力修復(fù)那些影響用戶使用的Bug; 而對于大部分對用戶影很少、甚至根本不影響的Bug，則可以推遲修復(fù)，甚至不修復(fù)。 在查找并修復(fù)Bug 的過程中，測試人員和開發(fā)人員經(jīng)常會發(fā)生爭執(zhí)。例如，當(dāng)開發(fā)人員宣布某一個Bug 已經(jīng)被Fixed 時，測試人員往往還不放心，又重新對該Bug 進(jìn)行檢查;當(dāng)開發(fā)人員宣布某一個Bug 是Duplicated 時，細(xì)心的測試人員也要驗(yàn)證該Bug 是否和另外一個Bug 相重復(fù)，如果另外一個 Bug 己經(jīng)被修復(fù)了，但這個Bug 還存在，就會讓開發(fā)人員重新修復(fù)該Bug;對于是否需要Postponed 一個Bug，測試人員和開發(fā)人員也常常爭論不休，測試人員認(rèn)為這個Bug 需要修復(fù)，而開發(fā)人員則認(rèn)為修復(fù)這個Bug 不值得，這時候就需要項(xiàng)目經(jīng)理來決定，因?yàn)闇y試人員要從用戶的角度來看待Bug ，開發(fā)人員則要考慮到開發(fā)期限和付出的代價，而項(xiàng)目經(jīng)理要同時考慮到這兩種情況。 只有項(xiàng)目經(jīng)理經(jīng)過權(quán)衡之后才能確定是否要推遲修復(fù)該 Bug；在By design 情況下，通常是爭論最多的時候。這時候也需要三方都坐下來談，其結(jié)果一般有三種:堅持原來的設(shè)計、修改原來的設(shè)計并增加特性、或者取消該設(shè)計。對Not repro 和Wont fix 情況也是這樣，需要測試人員、開發(fā)人員和項(xiàng)目經(jīng)理進(jìn)行協(xié)商，直到三方達(dá)成共識四、軟件測試方法和輔助工具 有了Bug 類型的定義以后，如何去找出這些Bug 呢？這就需要采用好的測試方法。以下介紹幾種常用的欽件測試方法。有多種方式對軟件測試方法進(jìn)行分類。例如，從代碼和用戶使用的角度可以將軟件測試方法分為如下幾種。 （1）覆蓋性測試 (Coverage Testing) 覆蓋性測試是從代碼的特性角度(即內(nèi)部)出發(fā)的測試方法，包括以下方式。 單元測試 (Unit Test): 按照代碼的單元組成逐個進(jìn)行測試。 功能測試(Function Test) 或特性測試(Feature Test): 按照軟件的功能或特性逐個進(jìn)行測試。例如，在Exchange 中，發(fā)送郵件和接收郵件就是兩個不同的功能或特性，在測試時就分別對它們進(jìn)行檢查，看是否工作正常。 提交測試(Check-in Test): 在開發(fā)人員對代碼做了任何修改，或者修復(fù)了某個Bug 時，需要重新Check-in 代碼 (即將修改后的代碼放大到整個大的系統(tǒng)中)。這時，開發(fā)人員往往也要進(jìn)行測試，看代碼是否工作正常。為了保險起見，開發(fā)人員往往要找測試人員幫著一起進(jìn)行測試(我們把這種情況稱做Buddy Test) 。測試人員和開發(fā)人員之間搞好關(guān)系是非常重要的，稍后我會專門講述這一點(diǎn)。 基本驗(yàn)證測試 (Build Verification Test ，簡稱BVT): 對完成的代碼進(jìn)行編譯和連接，產(chǎn)生一個構(gòu)造，以檢查程序的主要功能是否會像預(yù)期一樣進(jìn)行工作。這是最簡單而又最省時的一種測試方法。每產(chǎn)生一個新的構(gòu)造時都要進(jìn)行測試。如果連BVT 都通不過，表明問題很嚴(yán)重，開發(fā)人員需要盡快修復(fù)出現(xiàn)的問題，測試人員也就不用浪費(fèi)時間做其他測試了。 回歸測試 (Regression Test): 過一段時間以后，再回過頭來對以前修復(fù)過的Bug 重新進(jìn)行測試，看該Bug 是否會重新出現(xiàn)。 (2) 使用測試(Usage Testing) 使用測試是從用戶的角度(即外部)出發(fā)的測試方法。它也包括許多類型。 配置測試(Configuration Test): 從用戶的使用出發(fā)進(jìn)行多方面的測試。例如，保證軟件不僅能夠在Windows 9X 下運(yùn)行，也能夠在Windows ME 下運(yùn)行，還能夠在Windows NT/200O/XP 下運(yùn)行;或者軟件不僅能夠在配置高的計算機(jī)上運(yùn)行，也能夠在配置很低的計算機(jī)上正確地運(yùn)行?？傊?，要考慮到用戶的多種情況，用多種配置對軟件進(jìn)行測試。 兼容性側(cè)試 (Compatibility Test): 主要考慮兼容性問題，比如同一個產(chǎn)品的不同版本(如Office 2O00 和Office XP) 之間的兼容問題，不同廠家的同一個產(chǎn)品(如IE 和Netscape)之間的兼容問題，不同類型軟件(如IE 和Office)之間的兼容問題等。最難測試的往往就是軟件的兼容性問題，往往要投人巨大的人力和物力。一些廠商開發(fā)出來的產(chǎn)品在兼容性上做得很不好，就是因?yàn)闆]有足夠的人力和物力進(jìn)行測試。 我在做SQL Server 的XML 測試的時候，為了解決XML 的兼容性問題，用了6 個測試人員和100 臺計算機(jī)進(jìn)行測試。正因如此，微軟產(chǎn)品的兼容性都非常好。而不像市場上的一些產(chǎn)品，安裝以后就導(dǎo)致計算機(jī)上的許多其他軟件無法使用，或者出現(xiàn)各種各樣的問題，這樣不僅傷害了其他軟件，也傷害了用戶。 壓力測試(StressTest): 在各種極限情況下對產(chǎn)品進(jìn)行測試 (如很多人同時使用該軟件，或者反復(fù)運(yùn)行該軟件)，以檢查產(chǎn)品的長期穩(wěn)定性。例如，我們在開發(fā)IE 4.0 的時候，由于當(dāng)時有一個非常強(qiáng)的競爭對手，因此我們必須保證IE4.0 要做得非常好。當(dāng)時，為了測試IE4.0 的長期穩(wěn)定性，我們專門設(shè)計了一套自動測試程序，它一分鐘可以下載上千個頁面。我們使用這個測試程序?qū)E4.0 進(jìn)行了連續(xù)72 小時的測試，也沒有出現(xiàn)任何問題，如內(nèi)存泄漏、程序崩潰等。 本項(xiàng)測試可以幫助找到一些大型的問題，如死機(jī)、崩損、內(nèi)存泄漏等，因?yàn)橛行┐嬖趦?nèi)存泄漏問題的程序，在運(yùn)行一兩次時可能不會出現(xiàn)問題，但是如果運(yùn)行了成千上萬次，內(nèi)存泄漏得越來越多，就會導(dǎo)致系統(tǒng)崩滑。 性能測試(Performance Test): 本項(xiàng)測試是保證程序具有良好的性能。如果別人的產(chǎn)品只需5 秒鐘就能得出結(jié)果，而你的產(chǎn)品需要10 秒鐘才能得出結(jié)果，就說明你的產(chǎn)品性能不好。如果在測試過程中發(fā)現(xiàn)性能問題，修復(fù)起來是非常艱難的，因?yàn)檫@常常意味著程序的算法不好，結(jié)構(gòu)不好，或者設(shè)計有問題。因此在產(chǎn)品開發(fā)的開始階段，就要考慮到軟件的性能問題。 文檔和幫助文件測試(Documentation and help file Test): 因?yàn)橛脩敉ǔＪ峭ㄟ^文檔和幫助文件來學(xué)習(xí)使用產(chǎn)品的，如果文檔和幫助文件存在錯誤，就可能會導(dǎo)致用戶無法正常使用產(chǎn)品。這項(xiàng)工作通常在產(chǎn)品即將Ship(即準(zhǔn)備包裝發(fā)布)時進(jìn)行，以避免在修復(fù)Bug 的過程中需要反復(fù)修改文檔，或者忘記修改文檔，導(dǎo)致文檔與產(chǎn)品的特性不相符。 Alpha 和Beta 測試 (Alpha and Beta Test): 在正式發(fā)布產(chǎn)品之前往往要先發(fā)布一些測試版，讓用戶能夠反饋出相關(guān)信息，或者找到存在的Bug，以便在正式版中得到解決。 還有一種分類方法將測試方法分為如下幾種。 (1) 白盒測試 (White Box Testing) 又叫做玻璃盒測試(Glass Box Testing) 。在軟件編碼階段，開發(fā)人員根據(jù)自己對代碼的理解和接觸所進(jìn)行的軟件測試叫做白盒測試。這一階段測試以軟件開發(fā)人員為主，有時候SDE/T 也會輔助開發(fā)人員進(jìn)行測試。 (2) 黑盒測試 (Black Box Testing) 黑盒測試的內(nèi)容主要有以下幾個方面。 接受性測試 (Acceptance Testing)：類似于BVT 測試。 Alpha/Beta 測試 (Alpha/Beta Testing): 在此過程中，產(chǎn)品特征不斷地修改。當(dāng)發(fā)現(xiàn)Bug 后，在開發(fā)人員修改的同時，項(xiàng)目經(jīng)理也會對產(chǎn)品計劃做出相應(yīng)的調(diào)整，產(chǎn)品計劃不是一成不變的。 菜單/幫助測試(Menu/Help Testing)：大家千萬不要以為這一項(xiàng)測試不值得進(jìn)行。其實(shí)，在軟件產(chǎn)品開發(fā)的最后階段，文檔里發(fā)現(xiàn)的問題往往是最多的。因?yàn)樵谲浖y試過程中，開發(fā)人員會修復(fù)測試人員發(fā)現(xiàn)的Bug，而且可能會對軟件的有些功能進(jìn)行修改，同時項(xiàng)目經(jīng)理也會根據(jù)情況調(diào)整軟件的特性，因而在軟件開發(fā)和測試的過程中，所有的功能都不是固定不變的，都會進(jìn)行調(diào)整。所以，一般來說，直到軟件Ship 時才編寫軟件的幫助文檔，這樣才能保證幫助文件的內(nèi)容與軟件功能相符，我在做幫助文件測試的時候，總是假裝什么都不懂，就按照幫助文件提供的步驟去做，看看該文件是否正確。在實(shí)際測試中，我經(jīng)常能發(fā)現(xiàn)幫助文件中的Bug 。 發(fā)行測試（Release Testing）：在正式發(fā)行前，產(chǎn)品要經(jīng)過非常仔細(xì)的測試。除了專門的測試人員外，還需要幾千個甚至幾十萬其他用戶與合作者通過親自使用來對產(chǎn)品進(jìn)行測試，然后將錯誤信息反饋給我們。到了發(fā)行測試這一步，如果出現(xiàn)非改不可的Bug，就必須推遲軟件的發(fā)行，有的時候一推就是幾個月，期間需要重新對軟件產(chǎn)品進(jìn)行全面的測試，耗費(fèi)大量的時間和人力物力。 回歸測試（Regression Testing）：回歸測試的目的就是保證以前已經(jīng)修復(fù)的Bug在軟件Ship 以前不會再出現(xiàn)。實(shí)際上，許多Bug 都是在回歸測試時發(fā)現(xiàn)的，在此階段，我們首先要檢查以前找到的Bug 是否已經(jīng)更正了。值得注意的是，已經(jīng)更正的Bug 也可能又回來了，有的Bug 經(jīng)過修改之后可能又產(chǎn)生了新的Bug。所以，回歸測試可保證已更正的Bug 不再重現(xiàn)，不產(chǎn)生新的Bug 。 RTM 測試（Release To Manufacture Testing）：為產(chǎn)品真正的Ship 做好準(zhǔn)備所進(jìn)行的測試。事實(shí)上，在這一測試階段，對每一個Bug 都需要經(jīng)過很高職務(wù)的人同意才能更正。因?yàn)檫@時候修改軟件非常容易產(chǎn)生其他的錯誤，所以只有那種非修復(fù)不可的Bug 才會被允許進(jìn)行修改。如果在發(fā)行階段軟件還有許多嚴(yán)重的Bug 的話，恐怕就不能按時發(fā)布了。記得有一次一個微軟核心產(chǎn)品剛剛完成，準(zhǔn)備Ship 時，我對其進(jìn)行RTM 測試時就發(fā)現(xiàn)一個Bug：只要用該產(chǎn)品打印中文就會導(dǎo)致程序錯誤。這是一個很嚴(yán)重的Bug，于是開發(fā)人員馬上修復(fù)了該Bug，重新Ship 該產(chǎn)品。 功能及系統(tǒng)測試（Function System T