Graph Bugs
29:01 Share

在今天的节目中，我们的嘉宾是苏黎世联邦理工学院（ETH Zurich）的硕士生 Celine Wüst，她专注于安全可靠的系统，分享了她关于图数据库自动化软件测试的工作。Celine 展示了模糊测试——自动生成复杂查询的过程——如何帮助发现 Neo4j、FalconDB 和 Apache AGE 等图数据库管理系统中的隐藏错误。主要见解包括：状态感知查询生成如何检测缓冲区溢出和崩溃等关键问题；调试复杂数据库行为的挑战；以及安全导向的软件测试的重要性。我们还将了解哪家图数据库公司为在其软件中发现错误提供赠品，并获得 Celine 关于使用哪种图数据库的建议。-------------------------------想要收听无广告版本？试试我们的图课程？加入 Data Skeptic+，每月 5 美元或每年 50 美元 https://plus.dataskeptic.com</context> <raw_text>0 您正在收听 Data Skeptic：图与网络播客，该播客探讨了图数据结构如何影响科学、工业以及其他领域。欢迎收听 Data Skeptic：图与网络的另一期节目。今天我们将讨论另一个与图数据库相关的主题。这次是关于通过一种巧妙的测试技术来查找图数据库本身中的错误。Asaf，我觉得这似乎不是你的网络科学领域。

好吧，如果我要编写代码，我会编写没有错误的代码。所以我无法理解人们为什么这样做。奇怪的行为，工作保障。他们为什么这样做？这只是更多工作，对吧？可能吧。是的，我们今天要讨论的项目叫做 Dinkle，它是一个模糊测试器，我实际上对这个术语有点了解，但在这种情况下从未听说过。我想我没有深入研究这方面的文献，但模糊测试器是……

是一种会向某事物发送大量静态噪声以对其进行测试的工具。在这种情况下，它会向图数据库发送嘈杂且毫无意义的查询，并非为了对其进行性能测试，而是为了查找底层核心图数据库引擎中的错误。

有趣的话题，它与图相关，因为他们当然是在针对图数据库进行测试。我喜欢与 Celine 谈话的一点是，在最后，当你问她关于不同图数据库的问题时，听到一个在图数据库底层工作的人，了解其内部运作的人，他们的观点是什么，这很有趣。

对现有各种图数据库的看法。是的，在这种情况下，似乎并没有一个可以统治所有数据库的“至尊魔戒”，这取决于您的需求以及您想要优化的目标，您将对众多图数据库产品之一做出特定决定。是的，这是一个权衡。是的。因此，从软件自动化测试的角度来看，这里面的内容也很有趣，我很高兴我们有机会分享。让我们直接进入采访。♪

嗨，我是 Celine。我是一名来自 ETH 的硕士生，目前从事自动化软件测试工作。我的主要关注点是测试图数据库管理系统，这就是我今天来这里的原因。我学习的是计算机科学。我现在距离完成我的硕士学位还有几个月的时间，我的重点是安全可靠的系统和数据管理。

硕士通常会有项目或论文。你走哪条路？在 ATH，我们必须在最后提交一篇论文。我可能会继续从事自动化软件测试这个领域。你能告诉我们一些关于你的论文涉及的具体领域吗？现在，我写过一篇关于图数据库管理系统的学士论文。

例如测试图数据库管理系统，还有很多工作要做。因此，我可能会继续扩展它，即使只是帮助安全人员测试事物。是的。我想你指的是 Dynkle，对吗？没错。是的。对于还不熟悉它的听众，你能概述一下 Dynkle 是什么吗？Dynkle 最初是我的论文。

我 2023 年的学士论文。它是一个模糊测试器，因此它会自动为图数据库系统生成输入并对其进行测试。

我们主要关注的是真正地整合大量有状态信息，确保查询生成非常复杂。最终它取得了很好的成果。好吧，我明白了尝试自动化一些现有的数据库系统，特别是图数据库的想法。我很好奇你从哪里开始的。例如，想到的一件事是，在尝试攻击传统程序时，也许我想看看我是否可以使缓冲区溢出或类似的东西。

你能用什么工具或玩具来攻击图数据库？

如果你只是想生成随机查询，这就会很自然地出现。因此，如果你查看我们的一些错误报告，我们会遇到缓冲区溢出，遇到空值被取消引用，遇到不应达到的奇怪程序状态。我们几乎涵盖了所有这些基础，但前提是它确实是通过用户的输入（通过查询）可以访问的。

