经典BUG--001，《阴阳师》业原火BUG
BUG描述：
玩家可以不断刷副本来获得业原火副本的奖励（业原火奖励丰厚，但是需要限定门票）。
事故原因：
①对于现在的副本战斗，客户端会发起一个战斗请求，同时服务端记录相应的奖励返回给客户端，然后客户端在本地进行战斗计算；
②在战斗结束后，客户端会发起一个战斗结算请求，其中带有胜利或者失败标记，还有之前请求战斗时返回的奖励 id；
③由于八岐大蛇和业原火共用一个接口，只会在 type 上进行区分，且这两个副本的消耗机制不一样，八岐大蛇消耗体力，业原火消耗门票。由于业原火在失败等异常情况下不扣除门票，所以御魂副本在战斗开始的时候扣除体力，业原火在战斗结束的时候扣除门票；
④在客户端发送结算时候，需要判断是御魂副本还是业原火，根据 type，如果是御魂副本就跳过扣除，因为在战斗开始就已经扣过；如果是业原火就会扣除门票，同时发送奖励；
⑤客户端第一次发送业原火的战斗请求过来，所以服务端这里没有扣除门票，同时记录了相应的奖励发送给客户端，客户端同时快速切换到御魂界面，导致战斗进入到了御魂的战斗。在结算的时候，发送的是御魂的副本类型和业原火的奖励 id，所以服务端把此次战斗当成了御魂副本，所以没有扣除体力，同时发送了奖励；
⑥对于服务端来说，相信了客户端的协议，没有进一步的验证请求的合法性，导致了奖励的发放没有扣除相应的货币。
一句话总结就是：战斗开始时发送业原火的战斗 id 给服务端，服务端说，这个是业原火，等下战斗结束再扣门票；战斗结束时发送御魂的战斗 id 和业原火的奖励 id 给服务端，服务端说，这个是御魂副本，开始已经扣过体力了，不用再扣了，直接发奖励吧
测试总结：
这类问题很难在测试过程中被发现，需要测试人有很深的经验和复杂的操作。但是如果大家从协议测试考虑，就会相对简单很多。这个问题中御魂副本和业原火共用了次协议：dungeon_rune_attack(dungeon_id) ，当dungeon_id=1 时表示御魂 1 层，当 dungeon_id=13 时表示业原火的痴副本。在战斗开始的时候，发送 dungeon_id=13 告诉服务端打的是业原火痴副本；在战斗结束的时候，将其改成 dungeon_id=1 告诉服务端打的是御魂副本，服务端充分信任了客户端发来的协议，没有做二次验证就直接发奖，导致被刷。
经典BUG--002，《重返未来1999》实名认证BUG
BUG描述：
身份证最后一位是x的玩家，没法输入，导致无法实名认证。截至2020年3月，身份证号码最后一位是x的，全国人民总比的9%左右人口。如果是这个比例的用户量的话，这个BUG的影响还是挺严重的。事故原因：
1、漏测，测试的时候只考虑身份证是数字的情况，没有考虑还有字母要输入。当时看评论的时候，我也才发现原来身份证是有字母的情况。
2、手机输入法兼容，测试的时候没有兼容到足够的手机和输入法（这个也是不太可能完全兼容到的），兼容对测试来说，算是一个疑难杂症了，目前市面上的手机品牌+型号最少都有上千种了，每次玩家反馈回来一个问题，内部环境又复现不了，就很麻烦。
测试总结：
首先这类功能就是要覆盖足够全，做好用例评审。其次市面上主流机型的兼容一定是要做的，特别是很火，预下载很高的产品。最后也可以通过合理的设计，尽可能减少兼容性的问题。
