我大概在兩年前左右做了一個網頁版的聊天室
約莫上個月的時候，我無意間發現了一個bug
那個bug是對方已經傳了一個新訊息給我，但我這邊卻完全沒收到他傳給我的新訊息
但等我重新整理聊天室頁面之後，那個bug就從此徹底銷聲匿跡了
而且從兩年前到bug發生當時的那段時間以及bug發生當時至今這段時間，用起來都很正常
也就是說那個bug只在上個月那一次發生之後就再也沒被我看到了
雖然我不是IT業界的專業程式設計師
不過我想問一下：
當遇到這種程式已寫了兩年以上才難得出現過一次算是有點嚴重的bug被你發現到了
通常專業的都怎麼處理?
因為這樣的bug或許很難刻意的被製造出來，所以幾乎只能靠運氣碰碰看了
作者:
why3042 (yy)
2022-08-26 13:27:00買乖乖
作者:
DrTech (竹科管理處網軍研發人員)
2022-08-26 13:27:00沒正常的Log可分析？正常有做exception與log處理，沒收到訊息會查到怎麼復現。
作者:
alihue (wanda wanda)
2022-08-26 13:38:00當然是想辦法 reproducing。當然基本功的程式要寫好，error handling 做足。此外訊息要做成驗證機制，對方可收到才算完整傳送（看訊息如何設計）。
作者:
testPtt (測試)
2022-08-26 14:12:00通常是沒驗證有沒有傳成功
作者: hobnob (hobnob) 2022-08-26 14:16:00
如果無法重現但不影響軟體功能，就加log跟try catch補強程式就夠了
作者:
qwe70302 (為何一到90分就會輸)
2022-08-26 14:25:00沒有error的UIUX bug也只能想辦法重現，或是猜猜看code哪一段有可能造成這個問題(簡稱通靈)
沒辦法reproduce 就只能想辦法讓下次發生時能記錄到
作者:
DrTech (竹科管理處網軍研發人員)
2022-08-26 14:37:00Log 的輸出，Debug 的輸出可以寫在console ，上線後，建議
作者:
giacch 2022-08-26 14:41:00你就讓聊天室 每分鐘重新整理一次 不就解決了?
看bug嚴重性與修正的成本，每個bug當然也有它的權重若客戶沒發現就留個紀錄或報告主管有這種情況讓主管決定看要不要修
作者: ura1210 (jack) 2022-08-26 15:10:00
先記著吧，或是報QA，很有可能不是聊天室本身的問題
作者:
guest0710 (guest0710)
2022-08-26 16:02:00定義哪些問題需要處理 + 做處理機制 然後定期回顧
作者:
bnd0327 (阿噗噗)
2022-08-26 17:46:00如果是你自己做的其實可以先推測是哪一段出問題然後在那一段動手腳看能不能增加重現機率
作者:
single4565 (leekdumpling韭菜水餃)
2022-08-26 18:25:00建議是先紀錄給QA，讓QA後續追蹤
作者: k798976869 (kk) 2022-08-26 19:06:00
不重要 根本不用理
作者:
kirin021 (kirin)
2022-08-26 19:19:00感覺就是websocket一時斷掉，重整後重連回來
作者:
EKman (攻略)
2022-08-26 19:24:00等新人來當作他的試用期考核題目
作者:
iamshiao (CircleHsiao)
2022-08-26 20:16:00沒頭緒就呈報，看主管要不要追。 其實工作久了就會對成本比較有意識，不會像剛出來做那麼糾結在個別的問題
作者:
LoveMoon (我不是魔獸三國作者.....)
2022-08-26 20:22:00有使用者上 issue 再說…
作者:
peter98 (新兵)
2022-08-26 22:20:00個人覺得不重要 除非你沒其他事情做
在bug tracking system上寫unable to reproduce然後切掉
這種大部分是埋log~不過感覺很可能不是聊天室的問題+1
作者:
diabolica (打回大師å†æ”¹ID)
2022-08-27 00:04:00沒差
作者: saqwedcxz (阿慶è€å“¥) 2022-08-27 01:38:00
兩年來只被發現一次的bug然後還無法重現，正常都放著吧
作者:
qss05 (minami)
2022-08-27 08:09:00就算User反應，但照他的方式沒辦法重現，而且只有一次的話，通常都會說再觀察吧，畢竟你做不出異常也沒辦法處理
作者:
hduek153 (專業打醬油)
2022-08-27 09:39:00實務上這種傳說bug如果沒有頭緒就是包一包觀察吧
作者:
Csir (張胖胖)
2022-08-27 09:46:00有可能是封包掉嗎
作者:
DrTech (竹科管理處網軍研發人員)
2022-08-27 10:09:00封包掉，正常寫都很容易攔截到exception，原文不知道怎麼做的。
作者:
GoalBased (Artificail Intelligence)
2022-08-27 15:23:00具體情況具體分析，你的話我覺得找個熟聊天室功能的人看一下你的code就能抓到
作者:
overhead (overhead)
2022-08-28 07:21:00看關鍵程度和人力成本，決定是否維修。很關鍵的應用，派出最強老鳥修幾個月。相反的，不理它。
作者: lchcoding 2022-08-28 11:27:00
如果我做為你的客戶方我應該會加一個測試案例如下1.請找一台桌上型電腦，RJ45網路線為唯一對外通道（若有無線網路，請都先關閉）,開啟瀏覽器，此時要能正常瀏覽任一你熟悉的網頁.拔掉RJ45,此時再refresh瀏覽網頁時，應該報錯,無法瀏覽網頁.2.重新接回RJ45,進入聊天室，找朋友聊天，此時訊息-收/發應該都要正常.3.拔掉RJ45, 此時訊息應該發不出去，也收不進來（請用其他訊息工具確認）4.重新接回RJ45,等侯1分鐘，聊天室應該在已收/發訊息無損失的情況下，恢復訊息收/發正常.5.［系統強健性測試］.結束雖然這是強制性斷線，但應該也能cover你遇到的狀況如果你很有實驗精神，走進機房，隨便找一台路由或 Hub,然後挑一條網路線拔掉再插回去.那麼剛剛已經經過這一條網路線建立連線的Client,server 兩端遇到的現象就會跟你有九成像了只要中間轉接的硬體足夠多，server 會以為連線還正常，照常轉發訊息，但訊息永遠到不了client 端.client端會以為連線還正常不會產生已斷線的error
作者:
jej (晃奶大馬桶)
2022-08-28 13:04:00看你的聊天室用什麼協定阿這關乎到補救方式 不然你要別人通靈嗎還有訊息的發出 都要有log阿 這不是基本的嗎？就算ap沒做 也會有bright要作看你的內文看不出來要從何debug起
作者: abraxas (Abr.) 2022-08-28 14:57:00
重要度太低完全排不進時程
作者: f750502 (憤宅) 2022-08-30 18:15:00
寫壓測程式跑看看，如果有發生過跑一下就可以收log了吧
作者:
abola921 (南港金城武)
2022-09-12 23:31:001. 開issue記錄發生了什麼事。2. 等有空或是再次發生3. 想辦法復現bug。4. 動手除錯 or 忘了他
作者:
why3042 (yy)
2022-08-26 21:27:00買乖乖
作者:
DrTech (竹科管理處網軍研發人員)
2022-08-26 21:27:00沒正常的Log可分析？正常有做exception與log處理，沒收到訊息會查到怎麼復現。
作者:
alihue (wanda wanda)
2022-08-26 21:38:00當然是想辦法 reproducing。當然基本功的程式要寫好，error handling 做足。此外訊息要做成驗證機制，對方可收到才算完整傳送（看訊息如何設計）。
作者:
testPtt (測試)
2022-08-26 22:12:00通常是沒驗證有沒有傳成功
作者: hobnob (hobnob) 2022-08-26 22:16:00
如果無法重現但不影響軟體功能，就加log跟try catch補強程式就夠了
作者:
qwe70302 (為何一到90分就會輸)
2022-08-26 22:25:00沒有error的UIUX bug也只能想辦法重現，或是猜猜看code哪一段有可能造成這個問題(簡稱通靈)
沒辦法reproduce 就只能想辦法讓下次發生時能記錄到
作者:
DrTech (竹科管理處網軍研發人員)
2022-08-26 22:37:00Log 的輸出，Debug 的輸出可以寫在console ，上線後，建議
作者:
giacch 2022-08-26 22:41:00你就讓聊天室 每分鐘重新整理一次 不就解決了?
看bug嚴重性與修正的成本，每個bug當然也有它的權重若客戶沒發現就留個紀錄或報告主管有這種情況讓主管決定看要不要修
作者: ura1210 (jack) 2022-08-26 23:10:00
先記著吧，或是報QA，很有可能不是聊天室本身的問題
作者:
guest0710 (guest0710)
2022-08-27 00:02:00定義哪些問題需要處理 + 做處理機制 然後定期回顧
作者:
bnd0327 (阿噗噗)
2022-08-27 01:46:00如果是你自己做的其實可以先推測是哪一段出問題然後在那一段動手腳看能不能增加重現機率
作者:
single4565 (leekdumpling韭菜水餃)
2022-08-27 02:25:00建議是先紀錄給QA，讓QA後續追蹤
作者: k798976869 (kk) 2022-08-27 03:06:00
不重要 根本不用理
作者:
kirin021 (kirin)
2022-08-27 03:19:00感覺就是websocket一時斷掉，重整後重連回來
作者:
EKman (攻略)
2022-08-27 03:24:00等新人來當作他的試用期考核題目
作者:
iamshiao (CircleHsiao)
2022-08-27 04:16:00沒頭緒就呈報，看主管要不要追。 其實工作久了就會對成本比較有意識，不會像剛出來做那麼糾結在個別的問題
作者:
LoveMoon (我不是魔獸三國作者.....)
2022-08-27 04:22:00有使用者上 issue 再說…
作者:
peter98 (新兵)
2022-08-27 06:20:00個人覺得不重要 除非你沒其他事情做
在bug tracking system上寫unable to reproduce然後切掉
這種大部分是埋log~不過感覺很可能不是聊天室的問題+1
作者:
diabolica (打回大師å†æ”¹ID)
2022-08-27 08:04:00沒差
作者: saqwedcxz (阿慶è€å“¥) 2022-08-27 09:38:00
兩年來只被發現一次的bug然後還無法重現，正常都放著吧
作者:
qss05 (minami)
2022-08-27 16:09:00就算User反應，但照他的方式沒辦法重現，而且只有一次的話，通常都會說再觀察吧，畢竟你做不出異常也沒辦法處理
作者:
hduek153 (專業打醬油)
2022-08-27 17:39:00實務上這種傳說bug如果沒有頭緒就是包一包觀察吧
作者:
Csir (張胖胖)
2022-08-27 17:46:00有可能是封包掉嗎
作者:
DrTech (竹科管理處網軍研發人員)
2022-08-27 18:09:00封包掉，正常寫都很容易攔截到exception，原文不知道怎麼做的。
作者:
GoalBased (Artificail Intelligence)
2022-08-27 23:23:00具體情況具體分析，你的話我覺得找個熟聊天室功能的人看一下你的code就能抓到
作者:
overhead (overhead)
2022-08-28 15:21:00看關鍵程度和人力成本，決定是否維修。很關鍵的應用，派出最強老鳥修幾個月。相反的，不理它。
作者: lchcoding 2022-08-28 19:27:00
如果我做為你的客戶方我應該會加一個測試案例如下1.請找一台桌上型電腦，RJ45網路線為唯一對外通道（若有無線網路，請都先關閉）,開啟瀏覽器，此時要能正常瀏覽任一你熟悉的網頁.拔掉RJ45,此時再refresh瀏覽網頁時，應該報錯,無法瀏覽網頁.2.重新接回RJ45,進入聊天室，找朋友聊天，此時訊息-收/發應該都要正常.3.拔掉RJ45, 此時訊息應該發不出去，也收不進來（請用其他訊息工具確認）4.重新接回RJ45,等侯1分鐘，聊天室應該在已收/發訊息無損失的情況下，恢復訊息收/發正常.5.［系統強健性測試］.結束雖然這是強制性斷線，但應該也能cover你遇到的狀況如果你很有實驗精神，走進機房，隨便找一台路由或 Hub,然後挑一條網路線拔掉再插回去.那麼剛剛已經經過這一條網路線建立連線的Client,server 兩端遇到的現象就會跟你有九成像了只要中間轉接的硬體足夠多，server 會以為連線還正常，照常轉發訊息，但訊息永遠到不了client 端.client端會以為連線還正常不會產生已斷線的error
作者:
jej (晃奶大馬桶)
2022-08-28 21:04:00看你的聊天室用什麼協定阿這關乎到補救方式 不然你要別人通靈嗎還有訊息的發出 都要有log阿 這不是基本的嗎？就算ap沒做 也會有bright要作看你的內文看不出來要從何debug起
作者: abraxas (Abr.) 2022-08-28 22:57:00
重要度太低完全排不進時程
作者: f750502 (憤宅) 2022-08-31 02:15:00
寫壓測程式跑看看，如果有發生過跑一下就可以收log了吧
作者:
abola921 (南港金城武)
2022-09-13 07:31:001. 開issue記錄發生了什麼事。2. 等有空或是再次發生3. 想辦法復現bug。4. 動手除錯 or 忘了他