【探索篇】测试人员遗漏的Case点,我猜你也中枪了

记得当初上测试课程时，老师就讲到头脑风暴，让我们尽情发挥:想象，讲的就是不局限思维、发散、开拓思维，可能发生的情况都可作为输入条件，实际我们运用到工作中，测试用例的设计是一样的道理，不能局限正思维、逆思维，要全方位思维去想象和思考，总结，从而得到最终结论，我不是测试大神，但有个对测试炽热的心，在不断工作中，经常思考想象并反问自己，不断总结方法和经验，扩大测试覆盖范围面，你们也是和我一样吗？下面我列举几个案例，可能是我们测试工作中经常忽略的测试用例点。

案例一：用户淘宝网下单，进行订单付款

用例1：新创建的订单，是否可进行多次付款？

用例2：已付款的订单，是否可再次付款？

用例3：已发货、已收货、已完成、已退款订单、已评价订单等，是否可进行付款？

用例4：不存在的订单是否可付款？

案例二：APP中提现金额到银行卡

用例1：未实名认证，是否可提现？

用例2：未绑定银行卡，是否可提现？

用例3：绑定了错误的银行卡，是否可提现？

用例4：未登录，是否可提现？

从用例1 2 3 4可看出，应该很多人都不会去这样设计测试用例,你们觉得需要这样去设计测试用例吗？

案例三、未来状态/不存在的关联传参

用例1：如果status有1：招聘 2：非招聘

考虑0和3测试，程序如何处理的？是否会=<1统一处理成招聘,>=2统一处理成非招聘，如果这样处理了，下个版本如果加了status 3：急招，新版本后端先上线，app审核阶段，0会显示招聘，3会显示非招聘，这样是错误的，所以当时就应该非1和2，统一处理为不存在的状态

案例四：系统有客服和主管权限，客服和主管权限各不相同

用例1：客服是否可操作主管权限？

用例2：主管是否可操作客服权限？

案例五：列表类页面展示

用例1：假设列表字段为0、空、null值、超长、超大，测试异常、报错、溢出，列表是否正常展示

案例六：从商品列表，进入商品详情页

用例1：商品列表数据还未拿到时，进入了商品详情，商品详情页是否正常？

案例七：APP账号登录

用例1：登录失败，是否正常处理？

用例2:登录超时，是否正常处理？

从以上案例的用例中可以看出，我们很多时候都不会去这样设计，大多给出的理由都是，根本就没有入口、根本不会发生、没必要的，但我们有没有认证思考想一下，我们如果不这样去设计用例，后端代码逻辑到底能覆盖全吗？我们有没有注意到，线上经常发生的很多问题都是这些情况造成的？