要考慮企業(yè)組織的成熟度和測試項目的特性。一般來說，測試過程包含下面幾個階段：測試計劃和控制、測試分析和設計、測試實現(xiàn)和執(zhí)行、測試出口評估和報告以及測試結(jié)束活動。
測試過程定義中，需要明確每個測試過程階段的輸入和輸出、每個測試階段的主要測試活動以及每個測試階段中的質(zhì)量檢查點。明確定義軟件測試過程以及相關的測試活動和輸出，可以從制度上保證測試工作的順利進行，并且可以有針對性的進行測試活動的控制。軟件開發(fā)的產(chǎn)品質(zhì)量是通過整個開發(fā)過程的質(zhì)量控制來保證的。同樣，測試質(zhì)量也需要測試過程質(zhì)量來保證。
（3）完善以前版本相關文檔
收集和整理項目以前版本的相關文檔，包括開發(fā)文檔和測試文檔。從測試的角度來說，有兩方面的內(nèi)容：一是學習以前的相關軟件需求和設計文檔（可能是已有的，或者通過開發(fā)團隊收集和整理的文檔），來了解軟件的主要功能和實現(xiàn)方式；另一個是整理和收集測試相關的文檔，比如每個版本的測試計劃、概要測試用例、詳細測試用例以及以前版本的缺陷信息等。
假如對每個功能進行全面的分析，需要花費巨大的人力和時間成本，這可能是不太現(xiàn)實的。我們的經(jīng)驗是和開發(fā)團隊合作，召集各個領域和應用方面的技術(shù)專家，來對以前系統(tǒng)進行需求方面的文檔化，至少對每個功能特征進行部分的描述，同時對一些復雜的功能接口、用戶接口等進行詳細的需求分析，形成比較詳盡的系統(tǒng)需求文檔。
針對測試文檔，根據(jù)前面得到的一些基本文檔提供的信息，分析軟件的主要功能和重要功能，提供一些測試用戶場景以及它們的輸出預期。也可以通過探測性測試，得到軟件的一些表現(xiàn)行為和結(jié)果輸出。將這些用戶場景和測試輸出等進行文檔化，作為后續(xù)項目測試的基礎，也可以作為回歸測試的輸入和重點。
（4）軟件新增功能的文檔化
對新增加和升級的功能特征進行文檔化，從確定開發(fā)和測試的系統(tǒng)版本開始，我們需要對每個增加的功能、升級修改的功能進行詳盡的需求文檔化，作為后續(xù)開發(fā)測試活動的參考和基線。這樣，可以在后續(xù)的開發(fā)設計、測試設計等方面擁有共同的輸入和參考點。這對于系統(tǒng)的研發(fā)非常重要，這個環(huán)節(jié)沒有做好，項目的開發(fā)將一直處于混亂狀態(tài)，例如：系統(tǒng)需求不明確、開發(fā)條目不清晰、測試輸出預期沒有標準等，無法保證項目產(chǎn)品的質(zhì)量。
（5）基線化一個測試版本
確定一個固定的系統(tǒng)版本作為進行后續(xù)開發(fā)和測試的基礎。所有項目的利益相關者需要在這一點上達到共識：為什么產(chǎn)品的開發(fā)是基于已經(jīng)存在的軟件系統(tǒng)之上？然后選擇已有系統(tǒng)的一個版本作為新開發(fā)的基礎，并且它是唯一的進行后續(xù)開發(fā)測試的版本。
固定后續(xù)開發(fā)和測試的版本，可以更加直觀的來跟蹤缺陷。通過對已有系統(tǒng)代碼的升級或修改，可以判斷在新的軟件中某個現(xiàn)象是否是缺陷。在碰到輸出結(jié)果存在異議的時候，通過各個領域的專家來驗證到底是新系統(tǒng)引入的新缺陷，還是舊系統(tǒng)中本來存在的問題。通過該策略，大家既可以對系統(tǒng)的輸入和輸出達成一致，也可以作為對原有系統(tǒng)需求收集和文檔化的手段之一。
（6）基于風險的回歸測試
對于中途接手的項目測試，回歸測試將是測試過程中的一個重要關注點。因此，如何選擇回歸測試用例，來提高測試的效率和有效性，是測試團隊面臨的一個重要問題。
通過前面提到的各種建議，可以對測試團隊、測試過程和文檔化方面進行改進，從而有利于回歸測試用例的選擇?；貧w測試用例的選擇，基于測試風險而展開將是一個有效的手段。下面的實踐經(jīng)驗可以作為一個參考：
● 分析軟件中什么功能是客戶最經(jīng)常使用的？
● 什么功能對客戶而言是最重要的？
● 什么功能在以前版本中發(fā)現(xiàn)的缺陷是最多的？
● 新增加的功能或者升級，對原來的什么功能和模塊的影響是最大