從軟件質量保證上來劃分測試，測試可以劃分成靜態測試和動態測試。靜態測試就是指不運行被測程序本身，僅通過分析或檢查源程序的文法、結構、過 程、接口等來檢查程序的正確性，靜態測試可以分為代碼審查、代碼走讀、文檔審查等行為。動態測試是指通過運行被測程序，檢查運行結果與預期結果的差異，并 分析運行效率和健壯性等性能的測試過程。從那條參考的時間軸上來看，動態測試和靜態測試可以發生在整個軟件生命周期的全過程。關于靜態測試和動態測試的更 多討論在我的博文《靜態測試和動態測試》中有比較詳細的討論。

　　按照測試技術（test techniques）劃分，測試可以劃分為白盒測試、黑盒測試和灰盒測試。在這套理論的介紹中，后面會有專門的一節來介紹這三種測試。其中灰盒測試是指 白盒和灰盒測試相混合的一種測試。從那條參考的時間軸來看，白盒測試發生時間比較靠前，黑盒測試發生時間比較靠后，而灰盒測試發生的時間介于2者之間。

　　按照測試階段（test levels）劃分，測試可以劃分單元測試、集成測試、系統測試、系統集成測試、用戶驗收測試和維護測試，這一劃分是根據軟件生命周期和測試生命周期中自然形成的階段進行劃分的，當然越靠前的測試越先進行。

　　從第二幅圖可以看出，單元測試和集成測試是由開發團隊來做的，而集成測試和系統集成測試是由測試人員來做的，用戶驗收測試是由用戶和測試團隊來 做的，及時用戶不參與，測試人員也是在用戶的角度進行測試的，這里沒有做維護方面的測試。單元測試是指針對各個單元模塊進行的測試；集成測試就是由更多的 已經完成了單元測試的測試單元構成的測試，集成測試仍然不是在一個完整的測試過程上測試；系統測試是程序第一次以一個完整的個體形式進行運行而進行的測 試；而系統集成測試在系統測試的基礎上，還要關注整個軟件系統與外界的交互，比如調用打印機，比如與本軟件系統以外的其他系統進行交互；用戶驗收測試也就 是通常大家所說的UAT，這個時候整個軟件系統已經有了比較好運行狀態，可以接受用戶驗收測試啦。每一階段的結束被看做是輸出，都是作為下一階段的輸入， 在測試流程上有明確的定義什么這些輸入和輸出的標準，后面的章節會對這些標準做詳細的闡述。每一階段的測試，都應該包含前一階段的測試內容，也就是前一階 段的測試內容，但是側重點不一樣，從紅色的箭頭和紅色的邊框可以看出各個階段的測試側重點。比如UAT過程中遇到了不屬于UAT測試項的bug，當然也是 屬于UAT的內容。

　　按照測試類型（test types）劃分，這些劃分包含審計和控制、文檔和過程、功能、需求、接口、回歸測試、備份和恢復、工作流、性能、壓力、容量、變換、安裝、錯誤處理、并 行、事物流、可用、UI、可操作性和安全性等方面的測試。具體的一些測試類型的定義，可以從網上搜索得知。

　　各個測試類型可以發生在各個的測試階段，從第三幅圖可以看出，每個測試階段所涉及到的測試類型，而靜態測試應該和這些測試階段并列開來，也可以 理解成這些測試階段都是屬于動態測試的。從橫行可以看出錯誤處理和回歸測試發生在所有的測試階段，因為每個階段都會有bug，有bug就會有回歸，當然回 歸測試會發生在各個測試階段。從豎行上可以看出，系統測試涉及到了最多的測試類型，因為這個時候軟件系統是第一次以一個完整的個體而運行，需要的測試方面 是最多的。也并不是所有階段都要進行所有的類型測試。

　　從網上可以搜索到很多關于單元測試的定義，比如百度百科中就有詳細的介紹。而此理論中關于單元測試的內容有：

　　單元測試是對新的或者更改過的代碼模塊進行的初步測試。它驗證程序或模塊的內部邏輯和程序規范。

