SQLite如何测试

原文 http://www.sqlite.org/testing.html

目录

1. 介绍

1.1. 执行总结

2. 测试套件

3.异常测试

3.1 内存溢出测试

3.2 I/O错误测试

3.3 crash测试

3.4 复合破坏测试

4. 模糊测试(盲测？)

4.1 SQL模糊

4.1.1 使用The American Fuzzy Lop Fuzzer模糊

4.2 残缺数据库文件

4.3 边界值测试

5. 回归测试

6. 资源泄露自动检测

7. 测试覆盖率

7.1. 语句(statement)与分支覆盖

7.2. 保护(defensive)代码的覆盖测试

7.3. 强制覆盖边界值和布尔数组测试

7.4. 分支覆盖与MC/DC

7.5.度量分支覆盖

7.6.突变测试

7.7.全覆盖测试的经验

8. 动态分析

8.1. 断言

8.2. valgrind  // 是一款用于内存调试、内存泄漏检测以及性能分析的软件开发工具

8.3.Memsys2

8.4. 互斥断言

8.5.每日测试

8.6. 未定义的行为检查

9. 禁掉优化的测试

10. 检查表

11. 静态分析

12. 总结

1. 介绍

SQLite的稳定性和健壮性在某种程度上通过全面和仔细的测试来达成的。

SQLite 3.12.0版本大约由116.3k(116300)行 C代码构成。对比来看，这个项目有787倍数量的测试代码与脚本，91577.3k(91577300)行。

1.1. 执行总结

三个独立开发的测试套件

100%分支覆盖

数百万测试用例

内存溢出测试

I/O错误测试

宕机与掉电测试

模糊测试

边界值测试

禁用优化后测试

回归测试

残缺数据库测试

断言的扩展和运行期检查

Valgrind分析

未定义行为金叉

检查表

2. 测试套件

有三个独立的测试套件用来测试SQLite的核心库。每一个测试套件都被单独的设计、维护和管理。

1. TCL tests是最老的用于SQLite的测试集。他们被包含在与SQLite 核心相同的公共域源码树中。TCL tests主要用于开发阶段。TCL tests用TCL脚本语言编写。TCL test套件自身含有用于创建TCL接口的24.7k 行C代码。共1038个文件，12.8MB大小，37706个不同的测试案例，其中大部分测试用例是参数化的，可以用不同的参数多次执行，以使得一个全量测试能运行百万个测试用例。

2. TH3测试套件是一个专有测试，用c编写，针对SQLite core提供100%分支覆盖测试（100%MC/DC测试覆盖）。因为TH3测试套件设计用在嵌入式和特殊的平台上，所以不能容易的支持TCL和工作站的服务。TH3测试仅仅用于发布的SQLite接口。TH3由55.6MB文件，758.5K行C代码组成，实现了40100不同的测试用例。TH3测试是大量参数话的，所以一次全量的测试大概运行1.5kk个不同的测试实例。TH3测试套件的一个子集提供100%分支覆盖。A soak test（浸泡测试） prior to release does hundreds of millions of tests.TH3更多信息可以参见这里。

3. SQL逻辑测试，或者简称为SLT测试，该测试套件用于运行大量的SQL语句在不同的数据库引擎与SQLite之间对比，并验证他们能得到想用的结果。SLT目前对比的数据库包括PostgreSQL、MySQL，SQL Server和oracle 10g。SLT运行7.2kk个查询，含有1.12GB测试数据。

除这个三个主要的测试套件之外，还有几个小程序用来实现特殊的测试。

4. speedtest1.c用来测试在典型工作负载的情况下的SQLite的消耗的性能。

5. mptester.c用来测试多线程并发情况下读写一个数据库的情况。

6. threadtest3.c用来压测多线程同时使用SQLite的情况。

7. fuzzershell.c用来运行一些模糊测试。

在发布SQLite之前，以上所有的测试必须在多平台、多种编译配置的情况下运行成功。

开发者在代码提交到代码库之前，需要运行一个TCL tests的测试子集（被称作veryquick测试），大约有135.5k测试用例。veryquick tests包括大部分测试，除了异常、模糊、和soak test(浸泡测试)。veryquick tests能抓到充分的错误，而且只要几分钟而不是几小时。

3. 异常测试

异常测试被设计用来验证当SQLite遇到一些错误时能否有合适的处理行为。在一个功能齐全的电脑上，并且保证输入正确的情况下构建一个SQL数据库引擎是相对容易的。构建一个能对非法输入稳健的响应，并能在系统损坏时继续工作的系统是难很多的。异常测试被用来验证下面这些行为。

3.1 内存溢出测试

SQLite，和所有的SQL数据库引擎一样，大范围的使用malloc。在服务器和工作站上，malloc从不失败，这样正确处理OOM错误就不是那么的重要了。但是在嵌入式设备上，自从SQLite被频繁的用于嵌入式设备上，OOM错误是一个令人恐惧的平常错误，那么SQLite能优雅的处理OOM错误将显得尤为重要。

OOM测试通过模拟OOM错误达成。SQLite允许一个应用程序通过sqlite3配置接口来替换malloc的实现。TCL和TH3测试套件都能插入一个修改版本的malloc工具，使得在大量分配动作后失败。这种malloc能被置成只失败一次后继续工作或者失败后继续失败。OOM测试在循环中执行。在循环的第一轮迭代里…未完

3.2 I/O错误测试

I/O错误测试是寻找验证SQLite能为健壮的处理I/O操作失败。I/O错误可能源自磁盘空间满了、损坏的磁盘硬件、使用网络文件系统时网络断开、SQL操作过程中系统配置或者权限发生了变化或者其他硬件和操作系统故障。不论什么原因引起，SQLite能正确地处理这些I/O错误是非常重要的。

I/O错误测试和OOM测试在概念上很相似。通过模拟I/O错误来检查验证SQLite对这些模拟的I/O错误能否正确处理。在TCL和TH3测试套件中，通过在一系列的I/O操作后插入一个专门的用于模拟I/O错误的虚拟的文件系统对象。和OOM测试一样，模拟I/O错误可以设置单次失败，或多次失败。测试运行在循环中，逐渐增加失败的点，直至测试用例没有错误的跑结束。这循环会被执行两次，一次是仅仅单次模拟I/O错误，另一次是一直模拟I/O错误。

在I/O错误测视里，当I/O错误模拟失败机制被禁用后，数据库将被使用PRAGMA integrity check测试，以确保I/O错误没有引入数据腐败(玷污？损坏，脏数据?)

3.3 宕机测试

未完