首先介紹，在業界有兩種測試方法：
第一類測試方法是試圖驗證軟體是「工作的」，所謂「工作的」就是指軟體的功能是按照預先的設計執行的。
第二類測試方法則是設法證明軟體是「不工作的」。
兩種測試方法的利與弊：
第一類測試可以簡單的視為：在設計規定的環境下執行軟體的功能，將其結果與使用者需求或設計結果相比較，如果相符則測試通過，如果不相符則視為bug。這一過程的終極
目標就是將軟體的所有功能在所有設計規定的環境全部執行，並通過。
儘管如此，這一方法還是受到很多業界權威的質疑和挑戰。代表人物是glenford j. myers（代表論著《the art of software testing》）。他認為測試不應該著眼於驗證軟
件是工作的，相反應該首先認定軟體是有錯誤的，然後去發現盡可能多的錯誤。而第二類方法認為軟體測試員的目標是找到軟體缺陷，盡可能早一些，並確保其得以修復。有
些軟體企業以bug數量來作為考核測試人員業績得一項指標。
第一類測試方法以需求和設計為本，因此有利於界定測試工作的範疇，更便於部署測試的側重點，加強針對性。這一點對於大型軟體的測試，尤其是在有限的時間和人力資源情
況下顯得格外重要。而第二類測試方法與需求和設計沒有必然的關聯，如果計畫管理不當，測試活動很容易丟失重點，走入歧途。
微軟的測試過程，分為兩大類：
第一類測試是以需求和設計為本來驗證軟體的正確性：
第一步：驗證需求和設計：
這裡的需求和設計具體來說它一般包括：：（1）由專案經理根據使用者要求（資訊**於市場部門，使用者支援部門等等）而編寫的需求文字（requirement specification）
；（2）由專案經理根據需求文字而編寫的功能設計文字（functional design specification）；（3）由開發人員根據功能文字而編寫的實施設計文字（implementation
design specification）。微軟的測試人員要參與所有這些文字的審核。
作為測試人員，審核重點是檢查文件對使用者需求定義的完整性，嚴密性和功能設計的可測性。（是他們盡早的進入技術＆業務狀態）。
第二步：測試人員要根據已審核通過的需求和設計編制測試計畫，設計測試用例。
第三步：實施執行測試是整個開發過程中最複雜的乙個階段。
這種計畫性首先體現在開發和測試的相互協調配合，根據產品的架構和功能模組的依賴關係，按照專案的總體計畫共同推進。從測試的過程來看，總是先執行或執行
簡單用例，然後再複雜用例；先驗證單一的基本功能，再綜合的端到端的功能；先發現解決表面的，影響面大的bug，再深層的，不容易重現的bug。因此隨著專案開發和測試
的程序，產品的功能不斷完善，質量不斷提高。有一點要特別提出，就是很多測試要重複執行。特別是基本的自動化測試每天，每個build上都要執行。儘管大多數都是通過的
，很少有新的bug出現，這是防止質量回顧。
在第三步實施的過程中，測試人員還有乙個比較繁瑣卻很重要的工作就是維護自己testcase。比如通常以下兩種情況下要新增一些測試用例，一是對於當初測試設計
不周全的領域，二是對於外部的bug（比如從beta客戶報告來的），沒有被現有測試用例所覆蓋。
第二類測試
微軟的第二類測試是階段性的，常常根據需要而帶有隨機性和突擊性。對於這類測試，在微軟有乙個專門的名稱：「bug bash（bug大掃除）」。 bug bash通常發生在
專案開發各階段（微軟叫里程碑）的末期，比如beta版發布前，劃出乙個專門的時間段（通常1-3天），在這期間所有參與專案的人員，集中全部精力，運用各方面的知識，盡
全部智慧型來搜尋專案的bug。
在微軟還有「bug triage（測試，開發＆專案經理，三方會審）」的制度。對於每個bug，經過會審後不外乎有以下三中歸宿（總體上來說）： （1）被確認為「缺陷性」
bug，這樣的bug必須交開發人員解決，然後由原發現人驗證。 （2）被調整為非「缺陷性」bug，不用開發人員作任何更改，但必須將問題納入產品使用者文件，明確向使用者解釋，
並告訴使用者如何避免和應對。假象：產品的某個功能在系統記憶體嚴重不足的情況下，會暫停工作，並給很多不易被使用者理解的警告資訊。這顯然是個bug（按微軟的標準），正
確的應該是，首先軟體不應該完全停止工作，其次不應該多次警告，第三，警告資訊應簡明易懂，並給使用者以措施和建議。但是考慮到，一方面這種情況在使用者實際使用產品
時發生的機率很低，而另一方面，從開發角度，解決這個問題有很大的技術難度，影響面也太大。這種情況下會把這個bug改為「文本性」bug，也就是要求文字遍寫人員將這一
情況作一技術性解釋，並建議使用者不要將此產品同其他消耗大量記憶體的軟體同時使用。這類的bug在bug bash中很常見，因為大家在這種測試活動中思維方式比較超常。1）類
bug仍然很多，那測試部門很可能需要重新論證原先的測試計畫和測試用例設計，看是否需要增加測試用例。
確定測試計畫有這麼幾個依據：
1）產品的功能。功能的量和複雜性直接影響測試的工作量；
2）質量標準，有公司的標準、行業的標準、市場反饋的標準和客戶要求的標準等；
3）以往的經驗，有以往的產品的經驗，也有個人的經驗。
測試有道 微軟測試技術心得
本文節選自 測試有道 微軟測試技術心得 一書 中國軟體發展數十年，但是規模和產業層次一直處於發展初期。縱觀其原因，主要是因為，軟體人才和軟體工程管理缺乏，尤其是對於大規模的軟體產品研發的工程能 力缺乏。大規模的軟體產品研發需要產品規劃 架構設計 開發及軟體測試 使用者體驗 發布與部署等相關的能力和人...
測試有道 微軟測試技術心得
本文節選自 測試有道 微軟測試技術心得 一書 推薦序1 自從在 webcast 上開始 asp.net 課程以來，基本上每天都會接到幾十封郵件，其中一半郵件問一些很具體的技術問題，另外一半問一些很抽象的職業規劃問題，在這些抽象問題當中即使不使用聚集挖掘模型也可以看出其中最核心的問題，這個大家普遍關心...
測試有道 微軟測試技術心得
本文節選自 測試有道 微軟測試技術心得 一書 中國軟體發展數十年，但是規模和產業層次一直處於發展初期。縱觀其原因，主要是因為，軟體人才和軟體工程管理缺乏，尤其是對於大規模的軟體產品研發的工程能 力缺乏。大規模的軟體產品研發需要產品規劃 架構設計 開發及軟體測試 使用者體驗 發布與部署等相關的能力和人...