這幾天在TesterHome上看到有人關(guān)于測(cè)試如何保證項(xiàng)目發(fā)布質(zhì)量的提問，同時(shí)新達(dá)達(dá)北京研發(fā)團(tuán)隊(duì)最近也有一些關(guān)于后端代碼上線后質(zhì)量不可控的小煩惱，于是將我加入達(dá)達(dá)后對(duì)上線流程的優(yōu)化做了以下總結(jié)，供大家參考。

上線流程的演進(jìn)

第一階段 上線流程從無到有

我是達(dá)達(dá)研發(fā)團(tuán)隊(duì)的第一個(gè)測(cè)試工程師，在我加入之前研發(fā)團(tuán)隊(duì)人還很少，大概4個(gè)后端工程師和2個(gè)android工程師，當(dāng)時(shí)后端代碼上線的流程比較簡(jiǎn)單，從開發(fā)工程師coding到代碼最終上線一共會(huì)經(jīng)過3個(gè)環(huán)境：工程師本地開發(fā)環(huán)境 -> dev測(cè)試環(huán)境 -> 生產(chǎn)環(huán)境。開發(fā)工程師完成代碼開發(fā)，在dev測(cè)試環(huán)境自測(cè)后會(huì)把代碼push到對(duì)應(yīng)倉(cāng)庫(kù)的master分支上，等晚上9點(diǎn)上線。

流程及流程圖-最初

• 開發(fā)工程師提交branch分支到git server
• 測(cè)試工程師在dev環(huán)境部署branch分支測(cè)試
• 代碼測(cè)試通過后運(yùn)維工程師部署代碼上線
• 線上驗(yàn)證功能

Paste_Image.png

存在的問題

1. dba在代碼上線前還未完成dbrt ^[1] 導(dǎo)致服務(wù)啟動(dòng)異常
2. 運(yùn)維工程師在代碼上線前還未完sart ^[2] 導(dǎo)致服務(wù)啟動(dòng)異常
3. 代碼合并問題導(dǎo)致服務(wù)啟動(dòng)異常
4. master分支上有未經(jīng)過測(cè)試的代碼，且代碼有bug造成功能異常
5. 開發(fā)工程師的dbrt和sart提交時(shí)內(nèi)容不完整導(dǎo)致服務(wù)器啟動(dòng)異常

優(yōu)化方案

• 任務(wù)單管理，將dbrt，sart通過任務(wù)管理工具管理起來，dba和運(yùn)維工程師完成任務(wù)后，技術(shù)支持工程師確認(rèn)完成無誤才會(huì)開始上線
• master合并權(quán)限控制，將合并branch分支代碼到master這件事交由技術(shù)支持工程師統(tǒng)一負(fù)責(zé)，保證代碼合并質(zhì)量，同時(shí)避免有未測(cè)試的代碼上線
• 增加預(yù)發(fā)布環(huán)節(jié)，搭建一套獨(dú)立的qa環(huán)境，所有在生產(chǎn)環(huán)境進(jìn)行的代碼部署，配置變更，服務(wù)重啟等動(dòng)作都會(huì)在這個(gè)環(huán)境上進(jìn)行預(yù)演，測(cè)試工程師確認(rèn)沒有問題后才會(huì)進(jìn)行上線
• 線上問題review機(jī)制

流程圖-優(yōu)化后

• 開發(fā)工程師提交branch分支到git server
• 測(cè)試工程師在dev環(huán)境部署branch分支測(cè)試
• 開發(fā)工程師發(fā)送上線申請(qǐng)及提交dbrt sart，由技術(shù)支持工程師統(tǒng)一合并代碼
• 代碼合并完成后部署qa環(huán)境進(jìn)行回歸測(cè)試
• 代碼上線前檢查線上dbrt和sart的是否完成
• 以上環(huán)節(jié)都確認(rèn)無誤后部署代碼上線
• 線上驗(yàn)證功能

提示：灰底部分為流程新增部分

Paste_Image.png

經(jīng)驗(yàn)總結(jié)

• 代碼合并沖突需要認(rèn)真解決并驗(yàn)證解決效果
• 上線的代碼分支和測(cè)試回歸的分支必須是同一個(gè)分支
• 生產(chǎn)環(huán)境的代碼，數(shù)據(jù)，配置變更需要在上線前驗(yàn)證無誤后才能進(jìn)行操作

第二階段 自動(dòng)化回歸及監(jiān)控體系建設(shè)

第一階段優(yōu)化方案全都完成后，上線流程基本成型，從開發(fā)工程師開始coding到代碼最終上線會(huì)經(jīng)過4個(gè)環(huán)境：工程師本地開發(fā)環(huán)境 -> dev測(cè)試環(huán)境 -> qa預(yù)發(fā)布環(huán)境 -> 生產(chǎn)環(huán)境。隨著業(yè)務(wù)的增長(zhǎng)，開發(fā)團(tuán)隊(duì)規(guī)模變大，我們遇到了新的問題。

