无数据驱动自动化测试

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

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

下面分享一个案例，以某一个商品售卖接口以及相关接口组成的一条测试用例。这个接口购买某一个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测试框架：

Gitee地址https://gitee.com/fanapi/tester
GitHub地址https://github.com/JunManYuanLong/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 !。

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

虽不完美，足以表达我的思路！

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

无数据驱动自动化测试

接口测试视频

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

FunTester热文精选