項目交接：測試應該如何銜接

很多公司都有一些項目的交接問題存在，有從商務外包團隊将項目交接給公司自建團隊的，也有因為公司的一些組織架構的調整導緻的項目交接。（有些公司叫項目閉環，為什麼叫閉環我其實也不清楚啊，就是本來A團隊在AA部門做AAA項目，調整後就是A團隊在BB部門做AAA項目的一部分或者全部）

不管因為什麼，如果發生了項目交接，你做為項目承接團隊中測試工程師，要如何完成測試部分的交接呢？我們都是知道很多項目連代碼都是一團亂麻，就更别提測試了，那麼面對一團亂麻的項目，我們應該如何開始承接對應的測試呢？

第一步：是否有測試資産的移交

最開始我們要搞清楚是否有一些測試資産可以承接過來，那麼确定可以繼承的測試資産，我們可以從如下三個問題開始：

• 1、是否有自動化測試
• 2、測試用例什麼時候會被執行
• 3、測試代碼覆寫率（強烈建議業務測試也需要統計代碼覆寫率）

我相信很多項目對于上面的問題很難給出準确的答案，尤其是最後一條。如果你将要接手的項目沒有自動化測試，那麼你就要将測試重點放到業務測試用例上，關注業務測試用例如何如何被執行的，是否分級以及執行過程曆史上發現的BUG和被修複情況。最後，你還是要把所有業務測試用例執行一遍，這時候我特别建議你使用代碼覆寫工具統計代碼覆寫率，我相信你會看到大面積沒有被覆寫的代碼段。這說明原來的業務測試用例設計并不完善。

第二步：制定一個接手後的計劃

在拟定這個計劃的時候，要站在原項目的測試基礎之上，給出一個從混亂狀态到有序的可控狀态的時間表。那麼這個計劃中既要包含測試工程師的任務和時間也要包含開發工程師Codereview的流程、靜态代碼掃描等實施時間，但是切記不要太過急躁，希望接手那一天就完全走入正規，每一個項目從無序到有序都是一個過程，沒有辦法一口吃成個胖子。

第三步：實施落地

按照你的計劃開始一步一步落實，最開始還是要以業務測試為主，并且配合一些測試手段，提高測試的精準度。例如通過增量代碼覆寫情況，進而指導業務測試用例設計；推行靜态代碼掃描建立品質門禁；引入API自動化測試，降低手動測試工作量，如果測試團隊技術成熟度較高，那麼可以推行UI自動化，實作E2E的品質保證。

第四步：為重建構立單元測試

重構不得不說是任何一個團隊接手一個老項目的時候，每一個技術負責人的心結。每個人都想重構，都想把系統打上自己的印記，但是又不怕不是最合适的時期。但是無論如何，重構是早晚的事情，但是在開始重構之前，測試工程師一定要督促單元測試的覆寫度，當單元測試覆寫度足夠完善的時候才能開始重構，而不能随随便便就滿了研發重構的心願，否則你就會将團隊帶入一個不斷修複BUG、不斷救火的痛苦狀态中。