在自动化测试中，经常会听到一个词数据驱动，大意是讲通过测试数据驱动自动化用例的执行。其他相关的内容相信已经耳熟能详了，这里不多说，今天给大家分享一个次叫做无数据驱动，主要思路就是尽量取消在测试用例中的数据引入，把主要的测试数据的维护放在自动化测试用例以外，节省成本的同时提高用例的健壮性。
无数据驱动自动化测试的目标就是，通过测试用例最小量的数据引入，编写无限运行的测试用例，以降低维护工作量。
下面分享一个案例，以某一个商品售卖接口以及相关接口组成的一条测试用例。这个接口购买某一个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/testerGitHub地址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测试框架视频讲解（序）
- 获取HTTP请求对象--测试框架视频讲解
- 发送请求和解析响应—测试框架视频解读
- json对象基本操作--视频讲解
- GET请求实践--测试框架视频讲解
- POST请求实践--视频演示
- 如何处理header和cookie--视频演示
- FunRequest类功能--视频演示
- 接口测试业务验证--视频演示
- 自动化测试项目基础--视频讲解
- JSONArray基本操作--视频演示
- 自动化项目基类实践--视频演示
- 模块类和自动化用例实践--视频演示
- 性能框架多线程基类和执行类--视频讲解
- 定时和定量压测模式实现--视频讲解
- 基于HTTP请求的多线程实现类--视频讲解
