要點(diǎn)：

兩類(lèi)經(jīng)典的軟件測(cè)試方法
第一類(lèi)測(cè)試方法是試圖驗(yàn)證軟件是“工作的”，所謂“工作的”就是指軟件的功能是按照預(yù)先的設(shè)計(jì)執(zhí)行的；
第二類(lèi)測(cè)試方法則是設(shè)法證明軟件是“不工作的”。

兩類(lèi)方法的優(yōu)劣對(duì)比
很明顯這兩類(lèi)測(cè)試方法在具體目標(biāo)、或指導(dǎo)思想上截然相反。由此也決定了它們?cè)谒悸贰⑦^(guò)程和測(cè)重點(diǎn)上有很大的差別，并各有利弊的。
第一類(lèi)測(cè)試方法以需求和設(shè)計(jì)為本，因此有利于界定測(cè)試工作的范疇，更便于部署測(cè)試的側(cè)重點(diǎn)，加強(qiáng)針對(duì)性。這一點(diǎn)對(duì)于大型軟件的測(cè)試，尤其是在有限的時(shí)間和人力資源情況下顯得格外重要。
第二類(lèi)測(cè)試方法與需求和設(shè)計(jì)沒(méi)有必然的關(guān)聯(lián)，如果計(jì)劃管理不當(dāng)，測(cè)試活動(dòng)很容易丟失重點(diǎn)，走入歧途。
第一類(lèi)測(cè)試方法的缺點(diǎn)是缺乏靈活性，不利于測(cè)試人員主觀(guān)能動(dòng)性的發(fā)揮，不容易找到軟件的錯(cuò)誤（Bug）。而這方面正是第二類(lèi)測(cè)試方法的長(zhǎng)處。

微軟的策略
正是因?yàn)檎J(rèn)識(shí)到兩類(lèi)測(cè)試方法各有利弊，微軟在軟件測(cè)試活動(dòng)中將兩類(lèi)方法結(jié)合起來(lái)，以第一類(lèi)測(cè)試方法為基礎(chǔ)和主要線(xiàn)索，階段性地運(yùn)用第二類(lèi)測(cè)試方法。

微軟的第一類(lèi)測(cè)試
微軟的第一類(lèi)測(cè)試總體上說(shuō)分為三個(gè)步驟進(jìn)行：審核需求和設(shè)計(jì)—〉設(shè)計(jì)測(cè)試—〉實(shí)施運(yùn)行測(cè)試。
需求和設(shè)計(jì)本身也有正確性的問(wèn)題。依據(jù)不正確的需求和設(shè)計(jì)不可能開(kāi)發(fā)出正確的軟件產(chǎn)品，測(cè)試也將是徒勞的。因此驗(yàn)證需求和設(shè)計(jì)是微軟進(jìn)行第一類(lèi)測(cè)試的第一步。
同時(shí)這種審核對(duì)于測(cè)試人員也是一種熱身活動(dòng)，使他們盡早地進(jìn)入技術(shù)和業(yè)務(wù)狀態(tài)。
從測(cè)試的過(guò)程來(lái)看，總是先運(yùn)行或執(zhí)行簡(jiǎn)單用例，然后再?gòu)?fù)雜用例；先驗(yàn)證單一的基本功能，再綜合的端到端的功能；先發(fā)現(xiàn)解決表面的，影響面大的Bug，再深層的，不容易重現(xiàn)的Bug。
為了防止質(zhì)量回歸有很多測(cè)試用例是要反復(fù)運(yùn)行的。

