要點(diǎn)：

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

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

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

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

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

通常Bug Bash會產(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í)往往是后者。
但同時會造成收斂的缺陷趨勢出現(xiàn)嚴(yán)重的發(fā)散現(xiàn)象。

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

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

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

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

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

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

---

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