文/秋之川
第二十七章 如何結(jié)束代碼混亂的時代嗤放？
當(dāng)我們開始進(jìn)行新需求測試的時候，線上突然發(fā)現(xiàn)一個很嚴(yán)重的問題廊鸥，需要立即修復(fù)望浩，然后發(fā)布。找開發(fā)討論測試范圍的時候惰说，得知需要做很多額外的回歸測試磨德，問其原因，才得知他們起初并沒有分支的概念吆视，都是在一個代碼主干里去開發(fā)的典挑，現(xiàn)在要單獨發(fā)布一個修復(fù)補丁，可能會包含很多未經(jīng)測試的新代碼啦吧，甚至于未完成的代碼您觉。
這是何等混亂的一種情況，在這種情況下授滓，怎么才能保證版本質(zhì)量呢琳水？如果靠人山人海的回歸測試肯定是不現(xiàn)實的，且不說人力成本的問題褒墨，那始終無法明確邊界的回歸測試就是一個很大的風(fēng)險炫刷，誰也不能保證測試的充分性。
版本管理是唯一的根本性解決方案郁妈，這是很多剛剛轉(zhuǎn)做測試項目管理的人容易忽略的一個解決途徑浑玛，因為下意識里會把代碼的管理劃到開發(fā)管理的范疇里，其實它也是質(zhì)量管理里的一個重要環(huán)節(jié)噩咪。
我們先來看一下版本管理的幾個組成部分吧：
命名規(guī)則
提測包目錄
發(fā)布包目錄
Bug和包的關(guān)系
規(guī)范了版本包顾彰，接下來還需要根據(jù)產(chǎn)品的發(fā)布特性梳理整個項目期間的版本發(fā)包規(guī)則：
- 所有的代碼都 Checkin 到主 Trunk 1.0极阅；
- 開發(fā)到提測時間節(jié)點時，打一個 Tag 0.9涨享；
- 基于 Tag 1.0 構(gòu)建一個 Test Build 1.0筋搏；
- 根據(jù)約定好的構(gòu)建節(jié)奏，持續(xù)構(gòu)建 TB 1.1厕隧，TB1.2奔脐，TB1.3...用于功能驗證測試；
- 驗證測試完成之后吁讨，當(dāng) P40 和 P30 bug 數(shù)量衰減到0的時候髓迎，打一個 Tag 1.6；
- 基于 Tag 1.6 開一個 Branch 1.0建丧，用于這次的驗收發(fā)布驗證或灰度發(fā)布排龄；
- 在這個 Branch 1.0 的測試過程中，有任何代碼的改動翎朱，都需要同步 merge 回主 Trunk 1.0橄维；
- Branch 1.0 開出來之后，下個版本的新代碼就可以開始 checkin 到 Trunk 1.0 了拴曲；
- 在下個版本的開發(fā)過程中争舞，如果有現(xiàn)網(wǎng)緊急修復(fù)疗韵，就可以基于 Branch 1.0 去打分支進(jìn)行補丁版本發(fā)布了蕉汪；
版本發(fā)布流程
《告訴你如何從執(zhí)行測試到管理測試》帶你邁出第（27）步驹马！，點擊這里可查看完整地圖
作者簡介：14 年測試 + 11 年項目管理 + 11 年團(tuán)隊管理 = 一個測試?yán)媳?/p>
