產品上線前開會討論能否上線，統計有哪些方面的BUG，BUG嚴重程度，是否影響使用。客觀分析是否合適，不要誇大，也不要隨意。
這裏我們將線上問題大致分爲三類：
一、臨上線發現致命問題。如：流程走不通，某個模塊崩潰閃退，某個功能走不通對主流程有影響；這種情況一般不允許上線，最終結果需要各部門討論
二、影響用戶體驗，或使用頻率較高，可能影響後續流程的。如：電話號碼只允許輸入八位數，不能輸入11位數；或是公司名稱只能輸入一個字；這類BUG不影響正常功能使用，上線前評估，如果能解決則解決再上線，若花費時間較長，可以先上線再修改
三、輕微BUG。如：頁面交互，提示語信息等；這類問題上線後再優化
原則上來說，上線前存在P1、P2級別的BUG，不允許上線，可能之前漏測，可能修改出現的新BUG；當然，具體如何還需結合實際情況，打個比方：如果今天不上線，明天產品會失去作用。那麼這就需要與pm和開發分析，解決這個bug需要多久。如果需要兩個小時修改，可以上線後同時修改，或延遲2小時上線。
上線時如何做：
測試人員安排上線之後的測試（驗收測試、對線上產品進行簡單的冒煙測試），線上版本測試通過之後纔是大功告成。
上線後需要快速得出結論，從其他部門借調人手配合測試，可能是其他項目組的測試人員，也可能是其他部門的非測試人員。非測試人員需要搭配一個測試人員帶領測試
若得出結果，出現重大漏洞，需要緊急下線；
如果問題影響較小，可以維持上線狀態，同時緊急修復BUG。
對於兼容性問題，如閃退之類的，需給出具體數據，比如：在現有條件下，哪些型號的手機會出現閃退問題，哪些型號手機沒有問題。
如果只有一個產品，則需下線維護，如有web端和APP端互爲替代，則可以先上一個產品。
功能影響的是自己公司內部，可以允許上線，比如：審批流程有問題，影響不到客戶，可公司內部協調規定，不影響上線。
總結：
1、完整的測試流程，每個環節注意事項，尤其是測試用例和bug。用什麼用例，發現什麼BUG，印象深刻的BUG怎麼發現的，用例數量、BUG數量，計劃三要素：工作安排、里程碑、風險分析是怎麼考慮的。
2、項目上線後需要對項目的整個過程進行總結。包括對於團隊的總結和個人的總結，項目的得失，反思和改進。儘可能的在以後的迭代中避免同樣的問題發生。