测试方法只剩下了一个！如果要测试不存在的用户不能登录系统呢？很简单，增加数据即可！
Java代码：
| @DataProvider(name="testdata") def Object[][] dataForLogin(){ def data=new Object[2][] data[0]=['user1','1234',true] as Object[] data[1]=['user1','4321',false] as Object[] data[1]=['inexistuser','1234',false] as Object[] } |
在我们的测试方法里，测试数据和测试的行为进行了完全的分离。从系统的功能来说，功能一旦实现，那么就是一个黑盒，我们只要提供数据即可进行测试，这个数据包括两部分：输入和期待的输出。我开始暗自嘀咕：难道我以前那么多的洋洋得意测试方法很多都是不需要的吗？这些方式为什么会存在呢？恩，想起来了，这些方法是为了覆盖功能的各个路径的，是提高测试覆盖率的。那么为什么会产生这么多的测试方法呢？哦，在这些测试方法里，测试数据和测试行为是耦合在一起的！
我伸了个懒腰，突然想，这下好了，我已经封装好了功能行为，QA想增加测试用例只需要自己增加数据就可以了，嘿嘿，爽啊。说曹操，QA到。QA mm说，你的某个功能实现有问题。我瞅了一眼，说，不可能啊（这是dev面对bug的第一反应），俺有测试的，持续集成一直是绿条的。QA mm说，在你的开发环境下测试是没有问题的，但是在QA环境，因为数据库变了，数据变了，应用服务器变了，所以会有些问题。我极不情愿的登录到QA环境，一测试，还真是，郁闷。
怎么办？修复完BUG，第一反应就是自动化测试能不能跑在QA环境呢？一般情况下，这些测试需要干净的测试环境，我们会制造很多的测试数据，可是在QA环境下，QA有她自己的测试数据，这些数据都不存在了哈。恩，看看刚才的测试代码，哈，就用QA的数据也可以啊，心情愉悦的改下：
Java代码：
| @DataProvider(name="testdata") def Object[][] dataForLogin(){ def data=new Object[2][] data[0]=['hrong','1234',true] as Object[] data[1]=['hrong','4321',false] as Object[] data[1]=['rhao','1234',false] as Object[] } |
OK，完成！为了该测试既能在开发测试环境运行又能在QA环境下运行，我们可以引入一个环境变量，将测试数据扔到文件里，通过环境变量来加载不同的测试数据（测试文件）。
好吧，喝点东西（甲流很厉害，喝板蓝根好了），总结一下：
数据驱动测试：测试数据与测试行为分离，通过数据来驱动测试。
好处：在对测试行为封装好的情况下，QA mm能够自己通过数据修改自动化测试；
自动化测试能够运行在多个环境下（开发环境、QA环境、产品环境）；
测试的可读性；
测试方法大量压缩。
适用范围：功能测试（selenium测试）
通过环境准备测试数据（非测试用例自己准备数据）
可能存在的问题：比一般的测试编写困难，特别是在静态语言里。
