数据驱动在QTP的运用

phillipschen

所谓数据驱动就是用一个数据文件把测试脚本驱动起来，来达到更接近用户化更智能的测试．其目的是把测试人员从维护复杂的脚本程序中解放出来，只需维护好数据文件即可，减少了很多修改脚本的麻烦．下面讲一下通过四种途径来达到数据驱动．

１．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 编辑 ]

jackymail

大家不要被一些所谓的概念混淆，自己用着最方便就是最好的东西。
别把1+1也说得冠冕堂皇，应用的工具而已，扯得太远了就丢弃了本质的东西，到头来1+1都不知道得几。
不是谁的理论听起来有道理或者内容丰富就一定是对的，就算全对了，你能牢记住吗，看过就忘了吧？

数据驱动中的 driven 一词，你可以简单的理解成导向，导向什么？结果。就是测试数据决定了测试结果，这就是所谓数据驱动，QTP实现了数据驱动的功能，模型，feature,特征，无非是个词汇而已，怎么说都没问题，用QTP你可以简单的完成你想实现的数据驱动方法的测试，他就是实现了xx功能。

还有关键字驱动，就是 关键字决定了结果。 在QTP里关键字就是step中的测试对象名称（对象方法属性，或者值（测试数据））。测试对象名称的改变，就决定了结果的变更。以前有些人写的所谓框架是把对象从Excel表格中导入导出的，他们实现的就是关键字驱动。

什么驱动，就是什么决定结果。本来结果是固定的，由于驱动数据的变更，导致了结果的不同，没那么复杂。其实概念都是人定的，少去钻牛角尖，理解个大概意思就行了。

757563246

楼主，执行脚本，弹出“ActiveX 部件不能创建对象: 'scrīpting.FileSystemObject'

第 (16) 行: "Set fso = CreateObject("scrīpting.FileSystemObject")"。 ”怎样解决？

yanguohong0925

回复 20# jackymail


    同意！！！人们往往被概念的理解搞的稀里糊涂，偏离了原本出发的目的~赞这个理解，所谓驱动即是“导向”，万分膜拜

hututu

有所领悟了，本来想查odbc的，(*^__^*) 嘻嘻……，却发现了大家的讨论，不错

vitha

弄几个参数化数据到外部文件或者数据库中，再运行时读取。---这根本就不是数据驱动。数据驱动要有驱动的作用，数据可以控制业务逻辑的流向。这才是根本。

lansemogu1985

好贴，拜读，现在正在研究数据驱动呢……一天下来 有点感悟了

dreamever

通过这次讨论,我对数据驱动的理解又深入了,呵呵,这才应该是论坛的真正作用.
最后顶一下20楼,说的不错.

heqingbluesky

原帖由 jackymail 于 2008-5-9 10:42 发表
大家不要被一些所谓的概念混淆，自己用着最方便就是最好的东西。
别把1+1也说得冠冕堂皇，应用的工具而已，扯得太远了就丢弃了本质的东西，到头来1+1都不知道得几。
不是谁的理论听起来有道理或者内容丰富就一定是 ...

我同意Jackymail所说的，我们其实对于测试希望的结果有一个列表的（Expected Result List），我们通过不同的数据，实现不同的测试流程，得到希望的结果列表（Actaul Result List）。这个就是数据驱动，一言以概之。
对于从它引申出来的不同说法，我觉得都是大同小异，没有本质的差别。

william_qiao

如果想了解真正的数据驱动 建议大家看看下面的文章
http://blog.sina.com.cn/s/blog_560d7ada01000ck3.html
相关网站
http://safsdev.sourceforge.net/Default.htm

lantianwei

呵呵 我说怎么上面的定义这么熟悉，原来是自己当初写的。欢迎大家发表自己意见！

AUTO-TESTING

以驱动脚步完成自动化测试业务的完成，通过数据驱动不同的业务更方便

dreamever

如果再扩展一下15楼的例子，数据驱动也可以分为这样几个层次：
1、测试脚本执行时读取测试数据，测试脚本主动；
2、测试引擎读取测试数据表，根据测试数据表的内容调度测试脚本执行测试，测试脚本非主动；
3、根据读取的数据表或者测试用例，测试引擎自动生成测试脚本的序列，然后对测试脚本序列进行调度执行测试，模型驱动。

walker1020

希望有更深入的讨论，希望大家踊跃发言

shen1936

我对数据驱动的理解
windows下有一个ini的配置文件，原理跟这个一样

当我们使用QTP时，读取这个样的一个文件，不一定是INI的。
然后我们在这个所谓的INI中写我们所需要的东西。

举个例子（伪码）：
【运行策略】
1
【运行方式】
1，登录，查询，购买，退出
2，登录，购买，退出
3，登录，退出

解释一下：
当我们读取这个文档，首先读取【运行策略】这块的内容，读取为“1”，在【运行方式】中查找到1的方式是登录，查询，购买，退出。
然后我们在程序中通过对这个文件的读取获得对脚本的操作。执行我们的登录，查询，购买，退出脚本。
同样，当我们在【运行策略】中读取到2，那我们脚本的执行就是 登录，购买，退出

