故事经历如下：
5 月 11 日，澎湃新闻记者从上海市徐汇区人民法院获悉，近日，该院开庭审理了此案，徐某等五人因犯诈骗罪、传授犯罪方法罪被判处有期徒刑两年六个月至一年三个月不等，并处罚金。
徐某，1998 年生，是江苏某大学的在校生。2018 年 4 月，在利用肯德基客户端点餐过程中，徐某无意间发现两个 “生财小门道”。
第一个是在 APP 客户端用套餐兑换券下单，进入待支付状态后暂不支付，之后在微信客户端对兑换券进行退款操作，然后再将之前客户端的订单取消，这时候客户端上竟可以重新获取兑换券，此种方式分文未付骗取了一份兑换券。
第二个是先在 APP 客户端用套餐兑换券下单待支付，在微信客户端退掉兑换券，再在 APP 客户端用兑换券支付，这时便可以支付成功并获得取餐码，此种方式等于分文未付骗取了一份套餐。
看到这个新闻后，想到的是如何在工作中避免，所以来找各位问问~希望各位给予意见~~
这是面试题？
这个 BUG 主要还是业务逻辑漏洞，需要深入理解业务，就可以测试出来吧
感觉这个兑换券的状态记录有问题啊，下单待支付时，券的状态应该是锁定，这时候去退款，锁定中的券要么被拦截，要么就要先取消待支付的订单，再进行券的解锁，这里面应该是服务端的锅
感觉兑换券的状态和支付流程有问题。
下单处理时如果有使用兑换券，应该先校验券是否可用，可用才能继续下单。
下单成功后应该修改券的状态到已使用，修改前查询券状态是否为有效，然后加锁、该状态、释放锁
这不就是一个多端、多页面常犯的一个 bug 吗。一般交易支付类都会测试这种场景的啊
开发的锅
- 招聘一个脑子清楚的测试。
- 这些流程看起来也不复杂。如果一个 20 岁的人， 10 以内加减法都算不清楚，那还能怎么办？ 这不是普遍的问题，但赶上了也没辙。
- 和第三方协作，风险就是多
不谈论政治，只是感叹下一个大学生就这么没了
状态记录有问题，开发测试都有锅
为什么一定要想着写测试用例呢？
这种问题，应该做一个订单自动审计系统，每个订单到生产环节时，自动审计 物料成本 和 支付金额之间的差值，如果金额还不够物料成本 * 系数 ( 系数可以自定义)，就自动拦截订单，并告警；
然后测试端，把这个场景加进去，加到下订单的用例集里面去，后面所有上线的什么券，优惠，全部参考场景测试一遍，看看后台会不会生成异常拦截告警
汉学堂
回复
想探讨下，这个告警误报率会不会很高？
从逻辑上看，只要用了优惠程度大一点的券都会告警，有可能 100 个用优惠券的，实际只有 1 个钻空子，但你就得检查这 100 个告警是否有异常了。如果按照这个思路兜底，我理解更合适的方案是，审计的时候自动计算 总应付金额（基于订单表计算）是否等于 总实付金额（基于资金流水表）+ 使用的优惠券对应金额（基于优惠券使用记录表计算），这样应该会更准确？不过我觉得最简单的是，兑换券一人最多可拥有多少有个上限，直接查有没有人超过上限即可。
文中第一个场景没看懂，之后在微信客户端对兑换券进行退款操作，然后再将之前客户端的订单取消 ，退款的意思是退掉兑换券么？如果是，那兑换券退掉可以重新领取，还是符合一个用户最多拿一张兑换券的规则，看起来没啥问题。
第二个场景，就是兑换券已使用（待支付）时，没有限制住不给退了，订单支付时服务端也没有二次确认兑换券是否有效，属于很明显的业务逻辑漏洞。一般这类场景，业务逻辑应该是这个券被使用了（待支付）就会进入锁定或已使用状态，无法退掉。取消订单的时候，才会重新退回。
我觉得实时核对更合适吧