我们从一个最简单的登录例子开始。
最开始我们需要验证在用户名和密码都正确的情况下，能够正常登录系统，我们这样编写测试代码（以下都是伪代码，使用TestNG和Selenium）：
@Test
def should_login_success_with_exist_username_and_correct_password(){
LoginPage page = user.open(LoginPage,"/login.html")
user.perform("login",['user1','1234'],on(page))
assert page.successLogin
}
恩，很不错，运行一下，出现红条。为什么呢？原来测试数据库里没有用户名为user1的用户，好吧，写个数据库数据初始化脚本。再运行，OK，绿条！
那么，接下来我们再增加一个测试，需要覆盖密码错误时不能登录系统的情况，很快测试就完成了：
@Test
def should_login_success_with_exist_username_and_incorrect_password(){
LoginPage page = user.open(LoginPage,"/login.html")
user.perform("login",['user1','4321'],on(page))
assert page.successLogin,false
}
再运行一下测试，绿条。好啦，现在可以看下这段代码，恩，有些重复，重构一下：
@Test
def should_login_success_with_exist_username_and_correct_password(){
assert login('user1','1234')
}
@Test
def should_login_success_with_exist_username_and_incorrect_password(){
assert login('user1','4321'),false
}
def login(username,password){
LoginPage page = user.open(LoginPage,"/login.html")
user.perform("login",[username,password],on(page))
return page.successLogin
}
重构完成，可以看到，我们的测试方法里现在没有了任何行为，仅仅是数据！这样让我感觉有点怪，不管了，先用TestNG提供的@dataProvider整理一下：
@Test(dataProvider="testdata")
def testLogin(username,password,expected){
LoginPage page = user.open(LoginPage,"/login.html")
user.perform("login",[username,password],on(page))
assert page.successLogin,expected
}
@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[]
}
测试方法只剩下了一个！如果要测试不存在的用户不能登录系统呢？很简单，增加数据即可！
@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的数据也可以啊，心情愉悦的改下：
@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测试）
通过环境准备测试数据（非测试用例自己准备数据）
可能存在的问题：
比一般的测试编写困难，特别是在静态语言里
最后：该文章的思考来自于徐昊在团队内部的相应Session.
http://www.blogjava.net/ronghao 荣浩原创，转载请注明出处：）
posted on 2010-01-17 12:08
ronghao 阅读(2562)
评论(0) 编辑 收藏 所属分类:
工作日志