PTT職涯區 / Soft_Job (軟體人)

[請益] 業界遇到這種bug該怎麼處理?

看板Soft_Job (軟體人)作者 (香蕉共和國)時間3年前 (2022/08/26 13:24), 3年前編輯推噓24(26推 2噓 68→)
留言96則, 41人參與, 最新討論串1/4 (看更多)
我大概在兩年前左右做了一個網頁版的聊天室 約莫上個月的時候，我無意間發現了一個bug 那個bug是對方已經傳了一個新訊息給我，但我這邊卻完全沒收到他傳給我的新訊息 但等我重新整理聊天室頁面之後，那個bug就從此徹底銷聲匿跡了 而且從兩年前到bug發生當時的那段時間以及bug發生當時至今這段時間，用起來都很正常 也就是說那個bug只在上個月那一次發生之後就再也沒被我看到了 雖然我不是IT業界的專業程式設計師 不過我想問一下： 當遇到這種程式已寫了兩年以上才難得出現過一次算是有點嚴重的bug被你發現到了 通常專業的都怎麼處理? 因為這樣的bug或許很難刻意的被製造出來，所以幾乎只能靠運氣碰碰看了 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 36.226.110.67 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1661491462.A.11E.html
推
08/26 13:27, 3年前 , 1F
買乖乖
08/26 13:27, 1F
→
08/26 13:27, 3年前 , 2F
沒正常的Log可分析？
08/26 13:27, 2F
其實我當時在發現該bug時沒有開console分析 等我發現並看到該bug時已經來不及了 console沒有記錄到 有個難處是，我不可能每次用這個聊天室時，都要特別坐到電腦桌前，打開電腦開console去看吧 有時候可能只是用個手機隨便進一下聊天室用用看 結果那個bug就「無意間」跑出來的 ※ 編輯: banana2014 (36.226.110.67 臺灣), 08/26/2022 13:31:51
→
08/26 13:29, 3年前 , 3F
正常有做exception與log處理，沒收到訊息會查到怎麼復現。
08/26 13:29, 3F
對了，其實並不是每個bug都是以error的形式出來的 只要結果和畫面是不符合期待的，應該都被歸類作bug 所以即使程式有寫try...catch bug的出現也不一定會跳出error log讓你知道 這也是我覺得處理起來最棘手的bug之一 因為它根本連錯誤訊息都不會跳出來讓你知道 ※ 編輯: banana2014 (36.226.110.67 臺灣), 08/26/2022 13:35:06 ※ 編輯: banana2014 (36.226.110.67 臺灣), 08/26/2022 13:39:40
→
08/26 13:38, 3年前 , 4F
當然是想辦法 reproducing。當然基本功的程式要寫好，err
08/26 13:38, 4F
→
08/26 13:38, 3年前 , 5F
or handling 做足。此外訊息要做成驗證機制，對方可收到
08/26 13:38, 5F
→
08/26 13:38, 3年前 , 6F
才算完整傳送（看訊息如何設計）。
08/26 13:38, 6F
推
08/26 14:04, 3年前 , 7F
就不理阿...無法重現的bug沒有修的必要XD
08/26 14:04, 7F
→
08/26 14:12, 3年前 , 8F
通常是沒驗證有沒有傳成功
08/26 14:12, 8F
推
08/26 14:16, 3年前 , 9F
如果無法重現但不影響軟體功能，就加log跟try catch補強程
08/26 14:16, 9F
→
08/26 14:16, 3年前 , 10F
式就夠了
08/26 14:16, 10F
推
08/26 14:24, 3年前 , 11F
偶發就先記log，看之後有沒有辦法找出問題
08/26 14:24, 11F
推
08/26 14:25, 3年前 , 12F
沒有error的UIUX bug也只能想辦法重現，或是猜猜看code
08/26 14:25, 12F
→
08/26 14:25, 3年前 , 13F
哪一段有可能造成這個問題(簡稱通靈)
08/26 14:25, 13F
推
08/26 14:35, 3年前 , 14F
沒辦法reproduce 就只能想辦法讓下次發生時能記錄到
08/26 14:35, 14F
→
08/26 14:37, 3年前 , 15F
Log 的輸出，Debug 的輸出可以寫在console ，上線後，建議
08/26 14:37, 15F
→
08/26 14:37, 3年前 , 16F
加log是一種 還有其他能用的都加一加
08/26 14:37, 16F
→
08/26 14:37, 3年前 , 17F
上線後是寫在file才能追蹤。
08/26 14:37, 17F
推
08/26 14:41, 3年前 , 18F
你就讓聊天室 每分鐘重新整理一次 不就解決了?
08/26 14:41, 18F
推
08/26 14:41, 3年前 , 19F
sentry
08/26 14:41, 19F
推
08/26 15:01, 3年前 , 20F
看bug嚴重性與修正的成本，每個bug當然也有它的權重
08/26 15:01, 20F
→
08/26 15:02, 3年前 , 21F
若客戶沒發現就留個紀錄或報告主管有這種情況讓主管
08/26 15:02, 21F
→
08/26 15:03, 3年前 , 22F
決定看要不要修
08/26 15:03, 22F
噓
08/26 15:06, 3年前 , 23F
08/26 15:06, 23F
推
08/26 15:10, 3年前 , 24F
先記著吧，或是報QA，很有可能不是聊天室本身的問題
08/26 15:10, 24F
推
08/26 16:02, 3年前 , 25F
定義哪些問題需要處理 + 做處理機制 然後定期回顧
08/26 16:02, 25F
推
08/26 17:46, 3年前 , 26F
如果是你自己做的其實可以先推測是哪一段出問題
08/26 17:46, 26F
→
08/26 17:46, 3年前 , 27F
然後在那一段動手腳看能不能增加重現機率
08/26 17:46, 27F
推
08/26 17:46, 3年前 , 28F
怎麼覺得這篇有既視感XDDD
08/26 17:46, 28F
推
08/26 18:25, 3年前 , 29F
建議是先紀錄給QA，讓QA後續追蹤
08/26 18:25, 29F
推
08/26 19:06, 3年前 , 30F
不重要 根本不用理
08/26 19:06, 30F
→
08/26 19:19, 3年前 , 31F
感覺就是websocket一時斷掉，重整後重連回來
08/26 19:19, 31F
推
08/26 19:24, 3年前 , 32F
等新人來當作他的試用期考核題目
08/26 19:24, 32F
推
08/26 20:05, 3年前 , 33F
怎麼跟前陣子的 10% 那篇有點像
08/26 20:05, 33F
→
08/26 20:16, 3年前 , 34F
沒頭緒就呈報，看主管要不要追。 其實工作久了就會對成
08/26 20:16, 34F
→
08/26 20:16, 3年前 , 35F
本比較有意識，不會像剛出來做那麼糾結在個別的問題
08/26 20:16, 35F
推
08/26 20:22, 3年前 , 36F
有使用者上 issue 再說…
08/26 20:22, 36F
→
08/26 22:20, 3年前 , 37F
個人覺得不重要 除非你沒其他事情做
08/26 22:20, 37F
推
08/26 22:53, 3年前 , 38F
在bug tracking system上寫unable to reproduce然後切掉
08/26 22:53, 38F
推
08/26 23:51, 3年前 , 39F
這種大部分是埋log~不過感覺很可能不是聊天室的問題+1
08/26 23:51, 39F
→
08/27 00:04, 3年前 , 40F
沒差
08/27 00:04, 40F
→
08/27 01:38, 3年前 , 41F
兩年來只被發現一次的bug然後還無法重現，正常都放著吧
08/27 01:38, 41F
→
08/27 08:09, 3年前 , 42F
就算User反應，但照他的方式沒辦法重現，而且只有一次的話
08/27 08:09, 42F
→
08/27 08:09, 3年前 , 43F
，通常都會說再觀察吧，畢竟你做不出異常也沒辦法處理
08/27 08:09, 43F
推
08/27 09:39, 3年前 , 44F
實務上這種傳說bug如果沒有頭緒就是包一包觀察吧
08/27 09:39, 44F
推
08/27 09:46, 3年前 , 45F
有可能是封包掉嗎
08/27 09:46, 45F
→
08/27 10:09, 3年前 , 46F
封包掉，正常寫都很容易攔截到exception，原文不知道怎麼
08/27 10:09, 46F
→
08/27 10:09, 3年前 , 47F
做的。
08/27 10:09, 47F
推
08/27 11:27, 3年前 , 48F
都無法描述跟復現了，頂多記下來下次有發現再說
08/27 11:27, 48F
→
08/27 15:23, 3年前 , 49F
具體情況具體分析，你的話我覺得找個熟聊天室功能的人
08/27 15:23, 49F
→
08/27 15:23, 3年前 , 50F
看一下你的code就能抓到
08/27 15:23, 50F
→
08/27 19:02, 3年前 , 51F
你們傳訊息沒有留文本紀錄？至少要留10天吧
08/27 19:02, 51F
推
08/28 07:21, 3年前 , 52F
看關鍵程度和人力成本，決定是否維修。很關鍵的應用，
08/28 07:21, 52F
→
08/28 07:21, 3年前 , 53F
派出最強老鳥修幾個月。相反的，不理它。
08/28 07:21, 53F
→
08/28 11:27, 3年前 , 54F
如果我做為你的客戶方
08/28 11:27, 54F
→
08/28 11:27, 3年前 , 55F
我應該會加一個測試案例如下
08/28 11:27, 55F
→
08/28 11:27, 3年前 , 56F
1.請找一台桌上型電腦，RJ45
08/28 11:27, 56F
→
08/28 11:27, 3年前 , 57F
網路線為唯一對外通道
08/28 11:27, 57F
→
08/28 11:27, 3年前 , 58F
（若有無線網路，請都先關閉）,
08/28 11:27, 58F
→
08/28 11:27, 3年前 , 59F
開啟瀏覽器，此時要能正常瀏覽
08/28 11:27, 59F
→
08/28 11:27, 3年前 , 60F
任一你熟悉的網頁.拔掉RJ45,
08/28 11:27, 60F
→
08/28 11:27, 3年前 , 61F
此時再refresh瀏覽網頁時，
08/28 11:27, 61F
→
08/28 11:27, 3年前 , 62F
應該報錯,無法瀏覽網頁.
08/28 11:27, 62F
→
08/28 11:27, 3年前 , 63F
2.重新接回RJ45,進入聊天室，
08/28 11:27, 63F
→
08/28 11:27, 3年前 , 64F
找朋友聊天，此時訊息-收/發
08/28 11:27, 64F
→
08/28 11:27, 3年前 , 65F
應該都要正常.
08/28 11:27, 65F
→
08/28 11:27, 3年前 , 66F
3.拔掉RJ45, 此時訊息應該
08/28 11:27, 66F
→
08/28 11:27, 3年前 , 67F
發不出去，也收不進來
08/28 11:27, 67F
→
08/28 11:27, 3年前 , 68F
（請用其他訊息工具確認）
08/28 11:27, 68F
→
08/28 11:27, 3年前 , 69F
4.重新接回RJ45,等侯1分鐘，
08/28 11:27, 69F
→
08/28 11:27, 3年前 , 70F
聊天室應該在已收/發訊息
08/28 11:27, 70F
→
08/28 11:27, 3年前 , 71F
無損失的情況下，恢復訊息收/發正常.
08/28 11:27, 71F
→
08/28 11:27, 3年前 , 72F
5.［系統強健性測試］.結束
08/28 11:27, 72F
→
08/28 11:28, 3年前 , 73F
雖然這是強制性斷線，
08/28 11:28, 73F
→
08/28 11:28, 3年前 , 74F
但應該也能cover你遇到的狀況
08/28 11:28, 74F
→
08/28 11:29, 3年前 , 75F
如果你很有實驗精神，
08/28 11:29, 75F
→
08/28 11:29, 3年前 , 76F
走進機房，隨便找一台路由
08/28 11:29, 76F
→
08/28 11:29, 3年前 , 77F
或 Hub,然後挑一條網路線
08/28 11:29, 77F
→
08/28 11:29, 3年前 , 78F
拔掉再插回去.那麼剛剛已經
08/28 11:29, 78F
→
08/28 11:29, 3年前 , 79F
經過這一條網路線建立連線
08/28 11:29, 79F
→
08/28 11:29, 3年前 , 80F
的Client,server 兩端遇到的現象
08/28 11:29, 80F
→
08/28 11:29, 3年前 , 81F
就會跟你有九成像了
08/28 11:29, 81F
→
08/28 11:29, 3年前 , 82F
只要中間轉接的硬體足夠多，
08/28 11:29, 82F
→
08/28 11:29, 3年前 , 83F
server 會以為連線還正常，
08/28 11:29, 83F
→
08/28 11:29, 3年前 , 84F
照常轉發訊息，但訊息永遠
08/28 11:29, 84F
→
08/28 11:29, 3年前 , 85F
到不了client 端.
08/28 11:29, 85F
→
08/28 11:29, 3年前 , 86F
client端會以為連線還正常
08/28 11:29, 86F
→
08/28 11:29, 3年前 , 87F
不會產生已斷線的error
08/28 11:29, 87F
→
08/28 13:04, 3年前 , 88F
看你的聊天室用什麼協定阿
08/28 13:04, 88F
→
08/28 13:04, 3年前 , 89F
這關乎到補救方式 不然你要別人通靈嗎
08/28 13:04, 89F
→
08/28 13:04, 3年前 , 90F
還有訊息的發出 都要有log阿 這不是基本的嗎？
08/28 13:04, 90F
→
08/28 13:04, 3年前 , 91F
就算ap沒做 也會有bright要作
08/28 13:04, 91F
→
08/28 13:04, 3年前 , 92F
看你的內文看不出來要從何debug起
08/28 13:04, 92F
推
08/28 14:57, 3年前 , 93F
重要度太低完全排不進時程
08/28 14:57, 93F
噓
08/30 18:15, , 94F
寫壓測程式跑看看，如果有發生過跑一下就可以收log了吧
08/30 18:15, 94F
推
09/12 23:31, , 95F
1. 開issue記錄發生了什麼事。2. 等有空或是再次發生
09/12 23:31, 95F
→
09/12 23:32, , 96F
3. 想辦法復現bug。4. 動手除錯 or 忘了他
09/12 23:32, 96F
‣ 更多 banana2014 的文章
文章代碼(AID): #1Z25a64U (Soft_Job)
Soft_Job 近期熱門文章
更多 近期熱門文章 >>
PTT職涯區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 banana2014 的文章
文章代碼(AID): #1Z25a64U (Soft_Job)