項目上線流程

來自專欄軟體測試之道6 人贊了文章

目前公司項目偏多，平均每周五天基本上有四天都會有項目上線，有時一天會上線至少二個版本，就在昨天剛上線了一個項目，星期一才提測的一個項目，星期二就安排上線了，所以悄悄地告訴小夥伴們，昨晚俺加班了(再悄悄地告訴大家其實這個昨晚已經過去很久了~微笑臉)，今天跟小夥伴們分享一下王豆豆公司的上線流程。

01

早會

每天早晨上班之後，都會開早會，早會主要是回朔昨天的內容、今天的計劃、需要解決的問題三個方面。

開發每個人講自己的情況後。

主持人：「測試呢？」

測試A：... ...

測試B：... ...

王豆豆：「XX項目，昨天已經將所有的測試點測試完全了，今天開發合到master上回歸測試完成之後就可以上線了。」

開發A：「我一會兒就合"

王豆豆："好的"

散會之後，一小時過去了.....

王豆豆問開發A："合完了沒「

開發A：」還沒有，還在做code review"

然後再一小時間過去了，代碼還是沒有從分支到master上。

上午下班前問：」什麼時候能合完嗎？"

開發A自信滿滿地說：」下午上班就能合完了「

02

回歸測試

一直到下午三點左右，代碼才合併到master上，果真是合併十分鐘，等待四小時，不過這樣也有好處，項目組內只有項目leader才有合併代碼的許可權，他在合併代碼之前會再做一次code review，這樣最大程度保證代碼的正確性，只此以後，王豆豆就變聰明了，提前讓開發合master。

回歸測試流程：

1.配置參數和環境

2.回歸主要的流程

3.將以前提的bug再次回歸

4.回歸主要的異常流程

王豆豆回歸測試時主要就是由這幾個方面組成的，如果有需要跟第三方系統聯測的情況，那麼代碼合前到master時，需要設計測試用例場景覆蓋需求與第三方系統測試人員聯測，三方聯測最是花費時間，所以測試過程中如果有這個需求一定要提前安排好時間，與聯測人員約好相應的時間，聯測在回歸測試階段也會進行，這時主要以正向流程為主，目的是檢查業務流程是否完整、介面是否聯通、數據是否正確等幾個方面。

用於回歸測試的伺服器：

王豆豆目前公司有十台測試伺服器，平時根據項目、業務需求和測試任務的不同，在不同的測試服務上拉分支進行測試，幾輪測試完全之後，確定要上線時再將分支合併到master上，然後其中固定的一台測試伺服器上進行回歸，這台伺服器只用於回歸master分支，這樣就保證了測試任務的獨立性，同時也能保證測試上線配置不會遺漏。

針對上述情況，王豆豆舉例說明：

假設我們有5台測試伺服器，分別命名為test1、test2、test3、test4、test5。

剛好今天王豆豆就接到了一個新的測試任務，接到任務之後，王豆豆就會詢問測試小夥伴們哪台伺服器是現在沒人用的？假設今天test3沒人用，那王豆豆就選擇test3作為本次測試任務的測試伺服器。

確定了測試伺服器，開發轉測之後，王豆豆就會在test3這台機器上部署代碼（我們是用jenkins自動部署，早已脫離了手工去部署代碼），配置數據，進行測試。

通過幾輪的測試，當項目滿足上線需求之後，會讓開發將代碼從分支合到master上進行回歸。

回歸測試時，就會將代碼部署到test1上，test1所對應的代碼版本一定是master，這時就會在master上進行回歸測試。

03

上線前準備

回歸測試完成之後，通過測試，表明項目已經具備上線的要求了，那這時就開始做上線前的準備，上線前準備一般會為三個步驟：

第一步：確定上線策略

a.上線順序

如果有多個系統上線，上線順序是怎麼樣的？經常我們會有三個系統一起上線，那麼A、B、C三個系統的依賴關係是怎麼樣的？比如B系統的上線功能依賴於A系統的 上線功能，那麼就先上A系統，再上B系統，項目中上線順序根據實際情況確定上線。

b.修複數據策略

如果功能上線之後出現BUG，應該怎麼處理？一般我們會設一個開關，當新功能一旦出現問題，將開關打開，走原來的老流程。

如果上線之後出現BUG，BUG影響的數據應該怎麼修復？有時會單條單條的修改數據，但如果數據量太大，單條修複數據這個工作量就很大，那麼在有可能出現BUG地方設置一個點，有可能是task任務，重新跑原來的流程，也有可能是設置一個狀態，一旦數據出現問題，無法正常進入下一個流程，那麼設置狀態為error，當BUG解決後，可以重試，修復錯誤數據。

