“在同事代碼里種蠱bug只對(duì)特定人可見(jiàn)”這個(gè)說(shuō)法乍一聽像是段子但真正在軟件測(cè)試和開發(fā)一線摸爬滾打過(guò)的人看到這個(gè)標(biāo)題大概率會(huì)心一笑——這不就是我們天天在跟“偶現(xiàn)bug”、“環(huán)境相關(guān)bug”斗智斗勇的日常嗎項(xiàng)目里總有一種bug像認(rèn)主一樣只在某個(gè)同事的機(jī)器上穩(wěn)定復(fù)現(xiàn)換個(gè)環(huán)境、換個(gè)操作人它就消失得無(wú)影無(wú)蹤仿佛從未存在過(guò)。開發(fā)說(shuō)“我這邊跑得好好的”測(cè)試那邊一執(zhí)行就花屏崩潰兩個(gè)人隔著工位面面相覷最后只能靠“重啟大法”和“多跑幾次”來(lái)碰運(yùn)氣。這個(gè)現(xiàn)象背后其實(shí)是軟件運(yùn)行環(huán)境復(fù)雜性和測(cè)試方法論問(wèn)題的集中體現(xiàn)。今天我想從這個(gè)“種蠱”的玩笑話切入認(rèn)認(rèn)真真拆解一下bug為什么會(huì)對(duì)特定人“可見(jiàn)”這種問(wèn)題通常長(zhǎng)什么樣我們?cè)趺从孟到y(tǒng)化的手段把這類“玄學(xué)”變成“科學(xué)”以及在日常測(cè)試和開發(fā)協(xié)作中如何從源頭減少這種“人肉復(fù)現(xiàn)”的困境。這篇文章適合正在被偶現(xiàn)bug折磨的測(cè)試工程師、被“我這邊沒(méi)問(wèn)題啊”困擾的開發(fā)同學(xué)以及所有想讓自己排查問(wèn)題能力上一個(gè)臺(tái)階的人。1. 內(nèi)容整體設(shè)計(jì)與思路拆解把“玄學(xué)bug”翻譯成可理解的技術(shù)問(wèn)題1.1 為什么bug會(huì)“認(rèn)人”從三個(gè)真實(shí)場(chǎng)景說(shuō)起先聊聊幾個(gè)我實(shí)際遇到過(guò)的“認(rèn)人bug”案例看完你就知道“種蠱”的比喻有多貼切。第一個(gè)案例來(lái)自我參與過(guò)的一個(gè)桌面端圖像處理項(xiàng)目。同事A反饋軟件在保存圖片時(shí)偶發(fā)崩潰但詭異的是這個(gè)崩潰只在他那臺(tái)開發(fā)機(jī)上穩(wěn)定出現(xiàn)其他同事包括測(cè)試同學(xué)怎么操作都復(fù)現(xiàn)不了。大家一度懷疑是不是他電腦“有問(wèn)題”直到后來(lái)發(fā)現(xiàn)他機(jī)器上裝了一個(gè)企業(yè)版的截圖翻譯軟件這個(gè)軟件會(huì)注入系統(tǒng)級(jí)的全局快捷鍵和剪貼板鉤子偏偏跟我們的圖像保存流程在底層資源上發(fā)生了沖突。換句話說(shuō)bug“認(rèn)”的不是人而是那臺(tái)機(jī)器上特有的軟件環(huán)境組合。第二個(gè)案例是一個(gè)移動(dòng)端App項(xiàng)目。運(yùn)營(yíng)同事反饋某個(gè)頁(yè)面刷新后偶發(fā)白屏但測(cè)試人員用測(cè)試賬號(hào)怎么刷都正常。最終定位到問(wèn)題出在一個(gè)第三方統(tǒng)計(jì)分析SDK的初始化時(shí)序上運(yùn)營(yíng)同事的賬號(hào)因?yàn)闅v史數(shù)據(jù)量特別大首頁(yè)接口響應(yīng)比普通測(cè)試賬號(hào)慢了大約200毫秒而這個(gè)微小的時(shí)差就觸發(fā)了SDK內(nèi)部一個(gè)沒(méi)有做好狀態(tài)保護(hù)的競(jìng)態(tài)條件導(dǎo)致頁(yè)面渲染中斷。第三個(gè)案例更離譜。一個(gè)后端接口偶爾返回亂碼只有一位新入職的同事在下班后執(zhí)行定時(shí)任務(wù)時(shí)能碰到。排查到最后問(wèn)題出在他的電腦系統(tǒng)區(qū)域時(shí)間和格式設(shè)置跟公司標(biāo)準(zhǔn)鏡像不一致導(dǎo)致一個(gè)時(shí)間戳生成函數(shù)在特定時(shí)區(qū)格式下走了不同的分支觸發(fā)了編碼轉(zhuǎn)換的bug。你看這三個(gè)案例里的bug哪一個(gè)真的“認(rèn)人”了沒(méi)有。它們都遵循著自己的觸發(fā)邏輯只是這個(gè)邏輯跟特定環(huán)境、特定數(shù)據(jù)、特定時(shí)序強(qiáng)耦合導(dǎo)致在大多數(shù)人的常規(guī)操作路徑上根本走不到那條分支。所謂“特定人才可見(jiàn)”本質(zhì)上是“特定條件下才觸發(fā)”但因?yàn)檫@個(gè)“特定條件”不好描述、不好枚舉大家為了方便理解就給它貼上了“認(rèn)人”的標(biāo)簽。1.2 這類bug的共同特征環(huán)境依賴、偶發(fā)性與可復(fù)現(xiàn)壁壘把上面幾個(gè)案例放到一起看就能總結(jié)出這類“認(rèn)人bug”的三個(gè)核心特征。第一是環(huán)境依賴性強(qiáng)。這里的“環(huán)境”是廣義的不只是操作系統(tǒng)版本還包括系統(tǒng)語(yǔ)言、時(shí)區(qū)、字體庫(kù)、已安裝軟件、啟動(dòng)的服務(wù)、環(huán)境變量、依賴的第三方庫(kù)版本甚至硬件配置和屏幕分辨率。這些因素互相作用構(gòu)成了一個(gè)幾乎不可窮舉的組合空間。第二是偶發(fā)性與可復(fù)現(xiàn)率低。這類bug往往不是100%復(fù)現(xiàn)而是有概率地出現(xiàn)。概率可能高到十次里出現(xiàn)三次也可能低到幾天才出現(xiàn)一次。隨機(jī)性就是它們的護(hù)身符讓開發(fā)人員在debug的時(shí)候無(wú)從下手。第三是觸發(fā)條件隱蔽。這類bug的觸發(fā)邏輯往往藏在不直觀的路徑上可能是數(shù)據(jù)邊界值、可能是時(shí)序競(jìng)爭(zhēng)、可能是資源泄漏的累積效應(yīng)也可能是緩存失效策略的某個(gè)極端情況。你沒(méi)找到觸發(fā)條件時(shí)它幾乎不存在你找到了之后會(huì)覺(jué)得“原來(lái)就這么簡(jiǎn)單”。理解了這三個(gè)特征你就明白為什么這類bug在團(tuán)隊(duì)里會(huì)造成巨大的內(nèi)耗了——因?yàn)椤霸谖覚C(jī)器上跑得好好的”這句話在這種前提下不能說(shuō)是在撒謊只能說(shuō)是他的運(yùn)行環(huán)境確實(shí)沒(méi)有觸發(fā)那個(gè)潛在條件。2. 核心細(xì)節(jié)解析與實(shí)操要點(diǎn)把“特定條件”從黑盒里挖出來(lái)2.1 環(huán)境差異是最大的變量?jī)?yōu)先排查環(huán)境相關(guān)因素當(dāng)你接到一個(gè)“只有某人能復(fù)現(xiàn)”的bug報(bào)告時(shí)我希望你的第一反應(yīng)不是懷疑這個(gè)人也不是懷疑代碼邏輯當(dāng)然代碼確實(shí)可能是根因而是先列一個(gè)環(huán)境因素的清單逐項(xiàng)比對(duì)。我建議建立一個(gè)“環(huán)境差異自檢表”核心項(xiàng)目包括以下這些操作系統(tǒng)及版本、系統(tǒng)語(yǔ)言、區(qū)域格式與默認(rèn)時(shí)區(qū)應(yīng)用運(yùn)行所需運(yùn)行時(shí)版本比如Java版本、Node版本等依賴的本地服務(wù)版本與配置機(jī)器上安裝的、可能干擾應(yīng)用運(yùn)行的全局軟件輸入法、截圖工具、翻譯工具、內(nèi)網(wǎng)安全管理軟件等瀏覽器類型、版本、插件、禁用啟用狀態(tài)網(wǎng)絡(luò)環(huán)境是否在公司內(nèi)網(wǎng)、是否有代理、延遲和帶寬特征數(shù)據(jù)情況登錄賬號(hào)、賬號(hào)權(quán)限、歷史數(shù)據(jù)量、緩存狀態(tài)硬件差異屏幕縮放比例、DPI、顯卡驅(qū)動(dòng)版本、內(nèi)存容量在實(shí)際操作中我傾向于先回歸到“最可能出問(wèn)題的幾個(gè)點(diǎn)”。比如在桌面端優(yōu)先懷疑系統(tǒng)級(jí)鉤子和圖形接口的問(wèn)題在Web端優(yōu)先懷疑瀏覽器兼容性和網(wǎng)絡(luò)條件在移動(dòng)端優(yōu)先懷疑系統(tǒng)版本和網(wǎng)絡(luò)環(huán)境。不要一上來(lái)追求全量比對(duì)那樣效率太低。你得像個(gè)偵察兵一樣先把最容易藏著鬼的地方翻一遍。這里有一個(gè)特別容易踩的坑很多人覺(jué)得“環(huán)境一致”就等于“跑得起來(lái)”其實(shí)不對(duì)。舉個(gè)例子兩個(gè)人電腦上都裝了同一個(gè)版本的數(shù)據(jù)庫(kù)客戶端但一個(gè)用了系統(tǒng)自帶的驅(qū)動(dòng)一個(gè)用了應(yīng)用程序目錄下自帶的驅(qū)動(dòng)這就夠了——行為就是會(huì)不一樣。所以做環(huán)境比對(duì)的時(shí)候你得看得足夠細(xì)細(xì)到依賴包、驅(qū)動(dòng)、鉤子這種容易被忽略的層面。2.2 數(shù)據(jù)差異是隱藏的導(dǎo)火索別忽視賬號(hào)和數(shù)據(jù)量除了環(huán)境數(shù)據(jù)差異是第二大“蠱源”。一個(gè)只出現(xiàn)在特定人身上的bug往往跟這個(gè)人的操作數(shù)據(jù)有直接關(guān)系。比如之前提到的那個(gè)統(tǒng)計(jì)分析SDK的問(wèn)題就是“數(shù)據(jù)量大導(dǎo)致接口返慢”的極端場(chǎng)景。在處理這類問(wèn)題時(shí)我建議你問(wèn)自己三個(gè)問(wèn)題這個(gè)人的數(shù)據(jù)跟我們的測(cè)試數(shù)據(jù)有什么不同數(shù)據(jù)量、字段長(zhǎng)度、特殊字符、歷史記錄、權(quán)限標(biāo)記等這個(gè)人的操作路徑跟我們的測(cè)試路徑有什么不同是否高頻操作、是否跨功能跳轉(zhuǎn)、是否攜帶特殊狀態(tài)進(jìn)入頁(yè)面等這個(gè)人的賬號(hào)狀態(tài)有什么特殊新賬號(hào)、老賬號(hào)、內(nèi)部賬號(hào)、特定角色權(quán)限等把這些差異列出來(lái)之后你再去看代碼里哪些分支會(huì)因?yàn)檫@些差異走不同路徑。很多時(shí)候bug就藏在分支覆蓋不到的地方——代碼的if條件里有“如果數(shù)據(jù)量大于某個(gè)閾值則走批量處理”測(cè)試人員的數(shù)據(jù)量永遠(yuǎn)到不了那個(gè)閾值而運(yùn)營(yíng)同事的量級(jí)輕輕松松就觸發(fā)了。2.3 時(shí)序與并發(fā)最容易“認(rèn)人”的bug類型時(shí)序問(wèn)題在“認(rèn)人bug”里占的比例相當(dāng)高而且是最難排查的類型因?yàn)樗莿?dòng)態(tài)的、概率性的。我見(jiàn)過(guò)一個(gè)典型的例子一個(gè)桌面工具在啟動(dòng)時(shí)初始化了一個(gè)全局事件監(jiān)聽器并且注冊(cè)了一個(gè)異步任務(wù)。某同事的機(jī)器啟動(dòng)速度特別快固態(tài)硬盤太新結(jié)果某個(gè)組件還沒(méi)完成注冊(cè)異步任務(wù)就觸發(fā)了對(duì)它的調(diào)用直接拋了空指針異常。其他同事的機(jī)器硬盤慢一點(diǎn)人為創(chuàng)造了一個(gè)“安全窗口期”所以從來(lái)沒(méi)觸發(fā)過(guò)。這種問(wèn)題就是典型的“海森堡bug”——你越是想觀察它它越是不出現(xiàn)因?yàn)椤坝^察”這個(gè)動(dòng)作本身就改變了系統(tǒng)狀態(tài)。比如你為了調(diào)試加了一行日志就改變了時(shí)序的競(jìng)爭(zhēng)格局bug反而不出現(xiàn)了。面對(duì)這類bug我得先給你潑盆冷水通過(guò)常規(guī)debug手段去跟蹤它的概率很低。更有效的辦法是通過(guò)代碼審查去主動(dòng)尋找競(jìng)態(tài)條件尤其是以下幾個(gè)位置應(yīng)用啟動(dòng)階段的初始化序列誰(shuí)先誰(shuí)后順序是否有關(guān)異步回調(diào)中是否存在對(duì)共享狀態(tài)的未加鎖讀寫緩存加載與數(shù)據(jù)更新的時(shí)間窗口事件監(jiān)聽器的注冊(cè)與銷毀時(shí)序多線程下的懶加載邏輯這些位置就是“競(jìng)態(tài)條件”的高發(fā)區(qū)也就是“種蠱”的重災(zāi)區(qū)。你去主動(dòng)審查這些區(qū)域可能比讓你殺掉一億次程序去碰運(yùn)氣要高效得多。3. 實(shí)操過(guò)程與核心環(huán)節(jié)實(shí)現(xiàn)從接收bug到鎖定根因的系統(tǒng)化流程3.1 建立一個(gè)可執(zhí)行的問(wèn)題排查SOP在團(tuán)隊(duì)協(xié)作里處理“認(rèn)人bug”最忌諱的事情就是“接到反饋馬上開跑”沒(méi)有任何信息收集就直接去猜。正確姿勢(shì)是建立一個(gè)標(biāo)準(zhǔn)化的排查流程讓每個(gè)人面對(duì)這種問(wèn)題時(shí)都有章可循。我的做法是這樣的第一步獲得完整的復(fù)現(xiàn)信息不要滿足于“某某操作就崩了”這種描述。你需要問(wèn)清楚以下信息什么時(shí)間發(fā)生發(fā)生頻率是多少10次里幾次每天幾次觸發(fā)復(fù)現(xiàn)的具體操作步驟越詳細(xì)越好是否只有這個(gè)人能觸發(fā)其他人試過(guò)沒(méi)有是否換過(guò)機(jī)器、換過(guò)賬號(hào)、換過(guò)網(wǎng)絡(luò)測(cè)試過(guò)崩潰時(shí)的屏幕現(xiàn)象報(bào)錯(cuò)文本、卡死畫面、閃退前的最后交互最近有沒(méi)有裝過(guò)新的軟件、更新過(guò)系統(tǒng)、改過(guò)配置文件你會(huì)發(fā)現(xiàn)光是耐心做這一步就能排除掉至少三分之一“其實(shí)根本不是bug而是操作不當(dāng)”的情況。第二步環(huán)境與數(shù)據(jù)快照請(qǐng)報(bào)告者提供關(guān)鍵環(huán)境信息如果條件允許最好能直接拿到他的機(jī)器做一次遠(yuǎn)程操作。如果不能遠(yuǎn)程就讓他執(zhí)行幾條簡(jiǎn)單的環(huán)境采集指令比如打印環(huán)境變量、系統(tǒng)信息、依賴版本等把結(jié)果貼給你。第三步最小化復(fù)現(xiàn)嘗試不要急著在他完整的、復(fù)雜的操作環(huán)境里去復(fù)現(xiàn)。試著把觸發(fā)步驟簡(jiǎn)化把干擾因素剝離。比如他是在某個(gè)特定頁(yè)面、特定操作下崩潰的你就問(wèn)自己能不能只保留這個(gè)頁(yè)面、這個(gè)操作把其他一切無(wú)關(guān)的東西都卸載看看還能不能復(fù)現(xiàn)如果剝離掉某些軟件就復(fù)現(xiàn)不了了說(shuō)明問(wèn)題大概率在軟件依賴沖突上。第四步代碼層面的競(jìng)態(tài)與分支審查如果環(huán)境和數(shù)據(jù)快照都沒(méi)有鎖定根因就需要進(jìn)入代碼審查模式。重點(diǎn)審查我之前提到的幾個(gè)高發(fā)區(qū)域初始化序列、異步回調(diào)、緩存時(shí)序、事件注冊(cè)。第五步構(gòu)建最小復(fù)現(xiàn)工程最后的手段也是效率極高的手段根據(jù)你已經(jīng)了解到的觸發(fā)條件開一個(gè)demo工程把存在疑點(diǎn)的代碼邏輯單獨(dú)拎出來(lái)按照那個(gè)觸發(fā)場(chǎng)景去模擬。如果demo里能復(fù)現(xiàn)那恭喜你你一定能在demo里找到根因如果demo里復(fù)現(xiàn)不了說(shuō)明你掌握的觸發(fā)條件還不夠關(guān)鍵需要回頭重新挖。這套SOP看起來(lái)每一步都不難難的是堅(jiān)持按順序走。很多人一接到bug就跳到第四步甚至第五步繞過(guò)信息收集直接埋頭看代碼最后往往事倍功半。3.2 實(shí)操案例一個(gè)“認(rèn)人”bug的完整破解過(guò)程為了讓你對(duì)這套流程有直觀認(rèn)知我用一個(gè)我經(jīng)手過(guò)的案例完整走一遍。背景某公司內(nèi)部使用的數(shù)據(jù)報(bào)表系統(tǒng)某產(chǎn)品經(jīng)理反饋他在導(dǎo)出一個(gè)大數(shù)據(jù)量的Excel報(bào)表時(shí)偶爾會(huì)遇到程序無(wú)響應(yīng)而其他人在相同操作下從未遇到過(guò)。接到這個(gè)反饋后我沒(méi)有直接去看導(dǎo)出代碼而是先收集信息。問(wèn)了產(chǎn)品經(jīng)理幾個(gè)問(wèn)題后發(fā)現(xiàn)他導(dǎo)出的數(shù)據(jù)量通常在數(shù)十萬(wàn)行以上而測(cè)試人員導(dǎo)出的一般只有幾千到幾萬(wàn)行他的電腦是企業(yè)定制版Windows環(huán)境預(yù)裝了很多后臺(tái)運(yùn)行的安全和監(jiān)控軟件他的瀏覽器是企業(yè)內(nèi)網(wǎng)指定版本屬于較老的一個(gè)版本我讓測(cè)試同學(xué)先用數(shù)百萬(wàn)行假數(shù)據(jù)去導(dǎo)發(fā)現(xiàn)代碼本身在數(shù)據(jù)量大時(shí)確實(shí)存在性能瓶頸——Excel導(dǎo)出過(guò)程會(huì)使用一個(gè)中間數(shù)組來(lái)拼接數(shù)據(jù)在數(shù)據(jù)量超過(guò)某個(gè)閾值時(shí)會(huì)導(dǎo)致內(nèi)存占用激增。但僅憑這一點(diǎn)還不足以解釋“只對(duì)特定人可見(jiàn)”。接下來(lái)我做了一步操作讓產(chǎn)品經(jīng)理把瀏覽器換成了最新版Chrome再試一次結(jié)果發(fā)現(xiàn)bug不再出現(xiàn)。這就把范圍進(jìn)一步縮小了——舊版瀏覽器的JavaScript引擎在解析大數(shù)組時(shí)觸發(fā)了一次垃圾回收的長(zhǎng)時(shí)間停頓加上導(dǎo)出本身的內(nèi)存峰值兩個(gè)因素疊加才導(dǎo)致了頁(yè)面無(wú)響應(yīng)。最終根因是兩層第一層是導(dǎo)出邏輯在百萬(wàn)級(jí)數(shù)據(jù)下性能問(wèn)題第二層是舊版瀏覽器引擎的內(nèi)存管理缺陷放大了這個(gè)性能問(wèn)題。換到新版瀏覽器后引擎的內(nèi)存分配策略優(yōu)化了單純數(shù)據(jù)量大已經(jīng)不足以觸發(fā)卡死。這個(gè)案例告訴我一個(gè)很重要的道理很多“認(rèn)人bug”其實(shí)是多個(gè)因素疊加的結(jié)果。單看任何一個(gè)因素都不足以出問(wèn)題但組合起來(lái)就踩到了雷區(qū)。所以排查這類問(wèn)題要有“組合思維”。4. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄一份拿來(lái)即用的避坑手冊(cè)4.1 問(wèn)題速查表按癥狀對(duì)號(hào)入座我把處理“認(rèn)人bug”最常見(jiàn)的場(chǎng)景整理成了一張速查表你可以在接到bug報(bào)告時(shí)對(duì)照參考。癥狀特征最可能的原因方向優(yōu)先排查點(diǎn)只有某人機(jī)器必現(xiàn)其他人完全不現(xiàn)機(jī)器級(jí)環(huán)境差異系統(tǒng)鉤子、全局快捷鍵、輸入法、已裝軟件、驅(qū)動(dòng)特定賬號(hào)必然觸發(fā)換賬號(hào)消失數(shù)據(jù)量級(jí)/賬號(hào)權(quán)限差異賬號(hào)歷史數(shù)據(jù)量、權(quán)限標(biāo)記、角色分支邏輯操作快時(shí)容易觸發(fā)慢時(shí)正常競(jìng)態(tài)條件/時(shí)序問(wèn)題初始化序列、異步回調(diào)、懶加載時(shí)機(jī)傍晚或特定時(shí)間段出現(xiàn)定時(shí)任務(wù)/資源累積內(nèi)存泄漏、句柄泄漏、日志文件增長(zhǎng)代碼沒(méi)改過(guò)但突然開始出現(xiàn)外部依賴變更第三方服務(wù)更新、瀏覽器自動(dòng)升級(jí)、系統(tǒng)補(bǔ)丁換機(jī)房/換網(wǎng)絡(luò)后消失網(wǎng)絡(luò)鏈路差異代理設(shè)置、DNS解析、網(wǎng)絡(luò)延遲、限速策略這張表的好處是讓你拿到反饋后第一時(shí)間有方向不會(huì)像無(wú)頭蒼蠅一樣亂撞。它不是真理但能幫你把排查半徑從“全項(xiàng)目所有代碼”縮小到“某個(gè)具體領(lǐng)域”。4.2 提升偶現(xiàn)bug復(fù)現(xiàn)率的3個(gè)技巧如果你面對(duì)的偶現(xiàn)bug概率極低比如幾天才出一次那這里有幾個(gè)實(shí)測(cè)有效的技巧可以幫你提高復(fù)現(xiàn)概率。技巧一多路復(fù)用環(huán)境如果你懷疑是競(jìng)態(tài)問(wèn)題可以用腳本同時(shí)啟動(dòng)多個(gè)應(yīng)用實(shí)例人為制造高并發(fā)狀態(tài)?；蛘邔懸粋€(gè)自動(dòng)化腳本高頻重復(fù)觸發(fā)某個(gè)操作。把單次執(zhí)行的競(jìng)態(tài)概率通過(guò)重復(fù)次數(shù)放大。比如某次操作觸發(fā)競(jìng)態(tài)的概率是千分之一你腳本跑一萬(wàn)次理論上就能命中10次。技巧二降低外部干擾閾值有些bug在正常狀態(tài)下難以觸發(fā)是因?yàn)橛幸粋€(gè)“緩沖管”保護(hù)著——比如內(nèi)存不夠了系統(tǒng)會(huì)先卡頓而不是直接崩潰、隊(duì)列積壓了系統(tǒng)會(huì)變慢但不會(huì)丟數(shù)據(jù)。你可以通過(guò)工具人為收緊這個(gè)緩沖用內(nèi)存限制工具把可用內(nèi)存壓到某個(gè)水位用網(wǎng)絡(luò)延遲模擬工具把鏈路變慢用CPU限制把處理速度降下來(lái)。很多“邊界bug”就是在這種“受限環(huán)境”里現(xiàn)出原形的。技巧三引入隨機(jī)性有時(shí)候你自己的測(cè)試路徑太規(guī)整了反而碰不到bug觸發(fā)條件。讓測(cè)試工具隨機(jī)化操作順序、隨機(jī)輸入數(shù)據(jù)、隨機(jī)等待時(shí)間甚至隨機(jī)切換網(wǎng)絡(luò)狀態(tài)。讓“運(yùn)氣”來(lái)幫你比你按部就班跑一萬(wàn)遍效果更好。4.3 獨(dú)家避坑心得這些錯(cuò)誤做法會(huì)把你帶進(jìn)死胡同處理這類bug時(shí)有些做法我強(qiáng)烈建議你要避開它們會(huì)極大浪費(fèi)你的時(shí)間。不要在復(fù)現(xiàn)現(xiàn)場(chǎng)去跟蹤代碼?！昂Ｉug”是最典型的例子你越是介入觀察系統(tǒng)狀態(tài)改變?cè)酱骲ug越是不出現(xiàn)。需要調(diào)日志、加斷點(diǎn)的時(shí)候先讓現(xiàn)場(chǎng)穩(wěn)定用旁路手段采集信息而不是直接上手改運(yùn)行中的系統(tǒng)。**不要讓報(bào)告者一遍遍地“再試一次”。**如果你的同事已經(jīng)操作了十幾次都復(fù)現(xiàn)不了你再讓他試二十次意義也不大。這時(shí)候應(yīng)該退回到信息收集階段重新審視是不是漏掉了什么關(guān)鍵觸發(fā)條件。**不要忽視“時(shí)間”這個(gè)變量。**很多偶現(xiàn)bug跟運(yùn)行時(shí)間高度相關(guān)比如內(nèi)存泄漏要到一定程度才觸發(fā)、緩存插件要到某個(gè)過(guò)期時(shí)間點(diǎn)才出問(wèn)題。拿到反饋先問(wèn)對(duì)方“這個(gè)進(jìn)程跑了多久了”——這個(gè)問(wèn)題往往能讓你直接跳過(guò)大量無(wú)效排查。**不要過(guò)早下結(jié)論。**尤其是當(dāng)你說(shuō)“我覺(jué)得是第三方庫(kù)的鍋”的時(shí)候你得有證據(jù)。第三方庫(kù)經(jīng)常背鍋但很多時(shí)候根因是自己的代碼用錯(cuò)了方式調(diào)它。4.4 團(tuán)隊(duì)協(xié)作層面的三個(gè)建議處理“認(rèn)人bug”不只是技術(shù)問(wèn)題也是協(xié)作問(wèn)題。我分享幾個(gè)在團(tuán)隊(duì)管理層面很實(shí)用的做法。第一建立一個(gè)“異常環(huán)境登記表”。團(tuán)隊(duì)成員如果在自己機(jī)器上裝了特殊軟件、改了系統(tǒng)配置、升級(jí)了特殊工具主動(dòng)登記到表里。這樣一旦出現(xiàn)環(huán)境相關(guān)bug你能快速找到“誰(shuí)的環(huán)境可能最接近觸發(fā)條件”。第二統(tǒng)一開發(fā)環(huán)境標(biāo)準(zhǔn)化。推行虛擬機(jī)開發(fā)環(huán)境或者容器化開發(fā)環(huán)境讓代碼在團(tuán)隊(duì)里運(yùn)行的基礎(chǔ)設(shè)施是一致的。這一步能消滅一大半的環(huán)境差異類bug。當(dāng)然容器化不等于徹底解決問(wèn)題因?yàn)閿?shù)據(jù)差異和第三方服務(wù)差異依然存在但至少系統(tǒng)和依賴版本這一層穩(wěn)了。第三反饋bug時(shí)“帶上環(huán)境信息是強(qiáng)制要求”而不是可選項(xiàng)。在bug單里明確列出必填字段操作系統(tǒng)、應(yīng)用版本、受影響功能、復(fù)現(xiàn)步驟、復(fù)現(xiàn)頻率、瀏覽器版本如涉及。讓報(bào)告者養(yǎng)成提供完整上下文的工作習(xí)慣這對(duì)團(tuán)隊(duì)效率的提升是立竿見(jiàn)影的。5. 從源頭減少“認(rèn)人bug”的工程實(shí)踐5.1 防御性編碼在代碼層面堵住暗雷既然“認(rèn)人bug”往往是極端條件和環(huán)境碰撞的結(jié)果那從代碼層面減少這種“爆炸半徑”就是最根本的做法。我在評(píng)審代碼時(shí)特別關(guān)注幾個(gè)點(diǎn)代碼是否對(duì)資源狀態(tài)做過(guò)充分校驗(yàn)比如調(diào)用一個(gè)可能還沒(méi)初始化的組件是否做了空安全校驗(yàn)異步邏輯中是否有加鎖或原子性保護(hù)共享數(shù)據(jù)是否在并發(fā)訪問(wèn)時(shí)做了同步處理是否使用了固定的初始化順序如果依賴順序變化系統(tǒng)是否還能正常工作配置項(xiàng)是否有默認(rèn)值兜底當(dāng)某個(gè)系統(tǒng)屬性不存在或格式不符合預(yù)期時(shí)代碼是直接崩潰還是走退路邏輯這些細(xì)節(jié)看著基礎(chǔ)但恰恰是“認(rèn)人bug”的藏身之處。防御性編程不可能消滅所有bug但它能把需要靠“特定環(huán)境特定數(shù)據(jù)特定時(shí)序”才能觸發(fā)的bug大幅減少。5.2 測(cè)試策略面向組合場(chǎng)景設(shè)計(jì)用例常規(guī)測(cè)試用例設(shè)計(jì)關(guān)注的是功能正確性而“認(rèn)人bug”的測(cè)試重心應(yīng)該放在“組合場(chǎng)景”上。我建議在測(cè)試計(jì)劃中增加一類“環(huán)境組合用例”。這類用例的典型做法包括同一功能在不同操作系統(tǒng)、不同分辨率、不同瀏覽器下跑一輪冒煙用大中小三檔數(shù)據(jù)量各跑一遍核心流程在網(wǎng)絡(luò)延遲分別設(shè)置為正常、高延遲、丟包三種條件下執(zhí)行異步操作模擬后臺(tái)大量進(jìn)程占用的低資源環(huán)境執(zhí)行前臺(tái)操作用不同語(yǔ)言和區(qū)域設(shè)置的系統(tǒng)跑一遍時(shí)間相關(guān)功能實(shí)話實(shí)說(shuō)要做到全量組合測(cè)試任何團(tuán)隊(duì)都扛不住這個(gè)成本。更務(wù)實(shí)的做法是結(jié)合風(fēng)險(xiǎn)評(píng)估做“優(yōu)先級(jí)組合”只針對(duì)并發(fā)邏輯、時(shí)間敏感邏輯、平臺(tái)依賴邏輯和數(shù)據(jù)處理邏輯這四類高風(fēng)險(xiǎn)模塊做組合覆蓋而不是全項(xiàng)目鋪開。5.3 監(jiān)控與日志讓bug在發(fā)生時(shí)留下證據(jù)很多“認(rèn)人bug”之所以難查是因?yàn)樗l(fā)生時(shí)系統(tǒng)沒(méi)留下任何痕跡或者留下的日志不足以反推觸發(fā)路徑。我強(qiáng)烈建議在項(xiàng)目的關(guān)鍵路徑上加“結(jié)構(gòu)化日志”——不只是記錄“發(fā)生了什么”還要記錄“當(dāng)時(shí)的狀態(tài)是什么”。例如數(shù)據(jù)庫(kù)操作記錄數(shù)據(jù)量級(jí)、耗時(shí)、是否走批次模式初始化操作記錄初始化順序、完成耗時(shí)、各組件注冊(cè)狀態(tài)緩存操作記錄緩存命中和重載時(shí)機(jī)異常捕獲記錄完整的調(diào)用鏈、入?yún)?、關(guān)鍵變量值、系統(tǒng)屬性這些東西就像飛機(jī)的黑匣子平時(shí)不起眼但等到bug真正出現(xiàn)時(shí)它們就是唯一的破案線索。在這里我要特別提醒一點(diǎn)日志不是越多越好。日志太多會(huì)拖慢系統(tǒng)、淹沒(méi)關(guān)鍵信息反而降低問(wèn)題排查效率。我的經(jīng)驗(yàn)是抓住“關(guān)鍵決策點(diǎn)”來(lái)打日志什么叫關(guān)鍵決策點(diǎn)就是代碼里“做選擇”的地方比如選擇走哪個(gè)分支、選擇重試還是放棄、選擇默認(rèn)值還是用戶配置值。這些位置打上狀態(tài)日志排查問(wèn)題事半功倍。6. 寫在最后的個(gè)人體會(huì)與持續(xù)建議處理了這么多年“認(rèn)人bug”我個(gè)人最大的體會(huì)是這類問(wèn)題最消耗人的不是技術(shù)難度而是“不確定性”帶來(lái)的焦慮感。當(dāng)你不知道bug什么時(shí)候會(huì)出現(xiàn)、不知道它為什么只在某個(gè)人身上出現(xiàn)時(shí)你會(huì)自然地懷疑自己的代碼、自己的水平甚至自己的判斷力。經(jīng)歷過(guò)幾次硬仗之后我的心態(tài)變得很有彈性——遇到這類問(wèn)題不再慌而是把它當(dāng)成一次“尋寶游戲”線索就散落在環(huán)境、數(shù)據(jù)和代碼之間我要做的事情就是耐心把它們一一找出來(lái)連起來(lái)。這種心態(tài)的轉(zhuǎn)變比任何技術(shù)提升都管用。最后再分享一個(gè)實(shí)戰(zhàn)小技巧當(dāng)你實(shí)在找不到頭緒的時(shí)候試著把問(wèn)題“講給一個(gè)不懂技術(shù)的人聽”。你會(huì)發(fā)現(xiàn)為了把問(wèn)題講明白你得把很多抽象的技術(shù)細(xì)節(jié)翻譯成“人類的語(yǔ)言”這個(gè)過(guò)程本身就強(qiáng)迫你重新審視事情的邏輯結(jié)構(gòu)很多被我忽略掉的關(guān)聯(lián)就是在這個(gè)過(guò)程中突然蹦出來(lái)的?！胺N蠱”只是玩笑但“bug確實(shí)只對(duì)特定人可見(jiàn)”從來(lái)不是玩笑。它是環(huán)境復(fù)雜性的一個(gè)縮影也是每一個(gè)追求質(zhì)量的工程師繞不開的戰(zhàn)場(chǎng)。希望這篇文章里的一套SOP、一張速查表和幾個(gè)實(shí)戰(zhàn)心得能幫你在下次遇到這類“玄學(xué)bug”的時(shí)候多幾條清晰的路可以走。