我是一枚潛藏在數據庫引擎深處的Bug，躲在一個黑暗的角落很久了，歷經多個版本、N輪回歸測試的風雨洗禮，我存在，我驕傲。還記得那天，我懷著激動而忐忑的心情等待一位QA新人把我發布出去……
產品發布在即，一位頗有經驗的QA在無意間寫了一條短小精悍的用例讓QA新人來執行一遍，就是這條不起眼的用例，使我原形畢露。這個用例看起來很簡單：就是向數據庫里插入一條null記錄（還記得我們的Mr Null嗎？），一條字符串記錄；再一條null記錄，一條同樣的字符串記錄……如此反復，來個5000次，然后啟用創建數據字典的功能，將這若干條看似規律的記錄進行壓縮。好歹咱也算經歷過風風雨雨的，每天的持續回歸測試也沒有拿我怎么樣，可就在執行這條小用例時，神奇的事情發生了------數據庫發生了崩潰。
原因分析：
這個難題先后困擾過好幾個人，直到一位研究“炸彈”的開發GG，他對我進行了好好的剖析，終于發現了問題的緣由。具體要從數據庫引擎的壓縮機制開始講起：
● 記錄壓縮：是基于數據字典的壓縮。所謂數據字典，就是數據庫表所有記錄中出現頻率最大的字符串集合。壓縮時，將記錄中與數據字典相同的字符串進行替換，替換為數據字典的下標。由于數據字典的下標一定會遠遠小于字典所代表的字符串，因此就達到了記錄壓縮的效果。
● 實現流程：該引擎的數據字典在采集時，是將所有的記錄拼成一條長長的字符串流，然后從字符串流中采集出現頻率最高的子串，作為數據字典，而拼接記錄時并未在記錄間添加分隔符。這種一行null記錄、一行字符串記錄的方式，會使數據庫引擎采集的數據字典的長度超過記錄的最大長度，導致系統內部驗證報錯。
解決辦法：
知道了問題的本質，解決起來就很方便了，在將記錄拼接為長字符串流時，在每個記錄的拼接處添加分隔符。不能跨越分隔符采集數據字典，從而保證了數據字典的長度一定小于等于記錄的長度限制，問題解決！
經驗總結：
● 注意邊界問題。問題往往出現在邊界情況下，比如最大值/最小值/0值。如果在代碼中加入一些邊界斷言，可以幫助提早發現問題。
● 注意“null”的使用。不論開發還是測試，注意“null”的使用都可以幫助我們少犯一些錯誤，或者多發現一些問題。
● “殺蟲劑困境”的思考。再嚴密的單一性測試也不可能發現100%的Bug。將不同的測試思路和方法相結合，采用探索式的測試思維或許能幫助發現更多潛在問題。
說了這么多，我得閉嘴了，不低調的Bug是不厚道的，最后把一句很喜歡的佛語送給大家：“你見，或者不見我，我就在那里”，但是我們始終敵不過開發和測試的協同努力。
