注：非通用標準流程，僅為大家提供參考。

目標

制定完整且具體的測試路線和流程，為快速、高效和高質量的軟體測試提供基礎流程框架。最終目標是實現軟體測試規範化、標準化。

測試流程說明

流程圖

需求分析
需求分析由SA制定，要求細化每一個功能的細節，每一個按鈕的位置以及邊界範圍，對於稍大或稍複雜需求要求建模。
（1）測試需求是制訂測試計劃的基本依據，只有確定了的測試需求才能夠為測試計劃提供客觀依據;
（2）測試需求是設計測試用例的指導，只有確定了要測什麼、需要測哪些方面，才能有針對性的設計測試用例;
（3）測試需求是計算測試覆蓋的分母，沒有測試需求就無法有效地進行測試覆蓋.

需求評審（需求澄清）
參與人員，包括：SE、OM、PC、AD、TE以及QA。
SE提出需求。
開發人員（OM、PC、AD）考慮功能實現的方案與可行性。
TE主要是對需求的理解提出疑問，以便才能根據需求寫用例。
QA人員是最終對軟體質量進行驗證的人，所以也需要了解需求。

開發人員編寫排期
開發人員需求根據需求功能點進行排期，然後將開發計劃傳送給參與專案的所有人員。

測試計劃排期
測試人員根據開發計劃，安排測試的具體測試時間（包括SIT轉測），然後將測試計劃傳送給參與專案的所有人員。

編寫測試用例
根據詳細的需求文件，開始進行用例的編寫。

用例評審
用例評審前，先將用例傳送給相關人員，以便他們事先了解用例將對哪些功能進行驗證以及驗證的細節。
在用例評審中，參與人員需要對用例中與實際功能不符合的用例或者格式不規範規用例提出修改建議。

提交基線
開發人員完成所有功能後，會對自己的功能進行一個自測。自測完成後提交測試進行基線。

Showcase
開發人員自測完成後將實現的功能演示給測試人員。測試人員可以提出疑問由開發人員解答或者後續提單解決。

轉測
轉測試是開發把所有需求都開發完成，並所有需求都showcase完畢。（即：開發轉版本給測試組前進行的系統測試，目的是來評斷這個版本功能是否可測。如果預測試不通過，打回，開發組返工，如果通過，測試組開始第一輪系統測試。）迭代出口（轉測之前是迭代出口，迭代出口前是迭代期）完成了，需要自己到測試環境進行驗證。
轉測時間根據版本制定。版本轉測試以後，需要對本版本進行總結，版本製作人需要對合入版本期間的異常進行總結，對合入的事件做好記錄，對版本延遲的原因要給出負責主題。
(1)第一輪系統轉測試，測試組會執行所有測試用例，發現缺陷提交問題單，並每日彙報測試進展。第一輪測試結束後，測試組將所有的問題單跟蹤提交給開發人員，由他們進行修改。然後對基線後的第二輪進行測試，第二輪會對第一輪中發現的問題進行重點回歸。
(2)在他們修復bug期間，測試組會對第一輪系統測試做一個測試評估，出一個測試報告。 還要根據實際情況，對測試組寫的測試用例進行修改和增加，開發修改bug結束，提交一個新的版本給測試組。首先是迴歸缺陷，然後會在用例中挑選一些優先級別比較高的用例來進行測試，發現問題繼續提交缺陷問題單，直到缺陷率低於使用者要求，測試組將進行最後一輪的大版本測試，結束系統測試。具體測試輪次根據版本質量和專案複雜度而決定。

測試通過
經過兩到三輪或四輪的測試後，直到沒發現新的問題。或暫時無法解決，或不緊急的問題，通過上級確認，可以通過。
編寫測試報告與驗收方案（驗收方案是交由QA進行驗證的，測試人員重點關注的是功能是否可以正常執行，QA關注的是整個流程的質量以及終端使用者的質量）。

測試評估
執行階段結束了進入測試評估階段，測試組會出一個總的測試報告對測試組測試的這個過程和版本的質量做一個詳細的評估 ：
1) 需求需要評審那些？
2) 用例需要評審那些？
3) 計劃應該評審那些？
4) 缺陷評審那些？
5) bug評估？

測試總結文件報告輸出
可以讓具體的任務負責人對該本次測試中個人負責的模快進行評價，提出相關建議，給出總體的評估。
整體上的bug按照不同等級統計出來，用例數量、用例執行數量。
對專案中測試人力資源的統計。（單位：人/天）
專案中軟硬體資源統計。
提出軟體總體的評價。

測試報告
測試報告包括對軟體功能的結論，說明為滿足此項功能而設計的軟體能力以及經過一項或多項測試已證實的能力。
說明該專案軟體的開發是否達到預定目標，是否可以交付使用。總結測試工作的資源消耗資料：如工作人員的水平級別數量、機時消耗等。
記錄測試結果與發現及本專案測試工作所得到的各項輸出的承載體，根據輸入與計劃、要求的對比來總結此次專案所獲得的經驗。

備註
測試團隊職責：需求評審、測試計劃、測試用例、測試用例評審、測試執行、缺陷報告、缺陷跟蹤、測試報告
測試團隊交付件：測試計劃、測試用例、缺陷報告、測試報告