存在的問題

1. 線上功能變多，上線頻率較高，回歸測(cè)試的工作量變大
2. 回歸測(cè)試不充分，非核心功能偶爾會(huì)有問題
3. 上線后非核心功能的異常，有時(shí)候無法馬上發(fā)現(xiàn)

優(yōu)化方案

• 針對(duì)核心業(yè)務(wù)開展api自動(dòng)化，靠api自動(dòng)化來提高回歸測(cè)試效率及覆蓋率（這一階段的自動(dòng)化回歸主要針對(duì)qa環(huán)境）
• 完善監(jiān)控，基礎(chǔ)架構(gòu)組提供了一套基于日志的監(jiān)控系統(tǒng)，關(guān)于監(jiān)控系統(tǒng)的原理及實(shí)現(xiàn)可以參考文章《達(dá)達(dá)日志系統(tǒng)-收集》
• 搭建灰度發(fā)布環(huán)境，這個(gè)環(huán)境是一個(gè)mini版的生產(chǎn)環(huán)境，有1%的真實(shí)流量在該環(huán)境上跑，代碼上灰度環(huán)境后如果有異常，能通過上面的監(jiān)控系統(tǒng)得知

流程及流程圖

• 開發(fā)工程師提交branch分支到git server
• 測(cè)試工程師在dev環(huán)境部署branch分支測(cè)試
• 開發(fā)工程師發(fā)送上線申請(qǐng)及提交dbrt sart，后由技術(shù)支持工程師統(tǒng)一合并代碼
• 代碼合并完成后部署qa環(huán)境進(jìn)行回歸測(cè)試
• 在qa環(huán)境執(zhí)行api自動(dòng)化
• 代碼上線前檢查線上dbrt和sart的是否完成
• 以上環(huán)節(jié)都確認(rèn)無誤后部署代碼上灰度環(huán)境
• 測(cè)試工程師在灰度環(huán)境回歸測(cè)試
• 技術(shù)支持觀察監(jiān)控系統(tǒng)數(shù)據(jù)變化
• 以上環(huán)節(jié)都沒有問題，代碼在灰度環(huán)境觀察一小時(shí)上正式環(huán)境
• 線上驗(yàn)證功能
• 技術(shù)支持工程師上線后觀察LB的日志以及監(jiān)控系統(tǒng)數(shù)據(jù)變化

Paste_Image.png

經(jīng)驗(yàn)總結(jié)

• api自動(dòng)化能夠提高回歸測(cè)試的效率，但是需要平衡好資源投入和覆蓋率的關(guān)系
• 完善的監(jiān)控系統(tǒng)能夠讓我們?cè)诖罅坑脩舴答佒熬桶l(fā)現(xiàn)問題
• 灰度發(fā)布能夠盡早的發(fā)現(xiàn)問題，避免造成大面積的影響

第三階段 質(zhì)量保障過程化

到此，整個(gè)上線流程中代碼會(huì)經(jīng)過以下幾個(gè)環(huán)境，工程師本地開發(fā)環(huán)境 -> dev測(cè)試環(huán)境 -> qa預(yù)發(fā)布環(huán)境 -> 灰度發(fā)布環(huán)境 -> 生產(chǎn)環(huán)境，功能全部驗(yàn)證通過后才會(huì)部署代碼上線。大家都知道，一個(gè)項(xiàng)目會(huì)經(jīng)過需求 -> 開發(fā)設(shè)計(jì) -> 編碼 -> 測(cè)試-> 上線 這幾個(gè)階段，在整個(gè)生命周期中前問題越早發(fā)現(xiàn)，修復(fù)問題的成本越低。除此以外，在一些開發(fā)周期比較長(zhǎng)的項(xiàng)目中，經(jīng)常會(huì)遇到項(xiàng)目過程中沒有和master做rebase，導(dǎo)致最終合并代碼上線的時(shí)候沖突很多，解決沖突比較好費(fèi)時(shí)間精力，沖突解決完以后還需要對(duì)master分支做一次全量回歸，耗費(fèi)人力。

存在的問題

1. 開發(fā)周期長(zhǎng)的項(xiàng)目沒有定期和master做rebase導(dǎo)致合并代碼時(shí)沖突很多，耗費(fèi)人力解決沖突級(jí)回歸測(cè)試
2. qa環(huán)境和灰度環(huán)境發(fā)現(xiàn)bug，修復(fù)起來成本較高

成本高的原因：后端代碼通常是在下午2點(diǎn)-4點(diǎn)的流量低峰期上線，過了這個(gè)時(shí)間，項(xiàng)目上線就需要在晚上9點(diǎn)以后進(jìn)行，到時(shí)候開發(fā)工程師，測(cè)試工程師，運(yùn)維工程師等都需要在，確保上線正常。

