测试思想-测试设计 关于测试用例设计的一点感想

直接上例子,如下,要测的是一个卡券验证功能:

描述:打开二维码扫描卡券,可对卡券进行验证。支持的卡券分三种,会员主卡,折扣券,代金券,点击手动输入按钮(不知为何,拍照时显示成那熊样了),弹出如下界面

描述:输入编号,点击“优惠券”,“会员卡”图标,可对输入的卡券(会员主卡,代金券,折扣券)编号验证,另外,如果输入是手机号,则对手机号关联会员的会员主卡进行验证

如果不考虑逆向用例,考虑正向用例,你会咋样设计用例?是否如下:

扫码验证会员主卡

扫码验证折扣券

扫码验证代金券

手动输入会员主卡编号,优惠券验证

手动输入会员主卡编号,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语句来分析界面数据是怎么展示出来的,数据取值是否正确。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券