这是一个很棒的提案，我不希望显得消极，但我觉得像“我们找到了所有错误”这样的说法，只有在对错误有非常狭义的定义时才可能成立。我遇到过的最危险、最难发现的错误都是应用程序的业务逻辑方面的问题，而不是程序进入错误状态。我想到的是这种类型的问题：“数据库目前报告了一个针对客户的已完成交易，但没有完成的购买项目，应该如何在客户的最近交易页面上显示？”在这种情况下，实现“某个东西会出现且不会崩溃”是一回事，但要确保在所有其他地方的每个人的选择的上下文中，它实际上是一个有意义的选择，要困难得多。或者以数据库为例，比如“我们的查询规划器在这个边缘情况下生成了一个非常低效的计划”。
源讨论有什么事情困扰着你吗？原帖 418 条评论 · 导入时统计把你的经验，加入这段讨论。
我认为“bug”是指“本应做某事却失败了”。 关于业务逻辑的问题并不是系统的失败，系统是按照规格说明运行的，只是规格说明不够全面，现在我们进行迭代。
完整原文我认为使用“all”这个词是个错误，暗示FoundationDB中完全没有bug。然而，FoundationDB确实以在测试实践方面推动技术前沿而闻名：https://apple.github.io/foundationdb/testing.html。 所以在正常情况下，这听起来像是某人自大/过于自信，但在这里他们真的几乎接近零bug了。
完整原文我认为这里提到的“所有bug”基本上是指我们的极端严苛的确定性测试系统在进行了数以万计的运行后，没有再发现任何bug。当然，不能证明一个否定，但我们达到了“全部绿色”的状态，这给了我们极大的信心继续推进功能开发，相信我们是在坚实的基础上构建的——而时间证明了我们的判断是正确的。
完整原文我听过最好的“bug”定义是“软件没有按照文档工作”。当然，很多软件缺乏文档——这些就是文档bug。但我喜欢这个定义，因为即使文档不完整，这个定义也能引导你问自己：我会真的把软件的行为像这样记录下来吗？或者我会改变行为[并记录下来]？这对我来说更难把奇怪的行为掩盖过去。
完整原文说句公道话，那之后的一句话是“我知道，我知道，说这种话真是疯狂。”
完整原文我觉得业务逻辑的错误位于单独的一层，即应用层，把它们算在数据库本身身上是不公平的。 我同意，不理想的查询计划是数据库层的错误，这种缺陷可能很容易被错误测试框架忽略。
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。