微軟的第二類(lèi)測(cè)試
微軟的第二類(lèi)測(cè)試是階段性的，常常根據(jù)需要而帶有隨機(jī)性和突擊性。對(duì)于這類(lèi)測(cè)試，在微軟有一個(gè)專(zhuān)門(mén)的名稱(chēng)：“Bug Bash（Bug大掃除）”。
Bug Bash通常發(fā)生在項(xiàng)目開(kāi)發(fā)各階段（微軟叫里程碑）的末期，比如Beta版發(fā)布前，劃出一個(gè)專(zhuān)門(mén)的時(shí)間段（通常1-3天），在這期間所有參與項(xiàng)目的人員，集中全部精力，運(yùn)用各方面的知識(shí)，盡全部智慧來(lái)搜尋項(xiàng)目的Bug。
這是一個(gè)非常有意思的活動(dòng)，但要組織好這樣的活動(dòng)并非易事。一般有以下要點(diǎn)：
（1）盡管這是一個(gè)測(cè)試活動(dòng)，但參與者并不僅限于測(cè)試人員。項(xiàng)目經(jīng)理，開(kāi)發(fā)人員甚至于高層管理人員都應(yīng)參加，如同全民動(dòng)員。目的是要集思廣益；
（2）要鼓勵(lì)各部門(mén)，領(lǐng)域交叉搜索，因?yàn)樾碌乃悸泛鸵暯峭ǔＳ兄诎l(fā)現(xiàn)更多的Bug；
（3）為調(diào)動(dòng)積極性，增強(qiáng)趣味性，可以適當(dāng)引入競(jìng)爭(zhēng)機(jī)制，比如當(dāng)活動(dòng)結(jié)束時(shí)，評(píng)出發(fā)現(xiàn)Bug最多，發(fā)現(xiàn)最嚴(yán)重Bug的個(gè)人，給以物質(zhì)和精神獎(jiǎng)勵(lì)。
（4）可以分專(zhuān)題展開(kāi)，比如安全性、用戶(hù)界面可用性、國(guó)際化和本地化等等。

通常Bug Bash會(huì)產(chǎn)生超乎尋常數(shù)量的Bug。
一般我們認(rèn)為，產(chǎn)生Bug的量越大越好。因?yàn)椋绻a(chǎn)生Bug的數(shù)量少，你很難判斷是因?yàn)楫a(chǎn)品的質(zhì)量確實(shí)很高，還是Bug Bash做得不徹底。而且事實(shí)往往是后者。
但同時(shí)會(huì)造成收斂的缺陷趨勢(shì)出現(xiàn)嚴(yán)重的發(fā)散現(xiàn)象。

那么對(duì)Bug Bash所產(chǎn)生的大量Bug該怎么辦？
在微軟，有“Bug Triage （測(cè)試，開(kāi)發(fā)和項(xiàng)目管理，三方會(huì)審）”的制度。
對(duì)于每個(gè)Bug，經(jīng)過(guò)會(huì)審后不外乎有以下三中歸宿（總體上來(lái)說(shuō)）：
（1）被確認(rèn)為“缺陷性”Bug，這樣的Bug必須交開(kāi)發(fā)人員解決，然后由原發(fā)現(xiàn)人驗(yàn)證。
（2）被調(diào)整為非“缺陷性”Bug，不用開(kāi)發(fā)人員作任何更改，但必須將問(wèn)題納入產(chǎn)品用戶(hù)文檔，明確向用戶(hù)解釋?zhuān)⒏嬖V用戶(hù)如何避免和應(yīng)對(duì)。
      考慮到，一方面這種情況在用戶(hù)實(shí)際使用產(chǎn)品時(shí)發(fā)生的機(jī)率很低，而另一方面，從開(kāi)發(fā)角度，解決這個(gè)問(wèn)題有很大的技術(shù)難度，影響面也太大。這種情況下會(huì)把這個(gè)Bug改為“文本性”Bug，也就是要求文本編寫(xiě)人員將這一情況作一技術(shù)性解釋。這類(lèi)的Bug在Bug Bash中很常見(jiàn)，因?yàn)榇蠹以谶@種測(cè)試活動(dòng)中思維方式比較超常。
（3）被完全否定，立刻關(guān)閉，不再糾纏。
      這類(lèi)的情況在Bug Bash中也很常見(jiàn)。因?yàn)閰⑴cBug Bash人并不都很了解產(chǎn)品功能的準(zhǔn)確用法，誤報(bào)是難免的。盡管對(duì)這類(lèi)問(wèn)題沒(méi)有直接的后續(xù)措施，但這些信息仍然是有一定價(jià)值的，因?yàn)閷?lái)用戶(hù)中的新手很可能會(huì)犯同樣的毛病，而產(chǎn)品支持部門(mén)如果預(yù)先有這樣的經(jīng)驗(yàn)，就能及時(shí)準(zhǔn)確地提供幫助。所以這些信息要保存在Bug的管理庫(kù)中，以備將來(lái)產(chǎn)品支持部門(mén)查詢(xún)。
