一枚小Bug的獨(dú)白

第第頁一枚小Bug的獨(dú)白一枚小Bug的獨(dú)白

發(fā)表于：2023-04-07來源：網(wǎng)易杭州QATeam：君小食堯點(diǎn)擊數(shù)：標(biāo)簽：bug

我是一枚潛藏在數(shù)據(jù)庫引擎深處的Bug，躲在一個黑暗的角落很久了，歷經(jīng)多個版本、N輪回歸測試的風(fēng)雨洗禮，我存在，我驕傲。還記得那天，我懷著激動而忐忑的心情等待一位QA新人把我發(fā)布出去……

我是一枚潛藏在（數(shù)據(jù)庫）引擎深處的Bug，躲在一個黑暗的角落很久了，歷經(jīng)多個版本、N輪（回歸）（測試）的風(fēng)雨洗禮，我存在，我驕傲。還記得那天，我懷著激動而忐忑的心情等待一位QA新人把我發(fā)布出去

產(chǎn)品發(fā)布在即，一位頗有經(jīng)驗(yàn)的QA在無意間寫了一條短小精悍的（用例）讓QA新人來執(zhí)行一遍，就是這條不起眼的（用例），使我原形畢露。這個用例看起來很簡單：就是向數(shù)據(jù)庫里插入一條null記錄(還記得我們的MrNull嗎?)，一條字符串記錄;再一條null記錄，一條同樣的字符串記錄如此反復(fù)，來個5000次，然后啟用創(chuàng)建數(shù)據(jù)字典的功能，將這若干條看似規(guī)律的記錄進(jìn)行壓縮。好歹咱也算經(jīng)歷過風(fēng)風(fēng)雨雨的，每天的持續(xù)回歸測試也沒有拿我怎么樣，可就在執(zhí)行這條小用例時(shí)，神奇的事情發(fā)生了數(shù)據(jù)庫發(fā)生了崩潰。

原因分析：

這個難題先后困擾過好幾個人，直到一位研究"炸彈'的（開發(fā)）GG①，他對我進(jìn)行了好好的剖析，終于發(fā)現(xiàn)了問題的緣由。具體要從數(shù)據(jù)庫引擎的壓縮機(jī)制開始講起：

記錄壓縮：是基于數(shù)據(jù)字典的壓縮。所謂數(shù)據(jù)字典，就是數(shù)據(jù)庫表所有記錄中出現(xiàn)頻率最大的字符串集合。壓縮時(shí)，將記錄中與數(shù)據(jù)字典相同的字符串進(jìn)行替換，替換為數(shù)據(jù)字典的下標(biāo)。由于數(shù)據(jù)字典的下標(biāo)一定會遠(yuǎn)遠(yuǎn)小于字典所代表的字符串，因此就達(dá)到了記錄壓縮的效果。

實(shí)現(xiàn)流程：該引擎的數(shù)據(jù)字典在采集時(shí)，是將所有的記錄拼成一條長長的字符串流，然后從字符串流中采集出現(xiàn)頻率最高的子串，作為數(shù)據(jù)字典，而拼接記錄時(shí)并未在記錄間添加分隔符。這種一行null記錄、一行字符串記錄的方式，會使數(shù)據(jù)庫引擎采集的數(shù)據(jù)字典的長度超過記錄的最大長度，導(dǎo)致系統(tǒng)內(nèi)部驗(yàn)證報(bào)錯。

解決辦法：

知道了問題的本質(zhì)，解決起來就很方便了，在將記錄拼接為長字符串流時(shí)，在每個記錄的拼接處添加分隔符。不能跨越分隔符采集數(shù)據(jù)字典，從而保證了數(shù)據(jù)字典的長度一定小于等于記錄的長度限制，問題解決!

經(jīng)驗(yàn)總結(jié)：

注意邊界問題。問題往往出現(xiàn)在邊界情況下，比如最大值/最小值/0值。如果在代碼中加入一些邊界斷言，可以幫助提早發(fā)現(xiàn)問題。

注意"null'的使用。不論開發(fā)還是測試，注意"null'的使用都可以幫助我們少犯一些錯誤，或者多發(fā)現(xiàn)一些問題。

"殺蟲劑困境'②的思考。再嚴(yán)密的單一性測試也不可能發(fā)現(xiàn)100%的Bug。將不同的測試思路和方法相結(jié)合，采用探索式的測試思維或許能幫助發(fā)現(xiàn)更多潛在問題。

說了這么多，我得閉嘴了，不低調(diào)的Bug是不厚道的，