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