我是一枚潛藏在數(shù)據(jù)庫引擎深處的Bug，躲在一個黑暗的角落很久了，歷經(jīng)多個版本、N輪回歸測試的風(fēng)雨洗禮，我存在，我驕傲。還記得那天，我懷著激動而忐忑的心情等待一位QA新人把我發(fā)布出去……
產(chǎn)品發(fā)布在即，一位頗有經(jīng)驗的QA在無意間寫了一條短小精悍的用例讓QA新人來執(zhí)行一遍，就是這條不起眼的用例，使我原形畢露。這個用例看起來很簡單：就是向數(shù)據(jù)庫里插入一條null記錄（還記得我們的Mr Null嗎？），一條字符串記錄；再一條null記錄，一條同樣的字符串記錄……如此反復(fù)，來個5000次，然后啟用創(chuàng)建數(shù)據(jù)字典的功能，將這若干條看似規(guī)律的記錄進(jìn)行壓縮。好歹咱也算經(jīng)歷過風(fēng)風(fēng)雨雨的，每天的持續(xù)回歸測試也沒有拿我怎么樣，可就在執(zhí)行這條小用例時，神奇的事情發(fā)生了------數(shù)據(jù)庫發(fā)生了崩潰。
原因分析：
這個難題先后困擾過好幾個人，直到一位研究“炸彈”的開發(fā)GG，他對我進(jìn)行了好好的剖析，終于發(fā)現(xiàn)了問題的緣由。具體要從數(shù)據(jù)庫引擎的壓縮機制開始講起：
● 記錄壓縮：是基于數(shù)據(jù)字典的壓縮。所謂數(shù)據(jù)字典，就是數(shù)據(jù)庫表所有記錄中出現(xiàn)頻率最大的字符串集合。壓縮時，將記錄中與數(shù)據(jù)字典相同的字符串進(jìn)行替換，替換為數(shù)據(jù)字典的下標(biāo)。由于數(shù)據(jù)字典的下標(biāo)一定會遠(yuǎn)遠(yuǎn)小于字典所代表的字符串，因此就達(dá)到了記錄壓縮的效果。
● 實現(xiàn)流程：該引擎的數(shù)據(jù)字典在采集時，是將所有的記錄拼成一條長長的字符串流，然后從字符串流中采集出現(xiàn)頻率最高的子串，作為數(shù)據(jù)字典，而拼接記錄時并未在記錄間添加分隔符。這種一行null記錄、一行字符串記錄的方式，會使數(shù)據(jù)庫引擎采集的數(shù)據(jù)字典的長度超過記錄的最大長度，導(dǎo)致系統(tǒng)內(nèi)部驗證報錯。
解決辦法：
知道了問題的本質(zhì)，解決起來就很方便了，在將記錄拼接為長字符串流時，在每個記錄的拼接處添加分隔符。不能跨越分隔符采集數(shù)據(jù)字典，從而保證了數(shù)據(jù)字典的長度一定小于等于記錄的長度限制，問題解決！
經(jīng)驗總結(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是不厚道的，最后把一句很喜歡的佛語送給大家：“你見，或者不見我，我就在那里”，但是我們始終敵不過開發(fā)和測試的協(xié)同努力。
