引言
項目流程如果不分階段的梳理好,效率低,導(dǎo)致項目上線延期,對于產(chǎn)品質(zhì)量也得不到充分的保障.清晰的流程,會提升效率,少走彎路,節(jié)約時間、高效的定位問題、解決問題、保障質(zhì)量。若有多各個項目并行迭代，也能有條不紊的進行，順利保證項目上線。流程圖參考如下：
測試流程.jpg
（1）需求收集評審階段
- 需求來源收集：新增功能模塊需求、復(fù)盤、專項需求、Bug反饋。
- 整理需求、產(chǎn)品內(nèi)部評審需求方案是否通過。
（2）版本規(guī)劃階段
- SDK版本號、游戲版本號確認
- 版本迭代方式(強更/熱更)，設(shè)計好更新文案
- 需求文案出稿（文案涉及業(yè)務(wù)邏輯方面盡可能多闡述，如有埋點需求，也同步出稿）
- 若有多個項目迭代需求，產(chǎn)品內(nèi)部定優(yōu)先級
（3）版本排期階段
- 需求評審: 產(chǎn)品、開發(fā)前后端、美術(shù)、測試一起參與會議討論，最終確認到需求文案中。
- 禪道建立版本開發(fā)任務(wù)，相關(guān)人員排期，測試在前后端排期后根據(jù)需求新增功能模塊、業(yè)務(wù)邏輯、版本兼容等實際情況排出測試時間。
- 確定項目上線時間
（4）版本設(shè)計開發(fā)階段
- 產(chǎn)品跟進項目進度、美術(shù)進度、功能實現(xiàn)進度，相關(guān)人員及時更新禪道完成情況。需求若有變更，產(chǎn)品回復(fù)開發(fā)郵件，對應(yīng)需求文檔同步更新至禪道。
- 前后端聯(lián)調(diào)，保證業(yè)務(wù)邏輯正常。
- 測試設(shè)計功能測試用例（包含新增模塊、業(yè)務(wù)邏輯流程、版本兼容），發(fā)郵件告知前后端用例數(shù)量、控制Bug率，提高質(zhì)量。
（5）版本測試階段
- 產(chǎn)品發(fā)提測郵件、待前后端回復(fù)提測郵件后測試發(fā)冒煙測試用例郵件，同時部署測試環(huán)境。
- 冒煙測試若業(yè)務(wù)邏輯阻塞，打回讓開發(fā)修復(fù)后再提測，此時測試時間，上線日期也會適當(dāng)延后。
- 冒煙通過后測試依據(jù)測試用例、業(yè)務(wù)場景進行功能測試。
- 新版本更新方式校驗（強更、熱更）、設(shè)備機型兼容測試。
- 版本兼容（前后端兼容）后端數(shù)值兼容測試、若針對渠道優(yōu)化，需渠道兼容測試
（6）灰度&上線階段
- 回歸驗收通過，告知團隊準(zhǔn)備上灰度。
- 產(chǎn)品確認好上線配置、上線功能開關(guān)，此時沒有特殊原因，版本不再新增需求。
- 灰度環(huán)境：測試校驗主功能、版本更新方式（1194渠道）校驗 ，灰度測試通過進入生產(chǎn)環(huán)境校驗。
- 生產(chǎn)環(huán)境：校驗線上版本兼容當(dāng)前新版本后端，保證主流程業(yè)務(wù)邏輯測試通過。
- 生產(chǎn)環(huán)境：主流程測試通過后，進行15個渠道包更新方式校驗。
（7）項目收尾階段
- 測試發(fā)送測試通過郵件，如有遺留優(yōu)化Bug，告知產(chǎn)品及相關(guān)人員，下個版本迭代修復(fù)。
- 如有提審渠道，渠道包給產(chǎn)品提審
- 生產(chǎn)環(huán)境如有不合理測試數(shù)據(jù)，及時告知相關(guān)人員刪除。
- 相關(guān)人員及時更新禪道自己對應(yīng)的任務(wù)狀態(tài)。
（8）版本復(fù)盤
- 復(fù)盤需求方案建立、復(fù)盤數(shù)據(jù)核對。
- 開展復(fù)盤會議討論、分析數(shù)據(jù)、為后續(xù)版本迭代參考有價值信息。
- 會議結(jié)束，出復(fù)盤文檔。
（9）測試巡檢
- 上線后在空檔期進行線上分模塊巡檢測試，加強主業(yè)務(wù)功能測試。
- 匯總問題，出巡檢測試報告，下個版本優(yōu)化修復(fù)匯總問題。