那么我说没有代码检查正确吗？你真的只是把系统当作黑盒对待吗？是的，通常你会进行这样的黑盒模糊测试。你可以扩展它，但这几乎只是一种加速测试的方法，确保你覆盖更多新的代码，但这对于达到发现黑盒所需的有效性并不是真正必要的。

我相信你提到过查询生成，特别是复杂查询，是工作的一部分。这是否像现在流行的 AI 生成一样？或者 AI 甚至可以做到这一点？也许这些必须非常精细地设计，才能知道模式或其他什么。这是如何运作的？

所以这实际上只是一个随机生成器。它基于 Cypher 的语法。因此，它必须非常深入地了解 Cypher，才能真正建立不同子句之间的联系，并以良好的方式跟踪状态。我们并没有真正使用 AI。它实际上只是我们用来最终生成查询的随机位串。

我可以看出 AI 可以在某些地方使用，但对于它来说完成这项任务似乎非常困难。你提到过这是状态感知的。你能详细说明一下吗？

在 Dynkle 中，我们跟踪两种不同类型的状态。我们有查询上下文和图模式。现在在查询上下文中，我们只有在查询中创建和引用的所有变量。因此，你可以想象，如果你创建一个变量 x，并将其值赋值为 0，则会将其存储在查询上下文中。我们在生成查询期间存储此信息。

然后，我们还有图模式，我们基本上将其简化为节点和边标签以及不同键值属性的大集合，然后我们在查询生成过程中再次引用这些属性，以确保查询中存在大量数据依赖关系，这直接使其更加复杂，并增加了真正触发图数据库管理系统中隐藏很深的错误的可能性。

这些隐藏很深的错误是否类似于遗漏单元测试的疏忽，而这正是修复它所需的一切？

我的意思是，我们提交的许多错误报告确实导致添加了更多测试，但它们几乎总是必须修复图数据库管理系统中的某些内容。因此，通常情况下，系统不同部分之间会在后台进行大量交互，而开发人员并没有预料到这一点，这导致了这些错误。

我们只有一个案例，他们实际上调整了 Cypher 的文档以不允许某些查询结构。与其修复它，我们不如将其禁止，是吗？没错，是的。

那么，当你遇到错误时，用户体验是什么样的？我会收到异常还是会得到错误的答案？因此，我们主要关注异常和崩溃错误。这意味着您要么会收到一条错误消息，说明出现问题，要么会收到一条非常令人困惑的错误消息，这似乎与您的查询毫无关系。

或者它直接导致系统崩溃。我们没有专注于查找错误答案，即我们所说的逻辑错误，因为这是一个完全不同的领域。但问题是，Dynkle 实际上只是一个查询生成器，你可以很容易地扩展它。因此，可以使用 Dynkle 进行逻辑错误模糊测试，但你必须扩展 Dynkle 的生成系统。

因此，Dynkle 在这方面是一个非常通用的工具，我知道你可以用它来测试许多不同的数据库选项。你能谈谈你使用 Dynkle 探索过的哪些数据库吗？在 Dynkle 本身的论文中，我们主要关注 Neo4j，我们还测试了 RedisGraph，它现在名为 FalkerDB。最后，我们还测试了 Apache AGE。

我们在 Neo4j 中发现了最多的错误，因为我们花了大量时间对其进行测试，因为它实际上是一个非常广泛使用的数据库。据我所知，它现在仍然是。是的，我们在那里发现了许多异常错误。但没有崩溃，因为它是用 Java 编写的，很难让它崩溃。其他数据库的情况有所不同，因为它们是用 C 和 C++ 编写的。我们在那里确实发现了一些崩溃错误。

当你发现错误时，我想你会报告它？你能谈谈这个过程吗？当我谈论在线隐私安全时，我从 Delete Me 订阅者的经验中谈起。令人大开眼界的是，观看我的季度隐私报告向我展示了有多少数据经纪商正在收集我们的信息。在我的第一份报告中，我发现了数百个包含我的个人详细信息的列表。从旧地址到家庭联系方式，应有尽有。

我是一个低收入的公众人物，但我不想让其余的东西公开。使 Delete.me 与众不同的是其全面的方法。他们不仅仅删除一次您的信息。他们会持续监控和删除信息，并领先于隐私威胁。随着新的数据收集方法出现，他们的团队会调整和改进其保护策略。他们不仅关注已知的数据经纪商。他们不断扫描新的数据泄露来源，并开发删除流程来解决这些问题。

