直接上例子，如下，要测的是一个卡券验证功能：
描述：打开二维码扫描卡券，可对卡券进行验证。支持的卡券分三种，会员主卡，折扣券，代金券，点击手动输入按钮(不知为何，拍照时显示成那熊样了)，弹出如下界面
描述：输入编号，点击“优惠券”，“会员卡”图标，可对输入的卡券(会员主卡，代金券，折扣券)编号验证，另外，如果输入是手机号，则对手机号关联会员的会员主卡进行验证
如果不考虑逆向用例，考虑正向用例，你会咋样设计用例？是否如下：
扫码验证会员主卡
扫码验证折扣券
扫码验证代金券
手动输入会员主卡编号，优惠券验证
手动输入会员主卡编号，VIP验证
手动输入手机号，VIP验证
……
这样设计用例带来的结果是啥呢？用例数比较多，进而花费的测试时间也跟着变长，如果再加上一些条件(本例子中还有个条件：是否携带“不可优惠金额”，验证结果会受到其影响)，那就更多了，咋办呢？
实践中，我是这么做的，先不着急写用例，写操作，操作时用fiddler等工具，抓取发送的请求接口，进行观察，结果发现：
1、相同前提下，扫码或者是手动输入编号，调用的都是同一接口，扫码主要是读取卡券编号
2、相同前提下，手动输入卡券编号验证，点击 “优惠券”，“会员卡”图标，调用的也是同一个接口
调用接口
接下来就简单多了，对“扫码”进行详细的用例设计，然后针对手动输入编号，分是否输入手机号，如果是手机号，接口实现中必须根据传入的手机号查找对应会员的会员主卡，并进行校验；如果是非手机号，确保正确调用了接口即可。
综上，我们在测试用例不能仅停留在用例设计原理上，很多时候还应该从实现角度来进行设计分析，减少不必要的时间投入，特别是逻辑复杂的情况，通常我们可以做如下事情：
1、分析调用的接口请求
查看不同(相似)入口，发起的请求调用是否一样
2、分析代码实现
常查看代码逻辑，查看影响用例设计的因素之间的制约关系，举例如下
if 条件1 == 真:
do something
else if 条件2 == 真:
do something
if 条件1 == 真:
do something
if 条件2 == 真:
do something
如上，不同的代码实现，影响用例设计的条件1和条件2之间的关系是不一样的，对应的，用例设计也就不一样了。
3、查看调用的实现相关的sql语句
有时候，我们也可以通过日志获取开发代码调用的sql语句，作为用例设计中结果校验的手段。通过sql语句来分析界面数据是怎么展示出来的，数据取值是否正确。