　　開始點：單元測試開始在開發階段，當編碼已經完成，單元測試計劃已經被有關各方已批準。

　　結束點：單元測試結束后，所有的測試案例被成功執行，沒有嚴重缺陷1或2。一項行動計劃已經被記錄在案，以解決還未解決的其他缺陷。

　　單元測試的作用：單元測試有助于早期識別和修復缺陷，早期消除單元模塊的不確定性。

通過測試程序的各個部分，然后再測試其各部分的總和，集成測試就更簡單啦。

　　相關活動：測試計劃和測試用例審查，由有關各方批準的基線控制之下；

按計劃執行單元測試用例；通過跟蹤需求變更來驗證測試覆蓋面；進行缺陷分析；完成單元測試報告。

　　單元測試的評估有：代碼覆蓋率的百分比，符合組編碼標準，圈復雜度，行代碼，路徑，參數，缺陷密度。

集成測試　　

從網上可以搜索到很多關于集成測試的定義，比如百度百科中有詳細的介紹，而此理論中關于集成測試的內容有：

　　集成測試驗證多個已經完成了單元測試的模塊的執行。所測試的應用程序通常不連接到系統中的其他應用程序。

子系統模塊的通信測試是在一個控制和隔離的環境。

　　開始點：集成測試開始時，單元測試已經順利完成，當集成測試計劃已經被有關各方已批準，并且在基線控制之下。

　　結束點：集成測試結束后，所有的測試案例的成功執行，沒有嚴重缺陷1或2。一項行動計劃已經被記錄在案，以解決所有還未解決的缺陷。

　　集成測試的作用：集成測試有助于較早的識別和修復中缺陷，降低了成本。它也減輕了系統測試過程中的風險。

　　相關活動：測試計劃和測試用例審查，由有關各方批準的基線控制之下；

按計劃執行集成測試用例；通過跟蹤需求變更來驗證測試覆蓋面；進行缺陷分析；完成集成測試報告。

　　集成測試的評估有：成本和進度偏差，缺陷，生產力，效率和測試覆蓋度。

　　圈復雜度一種代碼復雜度的衡量標準，中文名稱叫做圈復雜度。

在軟件測試的概念里，圈復雜度“用來衡量一個模塊判定結構的復雜程度，數量上表現為獨立現行 路徑條數，即合理的預防錯誤所需測試的最少路徑條數，圈復雜度大說明程序代碼可能質量低且難于測試和維護，根據經驗，程序的可能錯誤和高的圈復雜度有著很 大關系”。

　　在這套理論中，大多用的是缺陷（defect）一詞，認為缺陷（defect）包含的范圍大于bug所代表的意思，認為軟件一切不足的地方都是 可以當做defect處理，而Bug所代表的內容比defect更少一些。其實現在各個公司有各自的叫法，還有叫issue的，但是意思都是一樣的，都是 指軟件的不足之處。此套理論的后面部分都是稱呼為缺陷（defect）。

　　以后介紹的各種測試的定義，都是按照圖中所展示的那樣結構來展示。左上角是一堆相關的測試類型或者測試階段，第一頁的最下面一排是關于這個測試類型中的各種文檔，相關的文檔并不一定全展示完了。第二頁的右上角都涉及到了這個測試階段或者測試類型所常用到的測試工具。

　　“參與者”里面詳細地介紹了這個測試階段有哪些測試角色參與，帶點的測試角色就被包含在這個測試中，在實際工作中，各個角色之間可以由同一人擔 當。這套理論中，測試團隊中都有一兩個叫“Test architect”的人，測試架構師是團隊中的關鍵人物，類似于系統架構師或者系統分析師，他的作用是參與系統的研發與架構，分析系統與功能模塊，找出測試的難點與關鍵點，決定測試工具環境平臺等方面的主意，在技術上主導團隊的測試過程。

　　第二頁的右下角有相關的評估方面，這些評估方面就是測試用例設計的依據。

