我用AI開發數據庫，沒想到被狠狠地教育了......

我在之前的文章中介紹過SQLite，這是個嵌入式數據庫，也是世界上最流行的數據庫。

（詳情參見這篇文章：）

有一天我突發奇想：既然是嵌入式數據庫，那應該不復雜，能不能用AI寫一個？

說干就干，我把SQLite的架構文檔發給了AI，讓它根據現有架構來實現。

你別說，AI實現得相當不錯，把Tokenizer，Parser，Code Generator，Bytecode Engine這些核心的概念都考慮到了，代碼寫得也不錯，著實是讓我吃驚。

但是，當我看到SQLite的測試的時候，我就知道，現在的AI，想寫出SQLite級別的代碼，恐怕是做夢。

因為SQLite簡直不是一個軟件，而是個怪物。

截至 3.42.0 版本（2023-05-16），SQLite 庫本身大約包含15.58萬行C代碼。

而測試代碼和測試腳本腳本加起來一共有9205萬行，是核心代碼的 590 倍！

不是5倍，50倍，而是590倍 ！

測試的目標不但要覆蓋“功能”，還要覆蓋分支，覆蓋異常，覆蓋現實世界的災難。

SQLite設立了4套“互不信任”的測試體系，避免同一思路的盲區。

0 1

“保命”測試

首先，它用TCL寫了一套“日常保命測試”，測試腳本有1390個文件，一共23.2M，包含了51,445 個不同的測試用例，參數化執行，會跑出數百萬測試。

開發者日常主要依賴一個非常快的、幾分鐘就能跑完的子集，用于每次提交前自己檢查。

0 2

“徹底”測試

SQLite有一套私有的C語言測試系統（名稱為TH3），為 SQLite 核心庫提供 100% 分支覆蓋率。

這個數字是非?？植赖模蠹叶贾栏采w所有分支很麻煩，例如這行代碼：

}

想要達到100%分支覆蓋，至少需要3個測試用例：

(1) a<=b

(2) a>b 且 c==25

(3) a>b 且 c!=25

除了分支覆蓋，SQLite還是是實現了100% MC/DC 覆蓋率。

MC/DC（Modified Condition/Decision Coverage）是航空、核工業級別的測試標準。也就是說SQLite 把一個嵌入式數據庫，按飛控軟件的標準來測。

TH3有個非常重要的特點，就是不靠“后門”，只是用SQLite公開的API接口，完全模擬用戶的行為。

TH3 包含大約 76.9MB、100萬行C 代碼，實現了 50,362 個不同測試用例。

在發布之前的一個長時間壓力測試中，會執行2.485億次測試。

0 3

對標測試

這是一個裁判性測試，它將大量 SQL 語句同時運行在 SQLite 和其他4個數據庫引擎（PostgreSQL、MySQL、SQL Server、Oracle 10g ）上，并比較結果是否一致。

換句話說，SQLite 不只要自洽，還要和“行業共識”對齊。

這個測試共運行 720 萬條查詢，測試數據總量 1.12GB。

0 4

模糊測試

模糊測試通過向SQLite提供無效、意外或者隨機數據來測試它的健壯性。

例如這樣的SQL語言：

  CAST('999999999999999999999999' AS INTEGER) < 0;

它完全符合SQL語法，但是幾乎不可能是人寫的，因為它精準命中了“超大內存申請”，“整數溢出”，“負索引”等極端情況。

更殘酷的是，模糊測試還會破壞數據庫文件（.db），對它做隨機位翻轉、截斷、重復、拼接。

例如，這是原始的數據文件（簡化）：

[Header][Page1][Page2][Page3]

模糊測試工具把它改成：

[Header][Page1][Page1][亂碼][Page3][Page3]

然后嘗試去打開它：

sqlite3_open("mutated.db", &db);

SQLite要做到不崩潰，不越界，不死循環，要么報錯，要么優雅失敗。

最后，模糊測試還會開關所有的宏定義，對不同的編譯器設置不同的編譯優化級別，讓同一條SQL在不同的情況下瘋狂運行，瘋狂地鞭打SQLite，折磨SQLite，直到它漏出所有的破綻。

由于SQLite在嵌入式領域非常流行，手機、路由器、車載、工業設備等在大量使用它，所以它特別注重對異常情況的處理。

內存不足測試

在服務器和工作站上，內存分配malloc()幾乎不會失敗，在嵌入式設備上，OOM就太常見了，SQLite必須得能優雅的處理OOM錯誤。

SQLite的測試框架（自己寫的）可以插入自定義的可控的malloc函數，設置成在調用一定次數后內存分配失敗，這樣就可以在循環中執行SQLite操作，確保能處理OOM錯誤。

I/O錯誤測試

磁盤空間不足、磁盤硬件故障、網絡中斷、SQL操作過程中發生的系統配置或權限更改，或其他硬件或操作系統故障......無論原因如何，SQLite 必須能夠正確響應這些錯誤。

測試的方法和OOM測試類似，都是模擬I/O錯誤，然后檢查SQLite能否正確響應

崩潰測試

應用系統崩潰，操作系統崩潰，數據庫更新過程中斷電，SQLite都不能發生故障。

這也是SQLite“原子提交”能被信任的原因。

復合失效測試

先發生I/O錯誤，然后出現OOM，再搞一個崩潰..... 保證程序還能正常運行。

SQLite的這些測試，它的數量、完善程度和復雜程度，看起來真是讓人脊背發涼。

這得付出多年的努力，經歷多少事故才能寫出來?。?/p>

被這樣測試保護的軟件，代碼質量可以說是固若金湯了。

AI能寫出這樣高質量的SQLite嗎？

寫個玩具版是可以的，但是想要復刻是萬萬不行的。

SQLite這種“高質量”不是體現在代碼本身，而是體現在幾十年積累的測試體系、失敗經驗和工程紀律上。

AI 可以幫助我們寫實現、補測試、找 bug，但無法憑空生成那些來自真實事故、長期演化出來的異常場景和驗證策略。

換句話說，AI 能參與寫 SQLite，但還不能“獨立孕育”一個 SQLite。

SQLite只是一個嵌入式數據庫，就已經恐怖如斯了，那些更加復雜的數據庫會怎么樣呢？

歡迎了解詳情的朋友在評論區留言！