1背景
互聯(lián)網(wǎng)產(chǎn)品的迭代節(jié)奏很快，如何能夠在快節(jié)奏的周期中粗合，保證產(chǎn)品在線上能夠穩(wěn)定運(yùn)行呢
2上線前的方案
2.1 冒煙測(cè)試全員參與
提測(cè)時(shí)萍嬉，組織相關(guān)方（PM\RD\UE\UE\QA）的冒煙測(cè)試，這樣做有如下好處
- 能夠預(yù)防項(xiàng)目進(jìn)行過程中需求不同步的問題
- 能夠最快的從各方角度發(fā)現(xiàn)BUG
- 能夠項(xiàng)目小組預(yù)知該提測(cè)版本的質(zhì)量現(xiàn)狀隙疚，對(duì)整個(gè)測(cè)試上線的時(shí)間有個(gè)預(yù)期
2.2 前期最大化的介入需求
最大化的介入需求過程壤追，能夠在細(xì)節(jié)上有更好的了解，這樣能夠更加深入的覆蓋在文檔中沒有體現(xiàn)的細(xì)節(jié)
- 需求的評(píng)審供屉，QA要提前熟悉需求行冰，帶著問題參加評(píng)審溺蕉，這樣能讓整個(gè)評(píng)審的過程更有效和高效
- 建立接口測(cè)試的常規(guī)化流程，這樣能夠加深對(duì)業(yè)務(wù)底層邏輯和數(shù)據(jù)流的了解悼做，也能夠提升在功能測(cè)試階段的質(zhì)量
2.3 全功能的checkList
每次版本的迭代疯特，除了新需求的這部分功能需要重點(diǎn)測(cè)試和回歸，對(duì)于之前歷史的功能也需要做一個(gè)全面的覆蓋回歸
- 測(cè)試用例的內(nèi)外部評(píng)審肛走，測(cè)試組內(nèi)評(píng)審和項(xiàng)目組評(píng)審
- 整理一個(gè)全功能覆蓋的checklist
- 整理一個(gè)P0級(jí)別的checklist辙芍，主要是頻次使用高和多發(fā)性問題的功能，主要是RD和PM參與上線的check
3上線后的方案
3.1 灰度測(cè)試
版本上線階段羹与，通過灰度測(cè)試故硅，找一批種子用戶試用這個(gè)新的版本
- 能夠檢驗(yàn)新功能的合理性
- 如果產(chǎn)生BUG，能夠最小化的縮小影響范圍
3.2 線上預(yù)防監(jiān)控
- 基礎(chǔ)服務(wù)的監(jiān)控預(yù)警纵搁，OP
- 服務(wù)端的日志監(jiān)控和錯(cuò)誤日志review
- APP端的友盟錯(cuò)誤統(tǒng)計(jì)和BUGLY問題上報(bào)的review
3.3 線上服務(wù)定期回歸
- 每晚重要功能點(diǎn)和問題多發(fā)功能點(diǎn)的回歸（可以依照埋點(diǎn)獲取數(shù)據(jù)）
- 線上問題的周分析會(huì)吃衅，找出疏漏點(diǎn)，優(yōu)化流程
4 效率上推動(dòng)
推動(dòng)力腾誉！快速的消除BUG
4.1 推動(dòng)力如何實(shí)施
- 任何一個(gè)需求的評(píng)審?fù)瓿珊笈遣悖挤e極主動(dòng)的推動(dòng)相關(guān)項(xiàng)目角色的排期、清晰大家的目標(biāo)
- 每天早會(huì)同步目標(biāo)利职，同步問題
- 對(duì)于產(chǎn)品設(shè)計(jì)或者運(yùn)營過程中不好的地方要善于記錄趣效，反饋給PM不斷的完善
- 對(duì)于系統(tǒng)服務(wù)技術(shù)方案上不利于用戶體驗(yàn)的地方也要記錄，反饋給RD同學(xué)
4.2 推動(dòng)力帶來的好處
- 留給后期的全功能回歸的時(shí)間越多
- 有更多的時(shí)間去做一些探索性測(cè)試
- 線上問題影響的用戶面盡量減少
5 改進(jìn)的點(diǎn)
隨著業(yè)務(wù)的越來越豐富猪贪，全功能回歸耗費(fèi)的時(shí)間越來越多跷敬，必須借助工具來提升效率，同時(shí)做到過程數(shù)據(jù)采集和量化
- 一個(gè)好的case管理和執(zhí)行工具
- 自動(dòng)化測(cè)試的引入
