牽著老婆滿街逛

嚴以律己,寬以待人. 三思而后行.
GMail/GTalk: yanglinbo#google.com;
MSN/Email: tx7do#yahoo.com.cn;
QQ: 3 0 3 3 9 6 9 2 0 .

微軟的軟件測試方法（二）

微軟的軟件測試方法（二）
我在前一篇“微軟的軟件測試方法”中介紹了微軟的兩類基本測試方法，其基本思想大家應該是比較熟悉的，因為它們還只是傳統的軟件測試方法的綜合。所以單從形式上，它并沒有體現出對傳統框架的突破。但是從另一個層面來考察微軟軟件測試時，你會對一些基本的事實感到驚訝。比如，“微軟的測試人員和開發人員數量大致相等或略多”，“微軟的產品成本中測試大約占40%以上”等等。人們會有疑問，僅僅是作為功能驗證和搜尋Bug的測試能消耗這么大量的資源嗎？有必要付出如此大的代價嗎？應該有理由相信，微軟作為一個軟件企業，其每一份投入都是有意義的，因此也可斷定微軟在軟件測試方面的努力一定超出傳統測試方法的范疇。

歷史回顧

為了更好的理解微軟件測試在方法和理念上的突破，我想首先回顧一下軟件開發和軟件測試的發展歷史，并從中揭示其必然性。Edward Kit 在他的暢銷書“Software Testing In The Real World : Improving The Process（1995， ISBN: 0201877562）”中將整個軟件開發歷史分為三個階段：

第一個階段是60年代及其以前，那時軟件規模都很小、復雜程度低，軟件開發的過程隨意。開發人員的Debug過程被認為是唯一的測試活動。其實這并不是現代意義上的軟件測試，當然一階段也還沒有專門測試人員的出現。

第二個階段是70年代，這個階段開發的軟件仍然不復雜，但人們已開始思考開發流程問題，并提出“軟件工程Software Engineering”的概念。但是這一階段人們對軟件測試的理解僅限于基本的功能驗證和Bug搜尋，而且測試活動僅出現在整個軟件開發流程的后期，雖然測試由專門的測試人員來承擔，但測試人員都是行業和軟件專業的入門新手。

第三個階段是80年代及其以后，軟件和IT行業進入了大發展。軟件趨向大型化。與之相應，人們為軟件開發設計了各種復雜而精密的流程和管理方法（比如CMM和MSF），并將“質量”的概念融入其中。軟件測試已有了行業標準（IEEE/ANSI ），它再也不是一個一次性的，而且只是開發后期的活動，而是與整個開發流程融合成一體。軟件測試已成為一個專業，需要運用專門的方法和手段，需要專門人才和專家來承擔。

測試與開發的融合

在這一歷史發展過程中，最值得注意的是測試與開發流程融合的趨勢。人們對這種融合也許并不陌生。比如測試活動的早期展開，讓測試人員參與用戶需求的驗證，參加功能設計和實施設計的審核。再比如測試人員與開發人員的密切合作，隨著開發進展而逐步實施單元測試、模塊功能測試和系統整合測試。的確這些都是測試與開發融合的表現形式，而且初期的融合也只反映在這個層次上。90年代以后，軟件的規模和復雜程度迅速提高，這種形式上的融合也迅速走向更深層次，更具實際意義。具體地說這種融合就是整個軟件開發活動對測試的依賴性。傳統上認為，只有軟件的質量控制依賴于測試，但是現代軟件開發的實踐證明，不僅軟件的質量控制依賴于測試，開發本身離開測試也將無法推進，項目管理離開了測試也從根本上失去了依據。在微軟，測試的確有這樣的地位和作用。這就是為什么微軟在軟件測試上有如此大的投入。

開發對測試的依賴

現代軟件開發，特別是大型軟件開發通常會遇到以下兩個問題：

（1）? ? 在開發初期，如何能夠展開大規模團隊，群體齊頭并進，而同時保持開發的有序性。從而有效利用資源，縮短開發周期。

（2）? ? 在開發后期，如何解決深層次的Bug，如何面對設計更改，而能夠保證產品的質量不出現或少出現回落。

對于小型簡單的軟件，這兩個問題也存在，但不突出，而且容易解決。但對于復雜的大型軟件的開發，這兩個問題常常會成為難以逾越的障礙。

