Mozi: Discovering DBMS Bugs via Configuration-Based Equivalent Transformation

ABSTRACT

测试数据库管理系统（DBMS）是一项复杂的任务。传统方法，如变异测试，需要深入理解SQL规范以生成具有等效语义的多样化输入。SQL规范的模糊性和复杂性使得准确建模查询语义变得困难，从而在测试DBMS的正确性和性能时遇到挑战。为了解决这一问题，我们提出了Mozi，一个通过基于配置的等效转换来发现DBMS错误的框架。Mozi的核心思想是比较同一DBMS在不同配置下的结果，而不是比较语义上等效的查询。该框架包括分析查询计划，更改配置以将DBMS转换为等效状态，以及重新执行查询，使用各种测试神谕来比较结果。例如，查询结果的差异表明正确性错误，而在优化后的DBMS上观察到更快的执行时间则表明性能错误。

我们通过在四个广泛使用的DBMS上测试Mozi来证明其有效性，即MySQL、MariaDB、Clickhouse和PostgreSQL。在持续测试中，Mozi共发现了101个以前未知的错误，包括四个DBMS中的49个正确性错误和52个性能错误。其中，90个错误已被确认，57个错误已被修复。此外，Mozi还可以扩展到其他DBMS模糊测试工具，以测试不同类型的错误。有了Mozi，测试DBMS变得更简单、更高效，有可能节省本来需要花费在精确建模SQL规范测试目的上的时间和努力。

INTRODUCTION

Background：

  1. DBMS的重要性：数据库管理系统（DBMS）是从简单的网页应用到复杂的大规模企业系统各种应用的基础。确保DBMS的正确性、可靠性和性能至关重要。
  2. 变异测试的使用：变异测试是测试DBMS的一种流行方法。这种方法涉及建立变异关系，这些关系是软件系统输入和输出之间的数学关系。即使输入发生变化或转换，这些关系也必须保持一致。
  3. 变异关系的例子：为DBMS建立变异关系的一种常见做法是生成具有等效语义的不同SQL查询并比较它们的输出。例如，查询“SELECT 1+1”和“SELECT 2”在语法上不同，但在语义上等效，因为它们都返回相同的结果。

limitations：

现有的metamorphic：

  1. 对SQL规范的精确理解要求：确定变异关系需要精确理解SQL规范。然而，SQL规范本身的模糊性和复杂性使得准确建模查询语义变得困难。
  2. 高度定制化需求：准确建模查询语义并建立变异关系通常需要针对正在测试的特定DBMS进行高度定制。
  3. SQL标准和DBMS扩展的复杂性：ANSI SQL标准的复杂性以及各个DBMS的特定扩展增加了建模SQL语义的难度。
  4. 处理NULL值的不一致性：SQL查询中NULL值的处理方式可能微妙且在不同的DBMS中有所不同。在某些系统中，NULL值可能被视为等同于空字符串或零，而在其他系统中，则被视为一个既不大于也不小于任何其他值的独特值。模拟这些在SQL语义上的差异是一项复杂的任务，需要详细了解每个DBMS的特定特性和行为。

Key insight：

使用配置基等效转换：Instead of focusing on query equivalence, Mozi emphasizes generating equivalent DBMSs with different configurations. Mozi允许绕过对全面输入规范建模的需求，使其成为一种更高效、更可扩展的DBMS测试解决方案。

  1. 三步发现错误流程：
    • 第一步：执行查询并记录目标DBMS上的执行计划。
    • 第二步：基于执行计划动态修改DBMS中的特定配置，例如优化策略，以创建与查询等效的不同实例。
    • 第三步：重新向re-issue的DBMS发出相同的查询，并比较结果。
  2. 基于结果比较设计测试Oracle：设计的测试神谕基于结果的比较，有助于识别各种类型的错误。结果中的差异表明存在正确性错误（也称为逻辑错误）。例如，如果禁用某个联接优化导致不同的结果，这表明优化实施中存在错误。
  3. 性能错误的揭示：如果某些优化被禁用的DBMS执行查询比原始实现更快，则揭示了性能错误，表明这些优化可能适得其反。

