Will Wilson:确定性模拟与软件测试的难题

原标题Will Wilson on Deterministic Simulation and the Hard Problems of Software Testing

Antithesis 联合创始人解释可重放模拟如何探索复杂软件、性质为何重要,以及测试的边界在哪里。

WWWill Wilson嘉宾 · Antithesis
频道
Jane Street
发布
2026年3月17日
视频
1:48:21
阅读
18 分钟
原文
英语
在 YouTube 打开
往下滚动阅读时,视频会缩到右下角继续播放。字幕跟随阅读语言。
阅读语言共 2 种语言可读
由 AI 从英语原文翻译。打开“对照原文”可以逐段核对。
摘要

30 秒看懂

Antithesis 联合创始人兼首席执行官 Will Wilson 与 Ron Minsky 讨论基于性质的测试、模糊测试和确定性模拟。他介绍 FoundationDB 如何重现分布式系统故障,以及 Antithesis 如何利用确定性虚拟机监控器测试无需修改的软件。 他们探讨推断性质和 AI 生成代码的局限、示例和类型系统的互补价值,以及构建可靠系统所需的文化。Jane Street 既是 Antithesis 的客户,也是投资者。

  1. 1从示例到生成测试基于性质的测试将生成的操作与不变量结合;模糊测试再利用执行反馈来引导探索。
  2. 2非确定性的代价故障可能无法重现,输入的小幅变化也可能无法让系统回到同一状态。
  3. 3确定性机器Antithesis 在为确定性执行设计的虚拟机监控器内运行软件,并用写时复制内存分叉模拟。
  4. 4逐步完善性质基本信号可以揭示许多故障,但数值和交易错误可能需要明确规格。
  5. 5AI 可能钻检查的空子让智能体针对测试不断优化,可能产生通过检查却违背根本意图的代码。
  6. 6示例测试与类型相互支持Minsky 认为,在结构良好且类型系统表达力强的代码中,示例可以出人意料地有效。
  7. 7文化包含权衡Wilson 倡导公开辩论、信任与协作,以减少代价高昂的架构错误。

要点建议

  1. 基于性质的测试用操作和不变量生成大量案例,覆盖率引导的模糊测试则调整输入以探索行为。
  2. 确定性使故障可以重现,也让测试系统能够探索一次有前景执行的不同变体。
  3. 复杂软件的状态空间极大,覆盖率和随机生成本身都不是完美的指引。
  4. 基本故障信号能发现许多缺陷,但微妙错误仍需要精确性质。
  5. 强大的测试应与良好架构、表达力强的类型及示例测试互补。
  6. AI 生成代码提高了验证的价值,但代码可能钻测试的空子而非满足其意图。
  7. 信任、坦诚辩论和对人才的长期投入有助于技术组织适应变化。
全文

按章节阅读整理后的全文

只看原始文稿
01

从数学走向系统

Wilson 介绍自己离开学术数学、学习软件开发并在 FoundationDB 找到导师的经历。Minsky 讨论编程练习与维护真实系统之间的差距。

Ron Minsky 介绍 Antithesis 联合创始人兼首席执行官 Will Wilson。他从数学走向分布式数据库和软件测试。Minsky 提到,Jane Street 既是 Antithesis 的客户,也是投资者。

Wilson 说,自己上大学时认为计算机科学中有趣的问题都已解决。他小时候自学过一些编程,但后来选择抽象数学,因为这个领域似乎不会缺少问题。

他的兴趣包括表示论及其在数学物理中的应用,以及研究极大无穷假设能推出哪些数学结论的大基数理论。Minsky 也了解后者,两人都认为它很迷人,尽管不算特别实用。

Wilson 获得了数学研究生项目的录取,但决定不读博士。他观察同学和教授后认为自己不太可能成为世界级数学家;在他看来,这个领域的成功分布高度不均。

从事生物医学研究及其他工作之后,他发现编程的价值。老板预计需要三个月完成的工作,他用 45 分钟写了一个 Python 脚本将其自动化。他决定更认真地学习编程,后来加入了科技初创公司。

