一. 第一步 — 評估bug的影響範圍
（1）分析bug影響的使用者數量
檢查bug是否業務核心環節的功能問題，是的話則影響的使用者量比較多
（2）分析bug影響的嚴重程度
檢查bug是否涉及到使用者的個人資訊洩露、資金財產損失等比較敏感的功能，涉及的話則
認為bug比較嚴重
對於bug影響範圍的評估，必須盡可能的快速且準確，因為影響範圍和程度會隨著時間不
斷擴大，及時了解目前的bug影響，可以為後續解決問題提供最適合的指導意見。
二. 第二步 — 解決線上問題
針對線上問題最重要的是要解決，在評估完影響範圍後，就需要制定對應的措施來解決問 題並恢復系統的正常使用。
（1）影響範圍比較小的bug
了解bug出現的場景，業務操作，努力復現bug
測試人員結合bug出現時的各種日誌（系統日誌、資料庫日誌、操作日誌、debug日
志），定位bug產生的原因
按照專案規劃的發布/公升級的時間節點，將bug修復的**發布到線上，bug解決
（2）影響範圍比較大的bug
bug影響範圍比較大時，如果還是通過修復bug的方式來解決，對使用者的影響或者公司的
損失無法把控，此時最重要的是：將問題範圍降到最低。無法明確問題引入原因時，可
以通過回滾版本的方式來規避。部分使用者功能可以通過後台配置的方式將功能降級或關
閉，如果是資源不足等效能問題時，可以通過重啟系統或者擴容的方式解決，再進一步
觀察，以上幾種規避問題的方法只是幫助我們爭取到時間，規避問題後還是要按照之前
修復bug的方式來定位問題，修復問題，並將修復的**發布線上，將bug徹底解決。
在實際工作中，我們需要根據bug的影響範圍來選取最適當的解決方法，目的只有乙個：
將問題影響範圍降到最低。
三. 第三步 ——回溯線上問題
當線上問題解決後，我們還需要對問題進行總結回溯，避免同樣的問題再次發生。線上
問題回溯主要從如下幾個方面進行：
（1）檢查其他的業務是否有同型別的問題
有問題的話提前解決，避免遺漏上線
（2）分析bug的根本原因，考慮如何避免此類問題再次發生
分析bug是在哪個階段引入？是設計階段、開發階段、測試階段？
分析bug引入的原因是什麼？是流程問題、技術問題、管理問題？
處理問題的流程是否合理？是否有問題預警、是否有緊急上線規範？
立即下線公司內部開發人員對bug進行處理並解決測試再根據情況進行測試和迭代測試
——————————————
這就要看問題的嚴重程度。
如果問題非常嚴重，嚴重影響專案的正常執行，甚至已經給公司帶來了經濟損失，要立刻將專案下線，讓運維人員 檢查是**出了問題，聯絡負責相關**
開發的開發人員，立刻處理bug，將損失降到最低。
然後測試人員測試相關功能，如果還有bug，開發繼續改bug。
如果沒有問題，專案繼續上線。
如果問題不是很嚴重，測試將bug記錄下來，寫道測試總結中，在下一次的改版時，交給開發人員修改bug。
如果專案上線在上線期間出現問題改怎麼辦
第一步及時止損，測試人員可以做的是重現這個問題並及時反饋給開發人員，找到解決方案進行修復 第二步要長記性，由於疏忽造成測試用例執行遺漏，測試人員需要在下次執行測試的過程和下個版本上線的前要補全測試用例並避免這樣的情況發生，不要自怨，堅強不屈，吸取經驗教訓，不斷提高測試能力 先處理bug，上線後出現b...
EDM資料營銷出現問題怎麼辦
在 edm資料營銷時出現一些問題，應該如何處理呢？下面博主為大家介紹一下。電子郵件營銷過程是乙個非常縝密的過程，即使是行業老手，在很多地方也還是容易出問題的。這些問題可能是一些容易解決的小麻煩甚至可能是觸犯法律的大問題，不一而同。問題發生後，如何應對成了關鍵。首先，就是不要慌亂，應該冷靜下來分析，決...
拿到專案該怎麼辦
拿到專案 該怎麼辦！首先 拿到專案後，我們肯定不會乙個人，而是乙個 小組乙個團隊，我們不是乙個人在 單打獨鬥！所以在拿到專案後就要 跟小組成員開會討論，拿到專案後 會拿到如下圖所示，各個頁面的樣式 和用ps檢視圖層的 我們現在 就可以把 相似的頁面 分類 分為 幾人組，讓小組 成員去 選擇乙個 型別...