要點：

兩類經典的軟件測試方法
第一類測試方法是試圖驗證軟件是“工作的”，所謂“工作的”就是指軟件的功能是按照預先的設計執行的；
第二類測試方法則是設法證明軟件是“不工作的”。

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

微軟的策略
正是因為認識到兩類測試方法各有利弊，微軟在軟件測試活動中將兩類方法結合起來，以第一類測試方法為基礎和主要線索，階段性地運用第二類測試方法。

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

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

通常Bug Bash會產生超乎尋常數量的Bug。
一般我們認為，產生Bug的量越大越好。因為，如果產生Bug的數量少，你很難判斷是因為產品的質量確實很高，還是Bug Bash做得不徹底。而且事實往往是后者。
但同時會造成收斂的缺陷趨勢出現嚴重的發散現象。

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

一些基本的事實
微軟的測試人員和開發人員數量大致相等或略多
微軟的產品成本中測試大約占40%以上

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

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

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

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

---

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