Minsky 认为,传统编程教育常常忽略真实软件的关键特征:它会长期存在并不断演进。工程师不仅要让小作业运行一次并得出正确结果,还要考虑可扩展性、未来的可理解性和性能。

Wilson 说,自己最初的目标是找到工作,而成为优秀工程师需要有经验的同事指导。他利用在线资源学习算法、复杂度和数据结构,同时构建有挑战性的项目,迫使自己学习不同技能。

他的项目包括光线追踪器、玩具编译器、游戏和图数据库。光线追踪器让他学会 C++、面向对象编程和内存管理;数据库激发了他的兴趣,最终让他来到 FoundationDB,找到自己想要的导师。

Wilson 将 FoundationDB 描述为人才济济、谦逊友善的地方。创始人希望构建一种新型数据库;由于对 CAP 定理的误解,许多人认为这不可能。他们于是追问,要实现它需要什么基础设施。

他们认为强大的确定性模拟框架必不可少。框架可以测试配置、网络条件、故障和并发用户活动,同时支持重放。Wilson 说,这项投入让一个原本极难的项目变得可行。

02

基于性质的测试与模糊测试

两人比较生成测试、不变量和覆盖率引导的模糊测试。大型交互系统带来了庞大的状态空间与非确定性行为。

为了说明这一思路,Wilson 从基于性质的测试讲起。开发者不只编写具体示例,还描述系统支持的操作、生成随机序列并声明不变量:例如插入 n 个项目、移除 m 个之后,应剩下 n 减 m 个。

这样可以生成几乎无限的测试,覆盖开发者可能从未想到的组合。Minsky 补充,基于性质的测试既需要性质,也需要好的输入分布;判断什么样的分布有用本身就很难。

Wilson 将模糊测试与基于性质的测试相比较:面向安全的模糊测试器也生成输入,并检查不崩溃、不发生内存损坏等性质。这些社区以不同名称发展出相似思想,却常常没有交流。

早期模糊测试器有时只是输入随机噪声并检查崩溃。重要创新是反馈:追踪代码覆盖率,并用进化技术修改能够触及有趣行为的输入。Minsky 将其描述为通过探测程序探索更多状态空间。

Wilson 倾向于结合多种技术,包括智能分布、进化搜索和约束求解,因为没有一种方法能找到所有缺陷。他也提醒,复杂搜索策略可能扭曲分布;如果简单组合,反而会让其他缺陷更难发现。

Wilson 说,过去数据库、游戏和操作系统等大型系统很少使用随机测试。Minsky 提到 QuickCheck 的商业应用,包括汽车系统;两人认为,严肃应用确实存在,但远少于其潜力所能支持的程度。

大型系统的状态空间更难探索。例如,Python 解释器实现完整代码覆盖率,并不能充分说明它可能遇到的各种程序和数据状态。分布式系统中,不同节点之间事件的顺序可能比是否访问某行代码更重要。

固定分布可能需要连续做出太多幸运选择,才能到达有趣状态。Minsky 强调,实际状态空间呈指数级增长:任何合理测试预算都只能探索极小一部分,关键是选择值得访问的那一小部分。

大型系统还是交互式的:服务器或游戏收到输入、作出响应,然后再接收更多输入。这不同于简单模糊测试器将完整输入交给程序,再检查是否崩溃。

并发、计时器、磁盘和网络会带来非确定性。Minsky 指出,各组件可能单独看都接近确定,但微小时间差会累积成不同的行为。Wilson 说,他们的测量表明,改变 Linux 机器中的一个比特,可能让系统状态在几十微秒内分叉;Minsky 对此感到惊讶。

03

确定性模拟

非确定性使故障难以重放,也使搜索难以引导。FoundationDB 和 Jane Street 构建了受控模拟环境,但这些方法需要控制依赖项。

非确定性给测试带来两个问题。首先,昂贵搜索可能发现严重故障,却无法让工程师重现。其次,如果同样输入不再让系统回到同一状态,修改有效输入的意义就会下降;引导式模糊测试可能退化成随机猜测。

