bug的一生：軟體測試員，你是如何利用專業技術修復bug的？

bug像是一個被過分寵愛的小孩子，得到了特別多的關注。它們在開發者的IDE裡悄然無聲的誕生，但在現身之刻卻引來一片喧鬧“——bug的一生

Bug的出生證明

1945年9月9日，下午三點。哈珀中尉正領著她的小組構造一個稱為“馬克二型”的計算機。這還不是一個完全的電子計算機，它使用了大量的繼電器，一種電子機械裝置。第二次世界大戰還沒有結束。哈珀的小組日以繼夜地工作。機房是一間第一次世界大戰時建造的老建築。那是一個炎熱的夏天，房間沒有空調，所有窗戶都敞開散熱。

突然，馬克二型當機了。技術人員試了很多辦法，最後定位到第70號繼電器出錯。哈珀觀察這個出錯的繼電器，發現一隻飛蛾躺在中間，已經被繼電器打死。她小心地用攝子將蛾子夾出來，用透明膠布帖到“事件記錄本”中，並註明“第一個發現蟲子的例項。”

從此以後，人們將計算機錯誤戲稱為蟲子（bug）

軟體測試中bug的生命週期

對於測試人員來說，bug的生命週期一般分為：發現bug—>提交bug—>驗證bug，那在這三個階段中如何體現測試的專業度呢？

第一階段：發現bug

1、充分利用80/20法則

80/20法則，又稱為，馬特萊法則、二八定律、帕累託定律、最省力法則、不平衡原則、猶太法則。

80/20法則揭示了80%的成果源自僅僅20%的行動，體現了投入與產出不平衡的“普遍真理”。

一般情況下，80/20法則適用於以下軟體測試情景：

80%的軟體缺陷存在於20%的軟體程式碼中（軟體缺陷的“群集”現象）

80%的軟體缺陷歸因於20%的軟體缺陷原因（軟體缺陷的“群集”現象）

在分析、設計、實現階段的複審和測試工作只能夠發現和避免80%的軟體缺陷，而系統測試也只能找出其餘Bug中的80%。

2、跟開發人員有效溝通

跟開發人員有效溝通，既可以溝通個人之間的友情，還可以獲得開發相關的知識，更可以得到有益於軟體測試的資訊。

3、從不同角度進行測試

從管理層的角度考慮，我們要了解被測產品在公司眾多產品中的優先順序，做到軟體測試的有效性，即確保軟體缺陷的有效性。

從開發人員的角度考慮，獲知開發人員認為軟體產品中那些模組開發難度大，缺乏信心，從而快速定位我們的測試重點。

從最終客戶的角度考慮，儘可能從他們的既有的使用習慣和可能的問題出發，也就是使用者體驗出發，找出儘可能多的軟體缺陷。

4、選擇簡易有效的測試工具

比如，網頁的連結測試，如果選擇一些簡單易用的連結測試工具，既能提高覆蓋率，又能發現較多的軟體缺陷。

5、進行專項測試

比如，安裝測試，解除安裝測試，雙（多）位元組測試，查詢測試，上傳附件測試，快捷鍵測試，UI整體風格測試（包括按鈕、成功資訊、警告資訊）等等。

6、參照單元測試結果

可以幫我們定位軟體測試重點，做到花費較少的時間，找出較多的軟體缺陷。

7、參照其他測試人員報告的軟體缺陷

每個人的思維都是有侷限性的，我們可以參照其他測試人員報告的軟體缺陷，獲取新的測試思路，從而發現以前未曾發現的軟體缺陷。

8、錯誤推測法

對於有一定軟體測試經驗的人來說，是一個短時間內發現較多軟體缺陷見效較快的方法，體現了經驗的價值。

第二階段：提交bug

1. 確保bug有效。

提交的Bug必須是有效的，就要求我們在提交Bug時，確認：

①交付過程中測試者需按照設定好的模組，對Bug進行歸類提交；

②Bug的型別預設為UI問題、功能問題、崩潰問題，提交Bug時不能弄錯；

③需求是否明確、前提條件是否滿足、輸入資料是否正確、操作步驟是否清楚、Bug是否唯一性；

④避擴音交設計如此、操作錯誤、重複的、已知的Bug；

⑤儘量少花時間在邊界值、頁面顯示問題上，多提業務邏輯功能、互動測試方面的問題。

2. 寫好bug描述。

1）bug描述精確、沒有歧義，詳細簡潔的測試步驟。

2）保證各個欄位內容與實際現象一致。比如：版本、復現率等

3）對於復現率低的問題，儘可能提供一些可參考資訊：截圖、影片、日誌、可能的步驟、可能原因等（如果你能透過各種手段定位到問題的原因，開發大神也會對你刮目相看的）

4）對於特殊的測試場景，附帶相關的資料，比如1024kb的圖片等

第三階段：驗證bug

1. 確認好bug的復現前提及操作步驟。

2. 確認bug產生的原因及修復方法。

1） 明確bug產生的原因，觸類旁通，分析其他模組可能存在的問題

2 ) 透過bug產生的原因，積累測試經驗，擴充套件測試思路

3） 透過bug的修改方法，分析修改是否能修復問題？是否回引發其他問題？

4） 積累bug經驗，在後續相關問題發現時，快速定位問題，提供解決思路

3. 確認bug的迴歸範圍及用例。

在瞭解清楚bug產生的原因及修復方法基礎上，再根據業務關聯、功能模組關聯確認迴歸範圍，確保bug修復全面且沒有引起新的bug。

總結：

bug千奇百怪，不是每個bug都需要經歷所有流程的。每個步驟都有它的難點。 有些bug難在事發點的定位，比如多執行緒，非同步邏輯中的bug； 有些bug難在原因很難分析，多數是你看不懂程式碼； 有些bug難在你不敢改，那是你的修改方案沒有做好充分的分析。

歡迎加入  51軟體測試大家庭，在這裡你將獲得【最新行業資訊】，【免費測試工具安裝包】，【軟體測試技術乾貨】，【面試求職技巧】... 51與你共同學習，一起成長！期待你的加入： QQ                     群：                    755431660