對于測試團隊而言，測試中途接手的項目和產(chǎn)品，存在很多的風(fēng)險和挑戰。本文首先從測試的角度闡述中途接手項目測試可能存在的風(fēng)險和挑戰;然后根據筆者的經(jīng)驗和知識，提出測試方面的建議，以幫助測試人員更好的開(kāi)展此類(lèi)條件下的測試活動(dòng)。
1)風(fēng)險和挑戰
(1)項目測試經(jīng)驗欠缺
對于中途接手的項目，測試團隊首先面臨的一個(gè)挑戰是缺少當前項目的測試經(jīng)驗，至少是不熟悉項目，例如：系統的整體設計架構、實(shí)現的主要功能、客戶(hù)的關(guān)注重點(diǎn)、系統的測試平臺、系統使用的測試工具、系統配置和管理的命令、系統中主要的缺陷分布等。項目中這些信息和知識，都需要測試團隊花費很多的時(shí)間進(jìn)行學(xué)習和理解。測試團隊中盡管有的成員可能對系統功能有些經(jīng)驗和知識儲備，但是對于該項目而言，測試經(jīng)驗方面肯定是欠缺的，或者是缺乏經(jīng)驗的。
(2)開(kāi)發(fā)測試文檔不全
中途接手的項目，測試團隊面臨的第二個(gè)問(wèn)題是：原有的需求文檔和測試文檔可能不全，甚至沒(méi)有，例如：由于軟件開(kāi)發(fā)的成熟度低下，或者由于項目移交的時(shí)候沒(méi)有將相關(guān)的文檔成功交接。而后續的測試工作需要詳細了解以前項目版本的需求和相關(guān)的測試文檔，從而可以深入學(xué)習和理解以前項目的基本功能。
對開(kāi)發(fā)團隊而言，沒(méi)有原始的需求文檔也是一個(gè)非常大的挑戰。首先，開(kāi)發(fā)人員只能通過(guò)研究軟件的代碼來(lái)理解系統的功能和實(shí)現。而對系統各種可能的數據輸入都進(jìn)行研究是不現實(shí)的，并且也很容易遺漏一些復雜的功能實(shí)現。其次，開(kāi)發(fā)人員在面對特定輸入情況下系統產(chǎn)生令人迷惑的輸出，開(kāi)發(fā)人員可能會(huì )想當然的認為系統就是這樣實(shí)現的。令情況更糟的是，開(kāi)發(fā)人員在確定系統正確的輸出和工作方式過(guò)程中，并沒(méi)有進(jìn)行相應的文檔化，而是在這基礎上直接進(jìn)行代碼設計，導致這種猜測循環(huán)經(jīng)常持續，從而使需求的收集和文檔化更加困難。
而對于測試團隊來(lái)說(shuō)，同樣面臨嚴峻的挑戰。雖然從表面上看，在已有系統上進(jìn)行測試，測試人員可以通過(guò)比較以前軟件的輸出和新的軟件輸出結果進(jìn)行對比。但是，基于不同版本輸出結果進(jìn)行判斷并不總是安全的，例如：原來(lái)系統的輸出就是錯誤的�；谶@樣的判斷，測試人員就會(huì )遺漏系統中的一些缺陷�；蛘�，原來(lái)系統實(shí)現的功能是不正確的，而在新的系統中，由于增加或升級了軟件修改了原來(lái)代碼的缺陷，其輸出是正確的�；趦烧咧g的比較，測試人員會(huì )認為新的系統由于代碼的修改引入了缺陷，而提交了不應該提交的缺陷報告。假如開(kāi)發(fā)人員修改了本來(lái)是正確的代碼，新的軟件中又引入了新的缺陷。原本應該在需求階段確定的預期結果的判斷，落到了測試人員頭上。
(3)不穩定的測試對象
在很多時(shí)候，項目在移交之前可能已經(jīng)交付給客戶(hù)使用了，后續的開(kāi)發(fā)和測試會(huì )在用戶(hù)版本的基礎之上進(jìn)行一些維護工作，例如：新功能的添加、缺陷的修改、系統架構的更改、新技術(shù)代替老技術(shù)等。在這種情形下，整個(gè)系統看起來(lái)更象是移動(dòng)的不穩定的實(shí)體，這樣導致的結果是新的系統一直處于多種開(kāi)發(fā)狀態(tài)的混合體，它們會(huì )經(jīng)歷不同的生命周期階段，是個(gè)不穩定的測試對象。
(4)測試工作量的估算
由于中途接手的項目經(jīng)常處于不穩定的狀態(tài)，導致測試工作量、測試進(jìn)度、測試人員和資源的估算更加困難。測試工作量的估算只能是基于對系統功能的粗略理解，而所謂的系統功能甚至可能是錯誤的，或者系統在維護過(guò)程中功能經(jīng)常發(fā)生變更。對于測試估算而言，即使有詳細的需求文檔的情況下，也是一件非常困難的事情。因此，對中途接手的項目，由于其不穩定的特點(diǎn)，進(jìn)行測試工作量的估算，將是難上加難的事情。
(5)回歸測試用例選擇
對于中途接手的項目，后續的開(kāi)發(fā)和測試是基于前面的軟件版本而展開(kāi)的。針對開(kāi)發(fā)活動(dòng)而言，后續的開(kāi)發(fā)主要是指軟件版本新功能的增加、版本的升級、平臺的升級，以及前面版本中遺留的缺陷的修改等。而對于測試活動(dòng)而言，后續的活動(dòng)主要是驗證新增功能是否符合系統的要求、確認是否滿(mǎn)足客戶(hù)的要求、確定缺陷是否已經(jīng)修復以及新增加的功能和缺陷修復沒(méi)有在原來(lái)系統中引入新的缺陷。因此，對于中途接手的項目，測試團隊的很多測試工作將關(guān)注在由于軟件變更而進(jìn)行的回歸測試。
在中途接手的項目中，回歸測試在整個(gè)測試活動(dòng)中會(huì )占有很大的比重。因此如何選擇每次測試的回歸測試用例，對于測試團隊而言，也是一個(gè)很大的挑戰。由于前面提到的測試項目經(jīng)驗欠缺和開(kāi)發(fā)測試文檔的不全，導致測試團隊很難進(jìn)行測試風(fēng)險的估算，從而很難確定回歸測試的重點(diǎn)和優(yōu)先級，影響回歸測試用例的選擇。
(6)項目知識的轉移
中途接手的項目，還有一個(gè)很大的挑戰是項目相關(guān)知識的轉移，例如：系統、開(kāi)發(fā)和測試相關(guān)知識的轉移。項目是從一個(gè)研發(fā)中心轉移到另外一個(gè)研發(fā)中心，由于語(yǔ)言、文化和習慣的差異，在知識轉移過(guò)程中，很難實(shí)現無(wú)縫的轉移。由于測試團隊中本身對項目的測試經(jīng)驗的不足，導致相關(guān)知識交流方面會(huì )更加困難。
2)經(jīng)驗和對策
從測試的角度，上面談了中途接手項目中存在的7個(gè)主要風(fēng)險和挑戰。雖然存在比較多的困難和不確定因素，測試人員還是可以利用已有的測試經(jīng)驗和知識，采取一些合適的手段和方法來(lái)應對這些問(wèn)題。
下面根據筆者在中途接手測試項目方面的經(jīng)驗，對上面提到的這些問(wèn)題提供一些參考的信息和建議。這些建議并不是肯定適合的，在進(jìn)行具體項目的時(shí)候，還需要考慮不同企業(yè)組織和不同項目的背景。同時(shí)，下面的經(jīng)驗并不是對應解決上面的每個(gè)風(fēng)險和挑戰，而是從整體上對如何進(jìn)行中途接手項目的測試提供了一些實(shí)踐。
(1)合適的測試經(jīng)理或專(zhuān)家
對于測試工作而言，測試經(jīng)理應該是整個(gè)測試團隊的靈魂，對于中途接手項目的測試中體現的尤為明顯。中途接手項目中，測試團隊的測試經(jīng)驗相對欠缺，因此測試工作的計劃、估算、執行以及控制等尤為重要，因此需要更加慎重的選擇合適的測試經(jīng)理來(lái)領(lǐng)導這樣的項目。合適的測試經(jīng)理，除了需要具備的一些能力和知識外，例如：熟悉測試過(guò)程、具備測試管理能力等，針對中途接手的項目測試，測試經(jīng)理具備下面幾個(gè)方面的能力也非常重要：
ü 測試經(jīng)理應該對項目產(chǎn)品相關(guān)的功能、協(xié)議等有很深厚的經(jīng)驗和知識，能夠從全局上把握軟件產(chǎn)品的風(fēng)險、測試的重點(diǎn)和優(yōu)先級。在項目測試初期，最好能夠在測試團隊中能夠起到知識方面的引路人;
ü 測試經(jīng)理應該有良好的溝通能力，包括對內溝通和對外溝通。由于項目是從國外研發(fā)中心轉移過(guò)來(lái)，因此需要測試經(jīng)理有很熟練的英語(yǔ)溝通能力。
對于有的組織和項目而言，測試經(jīng)理并不是技術(shù)方面的專(zhuān)家。那么，在面對中途接手的項目測試中，測試經(jīng)理需要選擇產(chǎn)品相關(guān)的測試技術(shù)專(zhuān)家(測試領(lǐng)域的專(zhuān)家，例如：數據通信領(lǐng)域的專(zhuān)家)對整個(gè)測試過(guò)程中的技術(shù)進(jìn)行把關(guān)。協(xié)助測試經(jīng)理進(jìn)行測試活動(dòng)的計劃、估算、協(xié)調和控制，同時(shí)幫助測試經(jīng)理進(jìn)行測試團隊的構建和發(fā)展，使得測試團隊能夠勝任中途接手項目的測試。
(2)合適的軟件測試過(guò)程
選擇了合適的測試經(jīng)理或者測試專(zhuān)家，基本上可以保證測試團隊對測試工作的適應性。測試質(zhì)量中除了人的因素外，另外一個(gè)很重要的因素是過(guò)程的因素。測試質(zhì)量的提高和保證，需要一個(gè)完善的測試過(guò)程來(lái)控制和保證。
當然，軟件測試過(guò)程的選擇，需要考慮企業(yè)組織的成熟度和測試項目的特性。一般來(lái)說(shuō)，測試過(guò)程包含下面幾個(gè)階段：測試計劃和控制、測試分析和設計、測試實(shí)現和執行、測試出口評估和報告以及測試結束活動(dòng)。
測試過(guò)程定義中，需要明確每個(gè)測試過(guò)程階段的輸入和輸出、每個(gè)測試階段的主要測試活動(dòng)以及每個(gè)測試階段中的質(zhì)量檢查點(diǎn)。明確定義軟件測試過(guò)程以及相關(guān)的測試活動(dòng)和輸出，可以從制度上保證測試工作的順利進(jìn)行，并且可以有針對性的進(jìn)行測試活動(dòng)的控制。軟件開(kāi)發(fā)的產(chǎn)品質(zhì)量是通過(guò)整個(gè)開(kāi)發(fā)過(guò)程的質(zhì)量控制來(lái)保證的。同樣，測試質(zhì)量也需要測試過(guò)程質(zhì)量來(lái)保證。
文章來(lái)源于領(lǐng)測軟件測試網(wǎng) http://kjueaiud.com/
