看板 Soft_Job 關於我們 聯絡資訊
我大概在兩年前左右做了一個網頁版的聊天室 約莫上個月的時候,我無意間發現了一個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
why3042: 買乖乖 08/26 13:27
DrTech: 沒正常的Log可分析? 08/26 13:27
其實我當時在發現該bug時沒有開console分析 等我發現並看到該bug時已經來不及了 console沒有記錄到 有個難處是,我不可能每次用這個聊天室時,都要特別坐到電腦桌前,打開電腦開console去看吧 有時候可能只是用個手機隨便進一下聊天室用用看 結果那個bug就「無意間」跑出來的 ※ 編輯: banana2014 (36.226.110.67 臺灣), 08/26/2022 13:31:51
DrTech: 正常有做exception與log處理,沒收到訊息會查到怎麼復現。 08/26 13:29
對了,其實並不是每個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
alihue: 當然是想辦法 reproducing。當然基本功的程式要寫好,err 08/26 13:38
alihue: or handling 做足。此外訊息要做成驗證機制,對方可收到 08/26 13:38
alihue: 才算完整傳送(看訊息如何設計)。 08/26 13:38
abccbaandy: 就不理阿...無法重現的bug沒有修的必要XD 08/26 14:04
testPtt: 通常是沒驗證有沒有傳成功 08/26 14:12
hobnob: 如果無法重現但不影響軟體功能,就加log跟try catch補強程 08/26 14:16
hobnob: 式就夠了 08/26 14:16
aaa1234136: 偶發就先記log,看之後有沒有辦法找出問題 08/26 14:24
qwe70302: 沒有error的UIUX bug也只能想辦法重現,或是猜猜看code 08/26 14:25
qwe70302: 哪一段有可能造成這個問題(簡稱通靈) 08/26 14:25
longlyeagle: 沒辦法reproduce 就只能想辦法讓下次發生時能記錄到 08/26 14:35
DrTech: Log 的輸出,Debug 的輸出可以寫在console ,上線後,建議 08/26 14:37
longlyeagle: 加log是一種 還有其他能用的都加一加 08/26 14:37
DrTech: 上線後是寫在file才能追蹤。 08/26 14:37
giacch: 你就讓聊天室 每分鐘重新整理一次 不就解決了? 08/26 14:41
Lomonosov: sentry 08/26 14:41
OriginStar: 看bug嚴重性與修正的成本,每個bug當然也有它的權重 08/26 15:01
OriginStar: 若客戶沒發現就留個紀錄或報告主管有這種情況讓主管 08/26 15:02
OriginStar: 決定看要不要修 08/26 15:03
MoonCode: 08/26 15:06
ura1210: 先記著吧,或是報QA,很有可能不是聊天室本身的問題 08/26 15:10
guest0710: 定義哪些問題需要處理 + 做處理機制 然後定期回顧 08/26 16:02
bnd0327: 如果是你自己做的其實可以先推測是哪一段出問題 08/26 17:46
bnd0327: 然後在那一段動手腳看能不能增加重現機率 08/26 17:46
winnie830925: 怎麼覺得這篇有既視感XDDD 08/26 17:46
single4565: 建議是先紀錄給QA,讓QA後續追蹤 08/26 18:25
k798976869: 不重要 根本不用理 08/26 19:06
kirin021: 感覺就是websocket一時斷掉,重整後重連回來 08/26 19:19
EKman: 等新人來當作他的試用期考核題目 08/26 19:24
arcade0425: 怎麼跟前陣子的 10% 那篇有點像 08/26 20:05
iamshiao: 沒頭緒就呈報,看主管要不要追。 其實工作久了就會對成 08/26 20:16
iamshiao: 本比較有意識,不會像剛出來做那麼糾結在個別的問題 08/26 20:16
LoveMoon: 有使用者上 issue 再說… 08/26 20:22
peter98: 個人覺得不重要 除非你沒其他事情做 08/26 22:20
kurtsgm: 在bug tracking system上寫unable to reproduce然後切掉 08/26 22:53
viper9709: 這種大部分是埋log~不過感覺很可能不是聊天室的問題+1 08/26 23:51
diabolica: 沒差 08/27 00:04
saqwedcxz: 兩年來只被發現一次的bug然後還無法重現,正常都放著吧 08/27 01:38
qss05: 就算User反應,但照他的方式沒辦法重現,而且只有一次的話 08/27 08:09
qss05: ,通常都會說再觀察吧,畢竟你做不出異常也沒辦法處理 08/27 08:09
hduek153: 實務上這種傳說bug如果沒有頭緒就是包一包觀察吧 08/27 09:39
Csir: 有可能是封包掉嗎 08/27 09:46
DrTech: 封包掉,正常寫都很容易攔截到exception,原文不知道怎麼 08/27 10:09
DrTech: 做的。 08/27 10:09
WaterLengend: 都無法描述跟復現了,頂多記下來下次有發現再說 08/27 11:27
GoalBased: 具體情況具體分析,你的話我覺得找個熟聊天室功能的人 08/27 15:23
GoalBased: 看一下你的code就能抓到 08/27 15:23
ChungLi5566: 你們傳訊息沒有留文本紀錄?至少要留10天吧 08/27 19:02
overhead: 看關鍵程度和人力成本,決定是否維修。很關鍵的應用, 08/28 07:21
overhead: 派出最強老鳥修幾個月。相反的,不理它。 08/28 07:21
lchcoding: 如果我做為你的客戶方 08/28 11:27
lchcoding: 我應該會加一個測試案例如下 08/28 11:27
lchcoding: 1.請找一台桌上型電腦,RJ45 08/28 11:27
lchcoding: 網路線為唯一對外通道 08/28 11:27
lchcoding: (若有無線網路,請都先關閉), 08/28 11:27
lchcoding: 開啟瀏覽器,此時要能正常瀏覽 08/28 11:27
lchcoding: 任一你熟悉的網頁.拔掉RJ45, 08/28 11:27
lchcoding: 此時再refresh瀏覽網頁時, 08/28 11:27
lchcoding: 應該報錯,無法瀏覽網頁. 08/28 11:27
lchcoding: 2.重新接回RJ45,進入聊天室, 08/28 11:27
lchcoding: 找朋友聊天,此時訊息-收/發 08/28 11:27
lchcoding: 應該都要正常. 08/28 11:27
lchcoding: 3.拔掉RJ45, 此時訊息應該 08/28 11:27
lchcoding: 發不出去,也收不進來 08/28 11:27
lchcoding: (請用其他訊息工具確認) 08/28 11:27
lchcoding: 4.重新接回RJ45,等侯1分鐘, 08/28 11:27
lchcoding: 聊天室應該在已收/發訊息 08/28 11:27
lchcoding: 無損失的情況下,恢復訊息收/發正常. 08/28 11:27
lchcoding: 5.[系統強健性測試].結束 08/28 11:27
lchcoding: 雖然這是強制性斷線, 08/28 11:28
lchcoding: 但應該也能cover你遇到的狀況 08/28 11:28
lchcoding: 如果你很有實驗精神, 08/28 11:29
lchcoding: 走進機房,隨便找一台路由 08/28 11:29
lchcoding: 或 Hub,然後挑一條網路線 08/28 11:29
lchcoding: 拔掉再插回去.那麼剛剛已經 08/28 11:29
lchcoding: 經過這一條網路線建立連線 08/28 11:29
lchcoding: 的Client,server 兩端遇到的現象 08/28 11:29
lchcoding: 就會跟你有九成像了 08/28 11:29
lchcoding: 只要中間轉接的硬體足夠多, 08/28 11:29
lchcoding: server 會以為連線還正常, 08/28 11:29
lchcoding: 照常轉發訊息,但訊息永遠 08/28 11:29
lchcoding: 到不了client 端. 08/28 11:29
lchcoding: client端會以為連線還正常 08/28 11:29
lchcoding: 不會產生已斷線的error 08/28 11:29
jej: 看你的聊天室用什麼協定阿 08/28 13:04
jej: 這關乎到補救方式 不然你要別人通靈嗎 08/28 13:04
jej: 還有訊息的發出 都要有log阿 這不是基本的嗎? 08/28 13:04
jej: 就算ap沒做 也會有bright要作 08/28 13:04
jej: 看你的內文看不出來要從何debug起 08/28 13:04
abraxas: 重要度太低完全排不進時程 08/28 14:57
f750502: 寫壓測程式跑看看,如果有發生過跑一下就可以收log了吧 08/30 18:15
abola921: 1. 開issue記錄發生了什麼事。2. 等有空或是再次發生 09/12 23:31
abola921: 3. 想辦法復現bug。4. 動手除錯 or 忘了他 09/12 23:32