51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

楼主: huangcm
打印 上一主题 下一主题

[求助] 规划自动化测试:测试用例,测试脚本,测试框架

[复制链接]

该用户从未签到

21#
发表于 2007-6-10 16:49:53 | 只看该作者
sdlkfj8 sdlkfj9
回复 支持 反对

使用道具 举报

该用户从未签到

22#
发表于 2007-6-10 22:38:06 | 只看该作者
"自动化测试的每个用例的起始页面和退出页面一般都是同一个页面,从哪里开始,在哪里结束。" 这是为什么呀
回复 支持 反对

使用道具 举报

该用户从未签到

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

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


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

使用道具 举报

该用户从未签到

24#
发表于 2007-6-11 16:49:31 | 只看该作者
sdlkfj2
回复 支持 反对

使用道具 举报

  • TA的每日心情
    开心
    2016-2-27 08:48
  • 签到天数: 2 天

    连续签到: 1 天

    [LV.1]测试小兵

    25#
    发表于 2007-6-12 20:13:48 | 只看该作者
    原帖由 lovelovecat 于 2007-6-10 22:38 发表
    "自动化测试的每个用例的起始页面和退出页面一般都是同一个页面,从哪里开始,在哪里结束。" 这是为什么呀


    这样是为了保证每次测试的初始环境是一样的
    回复 支持 反对

    使用道具 举报

    该用户从未签到

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

    但 ...

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

    使用道具 举报

    该用户从未签到

    27#
    发表于 2007-7-13 14:57:04 | 只看该作者

    很实用的贴子.

    很实用的贴子.
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    28#
    发表于 2007-7-13 14:58:39 | 只看该作者

    希望能看到更多更好的贴

    回复 支持 反对

    使用道具 举报

    该用户从未签到

    29#
    发表于 2007-7-25 16:18:17 | 只看该作者
    学习
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    30#
    发表于 2007-7-30 09:37:14 | 只看该作者
    mark~~
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    31#
    发表于 2007-9-8 11:47:32 | 只看该作者
    对,这个问题,才是我们一直在思考的问题,真希望以后多看到, 台困惑了
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    32#
    发表于 2007-9-8 17:26:04 | 只看该作者
    顶一下
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    33#
    发表于 2007-12-29 15:40:24 | 只看该作者
    !我觉得设计自动化用例的时候,我们是否可以借用其他行业所说的“模块化设计”;我们可以单独分别为登陆、增加、删除、修改设计用例,然后只要组装起来就可以正常使用了!本人的观点而以
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    34#
    发表于 2008-6-20 18:33:59 | 只看该作者
    这帖子不错。主题很有用,讨论很深入。

    受益了~~
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    35#
    发表于 2008-6-20 18:37:04 | 只看该作者
    转一篇资料:
    转自: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)
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    36#
    发表于 2008-6-21 00:30:58 | 只看该作者
    就一句话:VBS要有类的继承和多态就好了~~~
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    37#
    发表于 2008-6-21 18:05:56 | 只看该作者
    留个脚印
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    38#
    发表于 2008-6-23 15:06:09 | 只看该作者
    这篇帖子讨论的还是比较深入,希望更多的大牛参与讨论
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    39#
    发表于 2008-6-26 10:48:01 | 只看该作者
    很精彩!!!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

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


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

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-11-20 13:45 , Processed in 0.072424 second(s), 21 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表