。因此驗證需求和設計是微軟進行第一類測試的第一步。有必要指出的是，這里所說的需求和設計具體說來它一般包括：(1)由項目經理根據用戶要求(信息來源于市場部門，用戶支持部門等等)而編寫的需求文本(Requirement Specification);(2)由項目經理根據需求文本而編寫的功能設計文本(Functional Design Specification);(3)由開發人員根據功能文本而編寫的實施設計文本(Implementation Design Specification)。微軟的測試人員要參與所有這些文本的審核。作為測試人員，審核重點是檢查文本對用戶需求定義的完整性、嚴密性和功能設計的可測性。同時這種審核對于測試人員也是一種熱身活動，使他們盡早地進入技術和業務狀態。第二步，測試人員要根據已審核通過的需求和設計編制測試計劃，設計測試用例。在前面提到的三種文本中，功能設計文本是主要依據。原因很簡單，這類測試關心的是軟件是否能正確地實現功能，而不是這些功能如何被具體實施的。從這里大家可以看出這是典型的“黑盒測試”。確實微軟的測試主要是從用戶角度進行的黑盒測試。這一步的完成就意味著“測試計劃”和“測試用例設計”兩個文本的完成�！皽y試計劃” 文本主要闡述測試的范疇、領域、方法、工具、資源和計劃時間表等等�！皽y試用例設計”文本要列出測試用例、每個用例的設置、執行步驟和預期結果。測試的這兩個文本也要被項目經理和開發人員審核。這樣經過各種相互的審核，大家對項目形成了基本的共識。第三步的實施運行測試是整個開發過程中最長最復雜的一個階段。從總體上說就是將上一步設計的測試用例按計劃付諸實施的過程。這包括編寫自動化測試程序、反復運行自動化測試程序，也包括階段性執行手動測試用例。這一階段的測試必須在周密的計劃下進行，在前面我已提到，這正是第一類測試的特點和長處。這種計劃性首先體現在開發和測試的相互協調配合，根據產品的架構和功能模塊的依賴關系，按照項目的總體計劃共同推進。從測試的過程來看，總是先運行或執行簡單用例，然后再復雜用例;先驗證單一的基本功能，再綜合的端到端的功能;先發現解決表面的，影響面大的Bug，再深層的，不容易重現的Bug。因此隨著項目開發和測試的進程，產品的功能不斷完善，質量不斷提高。這里有一點要特別指出，有很多測試用例是要反復運行的，特別是基本的自動化測試每一天，每一個Build上都要運行。盡管這些測試大多數情況下都是通過的，很少再發現新的Bug，但其價值是顯而易見的，就是為了防止質量回歸�？梢奙yers的理論在這里是不適用的。這一階段測試人員還有一項繁瑣但卻很重要的工作，就是對已有的測試用例的維護。比如通常以下兩種情況下要新增一些測試用例，一是對于當初測試設計不周全的領域，二是對于外部的Bug(比如從Beta客戶報告來的)，沒有被現有測試用例所覆蓋。當產品的功能設計出現更改時(在微軟這是常事)，所涉及的測試用例當然也要相應地修改。微軟的第二類測試 微軟的第二類測試是階段性的，常常根據需要而帶有隨機性和突擊性。對于這類測試，在微軟有一個專門的名稱：“Bug Bash(Bug大掃除)”。 Bug Bash通常發生在項目開發各階段(微軟叫里程碑)的末期，比如Beta版發布前，劃出一個專門的時間段(通常1-3天)，在這期間所有參與項目的人員，集中全部精力，運用各方面的知識，盡全部智慧來搜尋項目的Bug。這是一個非常有意思的活動，但要組織好這樣的活動并非易事。一般有以下要點：(1)盡管這是一個測試活動，但參與者并不僅限于測試人員。項目經理，開發人員甚至于高層管理人員都應參加，如同全民動員。目的是要集思廣益;(2)要鼓勵各部門，領域交叉搜索，因為新的思路和視角通常有助于發現更多的Bug;(3)為調動積極性，增強趣味性，可以適當引入競爭機制，比如當活動結束時，評出發現Bug最多，發現最嚴重Bug的個人，給以物質和精神獎勵。(4)可以分專題展開，比如安全性、用戶界面可用性、國際化和本地化等等。微軟的第二類測試除了Bug Bash外，經常還有一些專業性的測試，最典型的是針對安全性攻擊測試。一般會邀請公司內部，或業界的專家來搜尋產品的安全漏洞。以上我從傳統軟件測試概念的角度，介紹了微軟的策略和兩類傳統測試方法的具體做法，及其側重點。這其實僅僅是一個基礎，一個很原始的基礎。軟件測試在微軟軟件產品開發中的作用、地位遠不是這些原始的方法所能達到的，也不是傳統軟件測試概念所涵蓋的。微軟在軟件測試方面有很多特有的做法，和概念上的突破，比如“軟件測試的信息服務功能”、“以用戶為中心的宏觀質量體系”、“分級測試”、“項目的質量管理系統”、“Bug三方會審”、“測試自動化”和“軟件測試的軟硬件—部門、團隊、人和基礎設施”等等。這些我會在以后的討論中分專題進行介紹。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
