(3)完善以前版本相關文檔
收集和整理項目以前版本的相關文檔，包括開發文檔和測試文檔。從測試的角度來說，有兩方面的內容：一是學習以前的相關軟件需求和設計文檔(可能是已有的，或者通過開發團隊收集和整理的文檔)，來了解軟件的主要功能和實現方式;另一個是整理和收集測試相關的文檔，比如每個版本的測試計劃、概要測試用例、詳細測試用例以及以前版本的缺陷信息等。
假如對每個功能進行全面的分析，需要花費巨大的人力和時間成本，這可能是不太現實的。我們的經驗是和開發團隊合作，召集各個領域和應用方面的技術專家，來對以前系統進行需求方面的文檔化，至少對每個功能特征進行部分的描述，同時對一些復雜的功能接口、用戶接口等進行詳細的需求分析，形成比較詳盡的系統需求文檔。
針對測試文檔，根據前面得到的一些基本文檔提供的信息，分析軟件的主要功能和重要功能，提供一些測試用戶場景以及它們的輸出預期。也可以通過探測性測試，得到軟件的一些表現行為和結果輸出。將這些用戶場景和測試輸出等進行文檔化，作為后續項目測試的基礎，也可以作為回歸測試的輸入和重點。
(4)軟件新增功能的文檔化
對新增加和升級的功能特征進行文檔化，從確定開發和測試的系統版本開始，我們需要對每個增加的功能、升級修改的功能進行詳盡的需求文檔化，作為后續開發測試活動的參考和基線。這樣，可以在后續的開發設計、測試設計等方面擁有共同的輸入和參考點。這對于系統的研發非常重要，這個環節沒有做好，項目的開發將一直處于混亂狀態，例如：系統需求不明確、開發條目不清晰、測試輸出預期沒有標準等，無法保證項目產品的質量。
(5)基線化一個測試版本
確定一個固定的系統版本作為進行后續開發和測試的基礎。所有項目的利益相關者需要在這一點上達到共識：為什么產品的開發是基于已經存在的軟件系統之上?然后選擇已有系統的一個版本作為新開發的基礎，并且它是唯一的進行后續開發測試的版本。
固定后續開發和測試的版本，可以更加直觀的來跟蹤缺陷。通過對已有系統代碼的升級或修改，可以判斷在新的軟件中某個現象是否是缺陷。在碰到輸出結果存在異議的時候，通過各個領域的專家來驗證到底是新系統引入的新缺陷，還是舊系統中本來存在的問題。通過該策略，大家既可以對系統的輸入和輸出達成一致，也可以作為對原有系統需求收集和文檔化的手段之一。
(6)基于風險的回歸測試
對于中途接手的項目測試，回歸測試將是測試過程中的一個重要關注點。因此，如何選擇回歸測試用例，來提高測試的效率和有效性，是測試團隊面臨的一個重要問題。
通過前面提到的各種建議，可以對測試團隊、測試過程和文檔化方面進行改進，從而有利于回歸測試用例的選擇�；貧w測試用例的選擇，基于測試風險而展開將是一個有效的手段。下面的實踐經驗可以作為一個參考：
ü 分析軟件中什么功能是客戶最經常使用的?
ü 什么功能對客戶而言是最重要的?
ü 什么功能在以前版本中發現的缺陷是最多的?
ü 新增加的功能或者升級，對原來的什么功能和模塊的影響是最大的?
在進行回歸測試過程中，理解下面的建議將有助于回歸測試的開展：
ü 回歸測試不是可有可無的，回歸測試對于確認變更的正確性和驗證沒有引入新的缺陷方面有重要的意義和作用，同時可以提供對軟件產品的信心。
ü 回歸測試不應該是流于形式的，應該制訂嚴格的回歸測試過程，包括軟件變更分析、軟件變更影響分析、定義回歸測試策略、定義回歸測試套件、執行回歸測試套件，以及報告回歸測試結果等。
ü 回歸測試的重點是保證軟件基本功能的正確性，因此在回歸測試過程中應該更多的關注在功能性，而不是非功能特性。
ü 回歸測試并不一定要覆蓋所有的軟件特征和功能，需要在測試風險、時間、成本和質量之間進行平衡。
ü 回歸測試用例需要不斷進行維護和更新，而不是一成不變的。
(7)面對面的知識共享
項目從一個研發中心轉移到另一個研發中心，在項目知識的交接過程中，由于語言、文化和背景等方面的差異，可能會存在比較多的問題。我們的經驗是，在成本允許的情況下，盡量采用面對面的知識共享方式，即可以派測試方面的專家到另一個研發中心去接手這個項目，主要的關注點包括：
ü 學習整個項目的演變過程，以前版本包含的基本功能、用戶關注的主要功能、每個版本中存在的主要問題等。
ü 盡量多的收集需求文檔、開發文檔和測試文檔，包括原來測試團隊在前面項目中測試的經驗教訓等。
ü 熟悉軟件環境的搭建和配置，包括測試儀表的使用、測試環境的基本配置等。
中途接手的項目測試，應該說存在多種多樣的問題和挑戰，并不是一件容易的事情。但是，通過上面的一些經驗、建議、措施和步驟，可以幫助測試團隊更好的組織、計劃、估算、控制測試活動，從而達到測試成本、質量、時間、風險等方面的平衡。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
