听说拼多多因漏洞被薅了200亿？- 谈谈软件测试

昨天看到一个大新闻： 拼多多在20日凌晨出现漏洞，用户可以领100元无门槛优惠券 。一夜之间，被黑产、羊毛党和闻讯而来的吃瓜群众薅了个底朝天，直到第二天上午9点才将优惠券下架。网上传言这一波损失超过200亿，但拼多多官方很快回应： 漏洞确有此事，但损失没这么多，不到千万，已报警，正在追回 。

拼多多本来就是家争议颇大的公司，这次事件更是引发舆论热议。据说，这个优惠券本不能正常访问，而是有做黑产（利用互联网不正当牟利）的人 挖到了一个漏洞，使得能从某个二维码入口领取到这个券，并把这个券散发出去。你别以为这是想劫富济贫，他们只是想拉足够的炮灰垫背 ，同时自己迅速将这个券兑换成话费、Q币等，以此获利。这事情从法律角度来说算得上“ 不当得利 ”，就算涉事账面金额真的有200亿，大部分也是可以追回的。所以，没吃到瓜的群众别懊悔，反倒是真占了便宜的，得考虑考虑了。

话说回来，可能有人要问了，怎么黑产就能弄出一个不存在的优惠券？我不了解具体漏洞细节，但从目前的信息来看，这个券在系统里肯定确实存在，有可能是内部测试或者某些特定条件下可以领。然而 估计程序上并没有做更多的领取条件限制，只是隐藏了访问这个券的公开入口 。就好比是有人在银行的某个保险柜里放了一笔钱，但没有上锁，觉得别人不知道这里藏了钱就没事。后来有人发现了，就把保险柜的位置告诉了所有人，那么每个人都可以过来拿钱。

讲道理，我没上锁也不代表你就能随便拿。但从一个开发者的角度来看， 不做必要的权限验证、规则判断，以及特殊情况下的异常处理，仅仅通过隐藏公开入口来限制领取，这是极为低级的失误 。让人忍不住想吐槽：拼多多那么有钱，招来的 程序员 咋这么不专业？而且为什么凌晨爆发的问题，到上午9点才封上，下架个优惠券也这么难吗？

不过吐槽归吐槽，不可否认的是， 软件的 bug、缺陷、漏洞，这是永远不可能杜绝的 。被人们看到的漏洞往往很低级，但考虑到软件产品的复杂度，以及开发进度、需求变更等客观情况，漏洞也并不是想象中那么容易避免。就在半个月前，知名民宿平台 Airbnb 就爆出过类似的大 bug：当你支付房费的时候， 如果切换货币，价格并没有跟着变 。你可以拿2000越南盾支付原价2000欧元的民宿。在计算机史上，类似的问题数不胜数，举几个知名例子：

• 1994年，英特尔的奔腾CPU芯片被曝出缺陷： 会在精度要求很高的数学计算上出现问题 ，比如 (4195835/3145727)*3145727-4195835 这样的结果计算出来不为 0。最后英特尔为此付出 4 亿多美元更换芯片 。就在大约一年前，英特尔的另一个芯片漏洞也波及了市面上绝大多数的电脑、手机和云服务器，这个我去年有文章科普过： 关于这波IntelCPU漏洞，我见过最形象易懂的解释
• 1999年，美国航天局的 火星极地登陆器在着陆时失联 。后经调查认定，故障原因很可能是一个 决定关闭推进器的数据位设置逻辑有误 。
• 1991年海湾战争中，美国的 爱国者导弹防御系统失效 ，未能成功拦截导弹致 28名美军士兵被炸死 。原因经分析后，是因为 系统时钟数据精度不够 ，存在微小误差，长时间运行后误差积累放大，在拦截过程中可能引起数百米的偏差。
• 千年虫问题 ：上世纪早期的软件开发者为了节省空间， 使用两位数记录年份 。然而到2000年时，一些软件仍在使用，使得99年之后变成00年，引发异常。有人估计全球为此花费的相关费用有 数亿美元 。

由此看来，程序员还真是一个高危职业，一不小心就可能造成巨大损失。 如果你没有生产过严重的 bug，可能是你运气真的好，但更可能是你代码写得还不够多。 对此我自己也是不少血泪教训。那面对难以避免的 bug，开发者应该怎么办呢？我的建议：

1、重视软件测试

正因为漏洞的普遍存在，以及可能带来的潜在损失，所以软件测试是即为必要的。除了需要有专门的测试人员把关，每个合格的开发者也应该是一个合格的测试者，正如有句话说的： 一个优秀的程序员就是那种即使是过单行道都要往两边看的人 （Doug Linder）。对于自己写出的代码，你自己是最了解的人。在开发早期就做好 单元测试 ，可以大大提升程序的稳定性，降低后期测试的成本。当你写的每个函数都通过单元测试，成为一个功能模块时，再进行 集成测试 ；最后对整个完成的产品进行 系统测试 。

企业更是应当重视软件测试的必要性，如果只追求功能快速迭代，拼命赶进度，最后有可能得不偿失。因为 bug 或操作失误导致企业破产的例子也不鲜见。

测试的方式一般分为 黑盒测试 和 白盒测试 。上面说的开发者自测一般是白盒测试，即你对代码的实现逻辑是已知的。白盒测试在选取测试用例时，讲究对 代码逻辑的覆盖 ，即你选用的测试数据要能保证让每一行代码每一个条件都被执行到，尤其是一些 边界条件 。而黑盒测试是指不考虑代码逻辑，仅关注程序的功能和输入输出。软件发布测试版让用户使用，就属于一种黑盒测试。在黑盒测试时，讲究对 等价类的覆盖 ，通俗地讲就是覆盖到所有可能发生的情况，包括正常的和不正常的，同样要注意边界。

我们 码上行动 有个期中项目，就是对教程中“猜数字”游戏的扩展，增加多次游戏的功能。看似简单的功能，实现起来不难，但几乎大部分同学提交的代码都会存在一定的缺陷。这就是由于编程新手缺乏测试的意识和方法，一般只会按照自己的设想输入，发现结果对了就认为大功告成。其实不然，你得考虑用户如果猜的数字超过范围怎么办？输入了小数怎么办？输入空白怎么办？输入了字符怎么办？……

那测试做到什么程度才到位？我觉得知乎上有人分享的一个笑话很到位：

更多关于测试的知识，欢迎大家找本《 软件测试 》相关书籍看一看，这个真的很有必要。

2、相信墨菲定律

墨菲定律：如果你担心某种情况发生，那么它就更有可能发生。

测试做得再好，也只能是减小 bug 的概率。作为一个开发者，你还是要认清现实，做好最坏的打算。

• 如果你要上线新功能，那很可能导致宕机
• 如果你要更新数据库，那很可能会丢失数据
• 如果你没有检查备份，那很可能它就恢复不了
• 如果你搞一个促销活动，那很可能会被羊毛党撸死
• 如果系统出现了漏洞，那很可能是在半夜
• ……

但真当你意识到这些绝望的时候，反倒可以提前做好应急预案，将损失限制在最小。如果拼多多在设置出100元无门槛券的时候就相当虎视眈眈的黑产羊毛党，可能事情就不会这样。不过也许现在就是他们的应急预案也说不定呢：控制损失的同时还赚了一大波曝光。世事难料啊！

换个角度，能造成巨大损失也是一种幸运。相比之下，你的产品挂了两天都没人发现，域名过期了都没人跟你抢，那才叫悲惨。所以最后， 希望各位有朝一日都能参与影响巨大的项目 ，但要有安全意识，千万别捅出大篓子

════