51Testing软件测试论坛

标题: 规划自动化测试:测试用例,测试脚本,测试框架 [打印本页]

作者: huangcm 时间: 2007-1-30 10:58
标题: 规划自动化测试:测试用例,测试脚本,测试框架
在执行QTP自动化测试前其设计的测试用例应该注意些什么

感觉应该和手工测试设计的测试用例会有所不同吧,至少注意点不一样吧.

有过QTP自动化实施经验的请说说,应该怎么设计更好些

[ 本帖最后由 huangcm 于 2007-2-5 17:45 编辑 ]

作者: beginnl 时间: 2007-1-30 11:46
我做自动化测试时依照的用例大部分还是参照手动测试时写的用例。我说说我的经验，大家一起探讨下：
1）关注点不同
自动化测试的每个用例测到的会有好几个功能点。
手工测试的每个用例测的可能就是具体的一个功能点。
2）用例编写方式不同
自动化测试的每个用例一般都是会从新增开始，到删除结束，做过的操作数据会在最后删除。
手工测试的每个用例不用关注数据是否保留。
3）其他
自动化测试的每个用例的起始页面和退出页面一般都是同一个页面，从哪里开始，在哪里结束。
手工测试用例无这个要求。

举例说有这样一个模块，下分三个功能：新建用户，修改用户，删除用户。
我录脚本时一般会录制2个，1。登录－新建用户－删除用户－登出；2。登录－新建用户－修改用户－删除用户－登出。
注：登录，登出事先录制好一个通用的脚本，供其他脚本调用。

在1。新建用户－删除用户脚本中，新建用户又分成好几个action，如必须输入项检查，非法字符检查，最大长度检查等等，最后才输入完全合法的值创建新用户，创建用户成功后再直接删除。
2。新建用户－修改用户－删除用户脚本中，新建用户这块不需再录制，直接调用第一个脚本中的action，接着与第一个脚本中一样，录制修改用户的action，最后再删除用户。

作者: kevin_swpi 时间: 2007-1-30 14:43
先顶楼上的一个

"
在1。新建用户－删除用户脚本中，新建用户又分成好几个action，如必须输入项检查，非法字符检查，最大长度检查等等，最后才输入完全合法的值创建新用户，创建用户成功后再直接删除。
"
这一步是不是可以不用多个ACTION
直接就一个副本然后在这个副本中包含一些检查项目或者其他的操作
对于一些输入的规范的话就可以直接设置参数然后在数据表中循环读取就是了

个人意见sdlkfj5

作者: huangcm 时间: 2007-1-30 15:14
谢谢beginnl的回复,
有些地方不是很明白,再问你下

"我录脚本时一般会录制2个，1。登录－新建用户－删除用户－登出；2。登录－新建用户－修改用户－删除用户－登出。"
其中2不是已经都包含了1中的用例调用,那是否只要一个2就可以了

就是是否可以这样
各个功能单独为一个用例脚本: 新建用户 , 修改用户 , 删除用户
之后在建一个测试,调用各脚本: 登录－新建用户－修改用户－删除用户－登出

(当然这样就会存在各个功能用例不能相互独立:
如 "修改用户"功能的测试用例可能要在 "新增用户"功能测试用例执行完之后,
但是可以把新建用户－修改用户－删除用户当做一个用例来看,那就是独立的)

[ 本帖最后由 huangcm 于 2007-1-30 15:59 编辑 ]

作者: huangcm 时间: 2007-1-30 15:17
这个是我看"软件测试自动化"电子书,贴出一部分内容, 有些我也不是很理解,大家可以说说自己的意见:

自动化测试用例设计原则：
1）设计相互独立的测试用例。测试用例的独立性能够保证一个测试用例不依赖另一个测试的成功完成来运行（不依赖于前一个测试用例的结果）。它也确保了即使在无人干预的情况下，自动化测试套件也能得出结果。如果不独立，第一随后的实验可能无法执行，分离失败的原因变的困难。
2）设计自包含式的（self-contained）测试用例，具有基准数据库这样基本状态的需求，基本状态消除了测试用例之间的线性依赖。
3）设计基于出发点的（home-based）测试用例。如果每个测试用例都是从一个己知点开始而目结束后会进行清理．这样做可以确保每个脚本都与先前测试脚本一样开始于同样的条件．有助于保证测试脚本是独立的。
4）设计无重叠的测试用例

