軟件測試人員遇到發現的bug不能重現怎么辦？
剛剛進入測試的童鞋們,想必都遇到過提出的bug,開發要求重現之后,但是在系統上已經重現不了的情況吧.
那么碰到這樣的情況,不管開發還是測試都很糾結,開發考慮,如果拒絕,萬一單子打回之后又出現了這個問題,那還要給我返回來;測試也會考慮,老是碰到無法重現的bug,總是給我打回來,我也覺得挺郁悶的.
那么碰到這樣的bug應該如何處理呢?
Sometime的bug真的要打回嗎?測試人員碰到了應該怎么去做?接下來我們就一起討論一下這種運氣成分的bug.
首先,如果在在當前版本發現了bug,一定要在A版本進行bug重現.
如果出現了更換版本,那么在這個過程中,開發人員可能會偷偷修改bug,提升績效考核.而且換了版本也有可能出現環境的不一致性,那么原環境的bug就不能在另外的環境上進行復現.
再就是可能出現在環境中的熱補,導致代碼有改變,所以引發的bug無法重現.因為有這么多不確定性,才可能導致了我們的bug無法重現或者運氣化重現,知道這些問題之后,就需要排除這些影響,在我們當時出現bug的環境下進行bug的重現.如果必要再在另一個版本上重現bug,而且時間允許的話,可以考慮回退到之前的版本.
其次,就是項目時間允許的情況下，開發人員應大力協作復現bug.開發人員在自己負責的那部分代碼確定沒有問題之后，這時候就需要去考慮接口，是否在接口數據處理上存在問題，同時也需要其他開發人員進行配合。而測試人員也需要盡最大努力來還原當時的場景：包括環境，數據，前置條件及測試步驟等。
再就是測試人員要再次確認用例設計的覆蓋度及周密性.
對於測試而言，用例設計的覆蓋不夠，步驟和設計不夠嚴謹也會導致bug不在我們的掌握中.
這個時候,測試人員要注意兩種情況.
一是原本用例就沒有好好設計過，未經評審過，大家測試時就很隨意，這樣的話就要抓緊時間,趕緊把用例好好重新設計一下，再叫上相關人員進行評審，這么做的目的也是為了保證測試用例得到了項目相關人員的認可，只有這樣,才能保證軟件覆蓋度能滿足本次項目需求的要求；
第二就是是該項目已經經過嚴格的需求評審及用例評審了。當然，即便如此也不能避免漏測以及對特殊情況的考慮。
如果經歷了以上三個步驟之后,絞盡腦汁，仍然不能使bug復現時，對這個bug進行關注,可以這么理解:經歷了各種步驟的努力之后,仍然不能復現的bug一定優先級別不高，那就需要重新評估重要度.
如果項目組統一決定不影響版本發布，就密切關注這個問題，在發布后進行驗證。而且該bug不能關閉，延期進行跟蹤,如果之后的幾個版本連續沒有出現問題,那么就可以關閉問題單了。
最后,是考慮公司的整體性情況,是否針對提交bug的規范上存在需要完善的地方,那么針對這種出現的問題進行公司規范的改善,對公司流程還有測試人員素質的提升,效果都是事半功倍的.