这个就是我理解的数据驱动，它也相当于高级的参数化，但是有有别于参数化

实现了我们对脚本的不同操作。

heqingbluesky

用一个简单的例子来说，数据驱动就是用不同的数据来组合，触发不同的业务流程（业务流应该是一个树形结构），达到最大的覆盖率，能够基本覆盖常用的业务流。
例如：你测试一个财务报表，你不仅要测试一个报表在每个月底的时候，生成的报表是否正确；你还需要验证在一个季度，跨年度的时候，报表的数据是否正确而已。
数据的驱动就是应该根据业务的需要，进行最大化（在自动测试工具的帮助下），覆盖最大的业务流分支，达到要求的测试覆盖率，永远也没有100％的覆盖。

dreamever

我觉的这个论题是很有意义的，51论坛上应该多一些这样的讨论，不然论坛真的成了一个问答版块了，我也就说一下我的想法吧。想到哪里说到哪里。
数据驱动本身不是一个工业级标准的概念，因此在不同的公司，都会有好几个解释版本。首先我同意楼主的关于数据驱动的观点，也就是说如果我们仅仅是把测试数据放在数据文件里，这只是一种比较高级的参数化而已。其实我更倾向于把数据驱动理解为一种模式或者一种思想
对于数据驱动的讨论，我们不妨先抛开QTP来进行。无论是进行自动化测试还是手工测试时，我们都需要设计测试用例，准备测试数据，并且把测试用例与数据分开，在一套测试用例上运行多套测试数据是比较有效率的。我相信这一点大家应该都认同吧。
那么我们不妨再看一下手工测试的场景：当一个手工测试人员A发现在测试数据存储目录下多了一套测试数据时，他就会意识到应该马上执行测试用例，并输入这套新的测试数据。其实是测试数据的变化触发了A的测试行为。（有人可能说了我们公司不是这么做的，注意，我们不是在讨论实际的测试管理，我们在对测试模型进行抽象）。如果我们更抽象一下，可以这样来看：当测试数据变化时，测试用例就会被执行（无论是A主动还是leader打电话通知），并且按照预先定义的规则去读取测试数据并执行测试用例。那么这种情况我们是不是可以理解为一种数据驱动呢？也就是说只要有了新的测试数据或者测试数据发生了变化，那么A就会去执行测试用例。这一过程的目的就是为了让所有的测试数据都得到输入并返回相应的输出结果。
如果大家同意上面的情景是一种数据驱动测试的例子，那么我们可以对自动化测试中的数据驱动进行同样的解释：由机器自动读取测试数据，然后测试用具运行测试脚本执行测试用例，并按照预先设置好的参数化字段读取测试数据，返回测试结果。目的就是使所有的测试数据都得到输入，并返回输出，验证数据的输入和输出是否符合预期值。这里的测试数据不仅包括业务数据，还包括一些动作关键字或决策关键字，以提供足够的信息，让测试工具知道该调用什么样的脚本，应该如何处理各种情况。相对于不同的测试工具，其表现形式有可能不同，QTP提供了关键字视图和数据表，robot提出了决策表的概念，Watir的话本身没有什么特殊的模式，完全看测试人员把框架设计成什么样了。其实本质上都是消息驱动的不同表现而已，例如刚才的手工测试的例子，测试数据发生变化我们可以把它看成一种消息，接收到这个消息A就开始执行测试。
现在在测试行业已经有很多的脚本设计模式了。线性脚本、模块脚本、关键字驱动测试、决策表驱动测试，还有微软提出的模型驱动测试，上次还听到一个稀奇古怪的名词叫思想驱动测试（可能是从开发模式抄过来的）。其实无论什么模式，其最终的目的都是为了提高测试用例的复用性，提供测试的覆盖率，减少测试脚本的维护量，让自动化测试框架更灵活，更具扩展性。数据驱动测试本身就是一个泛化的概念，我经常听到有人说：XX工具实现了数据驱动的功能，其实这种说法是不正确的。数据驱动本身是一种模式，一种设计思想，不是具体的软件功能。就好象我们不能说JAVA实现了MVC功能，不能说word提供了消息驱动功能一样（不明白的可以和开发人员请教一下）。模式和设计思想是放之四海而皆准的，至于如何实现，怎么实现，那就是仁者见仁，智者见智了

heqingbluesky

那你可以创建一个Scripting.Dictionary对象，临时保存界面的值，然后在进行Excel表中的数据驱动。运用不同的值测试不同的触发条件。
然后在Run－time result 和 excel中的结果进行比较，得出测试结果。如果用数据驱动测试控制测试流程，可能是用到不同的测试框架了，EMOS还是……

phillipschen

原帖由 zhou840401 于 2008-5-5 09:54 发表
楼主既然不知道什么是真正的数据驱动,那为什么还搞了一个这么大的标题"数据驱动在QTP的运用"

这是转帖，在看过某前辈BLOG文章后有些疑惑，因此转帖后再求教，如对您带来什么不便与误会还请见谅。

[ 本帖最后由 phillipschen 于 2008-5-5 10:19 编辑 ]

zhou840401

楼主既然不知道什么是真正的数据驱动,那为什么还搞了一个这么大的标题"数据驱动在QTP的运用"