在自动化测试中,经常会听到一个词数据驱动,大意是讲通过测试数据驱动自动化用例的执行。其他相关的内容相信已经耳熟能详了,这里不多说,今天给大家分享一个次叫做无数据驱动,主要思路就是尽量取消在测试用例中的数据引入,把主要的测试数据的维护放在自动化测试用例以外,节省成本的同时提高用例的健壮性。
无数据驱动自动化测试的目标就是,通过测试用例最小量的数据引入,编写无限运行的测试用例,以降低维护工作量。
下面分享一个案例,以某一个商品售卖接口以及相关接口组成的一条测试用例。这个接口购买某一个header的接口,主要参数gid, pid,在这个用例里面写死了,具体多少我忘记了,三年前的代码了,翻出来已经很不容易。主要业务逻辑非常简单,购买成功(有效期30天,自然天),然后属性中增加响应的值,余额减少响应的值,顺便对于购买这会额外赠送另外一个header的七天有效期。
/**
* 购买月卡用例
*/
public void testDemo001() {
String label = "购买月卡用例" + TAB + Thread.currentThread().getStackTrace()[1];
Headgear headgear = new Headgear(base);
Long aLong = headgear.getHeadgearInfo().get(27);
int balance = NajmBase.getUserBalance(drive.user_id);
long deadTime = drive.getDeadTime();
Verify verify = new Verify(drive.bugMonthCard(gid, pid));
int balance1 = NajmBase.getUserBalance(drive.user_id);
long deadTime1 = drive.getDeadTime();
Long aLong1 = headgear.getHeadgearInfo().get(27);
JSONObject result = new JSONObject();
result.put("状态码为0", verify.isRight());
result.put("用户金额减少", balance - balance1 == 2000);
result.put("用户月卡有效期增加", deadTime1 - deadTime == 30 * DAY);
result.put("用户赠送头套正常", aLong1 - aLong == 7 * DAY);
MySqlTest.saveTestResult(label, result);
}
关于为什么测试用长成这个样子,有兴趣的欢迎关注FunTester测试框架:
末尾我会放上FunTester测试框架的视频讲解,视频做得时间有点早,有些新功能,特别是性能测试方面缺失的略微多了些。可以参考我之前写过性能测试的文章。
在上面的测试用例中,我首先新建了一个基于User的业务模块类Headgear对象,为了完成接下来的模块中的接口调用。还有基础类NajmBase中我写了一些静态方法,这里应该是要单独拿出来做一个单个项目的工具类,三年前前的代码了。然后这个driver对象,是该用例类的基础驱动对象,也是一个模块类的对象,用于完成改模块的接口调用,因为当前类就是该模块的用例类,所以做了一个公共的类static对象。
这里的用例方法逻辑比较容易懂:第一步先从用户个人headers信息中心获取到27号的截止时间,然后获取用户的账户余额,然后用户去购买指定id的header,然后保存响应对象,将响应转换成通用的验证对象verify,在获取用户余额,ID为27的header的截止日期。最后通过之前保存的对象和数据信息进行业务的判断。
当然所有的用例都需要进行setup和setdown,这个用例需要维护的数据有几项,下面分享一下我的处理方案。ID为gid, pid的header的确定存在,而且执行用例的用户必需保证初始化就是购买过且在有效期,相信这个不难做到。
ID为gid, pid的价格恒定在2000,且执行用例用户余额在购买之前要大于这个数,这个不难办到,在setup中能够办到。
ID为gid, pid的header有效期30天,赠送的headerID为27的基本属性也跟ID为gid, pid的header一样各项属性保持稳定。
保证随时跟进业务变更,这个也不难。
这里花费较多时间去设计维护比如gid, pid这样的参数所对应的信息,以及用户金额等。
后期可以把这些信息全都优化掉,不必设置固定的gid, pid不必验证有效期,可以从header信息的接口获取。这样gid, pid可以不需要,价格2000也是不需要,有效期30天和7天也是不需要的,赠送的ID为27的header也不一定需要(需要看业务接口提供不提供赠送规则)。
在实际运行中,几乎没有因为自动化用例的问题,基本做到了write once,run everywhere !。
几乎的那一次原因如下:
虽不完美,足以表达我的思路!
下面是测试框架的视频讲解:
接口测试视频
FunTester,非著名测试开发,文章记录学习和感悟,欢迎关注,交流成长。
FunTester热文精选