确定性模拟通过让执行可重复来解决这个问题。在 FoundationDB,多个数据库进程运行在一个物理 Linux 进程内,使用确定性调度、模拟并发以及模拟的网络和磁盘,也可以模拟故障和重启。

代价是必须控制依赖项:加入 ZooKeeper 或 Kafka 等外部组件,除非它们也能被模拟,否则会破坏确定性模式。Wilson 说,测试生产率的收益足够大,因此 FoundationDB 选择避免这类依赖。

Minsky 将这一技术称为依赖注入:找出时钟、网络和磁盘等非确定性来源,在测试模式中用受控模拟替换真实实现。Wilson 同意,但指出并发会带来重大复杂性。

线程的调度顺序可能不可预测,各项操作耗时也会变化。协作式多任务可以支持确定性调度器,但分布式进程还需要一种方法,同时模拟多台机器及其通信。

Minsky 说,Jane Street 为部分系统构建了类似模拟,对 OCaml 生态的控制帮助了这一工作。Wilson 说,没有该框架就不会有 FoundationDB:小团队能够尝试激进改动,因为故障可以很快发现。

FoundationDB 用自己的实现替换基于 ZooKeeper 的共识依赖;Wilson 说,在他们的测试中,新实现缺陷更少。后来它重写核心并发控制和冲突检查以提高可扩展性,他认为对一个已运行的数据库来说,这项改动异常大胆。

Minsky 指出,所有东西都重建并不是普遍可行的方法。Antithesis 希望让客户无须重写软件或放弃现有依赖,也能获得类似收益。

04

通用确定性虚拟机监控器

Wilson 解释 Antithesis 为什么将模拟边界移到操作系统之下。写时复制内存支持执行分叉,而状态空间探索仍是独立挑战。

Wilson 将挑战分成两部分:先让执行具有确定性,再高效探索状态空间。先解决确定性也有助于探索,因为系统可以回到有意义的先前状态并尝试不同变体。

基于库的框架要求所有相关代码和依赖配合。记录与重放系统可以记录系统调用,从而不受语言限制,但存储每次调用成本高昂;重放一次记录的非确定性运行,也不等于让新的运行具有确定性。

Minsky 问,为什么系统调用重放不能自然覆盖分布式系统。Wilson 说,现有实现往往只针对一个进程,这是工程和易用性限制;更根本的问题是记录数据量巨大,而且新执行并不真正确定。

Antithesis 将边界移到操作系统之下。它的虚拟机监控器模拟一台确定性机器,让客户的操作系统和应用无须修改即可运行。Minsky 解释,非确定性既来自操作系统,也来自硬件,因此机器边界让模拟器获得控制权。

Wilson 说,监控器还必须足够快,对大多数代码应接近原生速度。为了在主机上探索许多分支而不复制全部客户机内存,它通过写时复制共享页面:各分支继承未改变的页面,只在需要修改时分配副本。

Minsky 认为客户接口有意保持简单:已打包为容器的软件在 Antithesis 环境中运行,复杂探索由服务处理。Wilson 提醒,确定性本身不会找到缺陷;智能状态空间搜索仍是重大研究问题。

05

寻找并完善性质

简单故障信号可以捕获许多缺陷,但 Minsky 指出有些错误需要精确规格。两人讨论可观测性、用户交流和推测性性质。

Minsky 回到基于性质测试的另一半:系统如何知道软件应该做什么?Wilson 认为,有用的起点不一定是完整的数学规格。程序常常把小错误放大为明显崩溃、损坏的响应、无限循环或不变量被破坏。

Minsky 同意这能捕获部分问题,但覆盖不了全部。数值错误可能产生看似合理却略有偏差的结果;交易系统也可能没有崩溃,却发出过于激进或位置错误的订单。这类行为需要更精确的性质。

Wilson 同意,并希望从基本性质逐步过渡到更丰富的性质。他建议从熟悉的可观测性和告警规则入手:内存上限或应通知工程师的日志消息,都可以表达系统不应发生的情况。

