轉(zhuǎn)測試

轉(zhuǎn)測試是項目上線前最后一道坎饿肺，需求全部做完并自測后，項目就進(jìn)入了轉(zhuǎn)測試階段朦前。很多沒想到的問題都會在這個階段涌現(xiàn)出來，這個階段大家都會很辛苦鹃操，通常都會加班加點韭寸。為了緩解這個階段的壓力，我們需要做以下幾個改進(jìn)：

一荆隘、提前做測試

把一些可提前做的事情放到轉(zhuǎn)測試之前做恩伺。比如：UI設(shè)計師正常是在轉(zhuǎn)測試后來驗收視覺效果。但項目周期只要超過1個月椰拒，我就會要求UI驗收在每一個前端頁面完成后晶渠，就開始驗收視覺效果。當(dāng)然這個提前燃观，要根據(jù)設(shè)計師的工作情況靈活調(diào)配褒脯。一般公司還會有UE設(shè)計師崗位，是驗收交互流程的缆毁。同樣也可以提前驗收番川。

如果是一個時間周期很長的項目，我更傾向于分階段轉(zhuǎn)測試脊框。比如本來項目發(fā)開周期需要兩個月颁督，根據(jù)需求分類，我們可以分成兩個階段性的里程碑浇雹。完成第一個里程碑就把這一部分轉(zhuǎn)測試沉御。這樣測試壓力就被分散了。

二昭灵、讓開發(fā)人員做好自測后在轉(zhuǎn)測

測試人員會根據(jù)測試用例驗收功能吠裆，首先會進(jìn)行單元測試和簡單的集成測試。本來這個是開發(fā)人員做的烂完，但是測試人員會按流程走一遍试疙。如果連基本功能測試都通不過，會直接打回窜护。所以效斑，讓研發(fā)人員自測后在轉(zhuǎn)測試，以免浪費時間柱徙。

還有一種回歸測試的時候經(jīng)常出現(xiàn)的問題：測試反饋一個問題缓屠，開發(fā)說已經(jīng)改了，兩個人可能因為溝通方法不對就吵了起來护侮。最尷尬的是測試人員當(dāng)著開發(fā)人員面給復(fù)現(xiàn)了bug敌完，所以為了自己不尷尬，自測是一定要做好的羊初。

三滨溉、給測試用例分優(yōu)先級

測試用例一般在需求確定后就開始準(zhǔn)備了。最開始我們團(tuán)隊里的測試是按照評審后測試用例的先后順序來測試长赞。這樣測試一輪需要非常久的時間晦攒。后面我們決定給測試用例的子項也做一個優(yōu)先級。先做常見的主流程測試得哆，然后在測試異常測試脯颜。對于需要前置資源的測試，統(tǒng)一拿到資源后在測試贩据。這樣測試的效率大大提升了栋操。

一般測試需要用到的工具、賬號都應(yīng)該在轉(zhuǎn)測試之前準(zhǔn)備好饱亮。

四矾芙、普及自動化測試

很多功能測試都是靠人力去測試的，所以測試周期會很長近上。要想辦法培養(yǎng)測試人員走自動化測試的道路剔宪。不要讓人力成為測試的瓶頸。目前市面上很多自動化測試的工具壹无，測試人員想要更進(jìn)一步歼跟，還是要多學(xué)會使用一些測試工具。當(dāng)然不是為做而做格遭，而是要根據(jù)工作中的要求哈街，選擇性地來學(xué)習(xí)。工欲善其事必先利其器拒迅。

五骚秦、善用第三方測試工具

很多測試工作市場上都有相對完善的測試工具，沒必要自己去模式環(huán)境璧微。比如作箍，對于一些兼容性測試，可以使用云測試這種第三方平臺來輔助測試前硫。公司只需要購買使用用戶最多的幾款機(jī)型即可胞得。

六、使用bug管理工具

測試工程師根據(jù)測試用例測試出的bug都會提交到項目管理軟件屹电，測試出一個提交一個阶剑。對于能復(fù)現(xiàn)的會有復(fù)現(xiàn)的操作步驟和日志跃巡。不能復(fù)現(xiàn)操作的，要提供日志牧愁。同時備注bug等級素邪。一般會優(yōu)先處理bug等級高的。我前面推薦的teambition猪半、worktile兔朦、tower之類的項目管理軟件也可以用作bug管理。

bug提交后磨确，研發(fā)人員能夠收到提醒沽甥，在這一階段研發(fā)的工作主要是修復(fù)bug，如果前期業(yè)務(wù)邏輯理解的很清晰乏奥，編碼規(guī)范摆舟、自測也做得好。這一階段相對是很輕松的英融。如果做得不好盏檐，那情況會很糟糕，bug會越改越多驶悟。如果真到這一步了胡野，只能優(yōu)先去處理等級高的bug。

異常情況

如果測試到最后痕鳍，真遇到bug多到達(dá)不到上線標(biāo)準(zhǔn)硫豆。怎么辦？這時候項目負(fù)責(zé)人千萬不能強(qiáng)行上線笼呆，準(zhǔn)備上線后在進(jìn)行修復(fù)熊响。這種冒險不值當(dāng)，可以選擇砍掉一部分你不重要的需求或者項目延期诗赌。絕不能帶著重大bug上線汗茄。

