bug的一生:如何體現測試專業度?

純潔的程式碼發表於2019-11-08

bug像是一個被過分寵愛的小孩子,得到了特別多的關注。它們在開發者的IDE裡悄然無聲的誕生,但在現身之刻卻引來一片喧鬧“——bug的一生(作者:James Whittaker)。
對於測試人員來說,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,多多思考也是能發掘隱藏在背後的問題、測試工具、測試知識,從而提高自己的測試能力、專業度。


相關文章