这就像有一个全天候工作的专用隐私保护者。通过注册 Delete.me 来控制您的数据并保护您的私人生活。现在，我们的听众可以享受特别折扣，今天通过短信发送 DATA 到 64000 获取 Delete.me 计划 20% 的折扣。这是 DATA 到 64000。可能需要支付短信和数据费。当你发现错误时，我想你会报告它？你能谈谈这个过程吗？

我的意思是，对于大多数非关键安全错误，我们只需打开一张工单，在 GitHub 上打开一个问题，他们就会从那里修复它。但对于那些安全关键的错误，大多数开发人员都设置了安全策略，我们可以向某个地方发送加密电子邮件，其中包含错误的详细信息，他们会从那里处理。

你能分享一些关于这个过程的细节吗？如果你提交了不止一个错误，我想你会经常与他们联系。你认识对面的人吗？你已经开始与他们沟通或类似的事情了吗？是的，在某种程度上。我现在在 LinkedIn 上与一些开发人员建立了联系，但特别是 Neo4j 非常感谢，他们实际上还送了我一些商品。我现在有一件他们的 T 恤和一顶帽子，我……

冬天可以戴着它。太棒了。我认为他们总有一天也应该支付一些错误赏金。

是的，没有。我们没有得到任何。也许有一天。是否存在难以重现的错误？也许，你知道，你生成了一个查询，但你没有持续看到它。当你提交错误时，他们很难看到它。是的，有一些情况，这种不确定性确实是一个问题。因为主要当你提交错误报告时，你想尽可能地减少查询。

因为，我的意思是，我们生成的查询有数千个字符长，有数千个子句，而且很难理解。所以我们所做的是，我们试图找到一个可以重现此错误的最小测试用例。如果存在一些不确定性，这意味着我们经常不得不重新启动数据库，将其恢复到初始状态，重新运行查询几次以确保错误仍然会触发。

但最终，这只会花费更多时间来报告。但我从未报告过他们无法重现的错误，主要是因为我也在不同的 Docker 容器中测试了所有内容，以确保这不是因为我的本地设置或其他原因。

因此，你通过生成这些复杂的查询来发现这些错误，正如你所说，这些查询可能难以被人解析。这意味着我们正在发现软件中的极端情况，还是这些错误也可能在其他情况下，在更日常的查询下显现出来？是的，这是一个很好的问题，在自动化软件测试的完全不同领域的其他项目中也已经探讨过这个问题。

我们生成的一些产生错误的查询看起来确实很荒谬，但最终，它们可能会作为更大查询的一部分出现

实际上用于生产，以及代码生成器。它们有时也会产生看起来不太有意义的结构，但因为对于这个查询生成器来说很容易，我在这里谈论的是查询生成器，你使用非常简单的代码生成复杂的查询。例如，OEM 是这种情况经常出现的地方。

它们也可能包含这些结构。我记得一个错误，还有一个开发人员对此做出了反应，说他遇到了同样的问题。但我们发现的大多数错误都在相当新的版本中

就像最近引入的错误一样，这意味着很多人可能还没有迁移到最新版本，因此他们还没有机会真正遇到这个错误。你能分享一些细节吗？我知道你已经谈到了各种系统，但也许你发现的错误的数量级是多少？我们说的是个位数还是数百个错误？有多少问题存在？

在论文中，我们提到了三个数据库中的 60 个错误。使用不同的策略，后台仍在发现更多错误。所以我们现在已经达到三位数了，我们到目前为止已经测试了四个数据库。

这是一个相当可观的数字，尤其考虑到之前在模糊测试图数据库管理系统方面所做的工作。因为基本上，我们可以完全覆盖更简单的方案。因此，他们发现的所有错误，我们也都可以用 Dynkle 找到。并发是你必须担心的事情吗？主要是在不确定的测试用例中。

否则，这不是一个大问题。你是否设想 Dynkle 解决方案也能应用于关系数据库？

关系数据库系统的工作，特别是它们的自动化测试，已经被很好地探索过了。关于这方面有很多论文。我有点怀疑它会出现在那里，但我的意思是，我很乐意接受它。Dynkle 是一项完成的工作吗？它只是一些查询的集合，还是以某种方式发展？

不，它在不断发展，数据库本身也是如此，因为与关系数据库相比，图数据库系统还处于起步阶段。它们仍在更改其语法、语义，它们在此处和那里添加新功能，我们使 Dynkle 也能够专注于这些功能，以便它们也能够测试这些新功能。

