微軟的軟件測試方法（二）
我在前一篇“微軟的軟件測試方法”中介紹了微軟的兩類基本測試方法，其基本思想大家應該是比較熟悉的，因為它們還只是傳統(tǒng)的軟件測試方法的綜合。所以單從形式上，它并沒有體現(xiàn)出對傳統(tǒng)框架的突破。但是從另一個層面來考察微軟軟件測試時，你會對一些基本的事實感到驚訝。比如，“微軟的測試人員和開發(fā)人員數(shù)量大致相等或略多”，“微軟的產品成本中測試大約占40%以上”等等。人們會有疑問，僅僅是作為功能驗證和搜尋Bug的測試能消耗這么大量的資源嗎？有必要付出如此大的代價嗎？應該有理由相信，微軟作為一個軟件企業(yè)，其每一份投入都是有意義的，因此也可斷定微軟在軟件測試方面的努力一定超出傳統(tǒng)測試方法的范疇。
歷史回顧
為了更好的理解微軟件測試在方法和理念上的突破，我想首先回顧一下軟件開發(fā)和軟件測試的發(fā)展歷史，并從中揭示其必然性。Edward Kit 在他的暢銷書“Software Testing In The Real World : Improving The Process（1995， ISBN: 0201877562）”中將整個軟件開發(fā)歷史分為三個階段：
第一個階段是60年代及其以前，那時軟件規(guī)模都很小、復雜程度低，軟件開發(fā)的過程隨意。開發(fā)人員的Debug過程被認為是唯一的測試活動。其實這并不是現(xiàn)代意義上的軟件測試，當然一階段也還沒有專門測試人員的出現(xiàn)。
第二個階段是70年代，這個階段開發(fā)的軟件仍然不復雜，但人們已開始思考開發(fā)流程問題，并提出“軟件工程Software Engineering”的概念。但是這一階段人們對軟件測試的理解僅限于基本的功能驗證和Bug搜尋，而且測試活動僅出現(xiàn)在整個軟件開發(fā)流程的后期，雖然測試由專門的測試人員來承擔，但測試人員都是行業(yè)和軟件專業(yè)的入門新手。
第三個階段是80年代及其以后，軟件和IT行業(yè)進入了大發(fā)展。軟件趨向大型化。與之相應，人們?yōu)檐浖_發(fā)設計了各種復雜而精密的流程和管理方法（比如CMM和MSF），并將“質量”的概念融入其中。軟件測試已有了行業(yè)標準（IEEE/ANSI ），它再也不是一個一次性的，而且只是開發(fā)后期的活動，而是與整個開發(fā)流程融合成一體。軟件測試已成為一個專業(yè)，需要運用專門的方法和手段，需要專門人才和專家來承擔。
測試與開發(fā)的融合
在這一歷史發(fā)展過程中，最值得注意的是測試與開發(fā)流程融合的趨勢。人們對這種融合也許并不陌生。比如測試活動的早期展開，讓測試人員參與用戶需求的驗證，參加功能設計和實施設計的審核。再比如測試人員與開發(fā)人員的密切合作，隨著開發(fā)進展而逐步實施單元測試、模塊功能測試和系統(tǒng)整合測試。的確這些都是測試與開發(fā)融合的表現(xiàn)形式，而且初期的融合也只反映在這個層次上。90年代以后，軟件的規(guī)模和復雜程度迅速提高，這種形式上的融合也迅速走向更深層次，更具實際意義。具體地說這種融合就是整個軟件開發(fā)活動對測試的依賴性。傳統(tǒng)上認為，只有軟件的質量控制依賴于測試，但是現(xiàn)代軟件開發(fā)的實踐證明，不僅軟件的質量控制依賴于測試，開發(fā)本身離開測試也將無法推進，項目管理離開了測試也從根本上失去了依據。在微軟，測試的確有這樣的地位和作用。這就是為什么微軟在軟件測試上有如此大的投入。
開發(fā)對測試的依賴
現(xiàn)代軟件開發(fā)，特別是大型軟件開發(fā)通常會遇到以下兩個問題：
（1） 在開發(fā)初期，如何能夠展開大規(guī)模團隊，群體齊頭并進，而同時保持開發(fā)的有序性。從而有效利用資源，縮短開發(fā)周期。
（2） 在開發(fā)后期，如何解決深層次的Bug，如何面對設計更改，而能夠保證產品的質量不出現(xiàn)或少出現(xiàn)回落。
對于小型簡單的軟件，這兩個問題也存在，但不突出，而且容易解決。但對于復雜的大型軟件的開發(fā)，這兩個問題常常會成為難以逾越的障礙。
通常大型項目的功能豐富，但架構、層次也會相當復雜。穩(wěn)妥的開發(fā)方式是，一次投入少量的人員，逐層開發(fā)，逐層穩(wěn)定。但這種方式顯然資源利用率低，開發(fā)周期長，不能滿足現(xiàn)代軟件和IT行業(yè)高速發(fā)展、瞬息萬變的需要。因此大型項目需要大型團隊。在微軟，產品開發(fā)團隊（主要包括開發(fā)、測試和項目管理）一般都有百人以上規(guī)模，有些產品甚至上幾千人（Windows2000的開發(fā)部門曾有3000多人）。這樣大規(guī)模的人力資源作用在一個動態(tài)的，內部相互聯(lián)系的系統(tǒng)中，若沒有有效的協(xié)同，其混亂是不可避免的。試想，有兩個開發(fā)人員，分別在開發(fā)兩個不同的功能模塊，其相互有依賴關系。為了相互協(xié)調，他們可以隨時進行當面討論。如果這種關系發(fā)生在五個開發(fā)人員和五個功能模塊之間，這種協(xié)調就只能通過定期的會議來進行。而一個大型項目，會有許許多多這樣的關系，而且很多時候這種關系有著不確定性和不可預見性。當一個開發(fā)人員編寫一段新的代碼或對已有代碼進行改動和調整時，他（或她）常常無法確定，或無法完全確定究竟有哪些相關的模塊會受到影響，以及在什么請況下這種影響會帶來什么結果。因為系統(tǒng)的復雜性已遠遠超出了人的邏輯思維、技能和經驗所能力及的范疇。因此這種傳統(tǒng)的協(xié)調手段是遠不能滿足需要的。
在微軟，這種協(xié)調是通過測試來實現(xiàn)的。具體來說就是：每日建造+自動化測試。關于每日編譯和自動化測試，我將來會作專門介紹，這里簡單的說就是每天都建造一個新版本，每個版本都要運行通過一定量的自動測試用例，以檢驗當天工作的質量。這里所說的質量當然有一般意義上質量的概念，但同時它也反映項目在開發(fā)過程中的整體協(xié)調性。
自動測試的最大優(yōu)點在于它的高度可重復性。一個理想的自動測試系統(tǒng)能夠讓人隨時、方便和迅速的運行大量的測試用例。因此一個開發(fā)人員可以通過檢查當天的自動測試結果來分析前一天代碼的質量（事后檢查），也可以在當天存入代碼前，先運行自動測試以進一步確保存入代碼的質量（事前檢查）。
在微軟，每日建造都是在午夜開始，完成后緊接著就是全面的自動測試，到早晨上班時間之前就會把結果自動通過e-mail等方式發(fā)送出來。開發(fā)人員上班后的第一件事往往就是檢查測試結果。如果沒有問題就會開始新的工作。如果有測試有用例沒有通過，開發(fā)人員則必須協(xié)同測試人員一起立刻找出原因，解決后才能開始新的代碼。有時一個小的失誤會引起大面積的測試用例失敗，很大一部分開發(fā)團隊會受到影響。為盡量避免這種情況，要求開發(fā)人員在存入代碼之前先在自己的個人建造版本上運行一定量的自動測試，全部通過后在存入。如開發(fā)人員沒有按照這樣的要求，而擅自存入質量不高的代碼而造成大量測試失敗，這種不負責任的行為是要受到嚴厲批評的。從這一過程可以看出，開發(fā)人員依賴測試來保證開發(fā)工作的質量，使開發(fā)整體地協(xié)調地向前推進。
當開發(fā)進入后期階段，盡管項目已總體成型，開發(fā)人員也會不時遇到一些技術上的挑戰(zhàn)。比如一些Bug的解決涉及對項目深層次結構的調整；再比如由于客戶反饋的意見造成設計的修改。每一次這樣的修改和調整事實上都是對一個穩(wěn)定系統(tǒng)的破壞，如果處理不當往往一個Bug的修改會生成很多新的Bug，就像一系列聯(lián)鎖的惡性循環(huán)。很多項目工期的延誤都是這樣造成的。要避免或至少將這種破壞減少到最低限度，開發(fā)人員首先需要知道這種破壞的影響面。在這里單靠開發(fā)人員自身的邏輯思維、技能和經驗是遠遠不夠的，自動測試再一次成為一種有效的工具。往往開發(fā)人員會制定不止一個方案，對每個方案上都運行一遍同樣一套自動測試用例，然后比較結果，選出最佳方案。自動測試在這方面所起的作用不僅在產品的開發(fā)過程中，它還延續(xù)到產品發(fā)布后。產品支持部門在為客戶提供應急解決方案時也要依賴自動測試。
管理對測試的依賴
在微軟，軟件項目管理的主要線索就是Bug的管理，其中最直接具體的管理活動就是“Bug三方討論會（Bug Triage）”。會議一般由項目管理Program Manager（簡稱PM）來主持，有開發(fā)人員和測試人員參加（所以叫三方會議）。會上對每個新生成的Bug進行討論，并決定（1）是否接受這個Bug；（2）Bug的嚴重級別和優(yōu)先級別；（3）Bug由誰來負責，是由測試提供進一步詳細信息，還是交由開發(fā)人員解決，以及大致的解決方案等等。會議還要對老的Bug檢查解決進度。這種討論會常常會發(fā)生爭論，要求測試人員具有足夠的技術基礎和用戶經驗，來捍衛(wèi)產品的質量。可以說項目開發(fā)到了某一階段后就是由這種Bug的管理所驅動的。這其中的原動力來自測試。
項目管理中一項非常重要但也十分困難的工作是衡量項目的進度，包括判斷項目的狀態(tài)，確定項目是否能預期完成。這方面，測試提供了兩個非常重要的參數(shù)，一個是Bug數(shù)量的趨勢，另一個是測試結果的趨勢。
Bug趨勢就是將每天新生成的Bug數(shù)和每天被解決的Bug數(shù)標成一個趨勢圖表。一般在項目的開始階段新生Bug數(shù)曲線會呈上升趨勢，到項目中后期被解決Bug數(shù)曲線會趨于上升，而新生Bug數(shù)曲線應下降，到項目最后，兩條曲線都趨向于零。PM會持續(xù)觀察這張圖表，確保項目健康發(fā)展，同時通過分析預測項目Bug趨于零的時間。在一定的歷史經驗的基礎上分析使用這一圖表會得到很多有價值的信息，比如說，可分析開發(fā)和測試在人力資源的配比上是否恰當，可以分析出某個嚴重的Bug所造成的項目質量的波動。
每天的自動測試結果同樣可以形成類似的圖表。它同樣非常有助于了解當前項目的質量狀況，開發(fā)測試進度。
由測試產生的這些數(shù)據不僅在項目開發(fā)過程中為項目管理提供有效的依據，而且也是產品通過發(fā)布的必要條件。在微軟，每個產品都要經過評審才能通過發(fā)布。前面介紹的幾個圖表是發(fā)布評審的重要內容，如果從圖表中發(fā)現(xiàn)臨評審前還出現(xiàn)過較大的質量波動，評審人員一定會對此提出質疑。
因此軟件項目管理依賴軟件測試提供其基本的管理素材。
可以說，現(xiàn)代大型軟件開發(fā)過程中開發(fā)和管理對測試的依賴性是測試與開發(fā)流程融合的一個根本因素。從另一個角度看，測試與開發(fā)流程融合決不僅僅是簡單的時間上的同步，更不是雙方空間上的接近，而是這種內在的依存關系的外在表現(xiàn)。開發(fā)對測試的這種依賴性對測試和測是人員提出了更高的要求。在理念上，軟件測試已遠不僅僅只是軟件功能的驗證和Bug的搜尋；在具體方法上，自動測試和測試工具的使用已成為基本的要求。在微軟，測試不僅使用一些通用的工具，每一個產品還有專門開發(fā)的專用工具庫，測試的代碼量常常超過項目本身的代碼量。
一個軟件企業(yè)要提高其軟件開發(fā)的能力，特別是針對大型軟件的大規(guī)模的快速開發(fā)能力，在測試方面對傳統(tǒng)理念和方法進行突破是必要的。微軟的實踐就是一個很好的印證。
本站僅提供存儲服務，所有內容均由用戶發(fā)布，如發(fā)現(xiàn)有害或侵權內容，請
點擊舉報。