创建自动化测试用例的三步方法；，下面给出了具体的实施方案：
第一步：设计测试用例-Fuchs说每一个测试用例都应该包含1-10个密叨相关的场景-具有10个以上场景的测试用例应该分成多个测试用例．每个场景都应该与一个惟一的预期结果相关联。
第二步：手工运行测试。Fuchs指出在回归测试中自动化测试是发现错误的最好方法，而在第一回合中用手工测试比较好；
第三步．自动化测试用例。在每个测试场景中．测试脚本应该包含以下几个部分：
  ．进行设置
  ．进行测试
  ．验证结果
  ．记录结果
  ．处理意外情况：跟踪意外情况并对它们进行恢复。
  ．决定停止还是继续测试用例
  。进行清理工作：测试用例返回到出发点。

作者: beginnl 时间: 2007-1-30 22:56
标题: 回复 #3 kevin_swpi 的帖子
谢谢你的意见！
我的做法是这样的：
在新建用户的时候我也录制了2个action，如create user-valid,create user-invalid，两个action相对独立的说。这样在其他模块中要调用新建用户这个脚本时，只需调用create user－valid，不用重新去验证invlid部分了。

对于一些输入的规范的话就可以直接设置参数然后在数据表中循环读取就是了。－这个方法怎么做的，能具体点说说吗？偶的方法笨笨的说^_^

作者: beginnl 时间: 2007-1-30 23:12
标题: 回复 #4 huangcm 的帖子
我录脚本时一般会录制2个，1。登录－新建用户－删除用户－登出；2。登录－新建用户－修改用户－删除用户－登出。"
其中2不是已经都包含了1中的用例调用,那是否只要一个2就可以了

答：两个脚本还是有区别的，因为第二个脚本经过了修改用户这一步操作，数据会有改动，如果对这些改动不加验证点验证倒是可以调用同一个脚本，但验证点会有变动，这时可以调用删除用户这个action的副本，然后再修改下验证点。

作者: wssgily 时间: 2007-1-31 09:15

原帖由 huangcm 于 2007-1-30 15:17 发表
这个是我看"软件测试自动化"电子书,贴出一部分内容, 有些我也不是很理解,大家可以说说自己的意见:

自动化测试用例设计原则：
1）设计相互独立的测试用例。测试用例的独立性能够保证一个测试用例 ...

能否把你的这本"软件测试自动化",共享一下,大家都学习一下,或者发到我的信箱可以吗?谢谢!
c7v8@hotmail.com

作者: huangcm 时间: 2007-1-31 09:30
标题: 回复 #8 wssgily 的帖子
软件测试自动化,我已经上传共享,没有的话可以去下载
http://bbs.51testing.com/thread-64429-1-1.html

作者: huangcm 时间: 2007-1-31 09:34
谢谢大家的回复,对于设计自动化测试用例和脚本ACTION的架构
我在研究下,再和大家一起讨论

作者: keynes_2005 时间: 2007-1-31 10:01
挺好的. 学习一下!

作者: walker1020 时间: 2007-1-31 11:30
从本质上来说，为使用QTP而设计的测试用例和为进行手工测试而设计的测试用例没有什么区别，因为QTP只是代替了某些手工操作步骤。至于beginnl 说的那几点不同，其实也不算它们的不同，因为我要求他们写测试用例的时候，这几点都要考虑到的，无论是手工测试还是用QTP进行测试。
当然，手工测试相对来说随意一些，但也可能会遗漏某些检查点；用QTP进行测试对脚本有一定的要求（如开始页面和最好的结束页面要一致），但它进行多次的、大量的测试后，仍然可以保证把脚本中的检查点都测试一遍。
个人观点，仅供参考。

作者: chris_328 时间: 2007-1-31 11:36
标题: 回复 #7 beginnl 的帖子
我觉得完全可以作为一个自动化测试流程来做，Action的运行和验证点的执行可以实现自动控制，只做一个流程对于脚本编写的效率和今后的维护成本都非常好，自动化测试不应该是录制手工测试用例的脚本，脚本设计也很重要
个人观点sdlkfj5

