这个Bug值200亿？谈谈怎么热爱你的Bug——软件测试工程师

有人喜欢创造世界，他们做了开发者；有的人喜欢开发者，他们做了测试员。什么是软件测试？软件测试就是一场本该在用户面前发生的灾难提前在自己面前发生了，这会让他们生出一种救世主的感觉，拯救了用户，也就拯救者这个软件，避免了他们被卸载的命运。

我爱 bug

我目前是 Pilot.com 的一位高级工程师，负责给创业公司提供自动记账服务。在此之前，我曾是 Dropbox 的桌面客户端组的成员，我今天将分享关于我当时工作的一些故事。更早之前，我是 Recurse Center 的导师，给身在纽约的程序员提供临时的训练环境。在成为工程师之前，我在大学攻读天体物理学并在金融界工作过几年。

但这些都不重要——关于我你唯一需要知道的是，我爱 bug。我爱 bug 因为它们有趣。它们富有戏剧性。调试一个好的 bug 的过程可以非常迂回曲折。一个好的 bug 像是一个有趣的笑话或者或者谜语——你期望看到某种结果，但却事与愿违。

在这个演讲中我会给你们讲一些我曾经热爱过的 bug，解释为什么我如此爱 bug，然后说服你们也同样去热爱 bug。

Bug 1 号

好，让我们直接来看第一个 bug。这是我在 Dropbox 工作时遇到的一个 bug。你们或许听说过，Dropbox 是一个将你的文件从一个电脑上同步到云端和其他电脑上的应用。

+--------------+     +---------------+
        |              |     |               |
        |  元数据服务器  |     |     块服务器    |
        |              |     |               |
        +-+--+---------+     +---------+-----+
          ^  |                         ^          |  |                         |
          |  |     +----------+        |
          |  +---> |          |        |
          |       |   客户端   +--------+
          +--------+          |
                   +----------+

这是个极度简化的 Dropbox 架构图。桌面客户端在你的电脑本地运行，监听文件系统的变动。当它检测到文件改动时，它读取改变的文件，并把它的内容 hash 成 4 MB 大小的文件块。这些文件块被存放在后端一个叫做块服务器blockserver的巨大的键值对数据库key-value store中。

当然，我们想避免多次上传同一个文件块。可以想见，如果你在编写一份文档，你应该大部分时候都在改动文档最底部——我们不想一遍又一遍地上传开头部分。所以在上传文件块到块服务器之前之前，客户端会先和一个负责管理元数据和权限等等的服务器沟通。客户端会询问这个元数据服务器metaserver它是需要这个文件块，还是已经见过这个文件块了。元数据服务器会返回每一个文件块是否需要上传。

所以这些请求和响应看上去大概是这样：客户端说“我有一个改动过的文件，分为这些文件块，它们的 hash 是 ‘abcd,deef,efgh’。服务器响应说“我有前两块，但需要你上传第三块”。然后客户端会把那个文件块上传到块服务器。

+----------