作者 | 杜沁園 等
責(zé)編 | 郭芮
出品 | CSDN（ID：CSDNnews）
曾在 Hacker News 上看到過(guò)一個(gè) Oracle 工程師處理 bug 的 日常：
先花兩周左右時(shí)間來(lái)理解 20 個(gè)參數(shù)如何通過(guò)神奇的組合引發(fā) bug。
改了幾行代碼，嘗試對(duì) bug 進(jìn)行修復(fù)，提交測(cè)試集群開(kāi)始跑近百萬(wàn)個(gè)測(cè)試 case，通常要 20~30 小時(shí)。
運(yùn)氣好的話會(huì)有 100 多個(gè) case 沒(méi)過(guò)，有時(shí)候上千個(gè)也有可能，只好挑選幾個(gè)來(lái)看，發(fā)現(xiàn)還有 10 個(gè)參數(shù)之前沒(méi)有注意到。
又過(guò)了兩周，終于找到了引起 bug 的真正參數(shù)組合，并跑通了所有測(cè)試。并增加 100 多個(gè)測(cè)試 case 確保覆蓋他的修改。
經(jīng)過(guò)一個(gè)多月的代碼 review，他的修改終于合并了，開(kāi)始處理下一個(gè) bug……
后來(lái)這個(gè)工程師感慨說(shuō)：“I don't work for Oracle anymore. Will never work for Oracle again!”
Oracle 12.2 有將近 2500 萬(wàn)行 C 代碼，復(fù)雜系統(tǒng)的測(cè)試是一件艱難、艱苦和艱巨的事情，而測(cè)試一個(gè)分布式數(shù)據(jù)庫(kù)的情況就更復(fù)雜了。我們永遠(yuǎn)不知道用戶(hù)可能寫(xiě)出什么樣的 SQL，表結(jié)構(gòu)和索引有多少種組合，此外還要考慮集群在什么時(shí)候節(jié)點(diǎn)發(fā)生宕機(jī)，以及受到網(wǎng)絡(luò)抖動(dòng)、磁盤(pán)性能退化等因素的影響——可能性幾乎是無(wú)限的。
那么有沒(méi)有一種方法能讓程序自動(dòng)幫我們查 bug？
如何做到「睡覺(jué)的時(shí)候讓程序自動(dòng)查 bug」？
項(xiàng)目的思路其實(shí)很簡(jiǎn)單，如果在每次跑 case 的時(shí)候能用統(tǒng)計(jì)學(xué)的方法對(duì)足夠多次實(shí)驗(yàn)的代碼路徑進(jìn)行分析，就可以找出疑似 bug 的代碼，最終結(jié)果以代碼染色的方式由前端可視化呈現(xiàn)，就得到了如下圖展示的效果：
「顏色越深，亮度越高」表示包含錯(cuò)誤邏輯的可能性越大。該方法不僅適用于數(shù)據(jù)庫(kù)系統(tǒng)的測(cè)試，同樣適用于其他任何復(fù)雜的系統(tǒng)。
背后的原理
項(xiàng)目最初是受到 VLDB 的一篇論文的啟發(fā) APOLLO: Automatic Detection and Diagnosis of Performance Regressions in Database Systems，該論文主要圍繞如何診斷引發(fā)數(shù)據(jù)庫(kù)性能回退的代碼，其核心思想也同樣適用于排查 bug。論文中提到的自動(dòng)診斷系統(tǒng)由 SQLFuzz，SQLMin 和 SQLDebug 三個(gè)模塊組成。
SQLFuzz：負(fù)責(zé)隨機(jī)生成 SQL，并利用二分查找定位到性能回退的前后兩個(gè)版本，傳遞給 SQLMin 模塊。
SQLMin：通過(guò)剪枝算法將 SQLFuzz 生成的 SQL 進(jìn)行化簡(jiǎn)，得出能夠復(fù)現(xiàn)該問(wèn)題的最小 SQL ，傳遞給 SQLDebug 模塊。目的是減少無(wú)關(guān)的代碼路徑，降低噪音。
SQLDebug：對(duì)源碼進(jìn)行插樁，使其在執(zhí)行 SQL 時(shí)能夠輸出代碼的執(zhí)行路徑。然后對(duì)兩個(gè)版本的代碼路徑進(jìn)行分析，建立一個(gè)統(tǒng)計(jì)模型來(lái)定位問(wèn)題的位置。
最終系統(tǒng)自動(dòng)生成測(cè)試報(bào)告，內(nèi)容包含：
哪一次的代碼 commit 引入了性能回退。
存在問(wèn)題的代碼源文件。
具體的函數(shù)位置。
而實(shí)際上，考慮到并發(fā)、循環(huán)、遞歸等帶來(lái)的影響，代碼執(zhí)行路徑分析會(huì)非常復(fù)雜。為了保證能夠在 Hackathon 那么短的時(shí)間內(nèi)展示出效果，我們又參考了另一篇論文 Visualization of Test Information to Assist Fault Localization，其核心思想是通過(guò)統(tǒng)計(jì)代碼塊被正確和錯(cuò)誤測(cè)試用例經(jīng)過(guò)次數(shù)，再基于分析算法來(lái)涂上不同的顏色，簡(jiǎn)單而實(shí)用。
其實(shí)借助這個(gè)思路也可以應(yīng)用到其他領(lǐng)域，后面我們將展開(kāi)來(lái)介紹。接下來(lái)我們先來(lái)看看 SQLDebug 是如何實(shí)現(xiàn)的。
聊聊細(xì) (gān) 節(jié) (huò)
如何自動(dòng)產(chǎn)生測(cè)試 case？
由于是基于統(tǒng)計(jì)的診斷，我們需要先構(gòu)建足夠多的測(cè)試用例，這個(gè)過(guò)程當(dāng)然最好也由程序自動(dòng)完成。事實(shí)上，grammar-based 的測(cè)試在檢驗(yàn)編譯器正確性方面有相當(dāng)長(zhǎng)的歷史，DBMS 社區(qū)也采用類(lèi)似的方法來(lái)驗(yàn)證數(shù)據(jù)庫(kù)的功能性。比如：微軟的 SQL Server 團(tuán)隊(duì)開(kāi)發(fā)的 RAGS 系統(tǒng)對(duì)數(shù)據(jù)庫(kù)進(jìn)行持續(xù)的自動(dòng)化測(cè)試，還有社區(qū)比較出名的 SQLSmith 項(xiàng)目等等。今年 TiDB Hackathon 的另一個(gè)獲獎(jiǎng)項(xiàng)目 sql-spider 也是實(shí)現(xiàn)類(lèi)似的目的。
這里我們暫時(shí)采用 PingCAP 開(kāi)源的隨機(jī)測(cè)試框架 go-randgen 實(shí)現(xiàn) SQL fuzzing，它需要用戶(hù)寫(xiě)一些規(guī)則文件來(lái)幫助生成隨機(jī)的 SQL 測(cè)試用例。規(guī)則文件由一些產(chǎn)生式組成。randgen 每次從 query 開(kāi)始隨機(jī)游走一遍產(chǎn)生式，生成一條 SQL，產(chǎn)生一條像下圖紅線這樣的路徑。
我們將每個(gè)產(chǎn)生式生成正確與錯(cuò)誤用例的比例作為該產(chǎn)生式的顏色值，繪制成一個(gè)頁(yè)面，作為 SQLFuzz 的展示頁(yè)面。通過(guò)該頁(yè)面，可以比較容易地看出哪條產(chǎn)生式更容易產(chǎn)生錯(cuò)誤的 SQL。
代碼跟蹤
為了跟蹤每一條 SQL 在運(yùn)行時(shí)的代碼執(zhí)行路徑，一個(gè)關(guān)鍵操作是對(duì)被測(cè)程序進(jìn)行插樁 (Dynamic Instrumentation)。VLDB 論文中提到一個(gè)二進(jìn)制插樁工具 DynamoRIO，但是我們不確定用它來(lái)搞 Go 編譯的二進(jìn)制能否正常工作。換一個(gè)思路，如果能在編譯之前直接對(duì)源碼進(jìn)行插樁呢？
參考 go cover tool 的實(shí)現(xiàn)，我們寫(xiě)了一個(gè)專(zhuān)門(mén)的代碼插樁工具 tidb-wrapper。它能夠?qū)θ我獍姹镜?TiDB 源碼進(jìn)行處理，生成 wrapped 代碼。并且在程序中注入一個(gè) HTTP Server，假設(shè)某條 SQL 的摘要是 df6bfbff（這里的摘要指的是 SQL 語(yǔ)句的 32 位 MurmurHash 計(jì)算結(jié)果的十六進(jìn)制，主要目的是簡(jiǎn)化傳輸?shù)臄?shù)據(jù)），那么只要訪問(wèn) http://<tidb-server-
ip>::43222/trace/df6bfbff 就能獲得該 SQL 所經(jīng)過(guò)的源碼文件和代碼塊信息。
因?yàn)橹饕繕?biāo)是正確性診斷，所以我們限定系統(tǒng)不對(duì) TiDB 并發(fā)執(zhí)行 SQL，這樣就可以認(rèn)為從 server/conn.go:handleQuery 方法被調(diào)用開(kāi)始，到 SQLDebug 模塊訪問(wèn) trace 接口的這段時(shí)間所有被執(zhí)行的基本塊都是這條 SQL 的執(zhí)行路徑。當(dāng) SQLDebug 模塊訪問(wèn) HTTP 接口，將會(huì)同時(shí)刪除該 SQL 相關(guān)的 trace 信息，避免內(nèi)存被撐爆。
基本塊統(tǒng)計(jì)
SQLDebug 模塊在獲取到每條 SQL 經(jīng)過(guò)的基本塊信息后，會(huì)對(duì)每個(gè)基本塊建立如下的可視化模型。
首先是顏色，經(jīng)過(guò)基本塊的失敗用例比例越高，基本塊的顏色就越深。
然后是亮度，經(jīng)過(guò)基本塊的失敗用例在總的失敗用例中占的比例越高，基本塊的亮度越高。
已經(jīng)有了顏色指標(biāo)，為什么還要一個(gè)亮度指標(biāo)呢？其實(shí)亮度指標(biāo)是為了彌補(bǔ)“顏色指標(biāo) Score”的一些偏見(jiàn)。比如某個(gè)代碼路徑只被一個(gè)錯(cuò)誤用例經(jīng)過(guò)了，那么它顯然會(huì)獲得 Score 的最高分 1，事實(shí)上這條路徑不那么有代表性，因?yàn)檫@么多錯(cuò)誤用例中只有一個(gè)經(jīng)過(guò)了這條路徑，大概率不是錯(cuò)誤的真正原因。所以需要額外的一個(gè)亮度指標(biāo)來(lái)避免這種路徑的干擾， 只有顏色深，亮度高的代碼塊，才是真正值得懷疑的代碼塊。
上面的兩個(gè)模型主要是依據(jù)之前提到的 Visualization 的論文，我們還自創(chuàng)了一個(gè)文件排序的指標(biāo)，失敗用例在該文件中的密度越大（按照基本塊），文件排名越靠前：
前端拿到這些指標(biāo)后，按照上面計(jì)算出的文件排名順序進(jìn)行展示，越靠前的文件存在問(wèn)題的風(fēng)險(xiǎn)就越高。
當(dāng)點(diǎn)擊展開(kāi)后可以看到染色后的代碼塊：
我們經(jīng)過(guò)一些簡(jiǎn)單的實(shí)驗(yàn)，文件級(jí)別的診斷相對(duì)比較準(zhǔn)確，對(duì)于基本塊的診斷相對(duì)還有些粗糙，這跟沒(méi)有實(shí)現(xiàn) SQLMin 有很大關(guān)系，畢竟 SQLMin 能去除不少統(tǒng)計(jì)時(shí)的噪聲。
還能不能做點(diǎn)別的？
看到這里，你可能覺(jué)得這個(gè)項(xiàng)目不過(guò)是針對(duì)數(shù)據(jù)庫(kù)系統(tǒng)的自動(dòng)化測(cè)試。而實(shí)際上借助代碼自動(dòng)調(diào)試的思路，可以給我們更多的啟發(fā)。
源碼教學(xué)
閱讀和分析復(fù)雜系統(tǒng)的源碼是個(gè)頭疼的事情，基于源碼的運(yùn)行時(shí)可視化跟蹤能否做成一個(gè)通用工具呢？這樣在程序執(zhí)行的同時(shí)就可以直觀地看到代碼的運(yùn)行過(guò)程，對(duì)快速理解源碼一定會(huì)大有幫助。更進(jìn)一步，配合源碼在線執(zhí)行有沒(méi)有可能做成一個(gè)在線 web 應(yīng)用呢？
全鏈路測(cè)試覆蓋統(tǒng)計(jì)
語(yǔ)言本身提供的單測(cè)覆蓋統(tǒng)計(jì)工具已經(jīng)比較完備了，但一般測(cè)試流程中還要通過(guò) e2e 測(cè)試、集成測(cè)試、穩(wěn)定性測(cè)試等等。能否用本文的方法綜合計(jì)算出各種測(cè)試的覆蓋度，并且與 CI 系統(tǒng)和自動(dòng)化測(cè)試平臺(tái)整合起來(lái)。利用代碼染色技術(shù)，還可以輸出代碼執(zhí)行的熱力圖分析。結(jié)合 profiler 工具，是不是還可以輔助來(lái)定位代碼的性能問(wèn)題？
Chaos Engineering
在 PingCAP 內(nèi)部有諸多的 Chaos 測(cè)試平臺(tái)，用來(lái)驗(yàn)證分布式系統(tǒng)的魯棒性，譬如像 Schrodinger，Jepsen 等等。混沌測(cè)試有個(gè)弊端就是，當(dāng)跑出問(wèn)題之后想再次復(fù)現(xiàn)就很難，所以只能通過(guò)當(dāng)時(shí)的情形去猜代碼可能哪里有問(wèn)題。如果能在程序運(yùn)行時(shí)記錄代碼的執(zhí)行路徑，根據(jù)問(wèn)題發(fā)生時(shí)間點(diǎn)附近的日志和監(jiān)控進(jìn)一步縮小范圍，再結(jié)合代碼路徑進(jìn)行分析就能精確快速的定位到問(wèn)題的原因。
與分布式 Tracing 系統(tǒng)集成
Google 有一篇論文是介紹其內(nèi)部的 分布式追蹤系統(tǒng) Dapper ，同時(shí)社區(qū)也有比較出名的項(xiàng)目 Open Tracing 作為其開(kāi)源實(shí)現(xiàn)，Apache 下面也有類(lèi)似的項(xiàng)目 Skywalking。一般的 Tracing 系統(tǒng)主要是跟蹤用戶(hù)請(qǐng)求在多個(gè)服務(wù)之間的調(diào)用關(guān)系，并通過(guò)可視化來(lái)輔助排查問(wèn)題。但是 Tracing 系統(tǒng)的跟蹤粒度一般是服務(wù)層面，如果我們把 trace_id 和 span_id 也當(dāng)作標(biāo)注傳遞給代碼塊進(jìn)行打樁，那是不是可以在 Tracing 系統(tǒng)的界面上直接下鉆到源碼，聽(tīng)起來(lái)是不是特別酷？
接下來(lái)的工作
以上我們只完成了一個(gè)非常簡(jiǎn)單的原型，距離真正實(shí)現(xiàn)睡覺(jué)時(shí)程序自動(dòng)查 bug 還有一段路要走，我們計(jì)劃對(duì)項(xiàng)目持續(xù)的進(jìn)行完善。
接下來(lái)，首先要支持并行執(zhí)行多個(gè)測(cè)試用例，這樣才能在短時(shí)間得到足夠多的實(shí)驗(yàn)樣本，分析結(jié)果才能更加準(zhǔn)確。另外，要將注入的代碼對(duì)程序性能的影響降低到最小，從而應(yīng)用于更加廣泛的領(lǐng)域，比如性能壓測(cè)場(chǎng)景，甚至在生產(chǎn)環(huán)境中也能夠開(kāi)啟。
看到這里可能你已經(jīng)按耐不住了，附上項(xiàng)目的完整源碼：
https://github.com/fuzzdebugplatform/fuzz_debug_platform
Welcome to hack!
作者簡(jiǎn)介：
黃寶靈，PingCAP 前端開(kāi)發(fā)工程師，喜歡 React 和 Type。
滿俊朋, 效率工具工程師, 目前在 PingCAP 從事 Benchmark, Stability 相關(guān)工具的研發(fā)。
杜沁園，中科大研究生，曾在 PingCAP 實(shí)習(xí)，從事數(shù)據(jù)庫(kù)測(cè)試工具的研發(fā)。
韓玉博，中科大研究生，在 Tradeshift 實(shí)習(xí)，從事前端開(kāi)發(fā)。