看板
[ Soft_Job ]
討論串[請益] bug「可遇不可求」，各位還會去debug它嗎?
共 11 篇文章
內容預覽:
最近開發一個通訊軟體. 有個閃退的bug自從上週被發現到之後就再也沒被觀察到. 也就是這個bug的出現沒有規律性，只能靠碰運氣. 出現機率也不高 (出現機率不到10%). 這也是我對這個bug感到煩惱的地方. 如果各位遇到這樣性質的bug. 你會怎麼去處理?. 會去盡可能的鑽研，並且製造出這bug出
(還有240個字)
內容預覽:
先講結論. 修bug還要看影響程度 impact/severity. 閃退是很嚴重的問題。 相當於app crash. 除非你有權力決定/並扛結果，否則就是看上層要不要修。. 或者能說服上層不修. 閃退就算是1% 也算嚴重。. ==> 不能假設只有1%的人會遇到，而是假設使用者用100次就會遇到的話
(還有324個字)
內容預覽:
10%.... 如果是終端消費者產品，這機率是會死人的。. 甚至可以說這是失敗的產品吧. 這在有規模的公司會被每天追殺吧，都得優先處理。 甚至bug發生在dvt/pvt階段，每小時都會有人來問解的怎麼樣了. 以嵌入式系統smart phone舉例. 這種複雜系統高整合度，貼進消費者極度重user e
(還有322個字)
內容預覽:
老實說，就算是萬分之一，但閃退是critial issue. 所以還是很高，還是該修. 如果這個產品是面對一般用戶，那閃退肯定會讓這產品評分很差. 如果這產品是商用，那更不用說，該修. 有興趣可以看一下這影片. https://www.youtube.com/watch?v=AaZ_RSt0KP8.
(還有267個字)
內容預覽:
1、crash的bug. 2、10%機率. 放在任何公司都沒有人認為這叫機率不高. 10%基本上一定有解. 10%當機很規律好嗎？XD. 分享一下過去遇到發生機率低於1%的bug怎麼解. 其實不要死腦筋認為找到root cause才是解. 1、寫自動測試程式開始壓力測試. 把1%機率以下的bug無限
(還有338個字)