无数据驱动自动化测试

在自动化测试中,经常会听到一个词数据驱动,大意是讲通过测试数据驱动自动化用例的执行。其他相关的内容相信已经耳熟能详了,这里不多说,今天给大家分享一个次叫做无数据驱动,主要思路就是尽量取消在测试用例中的数据引入,把主要的测试数据的维护放在自动化测试用例以外,节省成本的同时提高用例的健壮性。

无数据驱动自动化测试的目标就是,通过测试用例最小量的数据引入,编写无限运行的测试用例,以降低维护工作量。

下面分享一个案例,以某一个商品售卖接口以及相关接口组成的一条测试用例。这个接口购买某一个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号的截止时间,然后获取用户的账户余额,然后用户去购买指定idheader,然后保存响应对象,将响应转换成通用的验证对象verify,在获取用户余额,ID为27header的截止日期。最后通过之前保存的对象和数据信息进行业务的判断。

当然所有的用例都需要进行setupsetdown,这个用例需要维护的数据有几项,下面分享一下我的处理方案。

  • ID为gid, pidheader的确定存在,而且执行用例的用户必需保证初始化就是购买过且在有效期,相信这个不难做到。
  • ID为gid, pid的价格恒定在2000,且执行用例用户余额在购买之前要大于这个数,这个不难办到,在setup中能够办到。
  • ID为gid, pidheader有效期30天,赠送的headerID为27的基本属性也跟ID为gid, pidheader一样各项属性保持稳定。
  • 保证随时跟进业务变更,这个也不难。

这里花费较多时间去设计维护比如gid, pid这样的参数所对应的信息,以及用户金额等。

后期可以把这些信息全都优化掉,不必设置固定的gid, pid不必验证有效期,可以从header信息的接口获取。这样gid, pid可以不需要,价格2000也是不需要,有效期30天和7天也是不需要的,赠送的ID为27header也不一定需要(需要看业务接口提供不提供赠送规则)。

在实际运行中,几乎没有因为自动化用例的问题,基本做到了write once,run everywhere !

几乎的那一次原因如下:连开100年会员会怎样,由此引起的用例执行预警方便调整以后再讲。

虽不完美,足以表达我的思路!

下面是测试框架的视频讲解:

接口测试视频


FunTester,非著名测试开发,文章记录学习和感悟,欢迎关注,交流成长。

FunTester热文精选