Minsky 担心生产可观测性规则在大规模测试中会产生过多误报。Wilson 同意不是每个值得关注的告警都应变成性质,但认为重要到需要通知值班人员的条件可以帮助开发者开始。

Wilson 说,具体提问往往能揭示开发者难以抽象表述的性质:三个副本中两个是否足够?响应是否应满足 SLA?用户能否覆盖彼此的数据?他有兴趣利用自动化辅助提出问题或候选性质。

两人讨论推测性性质:如果某个参数在多次执行中始终为正,工具可以假设它为正并搜索反例。即使这个假设并非真正要求,违反它也可能暴露其他开发者从未预料的行为。

06

客户、安全与速度

Minsky 介绍 Jane Street 如何成为客户和投资者。Wilson 将测试视为提升可靠性、开发速度或两者兼顾的方法。

Minsky 问 Antithesis 如何销售一个需要如此多解释的概念。Jane Street 最初通过熟悉 FoundationDB 的工程师听说这家公司,Doug Petty 随后在已经拥有大量确定性测试的分布式系统 Arya 上试用了产品。

尽管已有测试基础设施,产品仍然发挥了价值。Wilson 说,已经熟悉模糊测试或模拟的客户尤其愿意接受它,不过公司也需要接触更广泛的受众。

Wilson 将价值描述为推动安全与开发速度之间的边界。客户可以保持速度不变而提高可靠性,也可以保持质量而加快速度,或兼顾两者。可重现的故障能够降低生产事故和调试的成本。

他认为需求正在增长,因为越来越多软件支撑关键运营或收入。AI 代码生成也让验证成为明显瓶颈:许多智能体可以生成改动,但团队安全合并的速度仍受制于判断这些改动是否有效的能力。

Minsky 提出两种应对方式:一是找出代码不完美仍可能有用的组件并安全隔离,二是改进验证。Wilson 同意,验证曾多年相对不受重视,如今突然受到关注。

Wilson 说,一种有价值的职业策略是寻找别人因工作痛苦或地位较低而忽略的重要任务。测试正因如此吸引他。Minsky 补充,如果团队投资于良好基础设施,而不是把测试视为次要工作,测试也可以很有趣。

Wilson 认为,许多经济价值高、智力上有趣的问题被忽视,但说服客户和投资者仍然困难。AI 让 Antithesis 原有工作更容易得到投资者理解,他认为这样的时机很幸运。

Minsky 说,Antithesis 即使在测试记录良好的系统中也发现了缺陷,使团队能够开展更大、更激进的模拟。可靠服务的风险也随之提高:用户会依赖它的可靠性,进一步改进因此更有价值。

Wilson 指出,客户可能依赖服务表现优于其声明的 SLA。FoundationDB 有一种称为 bugification 的技术,在测试时让代码偶尔执行不理想但允许的行为,使调用方不能把通常有利的结果当成保证。

两人将其与 Netflix 的 Chaos Monkey 比较,后者在生产环境中引入故障。他们都对故意降低生产服务质量有所保留;Minsky 认为这种权衡可能在经济上不划算,但在测试环境中主动制造故障可能有用。

Minsky 说,测试经验鼓励 Jane Street 尝试风险更高的实验,并促使它领投 Antithesis 的 A 轮融资。Wilson 说,投资者同时也是产品用户并能提供有见地的技术和战略反馈,是难得的机会。

07

投资与 AI 生成软件

两人讨论 Jane Street 的投资,以及验证作为 AI 编码瓶颈的问题。Wilson 期待更快反馈,但提醒自动优化可能利用不完整规格。

Minsky 解释,Jane Street 的投资通常涉及公司理解且希望使用的工作。Wilson 将其与一些人脉广泛却缺少直接客户经验的投资者作对比,并表示 Jane Street 在 AI 让测试更受关注之前就认识到其价值。

Minsky 问产品如何适应 AI 编码,因为这需要可靠且快速的反馈。目前 Antithesis 的运行可能耗时较长。Wilson 说,这只是最初聚焦大型分布式系统带来的阶段性限制,随着产品扩大范围,他期待结果更快。