通过专注于等效转换，Mozi减轻了传统方法所需的模拟微妙SQL语义的复杂性。

Challenges:

  • 识别和修改相关配置的难题：在不影响查询等效性的前提下，识别相关配置并对其进行修改是实现等效转换的主要挑战。随意更改与查询执行过程密切相关的配置可能会导致查询版本不等效；而修改与查询执行过程无关的其他配置可能没有任何效果。
  • 例子说明：例如，如果一个DBMS有一个限制查询最大执行时间的配置，如果这个时间限制被任意缩短，某些查询可能不会产生任何结果。然而，更改其他配置，如与查询无关表的访问控制，可能对查询执行没有任何影响。

Solutions：

  • 利用计划引导的转换：为了解决这一挑战，Mozi利用了计划引导的转换。大多数现代DBMS都能为给定的SQL查询生成执行计划，该计划详细说明DBMS执行查询的步骤。通过分析执行计划，可以确定DBMS用于执行查询的特定配置（例如，优化策略）。
  • 配置参数的有目的修改：这些信息可以用来更改某些配置参数，创建一个修改版的DBMS，该DBMS使用不同的逻辑执行查询，但结果相同。例如，如果执行计划显示正在使用特定的优化来加速查询执行，Mozi可以在修改版的DBMS中禁用这种优化。响应时间的减少表明DBMS内可能存在性能问题。
  • 利用DBMS的自省能力：通过利用DBMS的自省能力，Mozi可以更容易地操纵和配置DBMS环境，以测试不同的场景和配置。

之前好像有一篇是通过在查询的时候开启优化选项（我记得是SQLRight Detecting Logic Bugs of Join Optimizations in DBMS），也有一篇是通过更改查询计划来检测逻辑错误。

Evaluation:

  • 广泛的实验：我们对四种广泛使用的数据库管理系统（DBMS），即MySQL、MariaDB、Clickhouse和PostgreSQL，进行了广泛的实验，以评估Mozi在发现以前未知的错误方面的有效性。
  • 持续测试的结果：在为期三周的连续测试中，Mozi发现了共计101个以前未知的错误，包括49个正确性错误和52个性能错误。其中90个错误已得到确认，57个错误已被修复。
  • 与其他技术的比较：在24小时的实验中，与其他一些先进的测试技术相比，Mozi覆盖了更多的分支，并检测到更多的错误，例如比PQS多检测25个错误，比NoREC多22个，比TLP1多21个，比Apollo多24个，比Amoeba多26个错误。

Contributions:

  • 提出Mozi框架：我们提出了Mozi，这是一个通过配置基等效转换来识别DBMS错误的框架，它补充了现有的如变异测试等方法。Mozi旨在生成应在执行相同SQL查询时产生等效结果的不同DBMS实例。通过基于结果比较设计测试神谕，我们能够检测不同类型的错误。
  • 三步测试过程：我们提出了使用Mozi测试DBMS的三步过程：首先，分析生成的SQL查询的执行计划；其次，操纵DBMS配置以创建一个等效实例；最后，向新的DBMS发出相同的SQL查询并比较结果。我们提供了一种有效创建配置不同的DBMS的解决方案，利用分析的查询计划引导转换。
  • 实施并评估：我们在Mozi中实施了我们的方法，并在四个流行的DBMS中对其进行评估，与其他先进的技术相比。Mozi报告了共计101个错误，其中90个被确认为以前未知的错误。它还发现了比其他技术更多的分支和错误。

BACKGROUND AND MOTIVATION

DBMS and Configuration.

  1. DBMS的定义：数据库管理系统（DBMS）是用于管理数据库中数据的存储和检索的软件。
  2. DBMS配置：DBMS配置涉及可以调整数据库管理系统行为的设置和参数。这些配置选项可以影响数据库系统的性能、可靠性和安全性。
  3. 配置的常见类别：表1展示了DBMS配置的常见类别，包括：
    • 缓冲区缓存配置：确定DBMS用于存储经常访问数据的缓冲区缓存的大小和行为。
    • 并发配置：控制用于管理对共享数据访问的并发程度和锁定。
    • 内存分配配置：指定DBMS分配和使用内存的方式。
    • 磁盘使用配置：控制DBMS分配和使用磁盘空间的方式。
    • 优化配置：涉及优化DBMS性能的过程，以确保快速有效的数据访问和处理。它决定了查询如何被优化和执行，包括选择查询优化器、索引策略和并行设置的选择。
    • 安全配置：处理数据库系统的访问控制和认证。