經(jīng)過(guò)這樣的會(huì)審，篩選，如果（1）（2）類(lèi)Bug，特別是（1）類(lèi)Bug仍然很多，那測(cè)試部門(mén)很可能需要重新論證原先的測(cè)試計(jì)劃和測(cè)試用例設(shè)計(jì)，看是否需要增加測(cè)試用例。必要時(shí)還要盡早提出更改項(xiàng)目總體計(jì)劃和發(fā)布日期。 大量Bug的出現(xiàn)也許不是件愉快的事，但和把這些Bug留給用戶(hù)相比，代價(jià)要小得太多了。

一些基本的事實(shí)
微軟的測(cè)試人員和開(kāi)發(fā)人員數(shù)量大致相等或略多
微軟的產(chǎn)品成本中測(cè)試大約占40%以上

歷史回顧 
軟件開(kāi)發(fā)歷史四個(gè)階段：
第一個(gè)階段是60年代及其以前，那時(shí)軟件規(guī)模都很小、復(fù)雜程度低，軟件開(kāi)發(fā)的過(guò)程隨意。開(kāi)發(fā)人員的Debug過(guò)程被認(rèn)為是唯一的測(cè)試活動(dòng)。其實(shí)這并不是現(xiàn)代意義上的軟件測(cè)試，當(dāng)然一階段也還沒(méi)有專(zhuān)門(mén)測(cè)試人員的出現(xiàn)。
第二個(gè)階段是70年代，這個(gè)階段開(kāi)發(fā)的軟件仍然不復(fù)雜，但人們已開(kāi)始思考開(kāi)發(fā)流程問(wèn)題，并提出“軟件工程Software Engineering”的概念。但是這一階段人們對(duì)軟件測(cè)試的理解僅限于基本的功能驗(yàn)證和Bug搜尋，而且測(cè)試活動(dòng)僅出現(xiàn)在整個(gè)軟件開(kāi)發(fā)流程的后期，雖然測(cè)試由專(zhuān)門(mén)的測(cè)試人員來(lái)承擔(dān)，但測(cè)試人員都是行業(yè)和軟件專(zhuān)業(yè)的入門(mén)新手。
第三個(gè)階段是80年代及其以后，軟件和IT行業(yè)進(jìn)入了大發(fā)展。軟件趨向大型化。軟件測(cè)試已成為一個(gè)專(zhuān)業(yè)，需要運(yùn)用專(zhuān)門(mén)的方法和手段，需要專(zhuān)門(mén)人才和專(zhuān)家來(lái)承擔(dān)。
第四個(gè)階段是90年代以后，軟件的規(guī)模和復(fù)雜程度迅速提高，測(cè)試與開(kāi)發(fā)流程的融合也迅速走向更深層次，具體地說(shuō)這種融合就是整個(gè)軟件開(kāi)發(fā)活動(dòng)對(duì)測(cè)試的依賴(lài)性。傳統(tǒng)上認(rèn)為，只有軟件的質(zhì)量控制依賴(lài)于測(cè)試，但是現(xiàn)代軟件開(kāi)發(fā)的實(shí)踐證明，不僅軟件的質(zhì)量控制依賴(lài)于測(cè)試，開(kāi)發(fā)本身離開(kāi)測(cè)試也將無(wú)法推進(jìn)，項(xiàng)目管理離開(kāi)了測(cè)試也從根本上失去了依據(jù)。在微軟，測(cè)試的確有這樣的地位和作用。這就是為什么微軟在軟件測(cè)試上有如此大的投入。

