1. 引言

SQLite 的可靠性与健壮性部分得益于全面而严谨的测试。

截至 3.42.0 版本(2023-05-16)，SQLite 库包含约 155.8 KSLOC 的 C 代码。(KSLOC指千行源代码，即排除空行和注释后的代码行数。)相比之下，该项目的测试代码与脚本总量达92053.1 KSLOC，是代码量的590倍。

1.1. 执行摘要

• 四套独立开发的测试框架
• 部署环境下100%分支测试覆盖率
• 数以百万计的测试用例
• 内存耗尽测试
• I/O错误测试
• 崩溃与断电测试
• 模糊测试
• 边界值测试
• 禁用优化测试
• 回归测试
• 数据库格式异常测试
• 广泛运用 assert() 及运行时检查
• Valgrind 内存分析
• 未定义行为检测
• 检查清单

2. 测试框架

SQLite 核心库采用四套独立测试框架进行验证。每套框架均独立设计、维护与管理。

1. TCL测试是SQLite的原始测试套件。它们与SQLite核心位于同一源代码树中，同样属于公共领域。TCL测试是开发过程中主要使用的测试工具，采用TCL脚本语言编写。TCL测试框架本身包含27.2 KSLOC的C代码，用于创建TCL接口。测试脚本分布于1390个文件中，总大小为23.2MB。共有51445个独立测试用例，但其中许多用例采用参数化设计并多次运行(使用不同参数)，因此完整测试运行时将执行数百万个独立测试。
2. **TH3**测试框架是一套专有测试集，采用C语言编写，为SQLite核心库提供100%分支测试覆盖率(及100%多分支/双覆盖率测试)。TH3测试专为嵌入式及专用平台设计，此类平台通常难以支持TCL或其他工作站服务。TH3测试仅使用SQLite公开接口，包含约76.9MB或1055.4千行C代码，实现50362个独立测试用例。TH3测试采用高度参数化设计，因此完整覆盖测试需运行约240万个不同测试实例。实现100%分支测试覆盖的案例构成TH3测试套件的子集。发布前的持续测试约执行2.485亿次测试。TH3的更多信息可另行查阅。
3. SQL逻辑测试(SLT测试框架)用于对SQLite及其他多种SQL数据库引擎执行海量SQL语句，验证其返回结果的一致性。当前SLT对比对象包括SQLite、PostgreSQL、MySQL、Microsoft SQL Server及Oracle 10g。该测试运行720万条查询，测试数据总量达1.12GB。
4. dbsqlfuzz引擎为专有模糊测试工具。其他SQLite模糊测试工具仅变异SQL输入或数据库文件。Dbsqlfuzz同时变异SQL语句与数据库文件，从而能触发全新错误状态。Dbsqlfuzz基于LLVM的libFuzzer框架构建，并采用自定义变异器。包含336个种子文件。该模糊测试器每日运行约十亿次测试变异。Dbsqlfuzz确保SQLite能抵御恶意SQL或数据库输入的攻击。

除四大核心测试框架外，另有众多实现专项测试的小型程序，例如：

1. “speedtest1.c” 程序评估 SQLite 在典型工作负载下的性能表现
2. “mptester.c” 程序对多个进程并发读写单一数据库进行压力测试
3. “threadtest3.c”程序用于测试多个线程同时使用SQLite时的压力。
4. “fuzzershell.c”程序用于运行某些模糊测试。
5. “jfuzz”程序基于libfuzzer库，用于对JSON SQL函数的JSONB输入进行模糊测试。

在每次 SQLite 发布前，上述所有测试必须在多个平台和多种编译配置下成功运行。

每次向 SQLite 源代码树提交代码前，开发者通常会运行 Tcl 测试的子集(称为“veryquick”)，该子集包含约 304.7 万个测试用例。veryquick 测试涵盖除异常测试、模糊测试和持续测试外的绝大多数测试。其设计理念在于：既能有效捕获多数错误，又能将运行时间控制在数分钟而非数小时。

3. 异常测试

异常测试旨在验证SQLite在异常情况下的正确行为。构建能在功能完备的计算机上处理规范输入的SQL数据库引擎相对容易，而构建能对无效输入作出合理响应、并在系统故障后持续运行的系统则更为困难。异常测试正是为验证后者而设计。

3.1 内存耗尽测试