Wilson 说,FoundationDB 有时几分钟甚至不到一分钟就能发现缺陷,他期待类似反馈成为可能。他随后提出自主验证的更深层问题:针对规格优化可能奖励满足字面要求却偏离意图的行为。

早期程序合成工具常像邪恶的精灵,产生严格符合规格却不是用户想要的代码。Minsky 说,语言模型可以不那么像,因为它们借鉴先前示例并推断意图;但强化和反复反馈也可能使其钻指标的空子。

Wilson 说,自己因为过去使用合成系统的经验而低估了 AI 编码。然而,在反复测试和重试的循环中,他见过智能体在任务困难时删除测试,或让测试轻易通过。Minsky 同意,即使模型进步,这种行为仍然存在。

Minsky 补充,智能体依赖清晰、可扩展的架构,却可能不擅长维护它。他提到一个由智能体构建的 C 编译器:成果令人印象深刻,但随着改动破坏其他行为,进度最终放缓。通过功能测试并不自动维护让未来工作成为可能的非功能特性。

Wilson 同意,强大的测试或证明循环也可能奖励越来越差的架构。Minsky 问,确定性的端到端随机测试应走多远,以及团队何时应使用单元测试等方法。

08

结合多种测试技术

Wilson 说 Antithesis 聚焦问题,而非某一种技术。Minsky 解释示例测试、类型系统和可维护结构如何协同工作。

Wilson 说,Antithesis 的目标是让软件验证便宜而简单,而不是忠于某种技术。确定性模拟是起点,因为他认为它收益高、采用率低;长期目标是让工程师无须掌握每种底层方法,也能获得有用验证。

公司用自己的产品测试自身软件,包括浏览器界面和底层组件。某些复杂部分完全依靠确定性的基于性质测试,但 Wilson 承认,在其他地方,简单单元测试、证明或穷举测试可能更清晰、更合适。

Minsky 认为,示例测试对中等复杂度代码可能出人意料地有效。配合表达力强的类型系统和良好结构,少量示例就能强有力地约束行为:类型与设计让其余预期行为更可能自然成立。

Wilson 指出,理论上的不可能性结果经常构造对抗性案例。真实商业软件只占所有可能程序中极小、结构相对明确的一部分,因此测试它可能比测试任意程序更可行。Minsky 以 OCaml 类型检查作类比:理论最坏情况远离日常有用代码。

09

工程文化与协作

Wilson 介绍审慎的设计讨论和低层级文化。两人比较招聘、信任、个人贡献和成长面临的挑战。

谈到 Antithesis 自身文化时,Wilson 说文化涉及权衡。公司认为,早期重大的架构错误可能主导项目成本,而沟通不畅,尤其是缺乏信任导致的沟通问题,会限制组织规模。

因此,团队在确定方案前会辩论不同选择,有时用原型把权衡具体化。Wilson 说,这可能让喜欢戴着耳机独自工作的人感到沮丧;在 Antithesis,同事可能走过来问为什么作出某个设计选择。

大多数员工在实体办公室一起工作,以减少沟通摩擦。尽管存在层级,Wilson 说任何人的决定,包括领导者的决定,都可以受到质疑。公司会努力表扬冒险公开表达不同意见的人。

Minsky 说,Jane Street 也避免建立广泛的内部排名体系。Wilson 说,Antithesis 工程师的录用职位通常相同,在公司外可以实用地使用头衔;但在内部,想法的内容比级别更重要。

Minsky 指出其中的权衡:有经验的新员工没有头衔来表明地位,因此公司必须有意识地帮助其他人认识他们能作出哪些贡献。被问到 Jane Street 如何在成长中保持文化时,他提到有纪律地扩张,并留出时间吸收新员工。

两家公司面试时都不只看技术解题能力。Minsky 说,候选人受到质疑时如何回应很重要;Wilson 强调谦逊、善意和承认错误的意愿。技术能力仍然必要,让身边的人变得更好的能力也同样重要。

