通常情況下，大家普遍更加關注生產上出現在的問題，對於測試環境的bug呢，解決完了也就完了，很少再去關注。自然就沒有挖掘出bug背後的有效資訊。
最近小熊在著手進行質量持續改進，試著將各專案測試環境的bug匯出，整體上進行分類，歸因，看看能否找出問題背後的問題。
質量管理的帕累託圖法就說明，一般80%的問題，都是由20%的原因引起的，希望我們也能總結分析出那背後的20%原因來。
平時在測試過程中，一般發現問題，待開發解決，再回歸驗證，就基本結束了。
很少有人會多想想，這些bug為什麼會產生呢？什麼原因引起的呢？如何能避免重複的bug一錯再錯呢？
目前很多公司都是迭代開發模式，乙個迭代，乙個迭代，迴圈往復不停歇！
所以測試人員可能並沒有過多的經歷來分析過往的bug。
bug所暴露的一基本資訊就被忽略了，自然也無法被發現。
這件事是非常有意義的，如果我們能通過歸因把bug產生原因找出來，從設計和開發階段就改進的話，那麼很多情況在設計和問題就沒有必要流轉到測試環節了。
【以上是bug一次就驗證通過的情況】
【需要修復兩次解決的情況】
【一次測試通過的情況】
看到上面的bug時間成本了吧？測試和開發的小夥伴，每天有好多時間，就在和bug的纏綿中度過
不禁想起那首《時間都去哪了》
那麼問題都有哪些呢？
例如小熊發現在一些問題主要是介面沒有明確標準、異常方面沒有考慮，sql錯誤、提交併發等等。。。
當有了這些發現後，需要對每種情況制定相應的預防方法，例如介面問題，可以修訂到開發規範，
異常情況的預防，則需要在開發設計階段引入，
sql錯誤的預防則是要求開發寫完**進行自測
併發問題定為介面標準 等等。。。
每個公司的情況不同，大家都可以分析分析，定有收穫！
希望大家在質量這條路上越走越遠，越來越好。
另外小熊正在讀《質量免費》這本書，書中的很多觀念都非常棒，感興趣的小夥伴可以讀讀。
BUG 的分析 彙總
文章一 文章二 1.bug 分析的目的是未來避免相似bug 的發生。收集頻發 代表性的bug，深入分析bug產生的原因，在產品的設計 開發 測試過程中避免相同bug。所以bug 產生的原因要細化到具體的環節上，責任到人。2.只分析有代表性的bug，專注於分析影響大 有代表性 典型的bug。3.需要收...
bug程度分析
此欄位描述 bug 的嚴重等級。blocker,critical,major,normal,minor,trivial,enhancement blocker 會擋掉所有開發中 測試中的工作 critical 系統發生 crash 資料遺失 嚴重的記憶體流失 major 功能出現較大型的問題 nor...
深入BUG分析
一 認識bug 軟體bug是由於軟體開發者的疏忽和失誤造成的。軟體bug是軟體生命週期內發現和未被發現的所有問題總和。全面質量管理和全程軟體測試 軟體bug不單指軟體測試階段發現的軟體系統的功能性錯誤，還應包括軟體開發過程中需求 設計 開發等階段評審過程發現的問題，以及軟體發布後客戶發現並反饋的問題...