一、 新產品或工程管理流程
1、 需求調研
在軟件需求分析階段，測試人員從軟件生命週期的需求階段就開始介入在需求階段的測試人員參與軟件需求調研，以測試角度分析需求的可測性，可構思將來對其測試的方法、原則等；同時全面瞭解系統需求，從客戶角度考慮軟件測試需要達到的驗證狀態，即何些功能點需重點測試、何些無需，以便將來制定測試計劃。
2、 制定測試計劃
進行每一種測試之前，測試負責人要根據“產品定義書”及“總體設計說明”和“詳細設計文檔”制定“測試計劃”，制定總體的測試計劃，詳細闡明本次測試目的、對象、方法、範圍、過程、環境要求、接受標準以及測試人員和測試時間等內容，“測試計劃”經過審查通過，才能實施。
3、 需求Review
開發在完成軟件需求分析之後，會提交需求分析文檔，測試人員根據需求調研所瞭解的需求以及產品需求說明文檔等資料，對需求分析文檔進行Review，檢查文檔是否滿足了需求，是否與需求一致等等。
4、 設計Review
在軟件分析設計階段，測試人員參與設計討論，瞭解系統的實現方式和原理，並對概要設計和詳細設計提出自己的見解。設計結束之後，開發提交概要設計文檔和詳細設計文檔，測試人員對設計進行Review，檢查設計規劃和實現方案是否合理，如果不合理，存在的問題是什麼、如何改進等等。
5、 測試設計
在設計測試方案時，首先分解測試內容，對於一個複雜系統，通常可以分解成幾個互相獨立的子系統，正確地劃分這些子系統及其邏輯組成部分和相互間的關係，可以降低測試的複雜性，減少重複和遺漏，也便於設計和開發測試用例，有效的組織測試，將系統分析人員的開發分析文檔加工成以測試爲角度的功能點分析文檔，重要的是描述對系統分解後每個功能點逐一的校驗描述，包括何種方法測試、何種數據測試、期望測試結果等。然後以功能點分析文檔作爲依據進行測試用例的設計，設計測試用例是關係到測試效果以至軟件質量的關鍵性一步，也是一項非常細緻的工作，根據對具體的北側系統的分析和測試要求，逐步細化測試的範圍和內容，設計具體的測試過程和數據，同時將結果寫成可以按步執行的測試文檔。每個測試用例必須包括以下幾個部分：
（1） 標題和編號
（2） 測試的目標和目的
（3） 輸入和使用的數據和操作過程
（4） 期望的輸出結果
（5） 其他特殊的環境要求、次序要求、時間要求等
6、開發測試工具和準備測試數據
在軟件測試中，爲了提高測試工作的效益和質量，只要條件許可，應儘可能採用計算機自動或半自動測試的方法，利用軟件工具本身的優勢來提高工作效率。
7、測試執行
當所有必需的測試準備工作都已完成，並且產品已經開發完畢並提交測試，則可以按照預定的測試計劃和測試方案逐項進行測試。在測試過程中發現的任何與預期目標不符的現象和問題都必須詳細記錄下來，填寫測試記錄。爲了能準確的找出問題產生的原因，及時的解決問題，保證測試工作的順利進行，一般來說所發現的問題必須是能夠重視的。
8、迴歸測試
在測試中發現的任何問題和錯誤都必須有一個明確的解決方法。一般來說，經過修改的軟件可能仍然包含着錯誤，甚至引入了新的錯誤，因此，對於修改以後的程序和文檔，按照修改的方法和影響的範圍，必須重新進行有關的測試。另一方面，對於版本更新後的軟件也必須進行同樣的測試過程。
9、測試分析報告
測試結束後要及時地進行總結，對測試結果進行分析，由測試負責人提交“測試分析報告”。
10、產品發佈
測試完畢，整理產品發佈包和相關文檔併發布。對於新產品來說，必要的文檔必須包括：
（1） 安裝操作手冊
（2） 產品白皮書
（3） 管理維護手冊
（4） 用戶操作手冊
（5） 測試報告
11、版本控制
新版本軟件發佈之後，馬上對代碼進行質量控制。
（1） Build Master給新版本的源代碼打一個cvs tag，方便代碼回滾check out。比如，發佈版本爲p2p3.3.2，則給該軟件源代碼也打一個與發佈版本相同名字的tag p2p3.3.2。這樣做的一個好處是，在目前的軟件的基礎上做了修改併發布新的版本後，如果需要check out某個版本的源代碼，則可以通過這個版本的tag來check out，代碼的修改可以在該版本上進行。
（2） Build Master對新發布的軟件源代碼進行cvs lock，不允許開發人員在軟件發佈之後commit源代碼，直到有新版本需求修改再給開發人員開放commit權限。這樣做的好處是避免開發人員隨意修改和commit源代碼，確保源代碼服務器上的源版本版本與當前最新的發佈版本一致。
二、 工程維護管理流程
1、 收集新需求：新功能和不緊急的故障，其代碼的修改操作不必馬上進行，取而代之的是做好新需求與故障統計；對已經確認的故障也可以先在bug管理系統報bug，但只是記錄，不需求馬上修改。當然了，對於緊急的工程故障，需要馬上修改和測試。
2、 確認新需求：與工程人員或客戶或產品經理確認新需求，確保需求被理解正確。
3、 需求討論：當需求與故障積累到一定數量或者工程有新版本需求，進行一次發佈測試，在新版本開始修改之前把近期積累的需求與故障整理，與相關開發人員、測試人員、項目經理和測試經理討論，確認哪些新功能可以實現、新功能的實現方法與業務流程、新功能開發修改時間、測試版本、測試時間與發佈時間。
4、 在bug跟蹤管理系統報bug：確認所有需要修改的新功能和需求錄入bug跟蹤管理系統，並在bug跟蹤管理系統中詳細描述新功能需求和解決方法，同時整理相關bug列表，交付開發修改。
5、 制定測試計劃：
A、 根據用戶需求，定義並完善測試需求，作爲測試的標準
B、 確定重點測試事項，哪些功能需要重點測試
C、 測試時間計劃，並詳細計劃具體測試任務與時間
D、 風險說明
E、 測試準備，提前對測試環境和測試資源進行準備
F、 發佈具體時間
G、 資源需求：包括測試人員、硬件需求、軟件需求和培訓計劃
6、 編寫測試案例：根據功能需求編寫測試案例
7、 測試開發：開發自動測試腳本，補充自動測試案例
8、 測試實施：按照測試計劃進行測試，發現並申報bug
9、 測試評估：
A、 哪些需求通過了測試
B、 有哪些遺留問題
C、 測試效率評估
D、 開發質量度量和評估
E、 並根據評估編寫測試報告
10、 發佈新版本：
A、 編寫新功能文檔，給工程提供新功能說明
B、 編寫升級文檔，給工程提供升級參考方案
C、 軟件發佈，包括新版本軟件、新功能文檔、升級文檔和測試報告
11、 代碼版本控制：新版本軟件發佈之後，馬上對代碼進行質量控制。
A、 Build Master給新版本的源代碼打一個cvs tag，方便代碼回滾check out。比如，發佈版本爲p2p3.3.2，則給該軟件源代碼也打一個與發佈版本相同名字的tag p2p3.3.2。這樣做的一個好處是，在目前的軟件的基礎上做了修改併發布新的版本後，如果需要check out某個版本的源代碼，則可以通過這個版本的tag來check out，代碼的修改可以在該版本上進行。
B、 Build Master對新發布的軟件源代碼進行cvs lock，不允許開發人員在軟件發佈之後commit源代碼，直到有新版本需求修改再給開發人員開放commit權限。這樣做的好處是避免開發人員隨意修改和commit源代碼，確保源代碼服務器上的源版本版本與當前最新的發佈版本一致。
感謝360doc的“迷失咖啡屋”的分享！！！