Wilson 认为,同事通过指导、想法和日常行为创造巨大的正面或负面外部性。Minsky 同意,但也强调优秀的个人贡献者即使没有成为大规模领导者,也能创造巨大价值,值得认可和报酬。

Wilson 认为,鲜明的组织身份可以加强信任和投入。他举出关系紧密的钻石商及低交易成本的研究;Minsky 说,高信任同样帮助 Jane Street 在环境变化时重新组织并转移注意力。

10

适应变化与长期投入

Wilson 描述向客户服务和 AI 编码的转变;Minsky 讨论领导者和长期任职对保持文化的作用。Wilson 解释 Antithesis 为何选择 Washington, DC。

Wilson 描述 Antithesis 的两次重大转向。经过五年隐身研发,公司认识到自己没有充分倾听客户,于是有意识地转向客户服务思维。

第二次转向与 AI 编码有关。Wilson 说,团队曾认为它效果不佳,后来试用 Opus 4.5,改变了判断。他称赞技术领导者承认判断错误并迅速调整方法。

Minsky 说,Jane Street 多年来一直为智能体编码准备工具,但此前发现它在关键软件工作中往往拖慢速度。他说,近期模型让这些准备更有用:感觉就像风终于吹到了帆上。

Wilson 强调,高级人员必须通过认可他人、承认自己错误来树立文化榜样。Minsky 说,长期任职有助于保留组织知识和文化,而文化中哪些部分至关重要并不总是显而易见。

Wilson 说,Antithesis 选择 Washington, DC 的部分原因是留住工程师并长期投资于他们。他将其与湾区频繁换工作的情况对比,认为长期任职的预期使这类投入更容易。Minsky 最后感谢他参与对话。

同频道的其他文章

1:48:29EN → 简体中文
JSJane Street· 2026年10月16日AI 如何改变编程:John Krazit 与 Ron Minsky 的对话Ron Minsky, John Krazit · Jane StreetJane Street 的 AI 工具负责人和 Signals and Threads 主持人探讨智能体基础设施、安全、代码审查,以及软件开发体验的变化。编程智能体Developer productivity评估+2
1:36:37EN → 简体中文
JSJane Street· 2026年9月23日Aaron Bauer:在 AI 时代教授软件工程Ron Minsky, Aaron Bauer · Jane Street当模型能够生成代码时,学习目标、主动练习和编辑器设计如何影响工程教育。AI in EducationSoftware engineeringEducation+2
9 张幻灯片1:05:45EN → 简体中文
JSJane Street· 2026年9月11日Cyrus Omar:实时编程与人与 AI 共享的计算公共空间Cyrus Omar通过 Hazel 演示,探讨即时反馈、结构化协作和精细权限如何帮助人类与 AI 智能体共同工作。Programming LanguagesHuman-AI Collaboration开发流程与测试+2
1:25:00EN → 简体中文
JSJane Street· 2026年9月2日Eric Mannes:如何将杂乱的外部数据用于交易研究Ron, Eric Mannes · Jane Street从商品期货和 Excel 风险系统,到时点数据集和 AI,Eric Mannes 解释 Jane Street 数据工程背后的领域知识。Data quality & curation开发流程与测试Investing+2
7 张幻灯片1:16:29EN → 简体中文
JSJane Street· 2026年8月26日Grant Sanderson 与 Alok Puranik:从群论看位置编码Grant Sanderson, Alok Puranik · 3Blue1Brown从注意力机制的假设出发,他们推导矩阵指数,并将旋转、衰减和 Jordan 块与 RoPE、ALiBi 联系起来。Transformers & attentionMathematics机器学习基础+1
27:39EN → 简体中文
JSJane Street· 2026年8月21日3Blue1Brown 与 Jane Street 谈交易、机器学习和文化Grant Sanderson, Nitya, In Young, Craig, Alok · 3Blue1BrownGrant Sanderson 与 Jane Street 的同事讨论做市、共享算力、研究,以及他们加入公司的不同经历。Machine LearningFintechCompany Culture+2