image-20240524154647814

DBMS Metamorphic Testing.

  1. 变异测试的定义：变异测试是一种常用的方法，通过构建测试神谕来检测DBMS的正确性错误。变异关系是软件系统输入变化和输出变化之间的数学关系。当输入变化时，如果相应的输出变化不再符合这种关系，表明存在错误。
  2. 构建查询变体：常见的方法之一是类似EMI的方法，用于构建不同但等价的查询变体。具体来说，给定一个查询𝑄和其语义等价的查询集合𝐶，可以使用这个集合来对任何DBMS 𝐷进行比较：如果对于集合中的某个𝑄′，𝐷(𝑄) ≠ 𝐷(𝑄′)，则表明D中存在错误。
  3. 实际应用例子：例如，SQLancer的NoREC方法通过构建基于现有SQL查询的等价非优化SQL查询来检测DBMS优化器的逻辑错误。如果非优化SQL查询与现有SQL查询得到的结果不一致，则检测到优化器的逻辑错误。
  4. 挑战：为DBMS找到变异关系非常困难。发现有效的变异关系需要深入了解SQL规范，但通常一个关系只能关注SQL的一个特性。例如，TLP方法只能用于测试使用WHERE、HAVING、GROUP BY、聚合函数和DISTINCT特性的查询。
  5. 定制性和成本：变异关系可能需要针对特定的DBMS高度定制，这意味着将其适应其他DBMS可能会非常昂贵。

Basic Idea of Mozi.

  1. Mozi的核心思想：Mozi的关键理念是通过改变配置将DBMS转变为一个等效的系统，以此作为参照来验证执行结果。这种方法不是通过寻找数学关系来构建不同的查询，而是选择通过改变配置来转换DBMS。
  2. 构建测试神谕：基于转换过程和查询执行结果，我们可以构建测试神谕来发现错误。例如，当两个等效的DBMS在执行相同查询时得到不同结果时，可能存在实现上的正确性错误。
  3. 配置变更的影响：这种方法基于理解配置变更可能对系统行为产生重大影响的观点，这种变更常常导致意外后果。例如，启用或禁用某些查询优化可能会显著影响系统性能，而更改缓冲区大小或缓存大小可能会影响系统的内存使用。
  4. 不同配置的结果：不同的配置可能导致DBMS生成不同的执行计划，并覆盖完全不同的代码区域。如果修改的配置能为查询创建一个等效的DBMS，那么执行的计划应该具有相同的语义，但操作不同。

下面这个例子展示了Mozi如何在MySQL中检测到一个正确性错误。下面是这个例子的详细解释：

  1. 问题触发的SQL查询：文中提到的SQL查询在MySQL的默认配置下执行。这个查询使用了INDEX SCAN（索引扫描）方法来扫描表t1，并正确产生了记录。
  2. 配置的修改：为了测试和发现潜在的错误，Mozi使用了两条SET SQL语句来禁用优化器的索引扫描选项，从而创建了一个等效但配置被修改的DBMS实例。
  3. 重新执行查询并检测错误：Mozi在修改后的MySQL实例中重新执行了相同的SQL查询。这次查询没有正确执行，MySQL返回了一些错误消息。如图所示，MySQL选择了FULL SCAN（全表扫描）方法来扫描表t1，这导致了正确性错误的发生。
  4. 错误的检测难度：使用DBMS变异测试来检测这种正确性错误是具有挑战性的。变异测试通常通过构建等价的SQL查询并检查结果是否一致来检测异常。然而，为了触发这个错误，需要修改DBMS的配置，以改变相同SQL查询的执行方式。因此，这种错误对其他DBMS测试方法来说在同一时间框架内难以检测到。
image-20240524155627688

