四、測試手段
按測試手段來分類：
測試對象的可見度：黑盒測試、白盒測試
狀態：靜態測試、動態測試
測試執行的方式：手工測試、自動化測試
黑盒測試：在事件驅動與用戶需求的指引下，關注輸入的內容，會產生什麼樣的輸出
優點：1.容易實施，不需要關注內部的實現
2.更貼近用戶的使用角度
缺點：1.測試覆蓋率較低，一般只能覆蓋到代碼量的不到40%
2.針對黑盒的自動化測試，複用率較低，維護成本較高。
黑盒測試：關注功能、測試接口，對內部邏輯不考慮
主要測試內容：
1.是否有不正確或遺漏的功能？
2.在接口上，輸入是否能正確的接受？能否輸出正確的結果？
3.是否有數據結構錯誤或外部信息（例如數據文件）訪問錯誤？
4.性能上是否能夠滿足要求？
系統測試更多的使用黑盒測試來實現。
主要設計方法：等價類劃分法、邊界值分析法、錯誤推測法、因果圖法、正交實驗分析法、狀態遷移圖法、流程分析法
白盒測試：針對邏輯結構來測試
主要的邏輯單位：語句、條件、條件組合、分支、路徑
優點：1.迫使測試人員去仔細思考軟件的實現，理解原理
2.可以檢測代碼中的每條分支和路徑
3.揭示隱藏在代碼中的錯誤
4.對代碼的測試比較徹底
缺點：1.昂貴（較高的覆蓋量）
2.無法檢測代碼中遺漏的路徑和數據敏感性錯誤
3.不能直接驗證需求的正確性
主要測試方法：代碼檢測法、靜態結構分析法、靜態質量度量法（標準的質量模型）、邏輯覆蓋法、基本路徑測試法
灰盒測試：（系統組件層）介於黑、白盒測試之間的，關注輸出對於輸入的正確性，同時也關注內部表現
靜態測試：指無須執行被測程序，而是通過評審軟件文檔或代碼，度量程序靜態複雜度，檢查軟件是否符合編碼標準，藉以發現編寫的程序的不足之處，減少錯誤出現的概率
方式：互審、走查、會議（從不正式取向與正式）
動態測試：指通過運行被測程序，檢查運行結果與預期結果的差異，並分析運行效率、正確性和健壯性等。
黑盒測試：偏向於動態測試
白盒測試：靜態測試
手工測試：由專門的測試人員從用戶視角來驗證軟件是否滿足設計要求的行爲。更適合針對深度的測試和強調主管判斷的測試。如：衆包測試、探索室測試等。
自動化測試：使用單獨的測試工具軟件控制測試的自動化執行以及對預期和結果進行自動檢查。如：單元測試、接口測試、性能測試等。
手工測試VS自動化測試
手工測試：易發現缺陷；容易實施；創造性、靈活性；覆蓋量化難；重複測試率低；不一致性、可靠性低；人力資源依賴；
自動化測試：高效率、速度快；高複用率；覆蓋率容易度量；準確、可靠；不知疲勞；機械、發現缺陷率低；一次性投入較大
五、測試模型
按測試模式來分類：瀑布模式、敏捷測試、基於腳本的測試、基於風險的測試、探索式測試等。
瀑布模式：
項目計劃：按階段劃分的檢查點，輸出項目計劃書
需求分析：輸出產品的需求規格說明
軟件實現：產品實現方案，輸出概要設計等
程序開發：輸出程序版本
軟件測試：輸出測試結果、測試報告
集成維護：交給開發商後的後期維護
優點：1.強調需求、設計的作用；2.前一階段完成後，只需關注後續階段；3.爲項目提供了按階段劃分的檢查點，里程碑清晰；4.文檔規範
缺點：1.難以適應需求的頻繁變化；2.項目週期後段才能看到成果；3.強制的里程碑、完成時間點；4.文檔工作量大
V模型：（軟件開發的協作）
W模型：（開發與測試同時進行）
X模型：
H模型：
敏捷測試：（AT）
1.強調從客戶角度進行測試
2.重點關注迭代測試新功能，不在強調測試階段
3.儘早測試，不間斷測試，具備條件即測試
4.強調持續反饋
5.預防缺陷重於發現缺陷
傳統測試與敏捷測試：
傳統測試：1.測試是質量的最後保護者；2.嚴格的變更管理；3.預先的計劃和細節的準備；4.重量級文檔
5.各階段測試嚴格的入口和出口標準
6.更多在迴歸測試時進行重量級的自動化測試
7.嚴格依賴流程執行
8.測試團隊和開發團隊是相對獨立的
敏捷測試：1.開發和測試人員是緊密合作，大家都有責任對軟件負責； 2.變更是可接受的，擁抱變更
3.計劃隨着進展時常調整；4.只需要絕對必要的文檔
5.各迭代之間已經沒有明顯的入口和出口標準；
6.所有階段都需要自動測試，每個人都需要做，是項目集成的一部分
7.流程不再需要嚴格執行
8.團隊合作是無縫隙合作
基於腳本的測試—SBT（Script-basedTesting或ST）
Exploratory Test（ET）探索式測試：完全拋開測試腳本的測試
ST與ET的比較：
ST：系統性強；容易管理、控制；設計在先、執行在後；主要是驗證自己的思路；可預見性
ET：自由靈活；與ST是互補的；執行和設計（思考）並行；不斷和系統交互，帶着問題測試；學習的過程
ET優點：
1.更能激發測試人員的創造性和工作樂趣
2.增加了發現新的或較深入Bug的可能性
3.在較短時間內找到更多Bug以及對SUT（被測系統）作一個快速的評估
4.有利於更加有效地實施自動化
5.更加適用於敏捷項目
6.減少了在簡單、繁複用例上的無謂編寫時間
缺點：
1.測試管理上有侷限性，較難協調和管理
2.對於bug的重複利用和重現作用上有限
3.對測試人員的測試技能和業務知識深度依賴較大
4.只有在SUT已經完全可用的前提下才更有作用
5.ET的生產率很難定義
6.ET本身較難進行自動化
局部探索式測試：輸入（輸出）、狀態（臨時、永久）、代碼路徑（對代碼的覆蓋）、用戶數據（模擬實際用戶數據）、執行環境（操作系統、網絡拓撲、硬件設備、其他系統）
全局探索式測試：漫遊測試法
執行探索式測試：
（1）測試總體思路
（2）學習被測系統、業務邏輯，具體功能
（3）實施階段，完成測試點的覆蓋
（4）發散式測試，更深入地進行測試
（5）總結過程，分析測試有沒有遺漏
基於風險的測試（RBT）
一種基於對軟件失效的風險評估並以此爲指導測試計劃、設計、執行、結果評價的軟件測試類型
類型：質量風險（功能、性能）；管理風險（測試環境、被測系統關聯的第三方系統安全性不夠）
識別風險：
可能性：複雜性，時間壓力，高變更率，技能水平，地理分散度
驗證程度：使用頻率，失效可視性，商業損失，組織負面影響和損賽，社會損失和法律責任
優點：優先測試高風險問題的測試，要準確識別風險
基於模型的測試（MBT）
對需求功能點建模
藉助工具建模實施
主要的MBT工具：
Spec Explorer（Microsoft）
GraphWalker（OpenSource）
Tcases（OpenSource）
Modeljunit（OpenSource）