具體解釋如下：
單元測試：這里的單元測試進行的是編寫的代碼功能檢測，一般由研發員互相進行測試，測試員可參與的有代碼審查，利用工具進行復雜度分析等，比如Logiscrope等，一般很少的中小型公司會進行代碼走查，因為這個很費人力，特別是在人力資源緊張的時候（開發嵌入式軟件除外）。
模塊內功能測試：現在的軟件研發都是分模塊進行的，每人負責一些模塊，只有某些比較核心的模塊才由幾個人共同完成，但是即使這樣，一般也是將這些核心模塊進行細分，也就是說每人完成模塊內的某些功能，因此，完成可以從具體的功能入手，等每個功能一編譯通過能正常運行就可以提交驗證。此過程已經可以開始進行UI測試，為的是是界面模式統一。很多時候，我們都將UI測試忽略或者將之歸類入到系統測試階段進行。其實，像這么“雞肋”的東西是越早進行規范越能節省時間，不單單是測試員的時間，也是研發員的。在這里的測試用例可以從UML中獲取行為圖，參考進行編寫本模塊的用例。
模塊間功能測試：這個步驟對應于集成測試階段，根據目前的測試經歷推薦使用從底向上的模塊集成，這個相對于從頂向下的方法便利于貼近項目的研發進度，節省人力，能更好的定位缺陷被暴露位置，此時的測試用例也不用寫的太復雜，對測試員有個循序漸進的加深認識的過程。測試用例可以從UML中獲取交互圖，從中編寫模塊間的用例。
軟件系統測試：此階段的特征是--核心功能已完成，其余模塊編碼80%完成（用80%只是代表此時已經無其他技術障礙，可測的功能基本可以進行）。這時，可進行的測試有UI測試（最后一次的UI測試，以后無特殊需求可以少測）、安全測試（一般類應用軟件不如特殊應用軟件般對安全性有過高的要求，因此可以放在項目中后期進行）、性能測試等。另外，在此測試階段中包含了Alpha版的發布與測試�？梢岳谜环�、場景法互相補充來擴充完善測試用例。本人認為，場景法的利用可以從業務流程中獲取，這個比較主觀，正交法就相對客觀些，這兩者的互補性將可以使測試用例更完善。
Beta測試：發布一個版本提交用戶使用，直到驗收開始的這一階段所進行的用戶使用測試。這時，可進行安全測試、性能測試等。
正式驗收測試：依據之前各個階段的測試安排的最為周密的一次系統測試，提交測試報告，簽字確認通過，測試組正式退出該項目，以后用戶的的新需求或者新版本發布所需的測試通過測試需求單進行提交于測試組進行安排測試。而在此項目實施了之后發現的Bug由維護小組（一般是技術支持人員）反饋給研發員進行軟件的Bug修復。
以上的步驟糅合了基于W模型、H模型、UML用例模型還有些測試用例編寫的一些具體應用，特別突出的是測試部的獨立性。一般的，研發在概要編寫與詳細設計時已經開始某些模塊的某些功能的編寫，而這些，都會反應在UML圖中，因此，可以從UML中獲取靜態圖，從而進行單元測試的用例編寫；另外，能夠先完成的功能編寫耦合性一般不高，而且很多只是與數據庫進行交互即可的功能在完成時就可以驗證其正確性，這些測試用例也可以從UML圖中的行為圖或使用了某些工具（PB、Erwin等）設計出來的數據庫模型獲取要測試的用例；其余的階段類似。
假若要套用CMMI等級的話，這里要求企業內部至少滿足CMMI-2級（管理級）。即使到今天，相信還有不少的企業還處于缺乏項目開發文檔，測試介入于編碼即將完成或者是已實施過程中的階段。這就又要求測試員兼任起SQA的職責，除了建立一套比較完整的測試管理流程外還要改進研發的管理流程。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/