数据驱动在QTP的运用
所谓数据驱动就是用一个数据文件把测试脚本驱动起来，来达到更接近用户化更智能的测试．其目的是把测试人员从维护复杂的脚本程序中解放出来，只需维护好数据文件即可，减少了很多修改脚本的麻烦．下面讲一下通过四种途径来达到数据驱动．１．datatable
QTP本身程序就给我们提供了这么一个数据表，我们可以把测试数据或测试用例填入这个数据表中．
如：设计用例
username passwd
case1 mercury mercury
case2 xxxxxxx xxxxxx
录制脚本
For i=1 to Datatable.GetRowCount
Dialog("Login").WinEdit("Agent Name:").Set DataTable("username", dtGlobalSheet)
Dialog("Login").WinEdit("Password:").Set DataTable("passwd", dtGlobalSheet)
Dialog("Login").WinButton("OK").Click
datatable.GlobalSheet.SetNextRow
Next
本例是验证一个登录系统，通过DataTable不同的用例设计，驱动起这段脚本，达到测试的效果．当然上面的例子中还少一个很重要的步骤，那就是结果比较．如果不能进行结果比较的自动化测试不能够称为自动化测试．
当然我们这里主要讲的是数据驱动，所以不在对上面的例子进行补充．
２．文本文件
我们可以把文本文件当成数据文件，通过对文本文件的读写操作，来实现数据驱动．
例：文本文件内的内容
mercury,mercuy
读文件的代码
Function writeorderno(orderno)
Dim fso, myfile,username,passwd
Set fso=CreateObject("scrīpting.FileSystemObject")
Set myfile=fso.openTextFile("C: esting.txt",1,false)
tmp=split(myfile.readline,",")
username=tmp(0)
passwd=tmp(1)
myfile.close
End Function
写文本文件的代码
Function writeorderno(orderno)
Dim fso, myfile
Set fso=CreateObject("scrīpting.FileSystemObject")
Set myfile=fso.openTextFile("C:
esult1.txt",8,false)
myfile.writeline orderno
myfile.close
End Function
3.EXCEL文件
我们可以把EXCEL文件当成数据文件，通过对EXCEL文件的读写操作，来实现数据驱动．
可以把EXCEL文件当作对象的方式来完成写的操作
Dim Excel,ExcelSheet
Set Excel=CreateObject("Excel.Application")
Set ExcelSheet=CreateObject("Excel.Sheet")
ExcelSheet.Application.visible=true
ExcelSheet.ActiveSheet.Cells(1,1).value=１
ExcelSheet.ActiveSheet.Cells(1,2).value=２
ExcelSheet.ActiveSheet.Cells(1,3).value=３
Excel.Save "C: est.xls"
Set ExcelSheet=Nothing
用ADO的方式连接EXCEL文件来做读的操作
Dim conn,input,filename
filename="D:公基本情况(tb_gsgk)-标准格式.xls" '
Set conn= createobject("ADODB.Connection")
conn.Open "Provider=Microsoft.Jet.OLEDB.4.0; Persist Security Info=False;Data Source="&filename&";Extended Properties='Excel 8.0;hdr=yes'"
Set input= createobject("ADODB.Recordset")
input.Open "select * from [公基本情况-标准格式$] " ,conn,2,2
input.close
Set input=nothing
4.数据库
可以利用设计数据表，把测试数据和测试用例放在数据表里，用ADO或者其他任何可以访问连接数据库的方式连接数据库，来实现数据驱动
Dim res,cmd,sql
Set Res=createobject("adodb.recordset")
Set Cmd=createobject("adodb.command")
Cmd.activec ‘连接数据库数据源，需要修改
Cmd.CommandType = 1
sql="selec t * from 表 where name=username"
Cmd.CommandText = sql
Set res = Cmd.Execute()
Set res = nothing
Set cmd.ActiveConnection = nothing
Set Cmd= nothing
以上四种方法都可以帮助我们实现数据驱动，应该说数据驱动在自动化测试中运用的比较的广泛，才有必要拿出来探讨一下．
利用SQL connection访问
Dim conn
set conn=Createobject("ADODB.Connection")
Dim Srvname
Srvname="DSN=Dblis50;UID=sa; PWD=;APP=QuickTest Professional;WSID=ADMIN;DATABASE=Dblis50" ‘连接数据库数据源，需要修改
conn.connectionstring = Srvname
conn.Open
Dim Rec
Set Rec = CreateObject("ADODB.Recordset")
Dim SQL
SQL="select top 1 *from Lis_List"
Rec.open SQL ,conn
Dim Username
Username=Rec.fields("PatName")
Msgbox Username
利用SQL connection访问
Dim conn,res,cmd,sql,strconn
set conn=Createobject("adodb.connection")
Set Res=createobject("adodb.recordset")
Set Cmd=createobject("adodb.command")
strconn="DSN=Dblis50;UID=sa; PWD=;APP=QuickTest Professional;WSID=ADMIN;DATABASE=Dblis50" ‘连接数据库数据源，需要修改
conn.connectionstring = strconn
conn.Open
Cmd.Activeconnection= conn
Cmd.CommandType = 1
sql="select top 2 * from Lis_List"
Cmd.CommandText = sql
Set res = Cmd.Execute()
Dim Username
Username=res.fields("PatName")
Msgbox Username
Set res = nothing
Set cmd.ActiveConnection = nothing
Set Cmd= nothing
[ 本帖最后由 phillipschen 于 2008-5-4 17:18 编辑 ] 大家不要被一些所谓的概念混淆，自己用着最方便就是最好的东西。
别把1+1也说得冠冕堂皇，应用的工具而已，扯得太远了就丢弃了本质的东西，到头来1+1都不知道得几。
不是谁的理论听起来有道理或者内容丰富就一定是对的，就算全对了，你能牢记住吗，看过就忘了吧？
数据驱动中的 driven 一词，你可以简单的理解成导向，导向什么？结果。就是测试数据决定了测试结果，这就是所谓数据驱动，QTP实现了数据驱动的功能，模型，feature,特征，无非是个词汇而已，怎么说都没问题，用QTP你可以简单的完成你想实现的数据驱动方法的测试，他就是实现了xx功能。
还有关键字驱动，就是 关键字决定了结果。 在QTP里关键字就是step中的测试对象名称（对象方法属性，或者值（测试数据））。测试对象名称的改变，就决定了结果的变更。以前有些人写的所谓框架是把对象从Excel表格中导入导出的，他们实现的就是关键字驱动。
什么驱动，就是什么决定结果。本来结果是固定的，由于驱动数据的变更，导致了结果的不同，没那么复杂。其实概念都是人定的，少去钻牛角尖，理解个大概意思就行了。 楼主,所写的只不过是QTP可以读取外部数据的几种方式而已,没有什么"数据驱动"的东西啊. 原帖由 zhou840401 于 2008-5-4 17:01 发表 http://bbs.51testing.com/images/common/back.gif
楼主,所写的只不过是QTP可以读取外部数据的几种方式而已,没有什么"数据驱动"的东西啊.
QTP调用外部文件的方法有4种：
1.使用"Systemutil.Run"命令 调用各种外部文件
2.使用"InvokeApplication"命令 调用应用程序
3.通过"Excutefile"函数调用外部文件
4.在[资源]选项中调用外部文件 什么是数据驱动呢？很大一部分人肯定认为数据驱动就是把需要参数化的东西写在EXCEL里，然后在跑脚本时调用。如果我告诉你，这其实不是数据驱动，而只是较高级的参数化，你肯定会很惊讶！现在我来解释一下：首先为什么叫数据驱动呢，那么它肯定有驱动的含义，比如你用EXCEL可以控制测试的业务流吗？回答是不能的。那又如何作到驱动呢？所以说我们将测试数据放在独立的文件里只是高级的参数话。而数据驱动，你必须有数据来控制测试的业务流。比如你测一个WEB程序，有很多页面，你可以通过一个数据来控制每次是再哪个页面下工作的（即通过数据来导航到相应的页面）。它是关键字驱动的低级版本，他控制的是函数级的，而关键字是控制动作级的。所以数据驱动应该是可以控制整个测试的 现在我们用到最多的“数据驱动”其实就是比较高级的参数化，那么真正意义上的数据驱动如何实现呢？希望高人指点。 学习了！！:victory: "我们用到最多的“数据驱动”" 这个只能说在学习阶段用的做多的吧~~LZ也说了，数据驱动是可以通过数据来影响、控制流程的，而一般在工作中执行自动化测试，大多会达到这一程度的，否则过于僵化的程序结构会使得测试很不方便，而且浪费人力资源。
回复 5# 的帖子
感觉真正意义上的“数据驱动”跟录制工具策略有关，也就是录制出来的全是数据文件，把该数据文件放在任意理想环境中都能正常运行，而不需要接触任何代码。 我做的数据驱动是可以根据Excel中的数据改变测试流程的。我觉得首先是设计整个脚本结构，然后根据Excel数据做不同判断。
我是这样做的啦，share下，大家看看：
While Not myfile.EOF
select case mysheet.Fields("mycolumn").Value
Case "A"
RunAction A
Case "B"
....
End Select
myfile.MoveNest
Wend 楼主既然不知道什么是真正的数据驱动,那为什么还搞了一个这么大的标题"数据驱动在QTP的运用" 原帖由 zhou840401 于 2008-5-5 09:54 发表 http://bbs.51testing.com/images/common/back.gif
楼主既然不知道什么是真正的数据驱动,那为什么还搞了一个这么大的标题"数据驱动在QTP的运用"
这是转帖，在看过某前辈BLOG文章后有些疑惑，因此转帖后再求教，如对您带来什么不便与误会还请见谅。
[ 本帖最后由 phillipschen 于 2008-5-5 10:19 编辑 ] 那你可以创建一个Scripting.Dictionary对象，临时保存界面的值，然后在进行Excel表中的数据驱动。运用不同的值测试不同的触发条件。
然后在Run－time result 和 excel中的结果进行比较，得出测试结果。如果用数据驱动测试控制测试流程，可能是用到不同的测试框架了，EMOS还是…… 我觉的这个论题是很有意义的，51论坛上应该多一些这样的讨论，不然论坛真的成了一个问答版块了，我也就说一下我的想法吧。想到哪里说到哪里。
数据驱动本身不是一个工业级标准的概念，因此在不同的公司，都会有好几个解释版本。首先我同意楼主的关于数据驱动的观点，也就是说如果我们仅仅是把测试数据放在数据文件里，这只是一种比较高级的参数化而已。其实我更倾向于把数据驱动理解为一种模式或者一种思想
对于数据驱动的讨论，我们不妨先抛开QTP来进行。无论是进行自动化测试还是手工测试时，我们都需要设计测试用例，准备测试数据，并且把测试用例与数据分开，在一套测试用例上运行多套测试数据是比较有效率的。我相信这一点大家应该都认同吧。
那么我们不妨再看一下手工测试的场景：当一个手工测试人员A发现在测试数据存储目录下多了一套测试数据时，他就会意识到应该马上执行测试用例，并输入这套新的测试数据。其实是测试数据的变化触发了A的测试行为。（有人可能说了我们公司不是这么做的，注意，我们不是在讨论实际的测试管理，我们在对测试模型进行抽象）。如果我们更抽象一下，可以这样来看：当测试数据变化时，测试用例就会被执行（无论是A主动还是leader打电话通知），并且按照预先定义的规则去读取测试数据并执行测试用例。那么这种情况我们是不是可以理解为一种数据驱动呢？也就是说只要有了新的测试数据或者测试数据发生了变化，那么A就会去执行测试用例。这一过程的目的就是为了让所有的测试数据都得到输入并返回相应的输出结果。
如果大家同意上面的情景是一种数据驱动测试的例子，那么我们可以对自动化测试中的数据驱动进行同样的解释：由机器自动读取测试数据，然后测试用具运行测试脚本执行测试用例，并按照预先设置好的参数化字段读取测试数据，返回测试结果。目的就是使所有的测试数据都得到输入，并返回输出，验证数据的输入和输出是否符合预期值。这里的测试数据不仅包括业务数据，还包括一些动作关键字或决策关键字，以提供足够的信息，让测试工具知道该调用什么样的脚本，应该如何处理各种情况。相对于不同的测试工具，其表现形式有可能不同，QTP提供了关键字视图和数据表，robot提出了决策表的概念，Watir的话本身没有什么特殊的模式，完全看测试人员把框架设计成什么样了。其实本质上都是消息驱动的不同表现而已，例如刚才的手工测试的例子，测试数据发生变化我们可以把它看成一种消息，接收到这个消息A就开始执行测试。
现在在测试行业已经有很多的脚本设计模式了。线性脚本、模块脚本、关键字驱动测试、决策表驱动测试，还有微软提出的模型驱动测试，上次还听到一个稀奇古怪的名词叫思想驱动测试（可能是从开发模式抄过来的）。其实无论什么模式，其最终的目的都是为了提高测试用例的复用性，提供测试的覆盖率，减少测试脚本的维护量，让自动化测试框架更灵活，更具扩展性。数据驱动测试本身就是一个泛化的概念，我经常听到有人说：XX工具实现了数据驱动的功能，其实这种说法是不正确的。数据驱动本身是一种模式，一种设计思想，不是具体的软件功能。就好象我们不能说JAVA实现了MVC功能，不能说word提供了消息驱动功能一样（不明白的可以和开发人员请教一下）。模式和设计思想是放之四海而皆准的，至于如何实现，怎么实现，那就是仁者见仁，智者见智了 用一个简单的例子来说，数据驱动就是用不同的数据来组合，触发不同的业务流程（业务流应该是一个树形结构），达到最大的覆盖率，能够基本覆盖常用的业务流。
例如：你测试一个财务报表，你不仅要测试一个报表在每个月底的时候，生成的报表是否正确；你还需要验证在一个季度，跨年度的时候，报表的数据是否正确而已。
数据的驱动就是应该根据业务的需要，进行最大化（在自动测试工具的帮助下），覆盖最大的业务流分支，达到要求的测试覆盖率，永远也没有100％的覆盖。 我对数据驱动的理解
windows下有一个ini的配置文件，原理跟这个一样
当我们使用QTP时，读取这个样的一个文件，不一定是INI的。
然后我们在这个所谓的INI中写我们所需要的东西。
举个例子（伪码）：
【运行策略】
1
【运行方式】
1，登录，查询，购买，退出
2，登录，购买，退出
3，登录，退出
解释一下：
当我们读取这个文档，首先读取【运行策略】这块的内容，读取为“1”，在【运行方式】中查找到1的方式是登录，查询，购买，退出。
然后我们在程序中通过对这个文件的读取获得对脚本的操作。执行我们的登录，查询，购买，退出脚本。
同样，当我们在【运行策略】中读取到2，那我们脚本的执行就是 登录，购买，退出
这个就是我理解的数据驱动，它也相当于高级的参数化，但是有有别于参数化
实现了我们对脚本的不同操作。 希望有更深入的讨论，希望大家踊跃发言 如果再扩展一下15楼的例子，数据驱动也可以分为这样几个层次：
1、测试脚本执行时读取测试数据，测试脚本主动；
2、测试引擎读取测试数据表，根据测试数据表的内容调度测试脚本执行测试，测试脚本非主动；
3、根据读取的数据表或者测试用例，测试引擎自动生成测试脚本的序列，然后对测试脚本序列进行调度执行测试，模型驱动。 以驱动脚步完成自动化测试业务的完成，通过数据驱动不同的业务更方便 呵呵 我说怎么上面的定义这么熟悉，原来是自己当初写的。欢迎大家发表自己意见！:)
页:
[1]
2