通常大型項目的功能豐富，但架構、層次也會相當復雜。穩妥的開發方式是，一次投入少量的人員，逐層開發，逐層穩定。但這種方式顯然資源利用率低，開發周期長，不能滿足現代軟件和IT行業高速發展、瞬息萬變的需要。因此大型項目需要大型團隊。在微軟，產品開發團隊（主要包括開發、測試和項目管理）一般都有百人以上規模，有些產品甚至上幾千人（Windows2000的開發部門曾有3000多人）。這樣大規模的人力資源作用在一個動態的，內部相互聯系的系統中，若沒有有效的協同，其混亂是不可避免的。試想，有兩個開發人員，分別在開發兩個不同的功能模塊，其相互有依賴關系。為了相互協調，他們可以隨時進行當面討論。如果這種關系發生在五個開發人員和五個功能模塊之間，這種協調就只能通過定期的會議來進行。而一個大型項目，會有許許多多這樣的關系，而且很多時候這種關系有著不確定性和不可預見性。當一個開發人員編寫一段新的代碼或對已有代碼進行改動和調整時，他（或她）常常無法確定，或無法完全確定究竟有哪些相關的模塊會受到影響，以及在什么請況下這種影響會帶來什么結果。因為系統的復雜性已遠遠超出了人的邏輯思維、技能和經驗所能力及的范疇。因此這種傳統的協調手段是遠不能滿足需要的。

在微軟，這種協調是通過測試來實現的。具體來說就是：每日建造+自動化測試。關于每日編譯和自動化測試，我將來會作專門介紹，這里簡單的說就是每天都建造一個新版本，每個版本都要運行通過一定量的自動測試用例，以檢驗當天工作的質量。這里所說的質量當然有一般意義上質量的概念，但同時它也反映項目在開發過程中的整體協調性。

自動測試的最大優點在于它的高度可重復性。一個理想的自動測試系統能夠讓人隨時、方便和迅速的運行大量的測試用例。因此一個開發人員可以通過檢查當天的自動測試結果來分析前一天代碼的質量（事后檢查），也可以在當天存入代碼前，先運行自動測試以進一步確保存入代碼的質量（事前檢查）。

在微軟，每日建造都是在午夜開始，完成后緊接著就是全面的自動測試，到早晨上班時間之前就會把結果自動通過e-mail等方式發送出來。開發人員上班后的第一件事往往就是檢查測試結果。如果沒有問題就會開始新的工作。如果有測試有用例沒有通過，開發人員則必須協同測試人員一起立刻找出原因，解決后才能開始新的代碼。有時一個小的失誤會引起大面積的測試用例失敗，很大一部分開發團隊會受到影響。為盡量避免這種情況，要求開發人員在存入代碼之前先在自己的個人建造版本上運行一定量的自動測試，全部通過后在存入。如開發人員沒有按照這樣的要求，而擅自存入質量不高的代碼而造成大量測試失敗，這種不負責任的行為是要受到嚴厲批評的。從這一過程可以看出，開發人員依賴測試來保證開發工作的質量，使開發整體地協調地向前推進。

當開發進入后期階段，盡管項目已總體成型，開發人員也會不時遇到一些技術上的挑戰。比如一些Bug的解決涉及對項目深層次結構的調整；再比如由于客戶反饋的意見造成設計的修改。每一次這樣的修改和調整事實上都是對一個穩定系統的破壞，如果處理不當往往一個Bug的修改會生成很多新的Bug，就像一系列聯鎖的惡性循環。很多項目工期的延誤都是這樣造成的。要避免或至少將這種破壞減少到最低限度，開發人員首先需要知道這種破壞的影響面。在這里單靠開發人員自身的邏輯思維、技能和經驗是遠遠不夠的，自動測試再一次成為一種有效的工具。往往開發人員會制定不止一個方案，對每個方案上都運行一遍同樣一套自動測試用例，然后比較結果，選出最佳方案。自動測試在這方面所起的作用不僅在產品的開發過程中，它還延續到產品發布后。產品支持部門在為客戶提供應急解決方案時也要依賴自動測試。

管理對測試的依賴