DBMS EQUIVALENT TRANSFORMATION

image-20240524155823402

首先，Mozi分析生成查询的执行计划。它将生成的查询发送到具有默认配置的目标DBMS中。分析计划中使用的相关配置，如优化或内存选项。其次，Mozi通过修改目标DBMS的配置来构造其等效物以处理查询。然后Mozi重新发送SQL查询到被转换的等效DBMS，并记录新的结果。最后，通过比较旧结果和新结果，Mozi能够检测性能、正确性错误或其他类型的错误。例如，两个DBMS之间的不同结果表明存在正确性错误，而在禁用优化的DBMS上更快的执行表明存在性能错误。

3.1 Definitions

image-20240524161512255

image-20240524161521791

3.2 Plan Analysis

这段描述了Mozi在执行计划分析阶段的工作流程：

  1. 计划分析基础：Mozi基于查询执行计划来变换配置，因为执行计划不仅反映了查询的执行情况，还包括了影响执行的配置选项。
  2. 示例分析：例如，在一个例子中，我们打算在PostgreSQL中执行一个连接两个表的查询。执行计划显示PostgreSQL选择使用哈希连接（hash join）来连接“orders”和“users”表，并通过位图索引扫描（bitmap index scan）来过滤总价超过100的订单。计划还表明“users”表将进行顺序扫描（sequential scan）。
  3. 配置的修改：使用这个计划，我们可以通过禁用enable_hashjoin、enable_bitmapscan和enable_seqscan来改变执行过程。此外，计划还揭示了某些配置选项被用来影响它，例如哈希连接步骤的选择由配置选项“work_mem”决定，该选项决定了可用于哈希连接、排序和聚合的内存大小。在这个例子中，规划者估计了输入关系的估计大小和选择性，认为可用内存足以有效执行哈希连接。
  4. 配置转换的挑战：通过调整这些配置，我们可以将DBMS转换成一个等效的，但执行过程不同的系统。然而，保持查询等价性的转换是具有挑战性的。

image-20240524161855576

3.3 Plan-Guided Equivalent Transformation

这部分描述了Mozi使用计划引导的等效转换方法来确保在更改可能影响查询执行过程的DBMS配置时，保持查询在不同DBMS之间的等价性。以下是该过程的关键点：

  1. 计划分析：首先，分析并提取已执行查询的执行计划（第1行）。这一步骤是基础，用于理解查询如何在DBMS中执行。
  2. 配置集的识别：根据执行计划和预定义的测试神谕，确定与两者相关的候选配置集（第2-4行）。特别是，与测试神谕相关的配置将在3.4节进一步讨论。
  3. 保证等价性的配置变更：为了确保等价性，仅更改与计划相关但对查询正确性不关键的配置，例如内存分配和磁盘使用。不会考虑与底层功能相关的一些配置，如用于限制数据库中表的最大数量的“max_relations”。
  4. 配置参数的转换决策：接下来，决定是否转换候选集中的配置参数。对于候选集中的每个配置，使用flipCoin函数随机决定是否更改它（第6行）。
  5. 设置目标值：对于每个通过的配置，首先计算一个与当前值不同的有效值（第7-10行）。如果为真，那么将目标值设置到配置中，并将其添加到结果集中。确保目标值不违反任何约束或假设，并保证DBMS仍然返回准确的结果是至关重要的。例如，分配的内存量不应超过可用内存，时间限制应足够长以保证成功检索结果。

3.4 Various Test Oracles Construction

基于等效变换，我们可以在各种测试条件下检测dbms中的bug。例如，我们可以利用等效的转换来进行正确性测试、性能测试、内存安全测试、授权测试和遵从性测试。在本节的以下内容中，我们将讨论如何构造检测正确性和性能问题的测试谕。此外，我们还将探讨如何在第6节中的其他测试神谕中应用等效转换。

Test Oracles for Correctness Bugs.

