一、目標
制定完整且具體的測試路線和流程，為快速、高效和高質量的軟體測試提供基礎流程框架。最終的目標是實現軟體測試的規範化、標準化。
二、測試流程及說明
1、流程
2、說明
1）測試的依據：
《需求規格說明書》、《詳細設計》、《概要設計》和介面原型圖。
2）需求分析
（1）測試需求是制訂測試計劃的基本依據，只有確定了的測試需求才能夠為測試計劃提供客觀依據;
（2）測試需求是設計測試用例的指導，只有確定了要測什麼、需要測哪些方面，才能有針對性的設計測試用例;
（3）測試需求是計算測試覆蓋的分母，沒有測試需求就無法有效地進行測試覆蓋。
3）需求評審
參與人員：產品、開發人員、測試人員
產品提出專案需求。
開發人員考慮功能實現的方案與可行性。
測試人員主要是對需求的理解提出疑問，以便才能根據需求寫用例。
4）開發編寫排期
開發人員需要根據需求功能點進行排期，然後將開發計劃傳送給參與專案的所有人員。
5）測試計劃排期
測試人員根據開發計劃，安排測試的具體測試時間，然後將測試計劃傳送給參與專案的所有人員。
6）編寫測試用例
根據詳細的需求文件，開始進行用例的編寫。
7）用例評審
用例評審前，先將用例傳送給相關人員，以便他們先了解用例將對哪些功能進行驗證以及驗證的細節。
在用例評審中，參與人員需要對用例中與實際功能不符合的用例或者格式不規範規用例提出修改建議。
8）提交基線
開發人員完成所有功能後，對自己的功能進行一個自測。自測完成後提交測試進行基線。
9）轉測
轉測是開發把所有需求都開發完成，並自測完畢。
如果預測試不通過，打回，開發組返工，如果通過，測試組開始第一輪系統測試。
(1)第一輪系統轉測試，測試組會執行所有測試用例，發現缺陷提交問題單，並每日彙報測試進展。第一輪測試結束後，測試組將所有的問題單跟蹤提交給開發人員，由他們進行修改。然後對基線後的第二輪進行測試，第二輪會對第一輪中發現的問題進行重點回歸。
(2)在開發修復bug期間，測試組會根據第一輪系統測試對測試組寫的測試用例進行修改和增加，開發修改bug結束，提交一個新的版本給測試組。
首先是迴歸缺陷，然後會在用例中挑選一些優先順序別比較高的用例來進行測試，發現問題繼續提交缺陷進行修復，直到缺陷率低於使用者要求，測試組將進行最後一輪的大版本測試，結束系統測試。具體測試輪次根據版本質量和專案複雜度而決定。
10）測試通過
經過兩到三輪或四輪的測試後，直到沒發現新的問題、或暫時無法解決、或不緊急的問題，通過上級確認，可以通過，編寫測試報告。
11）測試報告
測試報告包括對軟體功能的結論，說明該專案軟體的開發是否達到預定目標，是否可以交付使用。總結測試工作的資源消耗資料：如工作人員的水平級別數量、機時消耗等，記錄測試結果與發現及本專案測試工作所得到的各項輸出的承載體，根據輸入與計劃、要求的對比來總結此次專案所獲得的經驗。
三、Bug的管理流程
1.bug生命週期及狀態（對於bug的狀態要實時更新）
New:（新的）
Assigned（已指派的）
Open（開啟的）
Fixed（已修復的）
Pending Reset（待在測試的）
Reset(再測試)
Closed（已關閉的）
Reopen（再次開啟的）
Pending Reject（拒絕中）
Rejected(被拒絕的)
Postponed（延期）
2.bug等級劃分
1）致命：造成系統崩潰、當機、死迴圈，導致資料庫資料丟失，與資料庫連線錯誤，主要功能喪失，基本模組缺失等問題；
2）嚴重：系統主要功能部分喪失，資料庫儲存呼叫錯誤，使用者資料丟失，以及功能選單不能使用但是不影響其他功能的測試。功能設計與需求嚴重不符，模組無法啟動或呼叫，程式重啟，自動退出，關聯程式間呼叫衝突，安全問題、穩定性等；
3）一般：功能沒有完全實現但不影響使用，功能選單存在缺陷但不影響系統穩定性；
4）建議：介面，效能缺陷，建議類問題，不影響操作功能的執行等。如：錯別字、介面格式不規範，頁面顯示重疊、不該顯示的要隱藏，描述不清楚，提示語丟失，文字排列不整齊，游標位置不正確，使用者體驗感受不好，可以優化效能的方案等。
3. 提交bug的書寫規範
bug包含的內容：包含了所屬專案，所屬模組，版本，指派給相應的人員，BUG標題，步驟，優先順序，以及bug環境、附件（可以附上出現的缺陷截圖）等。
注意事項
1）開發、測試雙方有爭議的bug，必須與產品確認才可進行下一步的操作；
2）測試需及時驗證已修復bug；
3）誰提交的bug要由誰驗證關閉。
四、測試中輸出的文件
1、測試計劃
內容：
- 引言：目的、背景、範圍、定義、參考資料；
- 測試內容：測試功能清單；
- 測試規則：進入準則，暫停/退出準則、測試方法、測試手段、測試要點、測試工具；
- 測試環境：硬體環境、軟體環境、特定測試環境要求；
- 專案任務：測試規劃，測試設計，測試執行準備，測試執行，測試總結；
- 實施計劃：工作量估計、人員需求及安排、進度安排、其它資源需求及安排、可交付工件；
- 風險管理。
2、測試方案
內容：
- 專案簡介：概括的對這個系統做一個描述，讓別人知道系統是做什麼的，簡潔而有重點；
- 測試目標：對於本次系統測試要達到什麼樣的標準，缺陷率應該控制在多少以內，定一個合理的目標；
- 測試策略：這個部分主要包括（1）資料流圖描述；（2）本專案的測試難點；（3）本專案測試的關鍵點；（4）需要特別申請的測試資源；（5）效能測試；
- 測試的內容和方法：這部分主要包括：（1）場景測試；（2）功能測試；（3）功能模組銜接測試；（4）介面測試；（5）介面測試；（6）相容性測試；（7）效能測試；（8）相容性測試；（9）安全性測試；（10）可靠性測試。
- 測試資料：包括（1）系統引數；（2）存量環境資料；（3）業務引數；（4）交易引數；（5）介面文字資料；
- 測試環境：（1）各應用測試環境的版本基礎；（2）測試環境硬體要求；（3）測試環境連線圖；
- 測試工具及其模擬器：根據專案實際是否使用
- 測試人員安排：
- 測試計劃：（1）主要工作安排；（2）測試輪次安排；（3）批量計劃；
- 人力資源評估；
- 風險及依賴。
3、測試用例
1）內容
包括用例編號、測試專案、測試標題、預置條件、測試輸入、測試步驟、預期結果、實際結果等。
2）用例級別劃分
對測試用例進行優先順序的劃分，一般需要從三個方面考慮：
P1：確保系統基本功能及主要功能的測試用例
P2：確保系統功能的完善方面的測試用例
P3：關於使用者體驗，輸入輸出的驗證以及其他較少使用或輔助功能的測試用例對應的，我們可以對測試用例分為三個級別：高、中、低
高（優先執行）：即關鍵路徑的測試用例，包括最常執行的功能、基本流程的輸入以及介面資料有效性校驗作為高階別的測試用例；若該級別的測試用例完全執行通過，則表示該軟體功能漸趨穩定；
中（次級執行）：即可接收級測試的用例，包括不常執行的功能、異常流程的輸入、邊界值以及異常資料的輸入作為中等級別的測試用例；若該級別的測試用例完全執行通過，則表示該軟體可以進行釋出了；
低（最後執行）：即建議執行的測試用例，也就是說該級別的測試用例不是不重要，而是該級別的用例在整個專案的生命週期內不是常常被執行，包括：GUI、介面顯示、錯誤資訊提示不統一、可用性、壓力和效能測試等。
4、測試報告
內容：
1.概述：一般會在概述中新增專案背景、需求描述等資訊；
2. 測試過程：主要包含評審記錄、測試範圍、測試用例；
3. 功能實現清單：列出是否已按本次測試計劃實現功能；
4. 測試統計：包括資源統計、執行情況、問題統計、問題列表、遺留問題；
5. 測試總結：主要總結本次測試測了哪些內容、用例覆蓋程度、bug解決程度等，以及最終是否決定通過本次測試。