在自动化软件测试的新工作中经常做的事情是提出新的策略来使错误显现出来，例如使逻辑错误显现出来。

它不会有意识地运行查询并说，哦，这个结果是错误的。我们发现了一个错误。你必须有一些策略才能真正将其识别为错误。这也是我们在构建 Dinkle 时考虑到的一个因素，以确保它确实是为以后添加的策略奠定基础。

你能举一个在某种程序级别上的策略示例吗？有很多关于不同策略的不同论文。我会说最简单的一种是，你生成一个查询，运行查询，然后以某种方式转换查询

这样结果就不会改变。例如，你可以更改，假设你在查询中有一个变量声明，将 1 赋值给变量 x，你只需将其更改为 1 + 0。这显然不应该影响查询的结果，但如果你重新运行这个查询，这个转换后的查询，并且它产生不同的输出，那么你就知道后台一定出了问题。

这感觉就像一个低级别的检查，我们会说，哦，你这里有一个同义反复。显然添加零应该给出相同的结果。但是，你知道，这似乎几乎就像你撒了一个很大的网。你能指望做出这样的简单改变吗？例如，我认为如果我手动这样做，我会做几周而找不到问题。你有什么吗？是的。你如何管理搜索空间？

这显然比仅仅做 a + 0 深入得多，特别是如果你查看 Cypher 中存在的所有语义，然后你可以用它来以某种方式转换查询。还有一些论文介绍了如何以某种方式解构图，以便你可以以某种方式重用它，你也可以预测结果。

它比仅仅向数字添加零深入得多，例如，但即使是很小的变化也可能导致数据库在后台生成完全不同的执行模型。所以它可以

获取看起来非常相似的查询，但最终，它实际上以非常不同的方式运行它，这可能会导致你几乎遇到错误的代码。你是否有关于在找到错误之前需要模糊测试多长时间的指标？也许是每 100,000 个查询的错误数量或类似的东西？

我的意思是，当然，当你开始报告它们时，这会显著下降。就像我们开始模糊测试时一样。是的。但即使现在我们对我们最初测试的版本上的当前版本进行模糊测试，我们也会发现一个错误。

似乎每几十个查询就会出现一个。但就目前而言，尤其是在 Neo4j 上，它已经被广泛测试过了，我们可以运行它好几天而找不到任何东西。所以差异很大。

在我看来，如果他们在内部将其作为其持续集成、持续部署策略的一部分，这将对他们有利。你的代码和许可证等是如何运作的，这有可能吗？是的，我们正在运行它。好吧，我们还没有将其开源，因为我们仍在不断扩展它。但我们计划使用 MIT 许可证发布它。所以基本上就是一个许可证……

允许你用它做任何事情。我们希望不同的公司能够在其持续集成中采用 Dinkle，因为特别是当我们看到新版本发布并对其进行测试时，当我们在一天或两天内提出五个新的错误报告时，这可能会让开发人员感到恼火，如果他们事先自己测试过，他们本可以发现这些错误。是的，我认为这将是他们应该采用的一个好程序。

你能分享更多关于生成过程的细节吗？正如你提到的，Cypher 是一种结构化语言。你如何利用这种洞察力以编程方式生成查询？我们所做的是构建所谓的抽象语法树，它本质上是表示查询的数据结构，但还不是字符串。

我们只是不断尝试构建这棵树，直到我们决定停止。然后我们将这棵树转换回字符串。这是一种相当常见的生成此类查询的方法。我们只需要确保在此生成过程中，节点的类型正确即可。

树的节点，这使我们能够利用所有这些不同的 Cypher 功能。你对图数据库的兴趣是你关注的焦点吗？还是你的专业？或者它只是你感兴趣的更大自动化测试领域的一部分？

是的，我觉得我真的是偶然进入这个领域的。我只是想写一篇关于自动化软件测试的学士论文。我的导师有一段时间有这个想法，想以更深入的方式测试图数据库管理系统。我想我无意中成为了一名专家，但这并不是我一开始的重点。我很想知道你认为未来会带你走向何方，因为你会继续探索这个领域，或者接下来你会做什么？

这是一个非常好的问题。它可能会有很多不同的方向。我可以继续测试图数据库管理系统，因为这很有趣。我也可以转向不同的领域。我已经对一些不同的项目有一些计划了。