这部分讨论了使用测试神谕来检测正确性错误，这些错误也被称为逻辑错误。

  1. 检测方法：为了检测正确性错误，可以通过直接比较来自等效DBMS的结果，检查结果是否有差异。
  2. 相关配置的确定问题：确定与正确性错误相关的配置是一个重要问题。具体来说，需要修改DBMS配置，以保证在两个不同的DBMS上执行相同的查询时，行为可能不同，但产生一致的结果。
  3. 配置的利用：
    • 优化配置：可以用来直接改变查询计划，影响查询执行。
    • 间接影响的配置：也可以考虑一些间接影响查询的配置，如缓冲区缓存配置、内存分配配置和磁盘使用配置。例如，影响内存缓冲区分配的配置可能不会直接影响查询处理，但可能导致内存泄漏或损坏，最终导致查询结果不正确或系统崩溃。
  4. 结果比较和记录：在转换后的DBMS上重新执行查询后，将结果与原始DBMS执行的结果进行比较。如果两个系统返回的值对每个查询都相同，则认为结果匹配。然而，如果返回值之间存在任何差异，Mozi将标记结果为不匹配，并记录差异。

Test Oracles for Performance Bugs.

这部分讨论了使用测试神谕来检测性能错误的方法。

  1. 性能错误的检测方法：通过等效转换创建一个性能较低的原始DBMS版本。如果这个弱化的DBMS显著比原始DBMS性能更好，就表明可能存在性能错误。
  2. 优化操作和性能错误：在基于成本的优化器中，通常期望禁用优化操作不会提高数据库引擎性能。如果禁用优化操作反而提升了性能，这表明存在性能错误，可能导致查询处理变慢和系统吞吐量降低。这种问题称为由反向优化引起的性能异常。
  3. 检测性能错误的步骤：
    • 配置转换：通过禁用查询优化或限制资源使用来弱化DBMS。
    • 执行查询：在转换后的DBMS上执行SQL查询，获取计划和执行时间。
    • 比较执行时间：如果新执行时间低于原始执行时间且结果相同，则检测到潜在的性能异常。
  4. 实验例子：在实验中，MySQL使用hash_join优化操作执行一个SQL查询的时间是10.42秒。当禁用hash_join优化操作时，新执行时间仅为1.54秒，减少了85%的原始执行时间。优化导致的性能下降表明确实存在性能问题，这一问题也得到了MySQL开发人员的确认。

IMPLEMENTATION

image-20240524163015686

Transformation Layer. 这部分描述了Mozi的转换层工作流程：

  1. 执行计划分析：通过执行SQL命令（如“EXPLAIN”）获取执行计划并提取涉及的SQL操作。
  2. 配置转换：使用SQL命令动态设置配置，例如使用“SET ENABLE_SEQSCAN TO OFF”禁用顺序扫描。
  3. 结果检查：基于测试神谕比较等效DBMS的查询执行结果，包括正确性测试和性能测试等。

此外，特定配置首先按类别或与神谕相关的组件分类，然后手动确定，例如与优化器相关的配置通常与性能问题相关。目前，已分别为MySQL和PostgreSQL识别出26和21个与性能相关的配置。

Adaptation Layer. 这部分描述了Mozi的适配层工作流程：

  1. SQL规范分析器：分析SQL规范文件，获取支持的SQL子句和配置列表。
  2. 查询生成器：利用分析结果生成各种复杂度的查询，从简单查询到涉及连接和子查询的复杂查询。具体过程包括从DBMS文法文件中提取BNF范式的语法规则和支持的子句，进行SQL语句建模，并生成涵盖广泛配置的查询。（复杂查询）
  3. 避免非确定性行为：在生成查询过程中，避免使用随机函数或变化的环境变量（如时间），以避免混淆测试神谕和产生误报。

EVALUATION

在本节中，我们评估了Mozi构建的测试神谕在检测错误方面的有效性。我们的评估旨在回答以下问题：

  • RQ1：Mozi能否发现以前未知的正确性和性能错误？
  • RQ2：Mozi与其他DBMS测试技术相比表现如何？
  • RQ3：计划引导的转换在Mozi检测错误方面的效果如何？
  • RQ4：Mozi能否帮助其他模糊测试工具发现错误？

5.1 Evaluation Setup

