最新--功能自动化测试“框架”演示-1（视频）

coomon2000

2222222222222222222

coomon2000

444444444444444433333333

wtucel

原帖由 yabest 于 2007-7-19 19:19 发表
呵呵，感觉这个框架没什么意义。

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

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

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

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

阶段的,只有先依葫芦画瓢

walker1020

梦醒十分 辛苦了！

梦醒十分

原帖由 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(宏)写出类似的东东，只能向别人索取现成的，那么我白费劲了。。

yabest

原帖由 梦醒十分 于 2007-7-20 09:43 发表


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

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

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

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

可能你讲的还不够清楚，期望能看到你下几期的演示。

yabest

原帖由 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函数。

梦醒十分

原帖由 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个语言（无人执守），第二天上班看图即可。

wang0744

为什么下到一半就不让我下了
555555555555555

wang0744

怎么扣这么多积分阿

wang0744

强烈要求不要扣这么多分
我明明还有17分的
结果还不够下8个文件

wang0744

最后一个好像有问题
下载了两次都不对

梦醒十分

51testing上传一次最大附件要求小于2M，我下次准备用webEX来录，尽量小些。
传上8个文件至少需要30分钟（要分8次传）

garyyes

原帖由 梦醒十分 于 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 编辑 ]

garyyes

原帖由 梦醒十分 于 2007-7-20 13:41 发表

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

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

denisye

不知为什么，下载总是错误，看不了..........发表不了看法，呵呵

还是很感谢楼主的共享精神的

denisye

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

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

看到这么多高手在聊，忍不住也说上几句，希望各位高手乱砸，呵呵

yabest

原帖由 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 编辑 ]

luanxue

后面的怎么下不了啊？？？？？？

garyyes

我之前做过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的目的是违背的，无法测试大量的数据。