但也有可能我只是成为一名软件工程师，然后离开学术界。但我们会看到它会带我走向何方。早些时候，你对 Java 做出了某种形式的赞扬，因为它具有其结构和那些东西。我想 JVM 在这里得到了一些赞扬。很难让它崩溃。

你对其他语言有什么看法？如果你要创办一家科技公司，你会推荐采用哪些语言？这可能取决于许多不同的因素。例如，这取决于系统将变得多大，取决于你的开发人员将有多么经验丰富，取决于你希望它有多快。

例如，我看到 Neo4j是用 Java 编写的。我看到了这家公司有多大。有这么多人在合作。显然，Java 可能在那里不是一个坏选择，但你会注意到性能下降，特别是当你将其与用 C 和 C++ 编写的数据库进行比较时。

显然，现在围绕 Rust 的炒作很多，它将这种性能与真正知道你的代码本质上是正确的并且不会出现某些类型的错误的舒适感结合在一起。但当然，Rust 的开发速度会变慢。所以是

使用同样有才华的开发人员构建相同的应用程序，如果他们要用 Rust 而不是 Java 来做，可能需要更长的时间。但当然，我不能就此一概而论。我没有太多行业经验，但这实际上只是许多不同因素之间的权衡，这些因素最终可能会决定应该选择哪种语言。

所以我们了解了你对语言的看法。如果你要在该公司中包含一个图数据库，你会如何做出选择？我会说，如果事情是面向客户的，我会选择 Neo4j。关键是，我认为这是成熟度和性能之间的权衡。

因此，Neo4j 非常成熟，非常安全，你不用担心人们能够攻击数据库。而如果你使用其他东西，例如 FileQDB，它要快得多。我们在测试 Dynkle 时收集了这些统计数据，FileQDB 与 Neo4j 相比有多快。

但是你确实有可能发生崩溃，这可能会导致你的系统遭受 DDoS 攻击，甚至在这些数据库系统中存在远程代码执行的 CVE。所以我会说，如果它是面向客户的，我会选择 Neo4j。如果它只是内部的，并且对安全性没有真正的威胁，我会选择 FalconDB，因为它性能要高得多。

好的决策树，因为我知道很多数据人员会做一些离线后端 ML 内部项目。没错。特别是考虑到 Falkyrie 在多大程度上也在宣传将大型语言模型的基础建立在图数据库管理系统上。所以我认为这可能也具有很大的应用潜力。

毫无疑问，大型语言模型可以为你做一定量的测试。但我也觉得我很快就看到了它们的局限性，因为我要求它审查代码之类的东西。你对未来的……

大型语言模型、阅读代码和你所从事的工作等更正式的系统之间的平衡是什么样的？这很难预测，特别是考虑到当前 AI 行业，特别是大型语言模型的波动性。感觉每天都有新的爆炸性新闻。所以你永远不知道它是否会突然在性能上飙升，成为一个绝对的代码大师，或者它是否会停滞不前，并且

真的不会变得更有用。我想关键在于责任和安全的重要性。我可以看出，在编码项目中使用大型语言模型在加速开发、使流程更容易方面非常有用。但最终，如果没有经过审查，它几乎就是在运行不受信任的代码。

并且已经有这样的案例，ChatGPT 生成的 Python 代码实际上直接导入恶意软件。我听说很多人告诉我他们想让它生成一些非常简单的代码。最终，它错过了一个非常明显的极端情况，这很容易导致引入错误。我想最终，我可以看到它在某些领域变得非常有用。

但在其他领域，我自己建议谨慎。但是的，我们会看到明天是否会有新的论文介绍如何完美地做到这一点，以及我所说的所有内容都是无效的。

这对我来说会很令人惊讶，因为归根结底，我们总是有停机问题。没错。是的，这是真的。但是的，我想最终，重要的是在代码背后要有一个人。想象一下，在最坏的情况下，假设谷歌将大型语言模型生成的一些新代码引入你的搜索引擎的后端，并且它会让一切瘫痪。

或者进入 Chrome？是的，例如，是的。将新代码放入 Chrome 中，这几乎会导致 Chrome 对于用户来说变得无法使用。那么最终谁应该负责呢？我想这可能也是我认为公司非常关注的事情。真正确保，你知道，最终有人要负责，因为它是……当然。是的，你总需要一个可以控制的人。没错，是的。

好吧，Selene，和你聊天很愉快。听众可以在网上关注你吗？你也可以在 LinkedIn 上找到我，用户名是 Selene Wüst，W-U 带有分音符，S-T。否则，我的意思是，感谢你的邀请。很高兴认识你。