bug的一輩子：如何體現測試專業度？

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

 

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

 

第一階段：發現bug

場景：

「測試不就是發現bug嗎，有什麼技術含量？」

 

思考:

當發現一個bug，除了儘快報告問題之外，咱們還能作哪些事情？

 

回答：

測試人員發現bug，花些時間細細品味

1. 這個bug復現的必要條件是什麼？

2. 除了發現bug的這條路徑，是否還有更多的路徑也會致使相同的問題？

3. bug是否存在可能影響其它數據或者其它應用的反作用？

4. 其它功能模塊是否也存在相似問題？

5. bug的復現路徑是否在用戶可達之路上？

6. 復現bug的路徑是否在測試用例中？有沒有可借鑑性？

 

經過以上分析，咱們可能得到如下額外收穫：

1. 經過bug的定位，確認必現路徑、可能的緣由，幫助開發快速定位、解決問題

 

2. 經過bug的路徑、影響範圍等分析，發掘更多的隱藏bug，《探索式測試》-惡鄰測試法：重災區每每會有更多的bug

 

3. 經過分析操做路徑，補充測試用例，擴展測試用例範圍、思路

 

第二階段：提交bug

場景:

一個陽光明媚的下午，小白正在測試一個用例的時候，忽然app異常退出了，再重複進行以上步驟，問題沒有復現。他意識到這是個bug，因而他趕忙提交給開發。沒過一會，開發大神怒氣衝衝的過來講「你這bug也沒必現步驟，也沒日誌，這怎麼修改！」。小白內心一陣嘀咕「原本就是一個bug，你應該想辦法解決呀，我怎麼知道」

 

思考：如何才能提交一個有效的bug？

回答：

1. 確保bug有效。

1）不要由於環境問題或者是操做錯誤引發「bug」

2）不要提交一些重複的bug

 

2. 寫好bug描述。

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

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

3）對於復現率低的問題，儘量提供一些可參考信息：截圖、視頻、日誌、可能的步驟、可能緣由等（若是你能經過各類手段定位到問題的緣由，開發大神也會對你另眼相看的）

4）對於特殊的測試場景，附帶相關的數據，好比1024kb的圖片等

 

第三階段：驗證bug

場景：

當我仍是一個測試新手的時候，對於bug驗證，每每是按照步驟驗證復現，若是沒有問題就關閉了（不知道如今還有多少人跟我當初同樣~）

 

思考：如何作好bug的迴歸驗證？

回答：

1. 確認好bug的復現前說起操做步驟。

2. 確認bug產生的緣由及修復方法。

1） 明確bug產生的緣由，舉一反三，分析其餘模塊可能存在的問題

2 ) 經過bug產生的緣由，積累測試經驗，擴展測試思路

3） 經過bug的修改方法，分析修改是否能修復問題？是否回引起其餘問題？

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

 

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

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

 

最後

一個小小的bug，多多思考也是能發掘隱藏在背後的問題、測試工具、測試知識，從而提升本身的測試能力、專業度。