我用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% 分支覆盖率。

这个数字是非常恐怖的，大家都知道覆盖所有分支很麻烦，例如这行代码：

}

想要达到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的这些测试，它的数量、完善程度和复杂程度，看起来真是让人脊背发凉。

这得付出多年的努力，经历多少事故才能写出来啊！

被这样测试保护的软件，代码质量可以说是固若金汤了。

AI能写出这样高质量的SQLite吗？

写个玩具版是可以的，但是想要复刻是万万不行的。

SQLite这种“高质量”不是体现在代码本身，而是体现在几十年积累的测试体系、失败经验和工程纪律上。

AI 可以帮助我们写实现、补测试、找 bug，但无法凭空生成那些来自真实事故、长期演化出来的异常场景和验证策略。

换句话说，AI 能参与写 SQLite，但还不能“独立孕育”一个 SQLite。

SQLite只是一个嵌入式数据库，就已经恐怖如斯了，那些更加复杂的数据库会怎么样呢？

欢迎了解详情的朋友在评论区留言！