51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

楼主: 梦醒十分
打印 上一主题 下一主题

[原创] 最新--功能自动化测试“框架”演示-1(视频)

[复制链接]

该用户从未签到

21#
发表于 2007-7-19 23:15:46 | 只看该作者
2222222222222222222
回复 支持 反对

使用道具 举报

该用户从未签到

22#
发表于 2007-7-19 23:16:19 | 只看该作者
444444444444444433333333
回复 支持 反对

使用道具 举报

该用户从未签到

23#
发表于 2007-7-19 23:32:43 | 只看该作者
原帖由 yabest 于 2007-7-19 19:19 发表
呵呵,感觉这个框架没什么意义。

弄来弄去,都是把步骤搬到excel里(不烦吗,怎么重用步骤呢),或者啥数据驱动(呆板笨重,只能用于少数几个固定流程的Case)!

其实,手工测试人员熟悉流程,自动化专家 ...



其实你说的也有一定的道理,但是要实现你说的这种效果相对来说更加困难,而且跟项目的实际情况相关吧,

不知道你有没有实际的例子?也录一段上来大家研究一下啊,我相信目前很多人都跟我一样对自动化框架还是处于初级

阶段的,只有先依葫芦画瓢
回复 支持 反对

使用道具 举报

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

    连续签到: 1 天

    [LV.1]测试小兵

    24#
    发表于 2007-7-19 23:33:12 | 只看该作者
    梦醒十分 辛苦了!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    25#
     楼主| 发表于 2007-7-20 09:43:51 | 只看该作者
    原帖由 yabest 于 2007-7-19 19:19 发表
    呵呵,感觉这个框架没什么意义。

    弄来弄去,都是把步骤搬到excel里(不烦吗,怎么重用步骤呢),或者啥数据驱动(呆板笨重,只能用于少数几个固定流程的Case)!

    其实,手工测试人员熟悉流程,自动化专家 ...


    其实视频演示的并不是介绍如何制作框架,任何一个框架也不可能是万能的,不可能适用于任何平台。
    我只是用一个最简单的例子,说明一下为什么要搭建框架,它解决了一个什么矛盾。
    我做过的项目每个都要根据项目情况进行实现。
    上面视频的例子,我也只用过在一个项目中,2个月完成4万5千行自动化代码,
    而且是不经任何改动完全通吃所有语言平台的代码。
    有时项目时间紧,只能采取最笨的方法,外包就是人海战术嘛。

    下期将介绍,一个Qtp专家面对20个手工tester,每天提上来上百个excel,QTP专家应用框架后经常是由于tester疏怱添写错误(不是缺添个动作,就是取值取错了。。。)而调不通,而要去要求出错的tester改正,QTP专家疲于奔命,他如何解决?

    请注意:
    1:我讲的都是以前在项目中的亲身经历,我想经验能使人少走弯路。
    2:我想传达的是一种设计思想和方法(要求是能真正理解),实不实用另说。
    3:如果讲完第二期,甚至第三期,你还不理解什么是框架或还把某段框架代码看成是实用的万能工具,那么是我讲的不好。
    4:如果讲完第二期,甚至第三期,你还不能自己动手用VBS或excel VBA(宏)写出类似的东东,只能向别人索取现成的,那么我白费劲了。。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    26#
    发表于 2007-7-20 10:55:45 | 只看该作者
    原帖由 梦醒十分 于 2007-7-20 09:43 发表


    其实视频演示的并不是介绍如何制作框架,任何一个框架也不可能是万能的,不可能适用于任何平台。
    我只是用一个最简单的例子,说明一下为什么要搭建框架,它解决了一个什么矛盾。
    我做过的项目每个都要根据 ...


    其实你也提到自动化的主要矛盾了,就是手工测试熟悉业务不熟悉技术,自动化专家熟悉技术不熟悉业务!
    所以需要分工合作,但是例子里,在Excel里写脚本,看不出多少分工,反而觉得比QTP Keyword View还笨。

    另外你提到二个月几万行代码。呵呵,代码不是越多越好,没有分层和重用的代码简直是场灾难,
    你能想像开发个几万行代码的大软件,竟然不用函数和对象,完全靠一行行代码堆积出来?

    按我的理解,框架的真义,还是分工、分层、重用!

    可能你讲的还不够清楚,期望能看到你下几期的演示。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    27#
    发表于 2007-7-20 11:13:33 | 只看该作者
    原帖由 wtucel 于 2007-7-19 23:32 发表



    其实你说的也有一定的道理,但是要实现你说的这种效果相对来说更加困难,而且跟项目的实际情况相关吧,

    不知道你有没有实际的例子?也录一段上来大家研究一下啊,我相信目前很多人都跟我一样对自动化框架

    还是处于初级阶段的,只有先依葫芦画瓢




    框架就是分工、分层、重用

    手工测试人员不用面对琐碎的技术,只要面对业务知识和测试逻辑,我希望他做的内容,是写如下Case函数

    Function TestUserGroupRole()

            Add_User("张三", "Password1", "Admin Group")
           
            Add_User("李四", "Password2", "Guest Group")
           
            Login_System("张三", "Password1")
           
            result = Try_Do_Operaction(...)
           
            if result="Fail" Then
                    Return "Fail", "Admin group user should can do operaction"
            End If
           
            Logout_System()
           
           
            Login_System("李四", "Password2“)
           
            result = Try_Do_Operaction(...)
           
            if result="Success" Then
                    Return "Fail", "Guest group user should can't do operaction"
            End If
           
            Logout_System()
           
            Return "Pass", "Test Passed. Admin group user can do operaction. And Guest group user can't do operaction"

    End Function

    而自动化专家则不用关心太多的业务知识和测试逻辑,主要面对技术细节。
    他做的内容,是写上面的Add_User()、Login_System()、Logout_System()等业务函数。

    这些业务函数可以供成千上万个Case函数反复调用,一旦某个业务操作发生变化,
    只要修改相应的业务函数即可,不用修改N多涉及的Case函数。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    28#
     楼主| 发表于 2007-7-20 13:41:13 | 只看该作者
    原帖由 yabest 于 2007-7-20 10:55 发表


    其实你也提到自动化的主要矛盾了,就是手工测试熟悉业务不熟悉技术,自动化专家熟悉技术不熟悉业务!
    所以需要分工合作,但是例子里,在Excel里写脚本,看不出多少分工,反而觉得比QTP Keyword View还笨。 ...

      那几万行代码是在这种情况下产生的:
    产品测试要求:
      产品功能已经不用测了。
      要求在英,简中,繁中,日文,韩文下去跑case找本地化的bug。
    每个case之间除了login可重用外,几乎没有相同的地方,所以无法用函数封装。
    项目要求我们自动化帮忙,自动去跑case,在关键地方自动拍图,要求能拍成横,竖滚动可翻页的图。
    大概五个语言case全跑完会产生3K多张左右的图,然后分给tester们去看,省得大家跑case.(跑一步拍张图,跑完再看,这就是多数手工测L10N方法)。
      注:对于不懂日文,韩文的新手tester,给他英文case,很难跑起来case,老手也经常跑错,因为根本不知点哪个button.这些很笨的脚本,就几乎是动作的堆积解决了这个问题。
    我们qtp的任务是:生成稳定的跨多语言的代码(后台写好生成器),写好能拍全景图的函数,最终也实现了抛弃Excel的做法,tester只需录,然后qtp内部帮它自动转成可描述语句。
      我们就是要用提前来的English build下生成代码,等多语言build一来,就让5套机器跑5个语言(无人执守),第二天上班看图即可。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    29#
    发表于 2007-7-20 13:58:25 | 只看该作者
    为什么下到一半就不让我下了
    555555555555555
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    30#
    发表于 2007-7-20 13:58:48 | 只看该作者
    怎么扣这么多积分阿
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    31#
    发表于 2007-7-20 13:59:23 | 只看该作者
    强烈要求不要扣这么多分
    我明明还有17分的
    结果还不够下8个文件
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    32#
    发表于 2007-7-20 14:22:41 | 只看该作者
    最后一个好像有问题
    下载了两次都不对
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    33#
     楼主| 发表于 2007-7-20 15:13:53 | 只看该作者
    51testing上传一次最大附件要求小于2M,我下次准备用webEX来录,尽量小些。
    传上8个文件至少需要30分钟(要分8次传)
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    34#
    发表于 2007-7-21 17:23:17 | 只看该作者
    原帖由 梦醒十分 于 2007-7-20 13:41 发表

      那几万行代码是在这种情况下产生的:
    产品测试要求:
      产品功能已经不用测了。
      要求在英,简中,繁中,日文,韩文下去跑case找本地化的bug。
    每个case之间除了login可重用外,几乎没有相同的地方,所 ...


    LZ的所谓数据驱动测试框架,在思路上是好的,但在实行方面根本是行不通的!
    从技术上,很多object不是一个attribute就能identify的,更不用说一些dynamic的object!
    从业务上,你的Demo只能做极其简单的test case,这对于现在逻辑这么复杂的系统,根本没用。譬如,各种各样的validation和checking,你的框架如何实现?既然是数据驱动,不同数据会导致不同的逻辑,你的框架如何cover这些多变的逻辑。

    在下真的很想跟LZ学习如何推销和包装自己,感觉LZ做得很成功。

    [ 本帖最后由 garyyes 于 2007-7-21 17:55 编辑 ]
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    35#
    发表于 2007-7-21 18:01:07 | 只看该作者
    原帖由 梦醒十分 于 2007-7-20 13:41 发表

      那几万行代码是在这种情况下产生的:
    产品测试要求:
      产品功能已经不用测了。
      要求在英,简中,繁中,日文,韩文下去跑case找本地化的bug。
    每个case之间除了login可重用外,几乎没有相同的地方,所 ...

    而且,你做本地化automation test的思路和方法都错了!因为几个语言版本,它们的业务逻辑是一样的,只是QTP 里面的identify的object变了,所以你只需要把object的属性改改,就能全部重用了。
    ^_^ ,说得不对的地方,请赐教。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    36#
    发表于 2007-7-21 23:37:01 | 只看该作者
    不知为什么,下载总是错误,看不了..........发表不了看法,呵呵

    还是很感谢楼主的共享精神的
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    37#
    发表于 2007-7-21 23:59:59 | 只看该作者
    其实我觉得不同的系统,根据不同的应用情况,架构的选用也是不一样的。因地制宜吧。
    以前我做一个B/S系统的架构体系,采用的就是三层结构:
    逻辑层
    应用层
    组织层
    逻辑层是底层的一些接口函数,完成业务人员所需要的功能特性吧
    应用层是添加数据相关需要的数据,实现逻辑实际功能
    组织层是管理Action的调度,安排执行顺序与错误处理机制
    好处在于逻辑层的封装把复杂的脚本实现业务过程信息对外屏蔽,用户只需关心应用层数据的注入,而把变化的数据层信息的提取放在了数据库中,这样用户只需要在一个小程序里牵动数据库信息的变更,就可以产生出合适的自动化脚本。组织层的建立,可以更好的实现不同的测试策略流程...........

    我现在做的一个在C/S结构下使用的架构,用户只需在特定目录建立一个很简单的文本文件,就可以自动生成出相关的自动化脚本,而只要和开发的约定一个共同的“语言”进行控件的属性使用,可以做到,还没出来的特性,相关的自动化脚本已经完成,把测试更前端的推进到开发的领域中去。
    不过这确实是件需要很多基本条件的都已完备才能做到的。

    看到这么多高手在聊,忍不住也说上几句,希望各位高手乱砸,呵呵
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    38#
    发表于 2007-7-22 02:33:25 | 只看该作者
    原帖由 denisye 于 2007-7-21 23:59 发表
    其实我觉得不同的系统,根据不同的应用情况,架构的选用也是不一样的。因地制宜吧。
    以前我做一个B/S系统的架构体系,采用的就是三层结构:
    逻辑层
    应用层
    组织层
    逻辑层是底层的一些接口函数,完成业务人 ...


    呵呵,感觉你这个分层设计和我架构里的很象:

    >>逻辑层是底层的一些接口函数,完成业务人员所需要的功能特性吧
    对应于我架构里的业务函数层,面向界面,封装各个业务操作,供Case函数层使用

    >>应用层是添加数据相关需要的数据,实现逻辑实际功能
    对应于我架构里的Case函数层,跟界面无关,只面向数据,完成各个Case的测试逻辑

    >>组织层是管理Action的调度,安排执行顺序与错误处理机制
    对应于我架构里的QTP主控模块,控制Case的运行。
    QTP主控模块提供一个Excel文件,让用户在里面指定要运行的Case和Case参数。
    然后QTP主控模块根据这个Excel来控制和完成整个测试的执行。同时提供测试结果记录、运行日志记录、错误保护等功能。

    不知道是不是这样的?

    [ 本帖最后由 yabest 于 2007-7-22 02:38 编辑 ]
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    39#
    发表于 2007-7-22 10:26:45 | 只看该作者
    后面的怎么下不了啊??????
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    40#
    发表于 2007-7-23 04:07:28 | 只看该作者
    我之前做过Web的,C/S的,Terminal的Automation test。其中web的系统,是最麻烦,最令人头痛的,因为动态的东西太多了。在我眼中,不同的系统只有逻辑的简单、复杂之分,其它并无影响。如果一个框架可以handle复杂的系统,那么更不用说简单的系统了。

    我也见识过很多套框架,从分层设计上说,都大同小异,而最大不同就是实施的具体方法上面。QTP现在主要有3种方法:
    1,Record、Modify & Playback
    2,Descriptive Programming
    3,LZ所说的Keyword Driven Framework (其实LZ做Demo的Framework,我手头上就有一套,几乎一摸一样,是从印度带回来的。)

    Keyword Driven Framework的利弊:容易使用,不会写code的人也能做;但功能超级弱,没有逻辑判断,更要命的是不能实现循环!这是与automation test的目的是违背的,无法测试大量的数据。
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-11-24 03:13 , Processed in 0.078984 second(s), 22 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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