拥有 10 个证书却找不到 Bug 的测试员
你拥有所有的证书。ISTQB、ScrumMaster、云端和安全认证。你的简历上写满了各种缩写。
但你却写不出一个能发现真实 Bug 的测试用例。
上个季度我面试了一位候选人。他们满口都是理论。他们提到了 V 模型和测试左移（shift-left）。当我让他们展示一个他们编写过的、成功抓到 Bug 的测试用例时，他们沉默了。
他们从未写过能让程序出错的测试。他们写的测试永远都是通过的。
证书测试的是你的记忆力。Bug 测试的是你的思维能力。
证书提供词汇和结构。它们能帮你通过招聘人员的筛选。但它们不会教你如何发现缺陷。
考试题目遵循教学大纲。但真实的应用程序并非如此。登录表单没有教学大纲。它只有各种奇怪的边界情况，比如服务器时钟偏差了四分钟，或者特定的时序问题。
持证测试员遵循检查清单。他们根据需求编写测试，并将其标记为通过或失败。
Bug 猎手则将测试视为一种调查。他们从假设开始，试图证明应用程序是错误的。
看看这种思维方式的区别。
标准测试检查的是“快乐路径”（happy path）：
- 进入产品页面。
- 加入购物车。
- 输入有效的卡片详情。
- 预期收到订单确认。
这种测试证明了在一切完美的情况下功能是正常的。它永远无法发现 Bug。
Bug 猎手的测试则充满怀疑：
- 输入一个带有拼写错误的卡号。
- 预期收到错误消息。
- 检查订单确认是否依然没有出现。
第二种测试假设应用程序会失败。它在问：“这里会在哪里崩溃？”
许多测试员存在的是经验上的差距，而不是简历上的空白。你见过因为数据错误或环境宕机导致的测试失败。但你还没见过因为你发现了逻辑缺陷而导致的测试失败。
停止为了新考试而学习。通过编写旨在“失败”的测试来弥补差距。
尝试这个练习： 挑选一个功能。花一个小时尝试去破坏它。
对于搜索功能：
- 测试乱码查询。
- 测试 SQL 注入字符。
- 测试空字符串。
对于文件上传：
- 测试没有扩展名的文件。
- 测试超大文件。
- 测试恶意文件名。
我曾经参与过一个测试覆盖率达到 95% 的支付系统。当时每个测试都通过了。然而，系统在生产环境中因为一个舍入误差 (rounding error) 导致了资金损失。我们的测试覆盖了常规路径 (happy path)，但没人想到去测试数学逻辑。
现在，我开始每一个测试时都会问一个问题：“要满足什么条件，这个功能才会发生静默失败 (fail silently)？”
不要去搭建作品集网站。不要去更新你的 LinkedIn。
写一个旨在失败的测试。如果它通过了，你就获得了一份安全保障。如果它失败了，你就发现了一个 Bug。
写下你测试了什么、你是如何测试的，以及你发现了什么。这才是证明你具备思考能力的真正证据。
这周你会写哪一个测试，来证明你能发现 Bug？
可选学习社区：https://t.me/GyaanSetuAi