作者: huangcm 时间: 2007-2-5 13:01
经过我几天来的研究，我觉得从自动化测试用例来说，与手动区别还是不大的，beginnl说的这点很赞同：
自动化测试的每个用例测到的会有好几个功能点。
手工测试的每个用例测的可能就是具体的一个功能点。

但在设计脚本时，要设计一个测试框架，在基于测试框架上设计各Action脚本会起到事半功能的效果。测试框架需要独立于应用程序。脚本必须独立测试用例。
也就是说设计的测试框架不能因为换了一个应用程序就无法使用了，脚本也不能因为换了个测试用例数据就要进行大修改维护。

如用户管理模块，我分别设计了新增用户，修改用户，删除用户三个Action。这三个脚本相互独立，不依赖于前一个脚本执行结果的成功．
针对测试用例１：新增A 修改 B 删除 c，
我用一个主脚本，调用　新增用户，修改用户，删除用户三个Action。
直接在数据驱动中录入测试数据Ａ；Ｂ；Ｃ，便可执行．
而无法修改Action来满足执行的测试数据

针对测试用例2：新增 B C D
我用一个主脚本，调用　新增用户 Action。
直接在数据驱动中录入测试数据B；C；D，便可执行．

在数据驱动中增加一些字段用来区分调用什么Action,进行什么验证等等,这个由你设计的测试框架和功能决定.

[ 本帖最后由 huangcm 于 2007-2-5 13:06 编辑 ]

作者: hiyizhiyu 时间: 2007-2-5 17:05
"自动化测试的每个用例测到的会有好几个功能点",之所以这样说,只是我们开发脚本的一个体会.但假如让一个没有开发过脚本的人来些test case,他又如何能很准确的判断哪些功能点应该合成一个case呢,而且他也无法保证合成出来的case是否符合你的开发习惯,等等.这样还是有一些弊端的.
现在测试团队的test case基本上都是一个功能点一个case,改变这种方式是否合理或者说单独来写自动化case,感觉需要平衡的东西还是很多的.
相比而言,脚本的设计架构更重要一些.和软件设计一样,分层是提高开发效率,降低维护成本的一个好方法,但由于缺乏高效的错误处理机制和本身调试环境的限制,又增加了额外的负担.
这个是俺前段时间做QTP的一点感受,反正是没有什么好的办法,希望各位DX多给好的意见

作者: huangcm 时间: 2007-2-5 17:36
标题: 回复 #15 hiyizhiyu 的帖子
按照我的方法,
开发脚本时无需考虑哪些功能点应该合成一个case,因为脚本的设计不依赖于case ,

如某一Action 设计时,读取数据驱动字段,
如果录入数据不为0,则录入数据,
如果该记录有提示,则执行验证提示
如果执行动作为保存,则执行保存;执行动作为取消,则执行取消

这样测试人员只要关心设计测试数据,和一些区分执行脚本的字段

作者: huangcm 时间: 2007-2-5 17:39
设计的脚本Action 中考虑该功能中所有测试可能的动作,和可能的结果
读取数据驱动数据,进行判断执行相关代码

作者: hiyizhiyu 时间: 2007-2-6 17:27
to huangcm: 不知道你是怎么定义"该功能"的,就是指一个功能点,还是一组功能点呢?如果是一个功能点,那如果每个功能点都如此设计,感觉是一个很复杂的过程啊!
还有我的理解是你为每个功能都设计几种场景,然后根据驱动数据中的字段来判断执行哪个场景,不知道这些场景是只属于这个功能还是可以被所有功能共享,如果是只属于特定功能,那脚本的开发可能也不简单,而且感觉结构也不太合理!
我接触QTP不久,也许对你的描述理解不够,呵呵,就当灌水吧
倒是期望你们多多讲一些好经验
thanks

作者: Coffey111111 时间: 2007-2-7 09:37
对脚本设置一个测试框架，如何设计一个好的框架便于测试效率的提高以及以后脚本的维护，我觉得是个难点，也想和大家讨论这个问题~~ 对脚本的设计到底要注意点写什么？有经验的人可以谈谈吗？sdlkfj5

作者: topor 时间: 2007-6-8 17:16
学习了，希望有经验的人可以接着coffey111111的话题继续讨论。sdlkfj2

作者: gotolife 时间: 2007-6-10 16:49
sdlkfj8 sdlkfj9

