数据驱动测试

　　data[1]=['inexistuser','1234',false] as Object[]

　　}

　　@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[]

　　}

　　@DataProvider(name="testdata")

文章来源于领测软件测试网 https://www.ltesting.net/