上線前準(zhǔn)備

項目測試達(dá)標(biāo)后，就需要著手啟動上線了铭若。在項目上線過程中我們還需要做以下準(zhǔn)備洪碳。

一、制定上線清單叼屠，先上測試環(huán)境

清單的要素包括：什么人瞳腌，在什么時間，需要準(zhǔn)備什么資料镜雨，做什么事嫂侍。其中，要明確先后順序，要明確如何驗證是否出現(xiàn)異常挑宠、明確驗證方式以及問題處理方式菲盾。

有條件的，要搭建一個跟正式環(huán)境一模一樣的測試環(huán)境痹栖。先在測試環(huán)境預(yù)上線一次亿汞，把所有的相關(guān)環(huán)節(jié)的資料和流程用清單的形式記錄好瞭空。尤其是上線過程中遇到的問題揪阿。解決后，再重新再走一遍上線流程咆畏。最好是能全自動部署南捂，減少人工參與。

二旧找、做好數(shù)據(jù)備份

上線之前溺健，先對前一個版本進(jìn)行備份。包括程序和數(shù)據(jù)钮蛛。一旦上線出現(xiàn)問題鞭缭，要能一鍵還原上一個版本。

三魏颓、上線時間

不要在周五上線版本岭辣。項目上線后，我們還需要觀察甸饱，所以要盡量避開周五沦童。另外項目上線的時間通常要選擇使用人數(shù)最少的時間，這樣受影響的用戶最少叹话。大部分情況都是在凌晨之后偷遗，所以一般項目上線后會聚個餐（早餐）

四、給相關(guān)人員做好培訓(xùn)功能

主要是給服務(wù)部門做好培訓(xùn)驼壶。比如客服氏豌、運營、銷售热凹。尤其是客服泵喘，要告知其可能出現(xiàn)的問題以及應(yīng)對方案。避免用戶反饋問題碌嘀，客服不知道的情況涣旨。這個也可以在測試階段去做，根據(jù)培訓(xùn)的工作量靈活調(diào)整股冗。

五霹陡、數(shù)據(jù)監(jiān)控和預(yù)警

上線后，還需要觀察一段時間正常的用戶日志和系統(tǒng)日志。有條件的還需要對重要業(yè)務(wù)設(shè)置關(guān)鍵性指標(biāo)烹棉。指標(biāo)出現(xiàn)異常要能夠有短信或電話預(yù)警攒霹。對異常的數(shù)據(jù)要去排查原因。這里不僅僅只考慮”壞“數(shù)據(jù)的異常浆洗，還要考慮“好”數(shù)據(jù)的異常情況催束。另外，數(shù)據(jù)異常不代表是程序有問題伏社，也可能是業(yè)務(wù)上引發(fā)的效應(yīng)抠刺。

六、A/Btest 驗證新功能效果

如果怕出現(xiàn)問題摘昌，可以提前對新功能做好A/Btest的控制速妖。A/Btest是指用戶打開軟件后，一部分用戶看到的老業(yè)務(wù)A的業(yè)務(wù)流程聪黎，另一部分看的是新功能B的業(yè)務(wù)流程排作。這樣便于我們觀察新功能對用戶行為帶來了什么影響膀值。如果數(shù)據(jù)下降很大找御，那說明新功能可能有問題畦粮，我們可以主動隱藏新功能。

七喉镰、復(fù)盤

上線后要做一個項目復(fù)盤旅择，復(fù)盤的目的有兩個：

一、對于項目中出現(xiàn)的問題梧喷，要找原因砌左。根據(jù)原因再想解決方案。避免在后面的項目中再次出現(xiàn)铺敌。比如說項目延期汇歹，可能每次都會出現(xiàn)，但每次出現(xiàn)的原因并不一樣偿凭。只要我們堅持改進(jìn)产弹，團(tuán)隊總能達(dá)到預(yù)期完成計劃的一天。

二弯囊、對于項目中做的好的痰哨，也要講，該表揚表揚匾嘱，能推廣的推廣斤斧。表彰推廣就是我們團(tuán)隊的價值觀體現(xiàn)。我們經(jīng)常說要打造組織文化霎烙，對工程師群體來說撬讽，組織文化就是在項目過程中生長起來的蕊连。

異常情況

上線前準(zhǔn)備也可能會碰到一些異常情況。這個時候出現(xiàn)問題游昼，只能先找原因甘苍，解決后才能上線。比如烘豌，我們在上線測試環(huán)境的時候载庭，非常順利。但是在正式環(huán)境上線后就出現(xiàn)了異常廊佩。這種問題一般是某個環(huán)節(jié)錯誤操作或者遺漏操作導(dǎo)致的囚聚。說到底還是上線清單寫得不夠詳細(xì)。不過也不要過于擔(dān)心這種情況罐寨，解決的多了靡挥，出現(xiàn)的概率只會越來越小序矩。

最后鸯绿，在項目上線并且確定沒問題之后，要給團(tuán)隊一個緩沖期簸淀，緩解一下壓力瓶蝴。所以說周四上線是最好的，周五發(fā)現(xiàn)沒什么事租幕。周六周日就能好好休息一下舷手。休息是為了更好的工作，因為下一個版本的需求馬上就要來了劲绪。