測試無法重現問題這個是測試過程中比較常見的現象,網上看到的總結的比較好文章,自己補充了4、5兩點:
1、回憶操作步驟、嘗試重現
盡量回憶當時的操作步驟,並且最大可能的復原當時的操作環境。
確認當時的操作步驟是否有誤。如果確認無誤,可以多次嘗試重現;
即使發現有操作錯誤的情況,也不要認為沒問題了,要思量為什麼會操作錯誤是否使用者也會有這種操作?然後和產品討論自己的想法,很可能這是使用者體驗上的問題。
可以把整個操作流程進行分解,逐個步驟進行考慮影響因素,然後進行驗證
視測試時間、嚴重程度、重要程度而定,要花多久進行重現,既不能一兩次就草草了事,也不能無休止的在這乙個問題上無限制消耗時間
如果是崩潰問題,一定要盡可能的抓取log並分析原因,然後提供給開發
2、提交bug與開發溝通
即使不能重現,也一定要提交bug備忘:
1)有的測試人員經常會因為不能重現,就不提交或忽略提交了,這是錯誤的
2)使用者那邊可能會出現,至少我們測試出現過,所以出於測試責任考慮,也要提交;
3)當前不能重現,不代表以後不能重現,既然出現問題了,那肯定是有問題,只不過當前無法解釋而已。
4)要把當時出現問題時的環境、步驟,盡可能的在bug上寫全,並且附上自己的分析和看法,哪怕是猜測也行,以便後續嘗試重現
開發對自己的程式了解深刻,看到bug後,有可能很容易就能知道問題所在立馬就能修改,或者根據現象給測試人員重現上的提示
對於這類bug,有些開發可能不太樂意讓提交,因為沒有重現步驟沒法改,所以一定要和開發明確說明,這首先是備忘一下,後續可能會重現或想到修改方法;就算最後一直無法解決,也可以置為不可重現關閉。(在搜狗專案中,開發的bug數是不計入績效統計的,所以開bug對於開發沒有什麼阻力)
切忌測試人員把單次發現的bug直接給開發,而不進行多次驗證、嘗試重現,因為這是不專業的表現,發現問題、多次多角度嘗試重現、幫助分析問題原因都是測試人員應該做的。
雖然重現bug是測試的職責,但初步定位bug也是測試人員需要提高的能力,因為這樣可以和開發一起找原因,提高開發對你能力的認可。但一定要注意,測試人員認為的原因,需要用一種建議的形式和開發溝通,否則會讓開發認為你太自負,並且一旦你說的原因是錯的,更會被認為是自不量力。
如果直到最後上線前都沒有重現,那麼就要把這個問題計入上線風險。
3、後續回歸測試時著重關注
一輪測試時發現的不可重現問題,在後續回歸測試或隨機測試時,可以把這類問題重新拿出來分析並嘗試重現(所以當即提交bug並詳細說明步驟與分析內容的重要性就體現出來了,如果沒有這些內容,後續想嘗試復現難度都很大)。
重現問題時,不要僅侷限在當前的環境下,換換思路、逆向思維、多發散、甚至帶點創造性的做法往往會有較大的驚喜。
一旦再次重現,一定要保留現場,叫開發人員一起檢視
如果發現了必現步驟,那麼就要好好進行分析,為什麼測試用例沒有覆蓋或者常規測試沒有發現,及時總結。
4、如果無法重現,也沒有任何資訊,可以讓開發增加監控日誌,以便下次出現問題時可以捕獲到相關資訊以便進行分析定位問題。
5、如果問題比較嚴重但無法重現,可以讓開發檢視自己的**,做**審查,評估**是否有問題。
遇到不可重現問題怎麼辦
測試無法重現問題這個是測試過程中比較常見的現象,網上看到的總結的比較好文章,自己補充了4 5兩點 1 回憶操作步驟 嘗試重現 盡量回憶當時的操作步驟,並且最大可能的復原當時的操作環境。確認當時的操作步驟是否有誤。如果確認無誤,可以多次嘗試重現 即使發現有操作錯誤的情況,也不要認為沒問題了,要思量為什...
遇到棘手問題怎麼辦
cpu飆高 cpu飆高處理步驟 top查詢出哪個程序消耗的cpu高 top c top h p查詢出哪個執行緒消耗的cpu高 top h p pid 這個命令就能顯示剛剛找到的程序的所有執行緒的資源消耗情況。printf x進行pid的進製轉換 找到cpu負載高的執行緒pid 8627,把這個數字轉...
openstack遇到問題怎麼辦
openstack是乙個開源雲平台,遇到問題怎麼辦呢?官方的求助方式 1 檢查日誌 openstack的 nova,keystone,glance 等都會產生日誌,日誌是發現問題的乙個重要手段,也是求助時需要提供的基本資料,否則求助時光說問題,不說症狀,社群也無法幫你解決問題。日誌有兩種方式,一種是...