与所有SQL数据库引擎相同，SQLite大量使用malloc()函数(详见[SQLite动态内存分配]专题报告[https://sqlite.org/malloc.html])。在服务器和工作站环境中，malloc() 实际运行中从未失败，因此内存不足(OOM)错误的正确处理并不特别重要。但在嵌入式设备上，OOM 错误却频繁得令人不安。鉴于 SQLite 常被用于嵌入式设备，确保其能优雅处理 OOM 错误至关重要。

内存不足测试通过模拟内存不足错误来实现。SQLite允许应用程序通过sqlite3_config(SQLITE_CONFIG_MALLOC,…)接口替换默认的malloc()实现。TCL和TH3测试框架均能插入修改版malloc()函数，使其在完成特定次数分配后触发故障。这些可监控的malloc实现可设置为仅失败一次后恢复正常，或首次失败后持续报错。OOM测试采用循环执行模式：循环首轮中，监控版malloc被设定为首次分配即失败。随后执行SQLite操作并验证其是否正确处理内存不足错误。此时将仪器化malloc的故障计时器递增一次，循环重复测试。该过程持续进行，直至整个操作流程在未触发模拟内存不足错误的情况下完成。此类测试需执行两次：首次将仪器化malloc设置为仅失败一次，第二次则设置为首次失败后持续失败。

3.2. I/O错误测试

I/O错误测试旨在验证SQLite对I/O操作失败的合理响应。I/O错误可能由磁盘空间耗尽、磁盘硬件故障、网络文件系统连接中断、SQL操作过程中系统配置或权限变更，或其他硬件/操作系统异常引发。无论成因如何，关键在于SQLite能否正确处理这些错误，而I/O错误测试正是为此而设。

I/O错误测试与内存不足测试原理相似： 通过模拟I/O错误并验证SQLite能否正确响应，来实现测试目的。在TCL和TH3测试框架中，均通过插入特殊设计的虚拟文件系统对象来模拟I/O错误——该对象会在执行固定次数I/O操作后触发模拟错误。与内存不足测试类似，I/O错误模拟器可设置为仅失败一次，或首次失败后持续失败。测试以循环方式运行，逐步提高失败阈值直至测试用例无误完成。该循环执行两次：首次设置模拟器仅模拟单次失败，第二次则设置为首次失败后所有I/O操作均失败。

在I/O错误测试中，禁用错误模拟机制后，将通过PRAGMA integrity_check检查数据库，确保I/O错误未导致数据损坏。

3.3. 崩溃测试

崩溃测试旨在验证SQLite数据库在应用程序或操作系统崩溃、或数据库更新过程中遭遇断电时不会发生损坏。另一篇题为SQLite中的原子提交的白皮书详细描述了SQLite为防止崩溃后数据库损坏所采取的防御措施。崩溃测试致力于验证这些防御措施是否有效。

当然，使用真实断电进行崩溃测试并不现实，因此崩溃测试通过模拟方式实现。系统会插入一个替代的虚拟文件系统，使测试框架能够模拟崩溃后数据库文件的状态。

在TCL测试框架中，崩溃模拟由独立进程执行。主测试进程会生成子进程，该子进程执行SQLite操作并在写入过程中随机引发崩溃。特殊VFS会随机重排并破坏未同步的写入操作，以模拟缓冲文件系统的影响。子进程终止后，原始测试进程会打开并读取测试数据库，验证子进程尝试的变更要么已成功完成，要么已被完全回滚。通过使用integrity_check PRAGMA指令确保数据库完整性不受破坏。

TH3测试框架需在嵌入式系统上运行，而这类系统未必具备创建子进程的能力，因此它采用内存中的虚拟文件系统来模拟崩溃。该内存虚拟文件系统可配置为在完成设定次数的I/O操作后生成文件系统快照。崩溃测试以循环方式运行：每次迭代时，快照生成点将向前推进，直至被测SQLite操作在未触发快照的情况下完成执行。在循环内部，待测SQLite操作完成后，文件系统将回滚至快照状态，并引入随机文件损坏——这种损坏特征与断电后常见的损坏类型一致。随后打开数据库并执行检查，确保其结构完整且事务要么已完全执行，要么已完全回滚。每次快照都会重复执行循环内部逻辑，每次随机损坏模式均不相同。

3.4. 复合故障测试

SQLite测试套件还探索了多重故障叠加的情形。例如，当系统尝试从先前崩溃中恢复时，若发生I/O错误或内存不足故障，相关测试将验证其正确行为。

4. 模糊测试

模糊测试旨在验证SQLite能否正确响应无效、超出范围或格式错误的输入。

4.1. SQL模糊测试

SQL模糊测试通过生成语法正确但语义荒谬的SQL语句，观察SQLite的处理行为。通常会返回某种错误(如“表不存在”)。偶尔纯属偶然，SQL语句也可能语义正确。此时需执行生成的预编译语句，确保其返回合理结果。

4.1.1. 使用American Fuzzy Lop模糊测试器进行SQL模糊测试

模糊测试的概念已存在数十年，但直到2014年Michal Zalewski发明首个实用的剖析引导模糊测试器——American Fuzzy Lop(简称AFL)后，该技术才成为有效的漏洞发现手段。与早期盲目生成随机输入的模糊测试器不同，AFL通过修改C编译器的汇编语言输出对被测程序进行仪器化改造，利用仪器化机制检测输入是否导致程序行为改变——例如进入新控制路径或循环次数变化。引发新行为的输入将被保留并进一步变异。通过这种方式，AFL能够“发现”被测程序的新行为，包括开发者从未预见的异常行为。

AFL在发现SQLite的隐蔽缺陷方面表现卓越。多数发现是条件判断在特殊情况下失效的assert()语句，但也成功定位了大量SQLite崩溃缺陷，甚至发现若干计算结果错误的案例。

凭借过往的成功，AFL自3.8.10版起成为SQLite测试策略的标准组成部分 (2015-05-07) 开始成为 SQLite 测试策略的标准组成部分，直至被 版本 3.29.0 (2019-07-10) 中的更优模糊测试器取代。

4.1.2. Google OSS Fuzz

自2016年起，谷歌工程师团队启动了OSS Fuzz项目。OSS Fuzz基于AFL风格的引导式模糊测试器，运行于谷歌基础设施之上。该测试器会自动下载参与项目的最新提交代码，执行模糊测试后通过邮件向开发者报告问题。当修复代码提交后，测试器会自动检测并向开发者发送确认邮件。

SQLite是OSS Fuzz测试的众多开源项目之一。SQLite代码库中的test/ossfuzz.c源文件即为SQLite对接OSS Fuzz的接口。

目前OSS Fuzz已不再发现SQLite的历史漏洞，但该系统仍在持续运行，并偶尔能在新提交的代码中发现问题。示例：[1] [2] [3]。

4.1.3. dbsqlfuzz 与 jfuzz 模糊测试工具

自2018年末起，SQLite开始采用名为“dbsqlfuzz”的专有模糊测试工具进行测试。该工具基于LLVM的libFuzzer框架构建。

dbsqlfuzz模糊测试工具同时变异SQL输入和数据库文件。它采用定制的结构感知变异器，处理专用的输入文件——该文件既定义输入数据库，也定义针对该数据库执行的SQL文本。由于同时变异输入数据库和SQL文本，dbsqlfuzz成功发现了SQLite中某些被传统模糊测试工具遗漏的隐蔽缺陷——这些工具仅变异SQL输入或数据库文件。SQLite开发团队始终在主干代码库上运行约16核的dbsqlfuzz测试。每个 dbsqlfuzz 实例每秒可评估约 400 个测试用例，意味着每天检查约 5 亿个用例。

dbsqlfuzz 模糊测试器在强化 SQLite 代码库抵御恶意攻击方面成效显著。自其纳入 SQLite 内部测试套件后，来自 OSSFuzz 等外部模糊测试器的漏洞报告已基本停止。

需注意：dbsqlfuzz 并非 Chromium所采用的基于Protobuf的SQLite结构感知模糊测试器，后者详见结构感知变异器文章。这两款模糊测试工具除同基于libFuzzer外并无关联。SQLite的Protobuf模糊测试工具由谷歌Chromium团队编写维护，而dbsqlfuzz则由SQLite原始开发者团队负责开发与维护。拥有多个独立开发的SQLite模糊测试工具是好事，这意味着更可能发现隐蔽问题。

2024年1月底，基于libFuzzer的第二款工具“jfuzz”投入使用。Jfuzz生成损坏的JSONB二进制数据块，并将其输入JSON SQL函数以验证这些函数能否安全高效地处理损坏的二进制输入。

4.1.4. 其他第三方模糊测试工具

SQLite似乎是第三方模糊测试的热门目标。开发者们了解到许多针对SQLite的模糊测试尝试，偶尔也会收到独立模糊测试工具发现的漏洞报告。所有此类报告均得到及时修复，从而提升产品品质，使整个SQLite用户群体受益。这种依靠众多独立测试者的机制与林纳斯定律相通：“只要有足够多双眼睛，所有漏洞都将浮出水面”。

值得特别关注的模糊测试研究者是Manuel Rigger。多数模糊测试工具仅能发现断言错误、崩溃、未定义行为(UB)等易检测异常，而Rigger博士的工具能定位SQLite计算出错误结果的场景。里格已发现大量此类案例。其中多数是涉及类型转换和亲和性转换的晦涩边界情况，且不少发现针对的是未发布的特性。尽管如此，这些发现仍具有重要价值——它们都是真实存在的漏洞，SQLite开发者们也感激能借此识别并修复底层问题。

4.1.5. fuzzcheck测试框架

来自AFL的历史测试用例、 OSS Fuzz及dbsqlfuzz的历史测试用例，均收录于SQLite主源代码树中的数据库文件集。每当执行“make test”时，“fuzzcheck”工具程序会自动重运行这些用例。在各类模糊测试工具多年积累的数十亿测试案例中，Fuzzcheck仅会筛选数千个“有价值”的案例进行运行。所谓“有价值”案例，即指展现出前所未见行为的测试场景。模糊测试工具发现的实际缺陷始终包含在这些有价值的测试案例中，但Fuzzcheck运行的多数案例从未成为实际缺陷。

4.1.6. 模糊测试与100% MC/DC测试的矛盾

模糊测试与100% MC/DC测试存在矛盾关系。具体而言：通过100% MC/DC测试的代码往往更易受模糊测试发现的问题影响；而在模糊测试中表现良好的代码，其MC/DC覆盖率通常远低于100%。这是因为覆盖率测试会抑制包含不可达分支的防御性代码，而缺乏防御性代码时，模糊测试更容易发现引发问题的路径。覆盖率测试似乎更适合构建日常使用中稳健的代码，而模糊测试则擅长构建能抵御恶意攻击的稳健代码。

当然，用户更希望代码在正常使用时既能保持健壮性，又能抵御恶意攻击。SQLite开发者正致力于实现这一目标。本节仅旨在指出同时达成这两点实属不易。

在漫长的发展历程中，SQLite始终专注于100%的覆盖率/数据覆盖率(MC/DC)测试。直到2014年模糊测试框架AFL问世后，抵御模糊攻击才成为关注焦点。当时模糊测试工具曾发现SQLite存在诸多问题。近年来，SQLite的测试策略已进化为更侧重模糊测试。我们仍保持核心代码100%的MC/DC覆盖率，但当前大部分测试CPU周期都投入于模糊测试。

尽管模糊测试与100% MC/DC测试存在张力，但二者并非完全背道而驰。SQLite测试套件实现100%覆盖的事实意味着：当模糊测试发现问题时，既能快速修复，又可最大限度避免引入新错误。

4.2. 异常数据库文件

大量测试用例验证了SQLite处理异常数据库文件的能力。这些测试首先构建结构完整的数据库文件，随后通过非SQLite手段修改文件中一个或多个字节引入损坏。接着使用SQLite读取该数据库。部分测试中，修改发生在数据中间位置，导致数据库内容改变但结构仍完整；另一些测试则修改文件未使用字节，不影响数据库完整性。关键测试场景在于修改定义数据库结构的字节。这些测试验证SQLite能否识别文件格式错误，并通过SQLITE_CORRUPT返回码报告问题，同时避免缓冲区溢出、空指针解引用等异常操作。

dbsqlfuzz模糊测试工具同样出色地验证了SQLite对格式错误数据库文件的合理响应机制。

4.3. 边界值测试

SQLite对其操作定义了若干限制，例如表的最大列数、SQL语句的最大长度以及整数的最大值。TCL和TH3测试套件均包含大量将SQLite推至定义边界的测试，以验证其在所有允许值下的正确性。额外测试则突破定义边界，验证SQLite能否正确返回错误。源代码中包含测试用例宏，用于确保每个边界两侧均被测试。

5. 回归测试

每当SQLite出现已报告缺陷，在TCL或TH3测试套件中新增能复现该缺陷的测试用例前，该缺陷均不视为修复。多年来，此机制已催生数以千计的新测试。这些回归测试确保历史修复的缺陷不会在SQLite后续版本中复现。

6. 自动资源泄漏检测

资源泄漏指系统资源被分配后未被释放。多数应用中最棘手的泄漏是内存泄漏——即使用malloc()分配内存后未通过free()释放。但其他资源也可能泄漏：文件描述符、线程、互斥锁等。

TCL和TH3测试框架均能自动追踪系统资源，并在每次测试运行时报告泄漏情况。无需特殊配置或设置。测试框架对内存泄漏尤为警惕：若变更导致内存泄漏，测试框架将迅速识别。SQLite设计上确保永不泄漏内存，即使在内存不足(OOM)或磁盘I/O错误等异常情况下亦然。测试框架对此执行机制极为严格。

7. 测试覆盖率

SQLite核心(含Unix虚拟文件系统VFS)在默认配置下，经gcov测得其TH3分支覆盖率达100%。FTS3和RTree等扩展模块未纳入本次分析。

7.1. 语句覆盖率与分支覆盖率

测试覆盖率存在多种衡量方式，最常见的是“语句覆盖率”。当人们提及程序“XX%测试覆盖率”时，若无进一步说明，通常指的就是语句覆盖率。该指标衡量测试套件中至少执行过一次的代码行占比。

分支覆盖率比语句覆盖率更严谨。它衡量的是机器码分支指令在两个方向上均至少被评估一次的数量。

为说明语句覆盖率与分支覆盖率的区别，请考虑以下假设的C代码行：

if( a>b && c!=25 ){ d++; }

此类C代码行可能生成十余条独立的机器码指令。只要其中任意一条指令被执行过，我们就认为该语句已被测试。例如，当条件表达式始终为假时，变量“d”可能永远不会被递增。即便如此，语句覆盖率仍将此行代码计为已测试。

分支覆盖率则更为严格。它要求对语句内的每个测试条件及子代码块分别进行评估。要使上述示例达到100%分支覆盖率，至少需要三组测试用例：

*   a<=b
*   a>b && c==25
*   a>b && c!=25

上述任一测试用例可实现100%语句覆盖率，但需三者齐备才能达成100%分支覆盖率。通常而言，100%分支覆盖率意味着100%语句覆盖率，但反之则不成立。需要再次强调的是，SQLite的TH3测试框架提供了更严格的测试覆盖标准——100%分支测试覆盖率。

7.2. 防御性代码的覆盖率测试

编写良好的C程序通常包含某些防御性条件语句，这些语句在实际运行中总是为真或总是为假。这引发编程困境：是否应移除防御性代码以获得100%分支覆盖率？

在SQLite中，答案是否定的。为测试需求，SQLite源代码定义了ALWAYS()和NEVER()宏。ALWAYS()宏包裹预期始终为真的条件，NEVER()包裹预期始终为假的条件。这些宏作为注释标识条件语句属于防御性代码。在正式构建中，这些宏会直接传递参数：

#define ALWAYS(X)  (X)
#define NEVER(X)   (X)

但在多数测试场景中，若参数未达到预期真值，这些宏将触发断言错误，从而快速警示开发者设计假设存在谬误。

#define ALWAYS(X)  ((X)?1:assert(0),0)
#define NEVER(X)   ((X)?assert(0),1:0)

在测量测试覆盖率时，这些宏被定义为常量真值，因此不会生成汇编语言分支指令，从而在计算分支覆盖率时不被计入：

#define ALWAYS(X)  (1)
#define NEVER(X)   (0)

测试套件设计为运行三次，分别对应上述ALWAYS()和NEVER()的定义。三次测试运行应产生完全相同的结果。运行时测试使用sqlite3_test_control (SQLITE_TESTCTRL_ALWAYS, …) 接口，可验证宏是否正确设置为部署所需的首选形式(即直通形式)。

7.3. 强制覆盖边界值与布尔向量测试

另一个与测试覆盖率测量配合使用的宏是 testcase()。其参数为需要生成同时评估为真和假的测试用例的条件表达式。在非覆盖率构建(即发布构建)中，testcase() 宏不执行任何操作：

#define testcase(X)

但在覆盖率测量构建中，testcase() 宏会生成评估其参数中条件表达式的代码。分析阶段会检查是否存在使该条件同时为真和假的测试用例。例如，testcase()宏可用于验证边界值是否被测试：

testcase( a==b );
testcase( a==b+1 );
if( a>b && c!=25 ){ d++; }

当switch语句中两个或多个分支指向相同代码块时，同样需要使用测试案例宏确保所有分支均被执行：

switch( op ){
  case OP\_Add:
  case OP\_Subtract: {
    testcase( op==OP\_Add );
    testcase( op==OP\_Subtract );
    /\* ... \*/
    break;
  }
  /\* ... \*/
}

位掩码测试中，testcase()宏用于验证掩码的每个位均影响结果。例如以下代码块中，若掩码包含MAIN_DB或TEMP_DB任一标识位则条件成立： if语句前的testcase()宏确保两种情况均被测试：

testcase( mask & SQLITE\_OPEN\_MAIN\_DB );
testcase( mask & SQLITE\_OPEN\_TEMP\_DB );
if( (mask & (SQLITE\_OPEN\_MAIN\_DB|SQLITE\_OPEN\_TEMP\_DB))!=0 ){ ... }

SQLite源代码中共使用了1184次testcase()宏。

7.4. 分支覆盖率与MC/DC覆盖率

上文描述了两种测试覆盖率测量方法：“语句覆盖率”和“分支覆盖率”。除这两种外，还有许多其他测试覆盖率指标。另一种常见指标是“修改条件/决策覆盖率”(MC/DC)。维基百科对MC/DC的定义如下：

• 每个决策点尝试所有可能的结果
• 决策点中的每个条件都呈现所有可能的结果
• 每个入口点和出口点均被调用
• 决策点中的每个条件都独立影响决策结果

在C语言中，由于**&&和||**是“短路”运算符，MC/DC与分支覆盖率几乎完全一致。主要区别在于布尔向量测试。即使未满足决策覆盖的第二项要求(即每个决策条件必须呈现所有可能结果)，只要对位向量中的任意多个位进行测试，仍可获得100%分支测试覆盖率。

SQLite通过前节所述的testcase()宏确保位向量决策中的每个条件都呈现所有可能结果。由此，SQLite在实现100%分支覆盖率的同时，也达成了100%的MC/DC覆盖率。

7.5. 分支覆盖率测量

SQLite当前使用gcov配合“-b”选项测量分支覆盖率。首先使用“-g -fprofile-arcs -ftest-coverage”选项编译测试程序，随后运行测试程序。接着执行“gcov -b”生成覆盖率报告。由于原始报告冗长且不易阅读，会通过简单脚本处理gcov生成的报告，将其转换为更易读的格式。整个过程当然已通过脚本实现自动化。

需注意：使用 gcov 运行 SQLite 并非对 SQLite 本身的测试，而是对测试套件的验证。gcov 运行不会测试 SQLite，因为 -fprofile-args 和 -ftest-coverage 选项会导致编译器生成不同代码。gcov 运行仅验证测试套件是否提供 100% 分支测试覆盖率。gcov 运行本质上是对测试的测试——即元测试。

在通过 gcov 验证 100% 分支测试覆盖率后，需使用交付编译器选项(不带特殊参数 -fprofile-arcs 和 -ftest-coverage)重新编译测试程序，并再次运行测试。第二次运行才是对 SQLite 的实际测试。

关键在于验证gcov测试运行与第二次实际测试运行必须产生相同输出。任何输出差异均表明SQLite代码存在未定义行为或不确定行为(即存在缺陷)，或是编译器本身存在缺陷。需注意，过去十年间SQLite曾先后在GCC、Clang和MSVC编译器中发现过缺陷。编译器缺陷虽罕见但确实存在，因此在交付配置环境下测试代码至关重要。

7.6. 变异测试

使用 gcov(或类似工具)验证每个分支指令在两个方向上均至少被执行一次，是衡量测试套件质量的有效手段。但更优的验证方式是证明每个分支指令都能改变输出结果。换言之，我们不仅要验证每个分支指令都存在跳转和穿透两种情况，更要确保每个分支都在执行有效工作，且测试套件能够检测并验证该工作。若发现某分支指令对输出结果毫无影响，则表明：与该分支关联的代码可被移除(从而缩减库体积并可能提升运行速度)，或者测试套件未能充分验证该分支所实现的功能特性。

SQLite 致力于通过变异测试验证每个分支指令的有效性。具体流程如下：脚本首先将 SQLite 源代码编译为汇编语言(例如使用 gcc 的 -S 选项)。随后该脚本逐行遍历生成的汇编代码，将每个分支指令依次替换为无条件跳转或空操作指令，重新编译后验证测试套件能否捕获该变异。

遗憾的是，SQLite中存在大量不改变输出结果却能提升运行效率的分支指令。此类分支在变异测试中会产生误报。以用于加速表名查找的哈希函数为例：

55  static unsigned int strHash(const char \*z){
56    unsigned int h = 0;
57    unsigned char c;
58    while( (c = (unsigned char)\*z++)!=0 ){     /\*OPTIMIZATION-IF-TRUE\*/
59      h = (h<<3) ^ h ^ sqlite3UpperToLower\[c\];
60    }
61    return h;
62  }

若将第58行实现“c!=0”测试的分支指令改为空操作，则while循环将无限循环，测试套件将因超时失败。但若将该分支改为无条件跳转，哈希函数将始终返回0。问题在于0本身是有效的哈希值。始终返回0的哈希函数在某种意义上仍能正常工作——SQLite仍能得到正确结果。此时表名哈希表会退化为链表，导致解析SQL语句时的表名查找速度略有下降，但最终结果保持一致。

为解决此问题，SQLite源代码中插入了“/*OPTIMIZATION-IF-TRUE*/‘和’/*OPTIMIZATION-IF-FALSE*/”形式的注释，用于告知变异测试脚本忽略某些分支指令。

7.7. 全覆盖测试实践

SQLite开发者发现，全覆盖测试是定位和预防缺陷的极高效方法。由于SQLite核心代码中的每个分支指令都受到测试用例覆盖，开发者可确信代码某部分的变更不会在其他部分引发意外后果。近年来SQLite新增的众多功能与性能优化，若无全覆盖测试的支持将难以实现。

维持100%的MC/DC覆盖率既费时又费力。对于普通应用程序而言，维持全面覆盖测试所需的投入可能并不划算。然而对于SQLite这类广泛部署的基础设施库，尤其是本质上“记忆”历史错误的数据库库而言，我们认为全覆盖测试具有充分合理性。

8. 动态分析

动态分析指在SQLite代码运行时执行的内部与外部检查。实践证明动态分析对维护SQLite质量大有裨益。

8.1. 断言

SQLite核心包含6754个assert()语句，用于验证函数先决条件、后置条件及循环不变量。assert()作为ANSI-C标准宏，其参数默认为布尔值且始终被视为真。若断言为假，程序将打印错误信息并终止。

通过定义NDEBUG宏进行编译可禁用Assert()宏。多数系统默认启用断言功能，但SQLite因断言数量庞大且分布于性能关键位置，启用断言会导致数据库引擎运行速度降低约三分之二。因此SQLite默认(生产环境)构建版本禁用了断言功能。仅当编译时定义 SQLITE_DEBUG 预处理器宏时，断言语句才会启用。

有关 SQLite 如何使用 assert() 的详细信息，请参阅文档SQLite 中 assert 的使用。

8.2. Valgrind

Valgrind 堪称全球最强大实用的开发工具。它本质上是模拟器——模拟x86架构运行Linux二进制文件的环境。(Valgrind在Linux以外平台的移植版本正在开发中，但截至本文撰写时，Valgrind仅能在Linux上稳定运行。SQLite开发者认为这意味着Linux应成为所有软件开发的优先平台。)由于Valgrind运行的是Linux二进制程序，它能检测各类关键错误，例如数组越界、读取未初始化内存、栈溢出、内存泄漏等。Valgrind能发现其他SQLite测试中容易遗漏的问题。当Valgrind检测到错误时，可将开发者直接定位到错误发生的精确位置，进入符号调试器，从而快速修复问题。

由于Valgrind本质是模拟器，在其中运行二进制文件的速度会慢于原生硬件。(粗略估算，工作站上Valgrind运行的应用程序性能约等同于智能手机原生运行时的表现。)因此通过Valgrind运行完整的SQLite测试套件并不现实。不过每次发布前，我们都会通过Valgrind运行快速测试和TH3测试的覆盖部分。

8.3. Memsys2

SQLite包含一个可插拔的内存分配子系统。默认实现使用系统的malloc()和free()函数。但若SQLite在编译时启用SQLITE_MEMDEBUG选项，则会插入替代内存分配封装器(memsys2)，该封装器能在运行时检测内存分配错误。memsys2封装器不仅检测内存泄漏，还可识别缓冲区溢出、未初始化内存使用及内存释放后尝试访问等错误。这些检测功能Valgrind同样具备(且实现更完善)，但memsys2的优势在于运行速度远快于Valgrind，这意味着检测频率更高且能支持更长时间的测试。

8.4. 互斥锁断言

SQLite内置可插拔的互斥锁子系统。根据编译时选项，默认互斥锁系统包含sqlite3_mutex_held()和sqlite3_mutex_notheld() 用于检测特定互斥锁是否被调用线程持有。SQLite 在 assert() 语句中广泛使用这两个接口，以验证互斥锁在正确时机被获取和释放，从而确保 SQLite 在多线程应用中正常运行。

8.5. 日志测试

SQLite为确保事务在系统崩溃和断电时保持原子性，会在修改数据库前将所有变更写入回滚日志文件。TCL测试框架包含一个替代的操作系统后端实现，用于验证此机制是否正确运行。“日志测试VFS”监控数据库文件与回滚日志间的全部磁盘I/O流量，确保任何写入数据库文件的操作都已事先写入并同步至回滚日志。若发现任何差异，将触发断言错误。

日志测试是对崩溃测试的额外双重检查，旨在确保SQLite事务在系统崩溃和断电时保持原子性。

8.6. 未定义行为检测

在C语言编程中，极易编写出具有“未定义”或“实现定义”行为的代码。这意味着代码在开发阶段可能正常运行，但在不同系统或使用不同编译器选项重新编译时却产生不同结果。ANSI C中未定义及实现定义行为的示例包括：

• 有符号整数溢出(与多数人预期的不同，有符号整数溢出未必会发生溢出循环)。
• 对N位整数进行超过N位的位移操作
• 执行负位移操作
• 对负数进行位移操作
• 对重叠缓冲区使用memcpy()函数
• 函数参数的求值顺序
• “char”变量是否为有符号或无符号类型
• 等等…

由于未定义行为和实现定义行为缺乏可移植性且易导致错误结果，SQLite竭力规避此类情况。例如在SQL语句中对两个整数列值进行加法运算时，SQLite不会直接使用C语言的“+”运算符，而是先检查加法是否会溢出，若会则改用浮点运算。

为确保SQLite不涉及未定义或实现定义行为，测试套件会通过检测未定义行为的仪器化构建重新运行。例如：使用GCC的“-ftrapv”选项运行测试套件，再使用Clang的“-fsanitize=undefined”选项重新运行。此外，还使用MSVC的“/RTC1”选项进行测试。随后通过“-funsigned-char”和“-fsigned-char”等选项重新运行测试套件，确保实现差异不会影响结果。测试在32位和64位系统、大端序和小端序系统上重复进行，并覆盖多种CPU架构。此外，测试套件还增补了大量刻意设计用于诱发未定义行为的测试用例。例如：“SELECT -1*(-9223372036854775808);”。

9. 禁用优化测试

通过sqlite3_test_control(SQLITE_TESTCTRL_OPTIMIZATIONS, …)接口，可在运行时禁用特定SQL语句优化功能。无论启用与否，SQLite 生成的查询结果应完全一致；启用优化仅能加速响应。因此在生产环境中，应始终保持默认设置(即启用优化)。

SQLite采用的一种验证技术是运行完整的测试套件两次：第一次保留优化功能，第二次关闭优化功能，并验证两次结果完全一致。这表明优化措施不会引入错误。

并非所有测试用例都适用此方法。部分测试通过统计查询过程中发生的磁盘访问次数、排序操作、全表扫描步骤及其他处理步骤，验证优化是否真正减少了计算量。当禁用优化时，这些测试用例会显示失败。但多数测试用例仅需验证结果正确性，此类用例无论启用与否均可成功运行，从而证明优化机制不会导致功能异常。

10. 检查清单

SQLite开发者使用在线检查清单协调测试活动，并在每次SQLite发布前验证所有测试通过。历史检查清单保留供查阅。匿名访客仅能查看清单，开发者可登录后通过浏览器更新清单项。SQLite测试及其他开发活动采用检查表的做法，灵感源自《检查表宣言》(http://atulgawande.com/book/the-checklist-manifesto/)。

最新检查表包含约200项内容，每次发布时均需逐项验证。部分项目仅需数秒即可验证并标记完成，而另一些则涉及运行数小时的测试套件。

发布检查清单未实现自动化：开发者需手动执行每个项目。我们认为保持人工干预至关重要——有时即使测试本身通过，执行过程中仍会发现问题。必须由人工在最高层级审查测试输出，并持续自问“这结果真的正确吗？”

发布检查清单处于持续演进中。每当发现新问题或潜在隐患，就会新增检查项以确保后续版本杜绝这些问题。实践证明，该清单是确保发布流程无遗漏的不可或缺工具。

11. 静态分析

静态分析指在编译时对源代码进行正确性检查。其涵盖编译器警告信息及更深入的分析引擎，例如Clang静态分析器。SQLite在Linux/Mac系统使用GCC/Clang编译时启用-Wall和-Wextra参数，在Windows系统使用MSVC编译时，均能实现无警告编译。Clang静态分析工具“scan-build”同样未生成有效警告(尽管近期Clang版本似乎会产生大量误报)。但其他静态分析工具仍可能触发警告。建议用户不必过度关注这些警告，而应相信前述SQLite的严格测试流程。

静态分析对发现SQLite漏洞帮助甚微。虽然静态分析曾发现过少量漏洞，但实属例外。为消除编译警告而引入的漏洞数量，远超静态分析发现的漏洞总量。

12. 总结

SQLite作为开源软件，常被误认为不如商业软件经过充分测试，可靠性存疑。但这种印象是错误的。SQLite在实际应用中展现出极高的可靠性与极低的缺陷率，尤其考虑到其快速演进的特性。SQLite的质量部分源于严谨的代码设计与实现，但广泛的测试在维持和提升SQLite质量方面同样发挥着关键作用。本文档总结了SQLite每次发布都经历的测试流程，旨在让用户确信SQLite适用于关键任务型应用场景。

本文文字及图片出自 How SQLite Is Tested

你也许感兴趣的：

• 每秒10万次事务处理，覆盖十亿行数据：SQLite的惊人效能
• 如果我们将Postgres当作SQLite使用会怎样？
• 滥用 SQLite 处理并发性
• 【外评】为什么 SQLite（在生产中）的声誉如此糟糕？
• WordPress正在测试对SQLite的支持
• 发布至今18年，为什么SQLite一定要用C语言来开发？
• 为什么 SQLite 不使用 Git 进行版本管理？
• SQLite 中的各种限制
• 最新的SQLite 3.8.7比3.7.17性能提升50%
• Postgres 17 与 18 版本性能对比