1000 个错误，一个 Google Sheet，以及我再也找不回来的五个小时
每个 Bug 都有一个故事。大多数故事都始于这句话：“在我的机器上运行正常。”
我们当时正在为一家潜在客户开发公司测试数据导入功能。这个功能看起来很简单：点击导入按钮，上传电子表格，系统就会加载联系人。所有人都认为它没问题。
这种假设是一个陷阱。
测试人员的存在就是为了打破这种假设。“快乐路径”（happy path）总是会欺骗你。
如果我们使用干净的 Excel 文件，导入就会通过。我们本可以去吃午饭，本可以发布这个功能。但客户会在周一早上的生产环境中发现这个 Bug。
问题出在 Google Sheet 上。
真实用户不会使用干净的 Excel 文件。他们使用的是杂乱无章的 Google Sheets。他们期望系统能够处理他们的混乱。
当我们上传 Google Sheet 数据时，系统崩溃了。我们看到了超过 1,000 个错误。屏幕上全是错误提示。同样的按钮，同样的数据类型，仅仅因为源格式发生了变化，就导致了系统的彻底瘫痪。
我们回到 Excel 进行更多测试。我们尝试了有效行和无效行的混合。系统处理得很好，跳过了错误行并继续运行。
然后我们尝试了现实世界的混乱情况。我们上传了一个包含数百行的批量文件。大部分都是垃圾数据，只有少数是有效的。
系统彻底崩溃了。校验逻辑在处理少量错误行时表现良好，但在面对堆积如山的错误数据时却无能为力。
我们花了五个小时才找到根本原因。我们盯着屏幕，重新运行测试，并把责任推给文件、浏览器和咖啡。
这五个小时的代价很低。如果不这样做，代价就是客户浪费掉整个下午，并对我们的产品失去信任。在测试阶段，你用时间为 Bug 买单；在生产阶段，你用客户为 Bug 买单。
我每次都会选择这五个小时。
一个优秀的测试人员不会问一个功能是否可用，而是会问如何把它搞坏。
停止像开发人员那样思考。开始像下面这些人一样思考：
- 上传错误文件格式的懒惰用户。
- 使用合并单元格和空行的混乱用户。
- 拥有 4,000 条脏数据而非 10 条干净数据的批量用户。
- 专门做那些不该做的事情的捣蛋鬼。
软件会在你意想不到的输入下崩溃。
最“简单”的功能往往是最危险的。导入按钮、搜索框和联系表单看起来无害，但事实并非如此。
如果一个功能通过了“快乐路径”测试，不要就此止步。要做那个问出“如果我上传一个能想象到的最烂的文件会怎样？”的人。
然后，去尝试一下。
Optional learning community: https://t.me/GyaanSetuAi