　　單元測試和集成測試都是由開發人員完成，在寫完代碼后進行的。單元測試和集成測試都有明確定義的開始點和結束點，并且測試結束的時候都要提供相應的輸出。測試開始的時候，測試計劃都已經被各方批準了才開始，各方是項目經理、測試經理、開發經理、需求分析負責人甚至是客戶或者投資者。當這個階段的 測試過程中未出現嚴重性為1和2的defect的時候才能結束此階段的測試，并且未解決的所有defect都應該被記錄下來，并且做好何時解決的計劃。一個缺陷被解決得越早，越能節省成本；一個發現的缺陷越到后面才來修復，需要更多的成本。

　　很多時候，并沒有把單元測試和集成測試分開來做，而是一起當做單元測試來進行的。

　　相關活動：測試計劃和測試用例審查，由有關各方批準的基線控制之下；按計劃執行用戶驗收測試用例；通過跟蹤需求變更來驗證測試覆蓋面；進行缺陷分析；完成用戶驗收測試報告。

　　系統測試的評估有：成本和進度偏差，缺陷，生產力，效率和測試覆蓋度。

　　可操作性測試的內容是：

　　可操作性測試驗證應用程序或系統可以在生產環境中運行。這是一個動態的測試階段，其中系統的所有驗證操作都在真實或模擬出來非常真實的生產環境中發生。可操作性測試考慮的是性能，資源消耗和符合標準等因素。

　　開始點：用戶驗收測試開始于成功的上一階段的用戶驗收測試的結束，用戶驗收測試計劃已經被有關各方已批準，并且在基線控制之下。

　　結束點：一旦被測系統符合測試計劃中規定的結束標準，測試便結束。

　　用戶驗收測試的作用：確保軟件產品的正確交付和直到軟件產品的正確部署。避免在生產環境（內部和外部）中產生可操作性方面的業務缺陷。

　　相關活動（由技術支持團隊實施和驗證如下活動）：部署和備份計劃；故障切換和恢復計劃；緊急中斷/修復計劃；在run books中更新生產支持；更新幫助數據。

　　系統測試的評估有：成本和進度偏差，缺陷，生產力，效率和測試覆蓋度。

　　用戶驗收測試（UAT）測試方面的知識，可以在網上找到很多。據我了解，很多公司和很多測試人員都知道這一測試階段。包括我在內，UAT只是處 于一個系統集成測試之后的測試階段，應該所有測試用例中涉及到和沒涉及到的defect和bug和一切看不順眼有問題的地方都可以當做測試得到的問題。 UAT是請實際的用戶參與測試或者測試人員站在用戶的角度去思考和測試系統，而很多時候并沒請實際用戶參與，只是測試人員站在用戶角度去思考和測試。系統 測試和系統集成測試涉及到的很多測試類型，將不再在這個測試階段進行。這個測試階段結束的時候，將很接近實際生產中的軟件情況啦，客戶很可能就決定是否接 受這個軟件結果。

　　在前面章節中講解測試階段的時候沒到可操作性測試，而我用介紹維護測試做了代替。可操作性測試應該是UAT結束后，從項目團隊到系統部署的這個 過程，由測試人員和技術支持團隊（也就是通常所說的售后技術工程師）在模擬的環境中進行部署操作或者直接到客戶那邊的實際環境中進行部署。這個階段要做部 署、回復、故障切換、緊急中斷和修復等在實際運行中的計劃。而且這個階段使用到的工具也是部署、監控和維護相關的工具。

　　最后階段當然是系統部署和交付給客戶后的維護過程，維護測試就是在這個階段之后。產品部署后，客戶方面有人會用監控和管理系統的運行，當出現 defect或者異常等情況，售后技術支持工程師會到客戶那邊進行處理。當售后技術工程師解決不了的話，會交給項目相關的支持團隊，這個團隊中就包括維護 測試團隊。所以很多很大的系統（比如銀行的系統）都會有專人就行監控和管理，也會有一個專門的技術團隊為這個系統服務。當系統出現defect的時候，交 給這個團隊修改和回歸測試，然后再以補丁的形式給系統更新。當系統有一些新的小需求的時候，由這個團隊來開發和測試，然后交付。這個團隊可以由原來開發時 候留下部分人員組成，當然也可以現招聘，可以在招聘中遇到招聘項目維護團隊的職位。