優(yōu)化方案

1. 部分核心業(yè)務(wù)會(huì)有單元測(cè)試，開發(fā)分支push到git的時(shí)候會(huì)在本地觸發(fā)單元測(cè)試，全部通過后才會(huì)提交成功
2. 針對(duì)核心業(yè)務(wù)代碼，當(dāng)分支代碼被合并到master后會(huì)自動(dòng)部署測(cè)試環(huán)境，并且觸發(fā)jenkins上部署的代碼掃描任務(wù)及自動(dòng)化測(cè)試任務(wù)
3. 每周用2小時(shí)針對(duì)代碼靜態(tài)掃描平臺(tái)掃出來的問題進(jìn)行優(yōu)化，目標(biāo)為保持問題數(shù)量不高于最初
4. 開發(fā)周期長(zhǎng)的項(xiàng)目在每次代碼上線后，需要對(duì)master分支做rebase

流程及流程圖

• 開發(fā)工程師提交branch分支通過單元測(cè)試后才被push到git server
• 測(cè)試工程師在dev環(huán)境部署branch分支測(cè)試
• 開發(fā)工程師發(fā)送上線申請(qǐng)及提交dbrt sart，后由技術(shù)支持工程師統(tǒng)一合并代碼
• 代碼合并入master分支后出發(fā)代碼掃描，單元測(cè)試，通過后自動(dòng)部署測(cè)試環(huán)境（目前只覆蓋java項(xiàng)目）
• 代碼合并完成后部署qa環(huán)境進(jìn)行回歸測(cè)試
• 在qa環(huán)境執(zhí)行api自動(dòng)化
• 代碼上線前檢查線上dbrt和sart的是否完成
• 以上環(huán)節(jié)都確認(rèn)無誤后部署代碼上灰度環(huán)境
• 測(cè)試工程師在灰度環(huán)境回歸測(cè)試
• 技術(shù)支持觀察監(jiān)控系統(tǒng)數(shù)據(jù)變化
• 以上環(huán)節(jié)都沒有問題，代碼在灰度環(huán)境觀察一小時(shí)上正式環(huán)境
• 線上驗(yàn)證功能
• 技術(shù)支持工程師上線后觀察LB的日志以及監(jiān)控系統(tǒng)數(shù)據(jù)變化

Paste_Image.png

經(jīng)驗(yàn)總結(jié)

1. 在盡可能早的階段發(fā)現(xiàn)問題能夠避免上線時(shí)候手忙腳亂
2. 代碼靜態(tài)掃描，單元測(cè)試，自動(dòng)化測(cè)試，持續(xù)集成是提高效率和質(zhì)量的好幫手
3. 開發(fā)周期長(zhǎng)的項(xiàng)目，定期做rebase會(huì)減少后面很多不必要的麻煩

我的一些思考

作為測(cè)試工程師，如果只是關(guān)注如何把項(xiàng)目測(cè)試完成，用什么工具和框架能夠做自動(dòng)化測(cè)試，如何做性能測(cè)試，這些是不夠的，這種情況下能做的事情比較局限，而且也無法保證項(xiàng)目上線后的結(jié)果。而從質(zhì)量保障體系的角度去思考，會(huì)發(fā)現(xiàn)一套合適的項(xiàng)目研發(fā)流程，好的研發(fā)架構(gòu)，完善的自動(dòng)化工具及監(jiān)控平臺(tái)對(duì)最終交付的結(jié)果影響很大。
天下武功唯快不破，質(zhì)量保障體系也是如此，從提升效率的角度來說，可做的不僅是各類自動(dòng)化，再我看來可以分為兩個(gè)維度：加快產(chǎn)品迭代和提高問題暴露。其中構(gòu)建打包分發(fā)平臺(tái)，自動(dòng)部署測(cè)試環(huán)境，打通用例，缺陷和自動(dòng)化測(cè)試系統(tǒng)等屬于前者；代碼靜態(tài)掃描，單元測(cè)試，各類自動(dòng)化測(cè)試，持續(xù)集成屬于后者。每個(gè)公司的團(tuán)隊(duì)規(guī)模，發(fā)展所處階段階段不一樣，需要根據(jù)具體的情況來制定流程及使用工具，一開始就追求大而全有時(shí)候反而會(huì)適得其反。

腳注

1. DateBase Administration Request Tracker，主要是指正對(duì)數(shù)據(jù)庫(kù)系統(tǒng)的需求，包括create table，alert table 以及數(shù)據(jù)庫(kù)維護(hù)數(shù)據(jù)等相關(guān)的需求 ?

2. System Administration Request Tracker，主要是開發(fā)環(huán)境，中間件等各種系統(tǒng)及環(huán)境配置修改，包括os，lb，nginx，memcached，redis等 ?