什麼是bug？
功能不符合需求， 不正確或缺失的異常處理，不符合用戶使用習慣的(要根據實際情況來)， 超出用戶期望的需求(畫蛇添足，也不一定)
一個bug單包含哪些要素
1、所屬的系統(產品)
2、發現的版本（輪次）
3、發現bug所屬的模塊
4、bug提交人
5、bug的錯誤類型：代碼錯誤、界面優化、設計缺陷、配置相關、安裝部署、安全相關、性能問題等（默認）
6、bug的重現概率： 必現 大概率重現 小概率重現 極小概率重現
7、bug的嚴重級別：致命 嚴重 一般 提示 （影響範圍越大，嚴重級別越高）
8、bug的優先級：高 中 低
9、bug的標題 言簡意賅說明是什麼bug， 而不是把測試用例名字複製一遍
10、bug單號 一般系統自動生成
11、bug內容：發現的環境、 預製條件、重現步驟、預期結果、實際結果， 截圖證明，bug錯誤說明，(當開發看到能容能夠獨立重現這個bug，說明寫的還行)
12：附件：測試用的數據或者出錯的日誌， 如果需要添加上日誌
提交bug的時候儘量把截圖附上，並對截圖進行標註，如果不好描述的可以錄製視頻， 如果是偶現bug ，把發生這個錯誤的錯誤日誌，操作過程說明清楚
畢竟字不如圖，描述半天不如一張圖， 圖不如視頻
發現bug爲什麼要提單？
1、bug容易漏掉，導致bug遺漏到客戶那裏
2、把bug錄入系統，給開發提供bug解決的依據，哪些bug 要優先改、哪些bug可以先不修改、
3、把bug錄入系統，方便開發定位這個bug，因爲bug會記錄重現步驟
4、把bug錄入系統，方便測試知道哪些bug 需要修改但是未修改，哪些bug已經修改可以迴歸
5、提交bug，測試人員有成就感
6、把bug錄入系統，是研發過程改進的大數據庫，根據不同維度的統計數據，發現研發過程中存在的問題
針對第6點舉例： 比如問題單過多（可能模塊太複雜，分給技能不熟練的人了，可能是這個人就沒有認真幹活）， 比如問題單迴歸不通過數量多（修改問題單不認真，導致延長測試周期）， 比如 版本上線後線上問題多 （測試不到位，測試點覆蓋不全，測試設計和用例評審不到位，或者執行的時候不認真 該打測試板子），通過這些數據我們可以優化我們的研發過程，提升團隊的效率
bug解決者一般填寫哪些內容
1、bug的解決方案有哪些：
設計如此、 重複bug、外部原因、已解決、無法重現、延期處理、不予解決
2、bug解決版本
3、問題原因
4、解決問題的方案
5、解決方案的影響範圍
開發寫這5點的目的是方便測試迴歸，迴歸時測試更有重點
bug迴歸的時候應該怎麼處理
前提： 迴歸之前，如果這個bug涉及到代碼修改，那麼修改好的代碼一定是部署到測試環境了
1、閱讀解決方案的內容
2、檢查問題單中的場景是否修改
3、檢查解決方案影響範圍的功能是否正確
閱讀1、2、3， 測試2、3涉及到的場景，都通過時， 問題單關閉，否則問題單打回給開發，讓重新修改
對於不予解決或者設計如此的問題，如果不認可開發的解決方案，有疑問怎麼處理？
1、認真閱讀不予解決的原因，或者這樣設計是否合理
2、如果認可原因，即可把問題單給關閉掉，如果不認可，反饋給測試領導吧
Bug處理流程
流程描述：
1、測試人員發現bug 提交給開發。
2、開發人員判斷是否是bug。
3、如果是bug，進行修改，修改完成後更改bug 狀態爲已解決。
4、如果不是bug，退回給測試人員並描述退回原因，或爲設計如此，或爲外部原因，
或者不能重現。
5、開發人員修改完成的bug，由測試人員進行驗證，確認修改正確，關閉bug。
6、驗證未通過的bug 重新激活，開發人員繼續修改，直至驗證通過，關閉bug。
7、測試人員需要對開發人員退回的bug 進行確認。
8、確認不是bug 關閉。
9、如與開發人員意見不一致，認爲是bug，需提交項目負責人仲裁。
10、項目負責人確認是bug 由開發人員修改，不是bug 由測試人員關閉。
測試處理bug單經常會遇到哪些問題
1、bug修改不完整 ，bug打回
2、開發說bug不是問題， 和開發溝通，不能達成一致，走給測試負責人處理
3、測試中不停發現BUG，一些比較小的BUG還要提嗎？
當然要提，
4、項目要着急上線， 但是還有一些bug沒處理，這個時候應該怎麼辦？
把這些bug的影響範圍彙報上去， 至於要不要上線讓領導定奪，咱們負責把bug的風險給彙報上去
偶現問題如何處理
1、出現bug後，首先截圖，查看日誌，把對應日誌保留下來
2、嘗試重現這個bug ，思考這個bug可能產生的原因， 然後每個原因逐步驗證，如果重現不出來，可以找開發幫忙 ， 這個步驟是爲了準確找到重現bug 的步驟， 開發修改的時候就容易多了，不然又會和開發來來回回扯皮
3、如果實在重現不出來， 還是要提交bug 的， bug單一定要寫清楚bug出現的環境， 版本、步驟， 錯誤截圖， 對應的日誌， 儘可能多的提供出現bug時的信息， 方便開發定位
怎麼和開發溝通bug
1.把自己的Bug Report完善；有時候開發看到一些莫名其妙的Bug Report會很生氣，這樣首先就影響了你在他心目中的印象，要讓別人改正，首先要保證自己是正確的、完善的。
2. 對事不對人；找開發的時候應該針對具體的問題，可以用“我們的軟件出現了這樣的問題”，而不要說“你這裏寫的不對”。
3. 擺事實；對於具體的bug，可以給開發說明一些事實，例如某個樣式問題其實十分影響用戶體驗。
4. 挖歷史；如果以前有類似的問題，可以把那個問題，以及造成的後果給開發闡述一下。
5. 平時跟開發拉好關係。測試立場要堅持， 該提bug還得提
6. 把更高層的人拉進來；很多時候都是公說公有理婆說婆有理，這時候就需要一些第三方的同事來幫忙，這個人通常要是能說事的才行，例如研發總監或者項目經理，但是主要不要讓人覺得狐假虎威的感覺，這招不適宜經常用。
缺陷的分佈特徵
缺陷往往喜歡扎堆，一個模塊已經發現的缺陷比別的模塊多，通常不是代表這個模塊已經把缺陷暴露完了，而是意味着這個模塊還存在有同樣多的缺陷尚未被發現。這就是著名的二八定理：80%的缺陷出現在 20%的模塊。
如果一個模塊bug較多，怎麼來判斷這個模塊bug發現乾淨了？ 那就是連續2輪發現的bug都很少
缺陷的抗藥性
測試進行得越多，新缺陷就越難被發現
因爲之前一直使用同樣的測試思路，同樣的一套測試用例，沒有新的突破。
某些缺陷天然地只有在很特殊或者很極端的情況下才會被觸發
所以需要進行交叉測試、bug學習（不斷在擴展我們的測試思路）、發散測試
發佈時並非所有的缺陷都要修復
有一些原因，使得有些缺陷我們不修復：
沒有足夠的時間
不算真正的軟件缺陷，可能這個bug是優化
修復的風險太大
不值得修復