微軟是怎么做軟件測試工作的？(2)

　　第一類測試方法的缺點是缺乏靈活性，不利于測試人員主觀能動性的發揮，正像Myers先生所說，不容易找到軟件的錯誤(Bug)。而這方面正是第二類測試方法的長處。

　　微軟的策略

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

　　微軟的第一類測試

　　微軟的第一類測試總體上說分為三個步驟進行：審核需求和設計—〉設計測試—〉實施運行測試。

　　前文已述，第一類測試是以需求和設計為本來驗證軟件的正確性。大家很自然的想到，需求和設計本身也有正確性的問題。依據不正確的需求和設計不可能開發出正確的軟件產品，測試也將是徒勞的。因此驗證需求和設計是微軟進行第一類測試的第一步。

　　有必要指出的是，這里所說的需求和設計具體說來它一般包括：

　　由項目經理根據用戶要求(信息來源于市場部門，用戶支持部門等等)而編寫的需求文本(Requirement Specification);

　　由項目經理根據需求文本而編寫的功能設計文本(Functional Design Specification);

　　由開發人員根據功能文本而編寫的實施設計文本(Implementation Design Specification)。

　　微軟的測試人員要參與所有這些文本的審核。作為測試人員，審核重點是檢查文本對用戶需求定義的完整性、嚴密性和功能設計的可測性。同時這種審核對于測試人員也是一種熱身活動，使他們盡早地進入技術和業務狀態。

　　第二步，測試人員要根據已審核通過的需求和設計編制測試計劃，設計測試用例。在前面提到的三種文本中，功能設計文本是主要依據。原因很簡單，這類測試關心的是軟件是否能正確地實現功能，而不是這些功能如何被具體實施的。

　　從這里大家可以看出這是典型的“黑盒測試”。確實微軟的測試主要是從用戶角度進行的黑盒測試。

　　這一步的完成就意味著“測試計劃”和“測試用例設計”兩個文本的完成。“測試計劃” 文本主要闡述測試的范疇、領域、方法、工具、資源和計劃時間表等等。“測試用例設計”文本要列出測試用例、每個用例的設置、執行步驟和預期結果。測試的這兩個文本也要被項目經理和開發人員審核。這樣經過各種相互的審核，大家對項目形成了基本的共識。

　　第三步的實施運行測試是整個開發過程中最長最復雜的一個階段。從總體上說就是將上一步設計的測試用例按計劃付諸實施的過程。這包括編寫自動化測試程序、反復運行自動化測試程序，也包括階段性執行手動測試用例。這一階段的測試必須在周密的計劃下進行，在前面我已提到，這正是第一類測試的特點和長處。

　　這種計劃性首先體現在開發和測試的相互協調配合，根據產品的架構和功能模塊的依賴關系，按照項目的總體計劃共同推進。從測試的過程來看，總是先運行或執行簡單用例，然后再復雜用例;先驗證單一的基本功能，再綜合的端到端的功能;先發現解決表面的，影響面大的Bug，再深層的，不容易重現的Bug。因此隨著項目開發和測試的進程，產品的功能不斷完善，質量不斷提高。

　　這里有一點要特別指出，有很多測試用例是要反復運行的，特別是基本的自動化測試每一天，每一個Build上都要運行。盡管這些測試大多數情況下都是通過的，很少再發現新的Bug，但其價值是顯而易見的，就是為了防止質量回歸。

　　可見Myers的理論在這里是不適用的。這一階段測試人員還有一項繁瑣但卻很重要的工作，就是對已有的測試用例的維護。比如通常以下兩種情況下要新增一些測試用例，一是對于當初測試設計不周全的領域，二是對于外部的Bug(比如從Beta客戶報告來的)，沒有被現有測試用例所覆蓋。當產品的功能設計出現更改時(在微軟這是常事)，所涉及的測試用例當然也要相應地修改。

　　微軟的第二類測試

　　微軟的第二類測試是階段性的，常常根據需要而帶有隨機性和突擊性。對于這類測試，在微軟有一個專門的名稱：“Bug Bash(Bug大掃除)”。

　　Bug Bash通常發生在項目開發各階段(微軟叫里程碑)的末期，比如Beta版發布前，劃出一個專門的時間段(通常1-3天)，在這期間所有參與項目的人員，集中全部精力，運用各方面的知識，盡全部智慧來搜尋項目的Bug。

　　這是一個非常有意思的活動，但要組織好這樣的活動并非易事。一般有以下要點：

　　盡管這是一個測試活動，但參與者并不僅限于測試人員。項目經理，開發人員甚至于高層管理人員都應參加，如同全民動員。目的是要集思廣益;

　　要鼓勵各部門，領域交叉搜索，因為新的思路和視角通常有助于發現更多的Bug;

　　為調動積極性，增強趣味性，可以適當引入競爭機制，比如當活動結束時，評出發現Bug最多，發現最嚴重Bug的個人，給以物質和精神獎勵。

　　可以分專題展開，比如安全性、用戶界面可用性、國際化和本地化等等。

　　微軟的第二類測試除了Bug Bash外，經常還有一些專業性的測試，最典型的是針對安全性攻擊測試。一般會邀請公司內部，或業界的專家來搜尋產品的安全漏洞。

　　以上我從傳統軟件測試概念的角度，介紹了微軟的策略和兩類傳統測試方法的具體做法，及其側重點。這其實僅僅是一個基礎，一個很原始的基礎。多特有的做法，和概念上軟件測試在微軟軟件產品開發中的作用、地位遠不是這些原始的方法所能達到的，也不是傳統軟件測試概念所函蓋的。微軟在軟件測試方面有很的突破，比如“軟件測試的信息服務功能”、“以用戶為中心的宏觀質量體系”、“分級測試”、“項目的質量管理系統”、“Bug三方會審”、“測試自動化”和“軟件測試的軟硬件—部門、團隊、人和基礎設施”等等。這些我會在以后的討論中分專題進行介紹。

　　_______________________

　　我在前一篇“微軟的軟件測試方法”中介紹了微軟的兩類基本測試方法，其基本思想大家應該是比較熟悉的，因為它們還只是傳統的軟件測試方法的綜合。所以單從形式上，它并沒有體現出對傳統框架的突破。但是從另一個層面來考察微軟軟件測試時，你會對一些基本的事實感到驚訝。比如，“微軟的測試人員和開發人員數量大致相等或略多”，“微軟的產品成本中測試大約占40%以上”等等。人們會有疑問，僅僅是作為功能驗證和搜尋Bug的測試能消耗這么大量的資源嗎?有必要付出如此大的代價嗎?

原文轉自：http://www.anti-gravitydesign.com