最近发了个帖子：《关于肯德基的新闻，这类 bug 该如何在测试中及时发现》这让我想起了一个测试工程师走进一家酒吧的故事！

...

一个测试工程师走进一家酒吧，要了一杯啤酒；

一个测试工程师走进一家酒吧，要了一杯咖啡；

一个测试工程师走进一家酒吧，要了 0.7 杯啤酒；

一个测试工程师走进一家酒吧，要了-1 杯啤酒；

一个测试工程师走进一家酒吧，要了 2^32 杯啤酒；

一个测试工程师走进一家酒吧，要了一杯洗脚水；

一个测试工程师走进一家酒吧，什么也没要；

一个测试工程师走进一家酒吧，要了一杯蜥蜴；

一个测试工程师走进一家酒吧，要了一份 asdfQwer@24dg!&*(@；

一个测试工程师走进一家酒吧，又走出去又从窗户进来又从后门出去从下水道钻进来；

一个测试工程师走进一家酒吧，又走出去又进来又出去又进来又出去，最后在外面把老板打了一顿；

一个测试工程师走进一家酒吧，要了一杯烫烫烫的锟斤拷；

一个测试工程师走进一家酒吧，要了 NaN 杯 Null；

一个测试工程师冲进一家酒吧，要了 500T 啤酒咖啡洗脚水野猫狼牙棒奶茶；

一个测试工程师把酒吧拆了；

一个测试工程师化装成老板走进一家酒吧，要了 500 杯啤酒并且不付钱；

一万个测试工程师在酒吧门外呼啸而过；

一个测试工程师走进一家酒吧，要了一杯啤酒';DROP TABLE 酒吧；

测试工程师们满意地离开了酒吧。然后一名顾客点了一份炒饭，酒吧炸了

...

是不是以后，就有一个测试工程师走进一家肯德基的故事了？但是，仔细看了这个帖子，发现不是那么回事？

「故事经历如下：」

5 月 11 日，澎湃新闻记者从上海市徐汇区人民法院获悉，近日，该院开庭审理了此案，徐某等五人因犯诈骗罪、传授犯罪方法罪被判处有期徒刑两年六个月至一年三个月不等，并处罚金。

徐某，1998 年生，是江苏某大学的在校生。2018 年 4 月，在利用肯德基客户端点餐过程中，徐某无意间发现两个“生财小门道”。

第一个是在 APP 客户端用套餐兑换券下单，进入待支付状态后暂不支付，之后在微信客户端对兑换券进行退款操作，然后再将之前客户端的订单取消，这时候客户端上竟可以重新获取兑换券，此种方式分文未付骗取了一份兑换券

第二个是先在 APP 客户端用套餐兑换券下单待支付，在微信客户端退掉兑换券，再在 APP 客户端用兑换券支付，这时便可以支付成功并获得取餐码，此种方式等于分文未付骗取了一份套餐。看到这个新闻后，想到的是如何在工作中避免，所以来找各位问问~希望各位给予意见!

很显然，这个没有进酒吧那么简单了，有人回答是：

「状态机」，「乐观锁」，「多线程」，嗯，从实现层面来看，抽取出来其实就这些东西。其实测试方式也很简单了。

按问题描述的步骤，就能测出该问题了。大部分同学把这个问题归咎于测试用例设计不全或者是漏测。也有同学提出了告警和监控，那又是另外一个层面的事情了。

为什么一定要想着写测试用例呢？这种问题，应该做一个订单自动审计系统，每个订单到生产环节时，自动审计 物料成本 和 支付金额之间的差值

如果金额还不够物料成本 * 系数 ( 系数可以自定义)，就自动拦截订单，并告警；然后测试端，把这个场景加进去，加到下订单的用例集里面去，后面所有上线的什么券，优惠，全部参考场景测试一遍，看看后台会不会生成异常拦截告警 From 汉学堂

对此，也有同学提出了疑问，认为噪音会很大，去噪是线上监控亘古不变的主题。

总结：其实，这个问题真的不难解，我只是比较好奇，肯德基是不是没有测试，也没有对账？

居然过了那么久才发现这个问题。另外也提醒下大家，不要利用 bug 谋利作恶，手勿伸，伸必抓！

-------- THE END --------

🍁