在微軟，軟件項目管理的主要線索就是Bug的管理，其中最直接具體的管理活動就是“Bug三方討論會（Bug Triage）”。會議一般由項目管理Program Manager（簡稱PM）來主持，有開發人員和測試人員參加（所以叫三方會議）。會上對每個新生成的Bug進行討論，并決定（1）是否接受這個Bug；（2）Bug的嚴重級別和優先級別；（3）Bug由誰來負責，是由測試提供進一步詳細信息，還是交由開發人員解決，以及大致的解決方案等等。會議還要對老的Bug檢查解決進度。這種討論會常常會發生爭論，要求測試人員具有足夠的技術基礎和用戶經驗，來捍衛產品的質量。可以說項目開發到了某一階段后就是由這種Bug的管理所驅動的。這其中的原動力來自測試。

項目管理中一項非常重要但也十分困難的工作是衡量項目的進度，包括判斷項目的狀態，確定項目是否能預期完成。這方面，測試提供了兩個非常重要的參數，一個是Bug數量的趨勢，另一個是測試結果的趨勢。

Bug趨勢就是將每天新生成的Bug數和每天被解決的Bug數標成一個趨勢圖表。一般在項目的開始階段新生Bug數曲線會呈上升趨勢，到項目中后期被解決Bug數曲線會趨于上升，而新生Bug數曲線應下降，到項目最后，兩條曲線都趨向于零。PM會持續觀察這張圖表，確保項目健康發展，同時通過分析預測項目Bug趨于零的時間。在一定的歷史經驗的基礎上分析使用這一圖表會得到很多有價值的信息，比如說，可分析開發和測試在人力資源的配比上是否恰當，可以分析出某個嚴重的Bug所造成的項目質量的波動。

每天的自動測試結果同樣可以形成類似的圖表。它同樣非常有助于了解當前項目的質量狀況，開發測試進度。

由測試產生的這些數據不僅在項目開發過程中為項目管理提供有效的依據，而且也是產品通過發布的必要條件。在微軟，每個產品都要經過評審才能通過發布。前面介紹的幾個圖表是發布評審的重要內容，如果從圖表中發現臨評審前還出現過較大的質量波動，評審人員一定會對此提出質疑。

因此軟件項目管理依賴軟件測試提供其基本的管理素材。

可以說，現代大型軟件開發過程中開發和管理對測試的依賴性是測試與開發流程融合的一個根本因素。從另一個角度看，測試與開發流程融合決不僅僅是簡單的時間上的同步，更不是雙方空間上的接近，而是這種內在的依存關系的外在表現。開發對測試的這種依賴性對測試和測是人員提出了更高的要求。在理念上，軟件測試已遠不僅僅只是軟件功能的驗證和Bug的搜尋；在具體方法上，自動測試和測試工具的使用已成為基本的要求。在微軟，測試不僅使用一些通用的工具，每一個產品還有專門開發的專用工具庫，測試的代碼量常常超過項目本身的代碼量。

一個軟件企業要提高其軟件開發的能力，特別是針對大型軟件的大規模的快速開發能力，在測試方面對傳統理念和方法進行突破是必要的。微軟的實踐就是一個很好的印證。

posted on 2006-07-27 21:33 楊粼波閱讀(571) 評論(0) 編輯收藏引用所屬分類: 軟件工程

只有注冊用戶登錄后才能發表評論。
【推薦】100%開源！大型工業跨平臺軟件C++源碼提供，建模，組態！

相關文章: 用例驅動的需求過程實踐特性、用例、需求－－ Rational軟件白皮書用例的需求分析-讀書筆記 Bug databases Performance test tools C++單元測試工具列表軟件測試相關的６３個國外站點微軟的軟件測試方法（二）微軟的軟件測試方法常見測試術語

網站導航: 博客園 IT新聞 BlogJava 博問 Chat2DB 管理

牽著老婆滿街逛

導航

統計

公告

常用鏈接

留言簿(11)

隨筆分類(466)

隨筆檔案(1513)

文章分類(46)

文章檔案(45)

相冊

收藏夾(39)

工具官網

技術網站

開源網站

其他窩點

收藏網站

銀行官網

友情鏈接

資源共享

搜索

積分與排名

最新評論

閱讀排行榜

微軟的軟件測試方法（二）