第一類測試方法可以與軟件的架構和軟件開發的計劃相配合，使軟件測試活動逐層次的展開，從而使軟件的功能和質量有計劃地逐步完善和提高（關于測試的層次問題，我會在今后的討論中專門介紹）。第二類測試方法不具備這種過程的漸進性。
第一類測試方法的缺點是缺乏靈活性，不利于測試人員主觀能動性的發揮，正像Myers先生所說，不容易找到軟件的錯誤（Bug）。而這方面正是第二類測試方法的長處。
微軟的策略
正是因為認識到兩類測試方法各有利弊，微軟在軟件測試活動中將兩類方法結合起來，以第一類測試方法為基礎和主要線索，階段性地運用第二類測試方法。
微軟的第一類測試
微軟的第一類測試總體上說分為三個步驟進行：審核需求和設計—〉設計測試—〉實施運行測試。
前文已述，第一類測試是以需求和設計為本來驗證軟件的正確性。大家很自然的想到，需求和設計本身也有正確性的問題。依據不正確的需求和設計不可能開發出正確的軟件產品，測試也將是徒勞的。因此驗證需求和設計是微軟進行第一類測試的第一步。
有必要指出的是，這里所說的需求和設計具體說來它一般包括：
1. 由項目經理根據用戶要求（信息來源于市場部門，用戶支持部門等等）而編寫的需求文本（Requirement Specification）；
2. 由項目經理根據需求文本而編寫的功能設計文本（Functional Design Specification）；
3. 由開發人員根據功能文本而編寫的實施設計文本（Implementation Design Specification）。
微軟的測試人員要參與所有這些文本的審核。作為測試人員，審核重點是檢查文本對用戶需求定義的完整性、嚴密性和功能設計的可測性。同時這種審核對于測試人員也是一種熱身活動，使他們盡早地進入技術和業務狀態。
第二步，測試人員要根據已審核通過的需求和設計編制測試計劃，設計測試用例。在前面提到的三種文本中，功能設計文本是主要依據。原因很簡單，這類測試關心的是軟件是否能正確地實現功能，而不是這些功能如何被具體實施的。
從這里大家可以看出這是典型的“黑盒測試”。確實微軟的測試主要是從用戶角度進行的黑盒測試。
這一步的完成就意味著“測試計劃”和“測試用例設計”兩個文本的完成�！皽y試計劃” 文本主要闡述測試的范疇、領域、方法、工具、資源和計劃時間表等等�！�測試用例設計”文本要列出測試用例、每個用例的設置、執行步驟和預期結果。測試的這兩個文本也要被項目經理和開發人員審核。這樣經過各種相互的審核，大家對項目形成了基本的共識。
第三步的實施運行測試是整個開發過程中最長最復雜的一個階段。從總體上說就是將上一步設計的測試用例按計劃付諸實施的過程。這包括編寫自動化測試程序、反復運行自動化測試程序，也包括階段性執行手動測試用例。這一階段的測試必須在周密的計劃下進行，在前面我已提到，這正是第一類測試的特點和長處。
這種計劃性首先體現在開發和測試的相互協調配合，根據產品的架構和功能模塊的依賴關系，按照項目的總體計劃共同推進。從測試的過程來看，總是先運行或執行簡單用例，然后再復雜用例；先驗證單一的基本功能，再綜合的端到端的功能；先發現解決表面的，影響面大的Bug，再深層的，不容易重現的Bug。因此隨著項目開發和測試的進程，產品的功能不斷完善，質量不斷提高。
這里有一點要特別指出，有很多測試用例是要反復運行的，特別是基本的自動化測試每一天，每一個Build上都要運行。盡管這些測試大多數情況下都是通過的，很少再發現新的Bug，但其價值是顯而易見的，就是為了防止質量回歸。
可見Myers的理論在這里是不適用的。這一階段測試人員還有一項繁瑣但卻很重要的工作，就是對已有的測試用例的維護。比如通常以下兩種情況下要新增一些測試用例，一是對于當初測試設計不周全的領域，二是對于外部的Bug（比如從Beta客戶報告來的），沒有被現有測試用例所覆蓋。當產品的功能設計出現更改時（在微軟這是常事），所涉及的測試用例當然也要相應地修改。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
