開發人員測試： 單元測試：隔離良好的、原子性質的、相互獨立的：使用xUnit框架開發 集成測試： 互相隔離的可能改變系統狀態的測試，比如，把數據保存到數據庫，寫文件……集成測試并不像聽上去那樣代表著功能需求�？梢允褂脁Unit編寫�！ 〖蓽y試會檢查代碼與第三方工具、或者其他層次代碼的集成情況，比如說，業務邏輯層依賴于數據訪問層�！ �功能測試：（也被叫做系統測試） 把系統的某部分當成整體來檢驗的測試，通常代表了一些功能需求。這些測試可能會改變系統的狀態�！ ‘a品所有者測試： 驗收測試：也是功能測試，不過輸入和輸出可以被非技術人員——產品所有者驗證�！� John Donaldson分享了關注于測試角色和測試類型的多維模型： “我喜歡你給出的測試視圖。但是我認為這是更大模型的一個實例，在那個模型里面，你（至少）擁有執行者－角色和測試類型�！ 绦姓撸巧洪_發人員、測試人員、QA、用戶、出資方等等�！ y試類型：單元測試、集成測試、功能測試、系統測試、驗收測試、滲入（soak）測試、冒煙測試等等�！ ≡诰唧w的情景下，某種角色會執行某些測試。但是，換個項目這種關系就可能不一樣�！� Dale Emery提議：“對于不清楚所寫測試的類型這種情況，應該將其定義為一種代碼壞味道，它說明缺乏清晰度。與此同時，一個測試可能會被歸類于多種類型，重要的是你當前視角的重點： 我所認為的挑戰在于：根據關注角度的不同，任何測試都有很多種理由充分的分類方法。人們可以從很多角度出發來給測試歸類。我在這篇文章中指出了一些： 所以我對區分測試到底屬于什么“類型”并不是十分感興趣，我更關注特定測試在特定時刻該從何種角度來區分，而且這對我也非常重要。我經常思索如下的問題： * 什么“單元”是由這個測試界定，并對之進行測試的？（什么系統、子系統、對象、協作......）——這個測試界定并測試了什么特性？ * 這個測試的主要關注對象是誰？誰最關心這個測試的運行結果？ * 基于該測試的運行結果，會做出何種決定？” Charlie Poole詳細分析了Calos的分類，進而建議到： “在我看來，最重要的區別在于開發人員關注的測試和客戶關注的測試�！ ∮懻撏宫F了這樣一個事實：測試的分類可能令人非常迷惑，特別是對初學者而言。大多數觀點認為需要從特定角度出發來給測試歸類，分類類型是否恰當則依賴于當時的關注點和場景�！�
文章來源于領測軟件測試網 http://www.kjueaiud.com/