軟件測試的科學和藝術.doc

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