c.舊數據分析

這個分析並不是每個項目都需要，僅限新功能上線後分影響老數據的那些項目。

舉一個簡單的例子：

前陣子做了一個流程改造的項目，以前流程是：

用戶數據----》先在A系統核驗通過----》入庫到A系統----》再同步到B系統進行業務操作----》最後再將數據同步到A系統

流程改動之後：

用戶數據----》先入庫到B系統，在B系統通過校驗後----》入庫到B系統---->再同步到A系統入庫----》B系統進行業務操作---》最後再將數據同步到A系統

針對這個流程改造項目上線之後，一定會有部分數據在上線之前是走的老流程，同時整個流程又沒走完，那麼在上線的時候就需要新流程去兼容老流程遺留下的數據，我們當時是增加了一個校驗，在老流程中數據是從A系統同步到B系統的，在新流程中數據是從B系統同步到A系統，那麼在B系統同步到A系統時增加一個校驗去判斷A系統中是否有相應數據的存在，沒有才同步。

第二步：寫上線申請郵件

上線之前，項目測試負責人要寫上線申請郵件，郵件內容包括有：

1.數據配置

有沒有開關？有就需要配置。

資料庫有沒有修改？有新增表，需要事先增表，有修改表結構，需要改表結構。

有沒有外部介面？有就需要配置介面URL，否則流程不能跑通，回調也不能通。

等等，根據實際情況來寫。

2.上線注意點

可以寫本次項目上線後，會引起的風險，哪些地方可能容易出現問題？需不需要加上監控等？又或者上線之後，需要人為地去監控數據。

3.在郵件中寫清楚上線策略

（第一步中考慮到的上線策略）

第三步：配置線上環境數據

根據測試人員編寫的上線申請郵件，在上線之前在線上環境中配置好數據，根據郵件來配置，所以在編寫郵件的時候需要將配置寫全，這些配置可以根據開發人員提測時的轉測郵件來寫，或者測試過程中的補充配置，謹記配置要寫完整。

完全以上步驟之後，就可以擇良辰開始上線了，一般上線的許可權只有幾個人有，所以上線的人員是固定的，上代碼時需要先將線上環境的job停掉，我們也是用jenkins進行自動化部署，只是需要人為的打版號、標籤，部署版本，停Djob任務，上線完全之後，啟動Djob任務等。

04

上線之後

對於測試人員來說，並不是你測試完全，項目上到線上(生產）環境上就OK了，就不關你的事了，而實則項目上線之後才是真正對測試人員的考驗，測試人員經常疑或為什麼總有一些BUG是在線上環境中才會被發現？

王豆豆總結了幾點：

1.線上環境數據的複雜度是測試環境不能比擬的。

2.業務操作的不可控性

3.實際場景的複雜性

基於以上三點，這也就是為什麼線上環境總是出現一些測試環境不能發現的BUG，排除測試人員漏測的情況。

故，上線之後，測試人員需要做好以下二件事：

第一，灰度測試

項目上線之後，首先是測試人員開始做灰度測試。

灰度測試時，可以設置由業務開關或者白名單之類做控制，只要少量數據或添加在白名單上的數據可以走新業務流程。

灰度測試完全之後，也就是將所有業務流程走完，檢查各項數據的正確性、流程是否通、流程是否完整等等檢查點。

確定無問題時，再將開關打開，再開放少量真實用戶數據。

第二，監控線上數據

灰度測試時就已經在監控線上數據和檢查線上數據，但因為灰度測試時數據量比較少，有時並不足以引發新問題，所以測試人員需要繼續觀察線上數據。

測試人員需要在項目上線之後的幾個小時內，重點監控線上數據的流向，一旦數據有異常，立即採取措施，回滾代碼又或者重新打開開關等，盡量將線上bug引起的損失降到最低，接下來就開始修改bug和修複數據。

在這個時候，測試人員對數據的敏感性特別就要發揮出來，有時似錯非錯的數據正是BUG的前兆，千萬不要掉意輕心。

整個項目上線前後的流程就大致如此，不管是上線前的準備還是上線之後數據的觀察都是一環扣一環，這些步驟有息息相關，前面的準備工作做得足，那麼後面監控數據就會相對輕鬆，因為不容易出現問題。

歡迎大家分享和轉發王豆豆的文章。