1000 个错误，一张 Google Sheet，以及我再也找不回来的五个小时
每个 Bug 都有一个故事。而这个故事始于一个谎言：“在我的机器上运行正常。”
我们为一家潜在客户开发公司测试了一个数据导入功能。它看起来很简单：点击按钮，上传文件，数据加载。
大多数人都认为这些功能是正常的。而测试人员的存在，就是为了证明这种假设是错误的。
“快乐路径”（Happy Path）是一个陷阱。
如果你上传一个干净的 Excel 文件，系统就能通过。你就可以去吃午饭，觉得工作已经完成了。但如果你止步于此，你交付的就是有缺陷的代码。客户会在周一早上的生产环境中发现这个错误。
问题出在 Google Sheet 上。
真实用户不会使用干净的 Excel 文件。他们使用的是乱七八糟的 Google Sheets。他们在电子表格里制造混乱，并期望系统能够处理。
当我们上传 Google Sheet 时，系统崩溃了。它产生了超过 1,000 个错误。同样的数据，同样的按钮，却因为格式的变化导致了彻底的瘫痪。
然后我们测试了数据质量。
- 几个无效行？系统会跳过它们并继续运行。
- 数百行混乱的数据？系统直接崩溃。
校验逻辑在处理小错误时表现良好，但在面对堆积如山的垃圾数据时却失效了。
我们花了五个小时来调试这个问题。我们怪罪文件、浏览器和数据，甚至怪罪了咖啡。
这五个小时的代价很低，而另一种代价则要高得多。如果客户发现了这个 Bug，他们会对你的产品失去信任。在测试阶段，你用时间来为 Bug 买单；在生产阶段，你用客户来为 Bug 买单。
我宁愿用时间来支付。
要发现真正的 Bug，你必须转变思维方式。不要问软件是否能正常工作，而要问如何把它搞坏。
不要再像开发者那样思考了。开始像这样思考：
- 上传了错误文件格式的懒惰用户。
- 使用合并单元格和空行的混乱用户。
- 拥有 4,000 条脏数据而非 10 条干净数据的批量用户。
- 专门做那些不该做的事情的捣蛋鬼。
软件会在你意想不到的输入下崩溃。
“简单”的功能往往是最危险的。导入按钮和搜索框看起来无害，但事实并非如此。
下次当一个功能通过了快乐路径测试时，请成为那个问出“如果我上传一个能想象到的最烂的文件会怎样？”的人。
然后，去动手试试吧。