從事it網際網路的人都知道，bug是程式設計師和測試人員最不喜歡面對的東西，很多人對於軟體**現bug這個事情，第一想到的就是測試人員的問題，因為他們都覺得這是測試人員沒有測試出軟體中存在的bug，導致後續軟體上線問題浮出水面。其實，出現bug這種情況是由很多原因造成的，不僅僅是測試人員一方的問題，切記不要把鍋全部甩給測試!出現bug在所難免，也並不可怕，可怕的是互相甩鍋推卸責任，導致bug一直留在那裡造成其他更大的負面影響和損失。
軟體中bug的出現還有其他原因：比如產品原型不清楚，有歧義。導致產品經理跟客戶之間是有歧義的，導致後期交付到專案方手裡，被當作了bug。另外，在專案開發方面，開發人員開發完後並沒有先自測，測試在測試回歸階段會因為一些隱秘的東西測不全。再或者是後期更改需求了，開發者加進去了，但是測試並不知道，造成未能及時測試出bug等。各種各樣的因素都會導致bug的出現，有時候bug的出現是整個團隊的問題造成的。
那我們應該怎麼處理軟體上線後暴露的bug呢?
一、即時反饋即時響應
不管是技術團隊，還是運營客服團隊，在軟體上線或提供給客戶使用後，都應該定期的去跟蹤軟體是否在正常工作，如果有客戶遇到問題(可能是乙個bug)應該及時的做好問題的收集、分析，並作出正確的反饋處理。問題不可怕，可怕的是這個問題一直留在那裡，可能使用者多用幾次怒火中燒，直接把它打入冷宮，更甚者給軟體提供組織帶來巨大的負面影響和經濟上的損失。
二、即時分析即時處理
當收到問題後，應該及時反饋給研發團隊，確定是否為bug，如果非bug的，那確定問題產生的原因，並讓問題對接人知曉後反饋和客戶。
如果確定為bug後，則需要對bug的嚴重等級進行評級。如果是輕微或者不會對使用者使用造成太大問題的，可以作為優化項放到後面版本迭代時進行修復。反之嚴重問題，就應該找到bug所屬模組的程式負責人，確定解決方案，並及時發布對應得補丁包或者給出解決措施。同時，問題對接人一定要給使用者進行反饋或說明，包括對解決方案的簡單說明。
三、問題處理完畢，查詢問題原因
bug出現的原因是什麼，可能有以下幾種情況：
1、測試環境無法重現
可能是線上的環境造成的bug或者是測試環境無法模擬的情況。
解決方法：盡量完善測試方法，盡可能模擬**線上測試環境，以及增加上線後的複查確認測試。
2、漏測
a、測試用例裁剪過度：錯誤預估優先順序或者時間過於緊迫裁剪了用例
解決方法：在後續版本或者其他專案啟動時重新評估測試時間，要求專家介入對優先順序進行評估，避免此類事件再次發生。
b、測試用例執行期間遺漏：由於測試人員疏忽造成測試用例執行遺漏
解決方法：調查該名測試人員的整個測試過程的工作情況，並隨機抽測其他模組，對該名測試人員進行綜合評估，給出結論，是因為疏忽漏測，還是因為負責模組過多漏測，還是有其他原因。應該及時反饋給測試經理，並對該測試人員後面的工作進行調整和處理。
c、測試用例覆蓋不全：需求模糊導致的，由於用例評審的不嚴格造成的;中途需求變更造成的;由於某些其他因素造成的
3、程式的質量問題
出現bug，肯定是因為程式出了問題。黑盒測試是很難發現邏輯和**層面的所有問題的。所以也應該從開發的角度去評估bug出現的原因，可能是因為開發粗心疏忽導致的，也可能是開發人員蓄意隱藏出現的。
解決辦法：首先確定bug出現的原因，如果是因為粗心，如錯誤的大小寫、錯誤的引數變數導致的，應該讓對應開發人員做出整改。如果是深層次的邏輯問題導致的，那應該在後續專案和版本中加大**的走查測試。
4、產品實際使用超出想象，導致的bug
這應該是整個團隊的問題，應該吸取經驗。規劃一款新領域、業務的產品，對這個領域可能沒有深入的理解，那麼可能會導致一些意想之外的bug。比如我經歷過的無人值守停車場的物聯網專案，主要依賴於攝像頭進行車牌識別然後進行車輛的放行。因為周期短，並且地域的限制沒做太過周全的測試，一開始也沒有暴露問題。但是實際使用中，發現攝像頭外殼因為沒有考慮導熱設計，導致在高溫暴曬下出現攝像機宕機。在陰暗潮濕環境下，車輛如果角度不正對攝像頭，導致識別錯誤等。你能說這是測試的問題，或者開發的問題，或者硬體的問題，工藝的問題。只能是大家經驗不足，是團隊所有人的問題。
5、產品上線後，在某種作業系統下出現相容性的問題，是誰的責任？
主流的系統，比如win10，有相容性的問題，肯定是測試的問題，沒有覆蓋主流的系統。後面應該明確需要相容的系統並進行測試。
歷史系統，比如xp，有相容性問題。但是規格明確寫明不支援xp。那麼有可能是市場調研、需求的問題，沒有搞清楚產品的實際客戶和特性。也有可能是使用者手冊的問題，沒有提示不支援xp，導致錯誤的安裝。還有可能是軟體的問題，沒有做保護，檢測到是xp系統，就應該停止安裝並提示系統版本太舊。而不是一路走到黑，安裝完出現一些相容性的問題。這都是需要後期進行考慮的。
四、追責
一般來說，上線的bug不能完全歸咎於某乙個人，或者是歸咎於測試部、開發部，這是乙個團隊合作的過程，出了紕漏誰也逃不掉，應該及時止損，吸取經驗教訓，在今後的版本或者專案中規避類似的問題出現。當然，如果真的是某個人的責任，那麼專案組就應該給予警告，讓其後續吸取教訓杜絕類似問題出現。
五、避免同樣的錯誤
第一次出現的問題處理好了，這事可以過去了，但是出現過的問題最好不要再次出現，否則一而再再而三的出現同樣的問題，會讓boss和領導懷疑整個團隊或個人的能力及責任感。所以，記得汲取教訓，避免以後跳進同乙個bug坑里。
專案上線後出現BUG該怎麼解決
一.第一步 評估bug的影響範圍 評估bug的影響範圍是處理線上bug的第一步，通常需要根據評估的結果來決定下一步的處理方案。影響範圍要從哪些方面進行評估呢？1 分析bug影響的使用者數量 檢查bug是否業務核心環節的功能問題，是的話則影響的使用者量比較多 2 分析bug影響的嚴重程度 檢查bug是...
關於極少出現的BUG怎麼辦
剛才看了一篇文章是關於一種10000次才出現一次的bug，用的是設定條件斷點，用vc的話其實也可以直接呼叫debug方面的api。但是，我有個問題，100000000次才出現一次的bug怎麼辦？別以為這是天方夜譚，在我的開發中，真真實實的出現過這種情況。當時具體作的專案記不大清了，不過這個問題是關於...
如果專案上線在上線期間出現問題改怎麼辦
第一步及時止損，測試人員可以做的是重現這個問題並及時反饋給開發人員，找到解決方案進行修復 第二步要長記性，由於疏忽造成測試用例執行遺漏，測試人員需要在下次執行測試的過程和下個版本上線的前要補全測試用例並避免這樣的情況發生，不要自怨，堅強不屈，吸取經驗教訓，不斷提高測試能力 先處理bug，上線後出現b...