在微軟，產(chǎn)品開(kāi)發(fā)團(tuán)隊(duì)（主要包括開(kāi)發(fā)、測(cè)試和項(xiàng)目管理）一般都有百人以上規(guī)模，有些產(chǎn)品甚至上幾千人（Windows2000的開(kāi)發(fā)部門(mén)曾有3000多人）。這樣大規(guī)模的人力資源作用在一個(gè)動(dòng)態(tài)的，內(nèi)部相互聯(lián)系的系統(tǒng)中，若沒(méi)有有效的協(xié)同，其混亂是不可避免的。試想，有兩個(gè)開(kāi)發(fā)人員，分別在開(kāi)發(fā)兩個(gè)不同的功能模塊，其相互有依賴(lài)關(guān)系。為了相互協(xié)調(diào)，他們可以隨時(shí)進(jìn)行當(dāng)面討論。如果這種關(guān)系發(fā)生在五個(gè)開(kāi)發(fā)人員和五個(gè)功能模塊之間，這種協(xié)調(diào)就只能通過(guò)定期的會(huì)議來(lái)進(jìn)行。而一個(gè)大型項(xiàng)目，會(huì)有許許多多這樣的關(guān)系，而且很多時(shí)候這種關(guān)系有著不確定性和不可預(yù)見(jiàn)性。當(dāng)一個(gè)開(kāi)發(fā)人員編寫(xiě)一段新的代碼或?qū)σ延写a進(jìn)行改動(dòng)和調(diào)整時(shí)，他（或她）常常無(wú)法確定，或無(wú)法完全確定究竟有哪些相關(guān)的模塊會(huì)受到影響，以及在什么請(qǐng)況下這種影響會(huì)帶來(lái)什么結(jié)果。因?yàn)橄到y(tǒng)的復(fù)雜性已遠(yuǎn)遠(yuǎn)超出了人的邏輯思維、技能和經(jīng)驗(yàn)所能力及的范疇。因此這種傳統(tǒng)的協(xié)調(diào)手段是遠(yuǎn)不能滿(mǎn)足需要的。
在微軟，這種協(xié)調(diào)是通過(guò)測(cè)試來(lái)實(shí)現(xiàn)的。具體來(lái)說(shuō)就是：每日建造+自動(dòng)化測(cè)試。
關(guān)于每日編譯和自動(dòng)化測(cè)試，這里簡(jiǎn)單的說(shuō)就是每天都建造一個(gè)新版本，每個(gè)版本都要運(yùn)行通過(guò)一定量的自動(dòng)測(cè)試用例，以檢驗(yàn)當(dāng)天工作的質(zhì)量。
全面的自動(dòng)測(cè)試，到早晨上班時(shí)間之前就會(huì)把結(jié)果自動(dòng)通過(guò)e-mail等方式發(fā)送出來(lái)。開(kāi)發(fā)人員上班后的第一件事往往就是檢查測(cè)試結(jié)果。如果沒(méi)有問(wèn)題就會(huì)開(kāi)始新的工作。如果有測(cè)試有用例沒(méi)有通過(guò)，開(kāi)發(fā)人員則必須協(xié)同測(cè)試人員一起立刻找出原因，解決后才能開(kāi)始新的代碼。有時(shí)一個(gè)小的失誤會(huì)引起大面積的測(cè)試用例失敗，很大一部分開(kāi)發(fā)團(tuán)隊(duì)會(huì)受到影響。為盡量避免這種情況，要求開(kāi)發(fā)人員在存入代碼之前先在自己的個(gè)人建造版本上運(yùn)行一定量的自動(dòng)測(cè)試，全部通過(guò)后在存入。如開(kāi)發(fā)人員沒(méi)有按照這樣的要求，而擅自存入質(zhì)量不高的代碼而造成大量測(cè)試失敗，這種不負(fù)責(zé)任的行為是要受到嚴(yán)厲批評(píng)的。
從這一過(guò)程可以看出，開(kāi)發(fā)人員依賴(lài)測(cè)試來(lái)保證開(kāi)發(fā)工作的質(zhì)量，使開(kāi)發(fā)整體地協(xié)調(diào)地向前推進(jìn)。

開(kāi)發(fā)對(duì)測(cè)試的這種依賴(lài)性對(duì)測(cè)試和測(cè)是人員提出了更高的要求。
在理念上，軟件測(cè)試已遠(yuǎn)不僅僅只是軟件功能的驗(yàn)證和Bug的搜尋；
在具體方法上，自動(dòng)測(cè)試和測(cè)試工具的使用已成為基本的要求。

一個(gè)軟件企業(yè)要提高其軟件開(kāi)發(fā)的能力，特別是針對(duì)大型軟件的大規(guī)模的快速開(kāi)發(fā)能力，在測(cè)試方面對(duì)傳統(tǒng)理念和方法進(jìn)行突破是必要的。

---

原文全文：http://www.51testing.com/?157364/action_viewspace_itemid_90429.html