“测试最终是测试错误为了证明程序无错误”——这句话我第一次听到是在一次内部评审会上，一个刚入行半年的最终测试工程师说的。当时会议室安静了两秒，为证然后有人笑了。明程不是序无嘲笑，是测试错误那种“你认真的吗”的笑。他一脸茫然，最终显然没明白问题出在哪。为证

问题在于，明程这句话把测试的序无目的彻底搞反了。测试从来不是测试错误为了证明程序没有错误，恰恰相反，最终测试是为证为了发现程序中存在的错误。这不是明程文字游戏，是序无两种完全不同的思维方式。

我见过一个真实的例子。某支付系统上线前，测试团队写了两千多条用例，全部通过。报告上写着“未发现严重缺陷”。项目经理很高兴，觉得质量有保障。结果上线第三天，一个用户在用特定银行的卡支付时，金额被扣了两次。查下来发现，测试环境里根本没有接入那家银行的沙箱，所有相关用例都是mock数据，走的是理想路径。两千条用例通过，证明不了任何东西，只是证明了那两千条路径恰好没踩到雷。

如果你抱着“证明程序无错误”的心态去测试，你会不自觉地选择那些容易通过的用例，会倾向于验证已知正确的逻辑，会因为“跑通了”而松一口气。这种心态下写出来的测试用例，本质上是在给程序做背书，而不是在找茬。找茬需要一种近乎偏执的怀疑：这段代码在边界条件下会怎样？网络延迟三秒会怎样？用户连续点击十次会怎样？数据库连接池满了会怎样？

有个做嵌入式开发的朋友跟我聊过。他们团队有个规矩：每个模块的测试负责人，必须尝试“搞垮”这个模块。不是跑通就行，是要想办法让它崩溃、让它输出错误结果、让它死锁。有一次，一个同事花了整整两天，就为了构造一个特定的时序，让两个线程在某个极小的时间窗口内同时访问同一块内存。最后他成功了，系统蓝屏。开发人员一开始很恼火，觉得这是在浪费时间。但那个bug如果流到现场，维修成本是六位数起步。

测试的本质是证伪，不是证实。波普尔讲科学哲学的时候说过，一个理论不能被证实，只能被证伪。测试也一样。你跑一万条用例通过，不能证明程序没有bug；但只要有一条用例失败，就能证明程序有bug。所以测试的价值在于那一条失败的用例，而不是那一万条通过的。

当然，有人会说：那测试报告里写“未发现缺陷”不就行了？问题是，很多团队把“未发现缺陷”等同于“没有缺陷”，然后把测试当作质量保证的终点。这就危险了。测试报告应该写的是“在本次测试覆盖范围内，未发现缺陷”，而不是“程序无错误”。前者是事实，后者是幻觉。

我自己的习惯是，每次测试结束，不写“通过”，写“本次未发现新问题，但以下区域覆盖不足”。这不是给自己留后路，是提醒所有人：测试的终点不是证明正确，而是暴露未知。你永远不知道下一个用户会怎么用你的程序，你只能尽量让自己在测试阶段多发现一个是一个。

所以回到开头那句话。如果哪个测试工程师跟我说“测试是为了证明程序无错误”，我会建议他换个岗位。因为他的心态已经不适合做测试了。测试需要的是怀疑、是破坏、是不信任。你越不相信程序是对的，你越有可能发现它哪里不对。而“证明无错误”这个念头，会让你在第一个通过的用例面前就停下来。

(责任编辑：热点)