作者: lovelovecat 时间: 2007-6-10 22:38
"自动化测试的每个用例的起始页面和退出页面一般都是同一个页面，从哪里开始，在哪里结束。" 这是为什么呀

作者: coletan 时间: 2007-6-10 23:53

原帖由 huangcm 于 2007-2-5 17:36 发表
按照我的方法,
开发脚本时无需考虑哪些功能点应该合成一个case,因为脚本的设计不依赖于case ,

如某一Action 设计时,读取数据驱动字段,
如果录入数据不为0,则录入数据,
如果该记录有提示,则执行验证 ...

下面说的什么我没看懂，但是上面说的开发脚本无需考虑功能点的结合，这点我不是很同意，我们做功能测试多数都是结合业务流来做的，这样的话一个脚本下来一般都是多个操作，而单独测一个功能的话还是很少就是登录也要带上个退出，单独测一个功能点，感觉有点像是性能测试吧，做做并发什么的，看看某些典型操作的响应时间。。。
呵呵，我也刚学测试····喷下口水

作者: chenjie021 时间: 2007-6-11 16:49
sdlkfj2

作者: walker1020 时间: 2007-6-12 20:13

原帖由 lovelovecat 于 2007-6-10 22:38 发表
"自动化测试的每个用例的起始页面和退出页面一般都是同一个页面，从哪里开始，在哪里结束。" 这是为什么呀

这样是为了保证每次测试的初始环境是一样的

作者: jackydao 时间: 2007-6-13 16:11

原帖由 huangcm 于 2007-2-5 13:01 发表
经过我几天来的研究，我觉得从自动化测试用例来说，与手动区别还是不大的，beginnl说的这点很赞同：
自动化测试的每个用例测到的会有好几个功能点。
手工测试的每个用例测的可能就是具体的一个功能点。

但 ...

我也来谈谈感受,如上所说,针对每个action(我叫它基础action),考虑到它会被调用到的情景,加入不同的判断和验证,的确是比较好的框架结构,我当初也是这样做的.但是后来越来越不大对劲,因为某个基础action的前提环境可能是多样化的,比如说大概有10种,但是你编写大部分基础action的时候可能也只想到了7,8种,如果你已经把这些基础action副本应用到脚本中,组合成一个个用例后,会逐渐发现可能还有几种情况没有考虑到,而这时候的维护量是相当大的,而且组合基础用例不如直接写脚本那样条理清晰,一目了然,如果任意一个脚本中多了个判断什么的,可能还要找半天.所以说,我觉得是比较理想化的,还不如直接写的方便.
个人意见,仅供参考

作者: kyo1101097 时间: 2007-7-13 14:57
标题: 很实用的贴子.
很实用的贴子.

作者: kyo1101097 时间: 2007-7-13 14:58
标题: 希望能看到更多更好的贴
顶

作者: ppent 时间: 2007-7-25 16:18
学习

作者: wtucel 时间: 2007-7-30 09:37
mark~~

作者: allenzgw 时间: 2007-9-8 11:47
对,这个问题,才是我们一直在思考的问题,真希望以后多看到, 台困惑了

作者: ssy2010 时间: 2007-9-8 17:26
顶一下

作者: yzbin097 时间: 2007-12-29 15:40

!我觉得设计自动化用例的时候，我们是否可以借用其他行业所说的“模块化设计”；我们可以单独分别为登陆、增加、删除、修改设计用例，然后只要组装起来就可以正常使用了！本人的观点而以

作者: testman 时间: 2008-6-20 18:33
这帖子不错。主题很有用，讨论很深入。

受益了~~

作者: testman 时间: 2008-6-20 18:37
转一篇资料：
转自：http://blog.chinaunix.net/u/21908/showart_258297.html