我们在四种广泛使用的开源dbms上评估了墨子，即MySQL（8.0.32）、MariaDB（10.8）、点击库（22.11.4.3）和PostgreSQL（15.2）。

5.2 DBMS Vulnerability Detection

Bug Statistics. 我们应用Mozi在三周内测试了性能和正确性错误。被评估的四个DBMS广泛使用且经过充分测试。尽管如此，Mozi表现良好，最终发现了101个以前未知的错误。我们还使用了SQLancer（及其测试神谕PQS、TLP和NoREC）、Apollo（检测performance bug）和Amoeba（检测performance bug）来测试这些DBMS，但它们只能发现其中的一部分错误（详见第5.3节）。

表2显示了错误的统计数据。Mozi报告了总计49个正确性错误和52个性能错误。我们将所有错误报告给了相应的DBMS开发人员。其中，46个正确性错误和44个性能错误已被确认是以前未知的错误。在撰写本文时，已有57个错误被修复，并且我们收到了开发人员的感谢。此外，由于DBMS的复杂性，11个错误仍在开发人员的验证中。

image-20240524163453262

根据DBMS开发人员的分析，Mozi检测到的错误分布在测试DBMS的35个以上的组件中。正确性错误难以检测，因为它们不会引起系统崩溃等明显迹象。性能错误同样重要，因为它们可能影响DBMS的整体响应时间。更重要的是，在与开发人员的沟通中，他们表示对通过构建等效DBMS来发现漏洞很感兴趣。他们发现了许多在开发过程中从未关注过的问题。在撰写本文时，开发人员总共修复了57个错误。

此外，在被检测到之前，许多bug在dbms中已经存在很多年了。图5显示了已确认的错误的导入错误代码的时间分布。如果没有Mozi，这些虫子可能会停留更多的时间，并导致潜在的危害。本文提出了一个只有Mozi所发现的PostgreSQL中的性能缺陷。

image-20240524163806609

5.3 Comparison with Other Techniques

image-20240524164225517 image-20240524164327370

Mozi在错误检测和分支覆盖方面改进的主要原因：

  1. 独立于特定SQL特性的测试神谕：Mozi的改进主要在于其测试神谕独立于特定SQL特性。这使得Mozi能够测试DBMS内更广泛的功能。
    • 其他工具的局限性：PQS、NoREC、TLP和Amoeba基于特定特性创建测试用例，限制了它们支持的SQL语法。例如，NoREC通过构建基于优化器规则的等效优化和非优化查询来检测DBMS优化器的逻辑错误，但这种方法只能覆盖符合优化器规则的SQL语法。
    • Mozi的灵活性：Mozi生成的SQL查询不受SQL语法限制，因为它依赖于DBMS本身来评估查询结果。因此，Mozi可以支持更多的SQL语法并覆盖更多的分支，从而检测到更多的正确性错误。
  2. 性能错误检测的优势：Apollo通过比较同一DBMS两个版本的查询性能来生成查询，有效检测性能回归错误，但受到差分测试的限制。
    • Apollo的局限性：Apollo依赖于版本之间的差异，无法检测到存在于两个版本中的错误，且版本差异较小时生成的查询数量有限。
    • Mozi的优势：Mozi基于已执行查询转换DBMS，通过更改配置扩展差异，触发更多DBMS行为。在只有有限版本的DBMS可用的情况下，Mozi依然可以有效地应用。

5.4 Importance of Plan-Guided Algorithm

image-20240524164734232

