針對每個測試級別，如下活動將被適當?shù)膱?zhí)行：
一、創(chuàng)建測試策略
輸入：
·要求的硬件和軟件組件的詳細說明，包括測試工具(測試環(huán)境，測試工具數(shù)據(jù))。
·針對測試和進度約束(人員，進度表)而需要的資源的角色和職責說明
·測試方法(標準)
·應用程序的功能性和技術(shù)性需求(需求，變更請求，技術(shù)性和功能性設(shè)計文檔)
·系統(tǒng)不能夠提供的需求(系統(tǒng)局限)
輸出：
·已批準和簽署的測試策略文檔，測試計劃，測試用例
·需要解決方案的測試項目(通常要求客戶項目的管理層協(xié)調(diào))
過程：
·測試策略是關(guān)于如何測試系統(tǒng)XYZ的正式描述，要求開發(fā)針對所有測試級別的測試策略。測試小組分析需求，編寫測試策略并且和項目小組一起復審計劃。
·測試計劃應該包括測試用例和條件，測試環(huán)境，與任務相關(guān)的測試，通過/失敗的準則和測試風險評估。測試進度表將識別所有要求有成功的測試成果的任務，活動的進度和資源要求。
二、創(chuàng)建測試計劃/設(shè)計
輸入：
·已批準的測試策略文檔。
·如果測試工具適用，自動化測試軟件和以前開發(fā)的測試腳本
·作為一種測試的結(jié)果(測試文檔問題)，測試文檔中沒有說明的問題
·從概要和詳細設(shè)計文檔(軟件設(shè)計，代碼和復雜的數(shù)據(jù))中導出的對軟件復雜性和模塊路徑覆蓋的理解
輸出：
·設(shè)計時發(fā)現(xiàn)的問題反饋給開發(fā)人員(軟件設(shè)計，代碼問題)
·已批準的測試場景，條件和腳本(測試設(shè)計，用例和腳本)
·測試數(shù)據(jù)
過程：
·通過復審發(fā)布版本的功能需求和準備能夠更好的拆分為測試腳本的業(yè)務功能邏輯集合，準備測試場景和用例。測試將定義為測試條件，用于測試的數(shù)據(jù)和期望的結(jié)果(數(shù)據(jù)庫更新，文件輸出，報告結(jié)果等等)。將可能在應用程序中出現(xiàn)的既普通又異常的情況描繪為測試場景。
·項目開發(fā)人員將定義單元測試需求和單元測試的場景/用例。在集成和系統(tǒng)測試之前，開發(fā)人員同時也負責執(zhí)行單元測試用例。
·在開發(fā)人員和客戶的協(xié)助下，測試小組將開發(fā)集成和系統(tǒng)測試的測試場景、用例。驗收測試用例將由客戶在項目和測試小組的幫助下開發(fā)。
·通過使用測試腳本執(zhí)行測試場景。腳本將定義用于執(zhí)行一個和多個測試場景的一系列步驟。測試腳本通常描繪在一般的系統(tǒng)操作中會出現(xiàn)的事務或過程。測試腳本包括用于測試過程或事務的特定數(shù)據(jù)。測試腳本將覆蓋多個測試場景并且包括運行/執(zhí)行/周期信息。測試腳本映射需求和用于保證任何測試都是在范圍內(nèi)的追溯矩陣。
·在測試之前，捕捉并且基線化測試數(shù)據(jù)。這些數(shù)據(jù)將作為單元和系統(tǒng)測試的基礎(chǔ)和在可控的環(huán)境下執(zhí)行系統(tǒng)功能。為了以后的對照，一些輸出的數(shù)據(jù)也被基線化。在回歸測試時，基線化的數(shù)據(jù)用于支持以后的系統(tǒng)維護。
·為評定應用程序的就緒情況、環(huán)境和被測試的數(shù)據(jù)，應召開測試準備會議。為了指出發(fā)本版本的入口標準狀態(tài)，應創(chuàng)建測試就緒文檔。
三、執(zhí)行測試
輸入：
·已批準的測試文檔(測試計劃、用例、程序)
·如果適用測試工具，自動化測試軟件和編寫好的腳本
·設(shè)計的變更(變更請求)
·測試數(shù)據(jù)
·測試和項目組的可用性(項目人員，測試小組)
·概要和詳細設(shè)計文檔(需求，軟件設(shè)計)
·通過配置/構(gòu)建人員能夠完全轉(zhuǎn)移到測試環(huán)境(單元測試過的代碼)的開發(fā)環(huán)境
·測試就緒文檔
·修訂文檔
輸出：
·代碼的變更(測試修復項)
·作為一種測試的結(jié)果(測試文檔問題)，測試文檔沒有說明的問題
·設(shè)計時發(fā)現(xiàn)的問題，反饋給開發(fā)人員和客戶(需求，設(shè)計，代碼問題)
·測試事故的正式記錄(問題跟蹤)
·為向下一級別轉(zhuǎn)移而準備的基線化包(已測試的源代碼和對象代碼)
·測試結(jié)果的日志和總結(jié)
·已批準和帶有修訂測試交付項的簽署文檔(已更新的交付項)
過程：
·在執(zhí)行階段中應召開Checkpoint 會議。(如果由需要，)每天應召開Checkpoint 會議處理和討論測試中的問題，狀態(tài)和活動。
·通過采用系統(tǒng)的手段跟進測試文檔來完成測試的執(zhí)行。當執(zhí)行測試程序的每一個包時，為了記錄程序的執(zhí)行和測試程序找出的任何缺陷，應該將問題記錄到測試執(zhí)行日志中。測試程序執(zhí)行后的輸出當作測試結(jié)果。
·為了確定是否可以得到預期的結(jié)果，測試結(jié)果應該由適當?shù)捻椖拷M員評估(，適合于測試的所有級別)。記錄并和軟件開發(fā)經(jīng)理/程序員討論所有差異/異常，為了以后的調(diào)查和解決應該將它文檔化(每個客戶可能有不同的記錄日志和報告bug/defect的過程，通過Configuration Management (CM)小組校驗這些過程)。通過/失敗的準則用來確定問題的嚴重級別，結(jié)果記錄到測試總結(jié)報告中。
·根據(jù)客戶的風險評估來定義在系統(tǒng)測試中發(fā)現(xiàn)的問題嚴重級別并記錄到他們選擇的跟蹤工具中。
·基于問題的嚴重級別有目的的修復并提交到測試環(huán)境中。被修改的問題應進行回歸測試并將沒有問題的修復項轉(zhuǎn)移到新的基線中。在測試完成后，測試組的成員應準備一份總結(jié)報告。總結(jié)報告要由項目經(jīng)理，客戶，SQA和/或測試組長復審。
·在證實達到一個指定的測試級別后，配置經(jīng)理應根據(jù)配置管理計劃中的要求整理發(fā)布的軟件組件并轉(zhuǎn)移到下一個測試級別。軟件只有在客戶正式驗收之后才可以轉(zhuǎn)移到生產(chǎn)環(huán)境中。
·測試小組復審在測試和更新文檔時發(fā)現(xiàn)的測試文檔問題。一些問題可能是由于技術(shù)性和功能性之間不一致或修改所造生的。