针对自动化测试用例的要求(requirement of test case for autotest
一，目的明确，有具体的输入输出

Purpose

以前的目的

Verify if the CDR is right about user order tvod program

修改后

Verify that while TVOD ordered from EPG CDR record created correctly

Input data and out put data shall be described clearly

二，有明确的步骤和检查点

Step

1.MC sigon

2.Enter 'TVOD' at EPG

3.Select one TVOD program

4.Order the tvod program

5.Check the cdr that build by AC

/opt/utoss/accountcenter/chargedata/online/succ

1.Enter 'TVOD' at EPG

2.Select a TVOD program

3.Order the tvod program

4.Open cdr (file) which exists on AC under

/opt/utoss/accountcenter/chargedata/online/succ

5.Check the value pending after tag "7/" matches the service ID

Clear steps and check point

三，准备要求是数据的准备

Precondition

1.OSS is normal

2.Billing of TVOD had config at OSS

3.Have one MC

4.VSLR/PSC/EPG/USC/AC is normal

1 Find or create IPTV subscriber refer to TC IDxxxx1, give UserID

2.Find a TVOD from OSS refer to TC IDxxxx2

3.Get "ServiceID" from "Service" table on OSS db by giving UserID

4.Install new subscriber on MC refer to TC IDxxxx3 or sign on MC refer to TC IDxxxx4

Not environment preparation, it should be detail data preparation to meet this test case needs. (it’s better to refer to test case ID, if it’s too difficult, at least give the test case set path.)

四，预期结果必须细化

Expected Result

1.User can order the tvod program

2.AC can write the cdr after user order the tvod program

/opt/utoss/server/accountcenter/chargedata/online/succ/

3.Every tag of the cdr is right

1. AccountCenter can write the cdr after user order the TVOD program, there should be a record about the user order the TVOD

2. Check specified field 7 of the cdr, it should eauql to the serviceid of the user

Clearly describe the expected result which matched the output data descript in “Test Purpose”

case 2:

Purpose

NMS support browse chassis inventory inside CO

Verify that chassis inventory shall be browsed on NMS CO Physical View, and chassis id from inventory is matched with chassis id from blade of the chassis

1. Login NMS

2. Open one physical view

3. Browse chassis inventory inside CO

4. Check the result and compare these data with real information

Step

1. Login NMS

2. Open one real CO's s physical view.

3. Browse chassis inventory on CO physical view, select any one chassis, get its ChassisID (SRS or HLD must provide enough information such as “look and view” or operation flow, comments by Norten)

4. Browse blade inventory on CO physical view, select any one blade of selected chassis, get its BladeIP

5. Telnet on the selected blade, get chassis id from /usr/local/rss/chassis_id file

6. Compare the chassis id from inventory with chassis id from blade

Precondition

Master Chassis Manager run normally

NMS run normally

Some NE run normally

At least one real CO and NE is running or create a real CO

Expected Result

1. NMS support to browse chassis inventory inside CO

2. User can check chassisPhysicalID information.

1. NMS support to browse chassis inventory inside CO

2. The chassis id from inventory is matched with chassis id from blade.

(Notice: The chassis id from inventory is in Hex format, the chassis id from blade is in Dec format)

作者: xiaoyaoke 时间: 2008-6-21 00:30
就一句话:VBS要有类的继承和多态就好了~~~

作者: FLY000 时间: 2008-6-21 18:05
留个脚印

作者: wzdoxu 时间: 2008-6-23 15:06
这篇帖子讨论的还是比较深入，希望更多的大牛参与讨论

作者: kun_fly 时间: 2008-6-26 10:48
很精彩！！！

作者: SummerQiu 时间: 2009-5-18 21:09

原帖由 yzbin097 于 2007-12-29 15:40 发表
!我觉得设计自动化用例的时候，我们是否可以借用其他行业所说的“模块化设计”；我们可以单独分别为登陆、增加、删除、修改设计用例，然后只要组装起来就可以正常使用了！本人的观点而以

我在实际的自动化测试中，应用的也是模块化设计，感觉前期的模块化设计投入较大，但是后期的使用效果还是很明显，维护成本也相对可控。模块化设计对最初设计的是否合理全面要求很高，一旦设计不合理，对后面的使用也是有很大风险的。

作者: SummerQiu 时间: 2009-5-18 21:09

原帖由 yzbin097 于 2007-12-29 15:40 发表
!我觉得设计自动化用例的时候，我们是否可以借用其他行业所说的“模块化设计”；我们可以单独分别为登陆、增加、删除、修改设计用例，然后只要组装起来就可以正常使用了！本人的观点而以

作者: lantianwei 时间: 2009-5-18 21:40
不错的帖子！

作者: z93620104 时间: 2009-5-19 09:17
好贴大家同分享

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)