这部分描述了Mozi在禁用和启用计划引导转换时的性能对比，以评估计划引导转换的重要性：

  1. 实验设置：
    • 实现了两个版本的Mozi：一个禁用了计划引导组件的版本（Mozi !𝜌），该版本随机更改配置而不依赖SQL查询的执行计划。
    • Mozi !𝜌包括Mozi !𝜌𝑐𝑜𝑟（用于检测正确性错误）和Mozi !𝜌𝑝𝑒𝑟（用于检测性能错误）。
    • 将Mozi 𝑐𝑜𝑟和Mozi 𝑝𝑒𝑟与其禁用计划引导的版本进行对比测试24小时，记录检测到的错误数量和覆盖的分支数量。
  2. 结果总结：
    • 正确性错误：
      • Mozi 𝑐𝑜𝑟在MySQL、MariaDB、Clickhouse和PostgreSQL上比Mozi !𝜌𝑐𝑜𝑟多触发4、7、5和2个正确性错误，覆盖的分支分别多1865、5110、6559和8689个。
    • 性能错误：
      • Mozi 𝑝𝑒𝑟在MySQL、MariaDB、Clickhouse和PostgreSQL上比Mozi !𝜌𝑝𝑒𝑟多发现7、8、2和1个性能错误，覆盖的分支分别多4011、6403、6667和6057个。
  3. 结论：
    • 计划引导在Mozi的性能中起重要作用，帮助Mozi覆盖更多的目标DBMS状态和发现更多错误。
    • 计划引导通过帮助Mozi找到与SQL查询执行过程相关的配置，使优化计划发生显著变化，触发许多新行为并覆盖新分支。
    • 禁用计划引导后，Mozi !𝜌通过任意修改配置来转换DBMS，但这种任意更改可能不会影响特定查询的覆盖逻辑。因此，Mozi比Mozi !𝜌覆盖更多分支，计划引导在有效覆盖分支和成功检测错误方面起到了关键作用，充分回答了RQ3。
image-20240524165233004

5.5 Scalability of Mozi to Other Fuzzers

image-20240524165400705

这部分描述了将Mozi与其他工具结合以检测性能和正确性错误的实验设置和结果：

  1. 实验设置：
    • Mozi被适配到两个广泛使用的针对崩溃错误的模糊测试工具SQLsmith和Sqirrel中，以检测性能和正确性错误。
    • 实现了SQLsmith+Mozi 𝑐𝑜𝑟 和Sqirrel+Mozi 𝑐𝑜𝑟 来检测正确性错误，以及SQLsmith+Mozi 𝑝𝑒𝑟 和Sqirrel+Mozi 𝑝𝑒𝑟 来检测性能错误。
    • 只用了少量C++代码（SQLsmith分别为294和378行，Sqirrel分别为287和391行）来适配两个测试神谕。
    • Mozi的测试神谕通过基于配置的等效转换方法构建，与SQL生成独立，因此可以轻松适应其他SQL生成器。
    • 每个生成的查询首先使用目标DBMS的原始配置执行，然后根据计划指导转换配置并重新运行查询以检测错误。之后恢复原始配置，并生成下一个查询。
  2. 结果总结：
    • 错误检测：Mozi有助于SQLsmith和Sqirrel检测正确性和性能错误。
      • SQLsmith+Mozi 𝑐𝑜𝑟 和Sqirrel+Mozi 𝑐𝑜𝑟 除了崩溃错误外，分别发现了13和7个正确性错误。
      • SQLsmith+Mozi 𝑝𝑒𝑟 和Sqirrel+Mozi 𝑝𝑒𝑟 除了崩溃错误外，分别检测到14和12个性能错误。
    • 崩溃错误检测：Mozi不会显著降低SQLsmith和Sqirrel在检测崩溃错误方面的有效性。
      • SQLsmith+Mozi 𝑐𝑜𝑟 和SQLsmith+Mozi 𝑝𝑒𝑟 仅比SQLsmith少检测到一个崩溃错误。
      • Sqirrel+Mozi 𝑐𝑜𝑟 检测到与Sqirrel相同的6个崩溃错误，Sqirrel+Mozi 𝑝𝑒𝑟 比Sqirrel多检测到一个崩溃错误。
  3. 结论：
    • Mozi可以帮助其他模糊测试工具检测到更多类型的错误，包括正确性错误和性能错误。
    • 通过基于配置的等效转换，Mozi使目标DBMS表现出潜在的不同行为，从而可以比较查询结果，检测到更多的正确性和性能错误。
    • 尽管由于多次执行每个SQL查询和额外的SQL语句，增强版本执行的查询较少，但修改DBMS配置和重新执行SQL查询可以触发新的行为，帮助识别新错误。

总结：Mozi能够帮助其他模糊测试工具发现更多种类的错误，充分回答了RQ4。