51Testing软件测试论坛

标题: GUI的自动化测试的三种类型 [打印本页]

作者: minz32 时间: 2004-6-29 08:19
标题: GUI的自动化测试的三种类型
GUI的自动化测试可以由简入难分成三种类型：
1）纪录回放类：
这一类不需要太多的计划，编程和调试。优点在于简单，方便。缺点在于稳定性差，所以脚本运行寿命短，而且与不同配置的兼容性差。同时由于缺少结果的验证部分，基本上找不到什么Bug。可考虑在产品开发接近尾声时，用于尚未自动化的已知Bug的回归检验。

2）测试用例自动化类：
这一类是指将需要反复测试或在多种配置下重复测试的用例自动化。基本实现过程通常为：
- 设计测试计划
- 设计测试用例
- 针对每一个用例评估自动化的可行性和经济性
- 将决定要自动化的用例作详细步骤分解。
- 编写公用步骤，公用资源库（Logging 和 exception handling 部分是必不可少的）
- 编写自动化程序（别忘了结果的验证部分）
- 调试
- 实际运行

这一类自动化测试最为灵活，也能发现较多的Bug。又能较好的与测试计划相协调。当前多数测试做的比较好的企业都主要使用这种类型的自动化。

3）自动测试类：
这一类是指自动生成测试用例并自动运行。这类自动化测试的最大的优点在于它的无限可能性。另外它通常能发现手工测试极难发现的错误。而且一旦实现了这种自动化，其维护费用实际上是大大低于前两类测试的。不过这类测试自动化的初始投入非常高，而且它的效果受其智能化程度的制约也非常大。除非是专业测试公司或是象微软、IBM这类超大型企业，多半都没有实力来研究这类测试自动化。
不过从长远来说，只要有较好的工具能将这类自动化的初始投入降下来，这类测试自动化才是软件测试发展的必然方向。
这一类测试的基本实现过程通常是：
- 购买或开发基本测试自动化框架
- 编写必要的接口，钩子，及其他公用资源。
- 建立软件、组件、或功能的行为模型
- 设立测试目标等参数
- 自动生成测试用例及测试计划
- 筛选并运行测试用例
- 评估结果

作者: Richard 时间: 2004-9-24 16:18
标题: 现在有个轮廓了
现在有个轮廓了

作者: 常青藤 时间: 2004-10-7 12:52
楼主对自动化测试总结的不错，我想补充2点：
1）纪录回放类的测试软件最大优点是能节省我们有限的人力，比如我们用winrunner 开1000多个customer 10000多个accout，是不是很省力呢？
2）目前的GUI测试软件的局限性。只能被动捕获被测试系统的执行信息,而不能和被测试系统进行交互,且有选择地捕获被测系统的执行信息; 在面向路径测试用例的生成问题上很有局限性.

作者: QA_BAY 时间: 2004-11-3 13:19

Originally posted by 常青藤 at 2004-10-7 12:52 PM:
楼主对自动化测试总结的不错，我想补充2点：
1）纪录回放类的测试软件最大优点是能节省我们有限的人力，比如我们用winrunner 开1000多个customer 10000多个accout，是不是很省力呢？
2）目前的GUI测试软件的局 ...

你说用winrunner 开1000多个customer 10000多个accout,在哪里设呢,可以告诉我一下吗?或者有例子吗?

作者: peggie 时间: 2005-1-30 17:56
标题: 请问这句话如何理解？
1）纪录回放类：
可考虑在产品开发接近尾声时，用于尚未自动化的已知Bug的回归检验。

作者: 常青藤 时间: 2005-3-12 21:00
QA_BAY，你想要的例子。由于涉及到公司机密问题，我也没办法给你。sorry

作者: 有点眉目了 时间: 2005-4-27 13:43
写的好！！顶！！

作者: takiro 时间: 2005-5-31 09:21
对于以上的几点用简单的说法可以这样说吗？
1。记录回放
即是录制GUI界面过程然后回放过程来发现BUG
2。测试用例自动化类
即是针对需要自动化测试的部分筛选合适的数据用例录制操作流程再对录制脚本进行维护和修改来更好地发现BUG
3。自动测试类
即是根据自身的情况开发或是购买自动化框架然后自己来添入内部代码生成合适的
测试用例来指导自动化测试测试完毕评价结果

作者: rzm_1974 时间: 2005-6-20 11:00
我的理解是
1.已经很明确了，没什么好说的
2.手动写测试用例和组织数据。设计测试脚本。然后用设计的脚本去跑你的用例和数据，并得出测试的结果。
3.框架能够根据你的需要自动生成用例，数据。然后系统可以运行产生的用例和数据。并得出测试的结果.

不知我的理解是否正确，望楼主指正。谢谢。

作者: lvsh11 时间: 2005-8-2 17:48
基本了解。~~

作者: xiaoshancom 时间: 2005-8-4 14:55
微软现在用的自动化测试策虐是测试开发人员预期最可能出现bug的地方
然后在代码中throws exception
质量的保证完全由测试开发人员自己掌握

作者: 竹林 时间: 2005-8-11 16:15
收获多多：）

作者: ww0221542 时间: 2005-8-15 14:43
对楼主所说的第三点不是很明白，怎样可以自动生成测试用例呢？是自动生成测试数据还是什么？微软和IBM可以做到这一点么（像楼主说的自动化测试，如果能，请指出是怎么做到的，谢谢）？
另外微软的测试也不是那么简单的，具体的项目有具体不同的测试框架和方法，仅仅throw exception和一些小的私人公司也没什么区别了。

作者: xiaoshancom 时间: 2005-8-25 18:14
因为结果是被动的预期
写脚本的要预期最可能出现错误的地方
这样才能生成完整的bug报告

作者: 阿不 时间: 2006-4-3 01:25
有一点点儿懂了～～～

作者: 983221wy 时间: 2006-4-5 09:18
谢谢了！！！！

作者: 貔貅 时间: 2006-4-26 17:21
人工智能没有成熟前,第三点是不可能实现的.微软及IBM也无非作到第二点而已

作者: xiaocao412 时间: 2006-5-15 14:04
搂主可不可以将第2种方法相应的文档给大家分享一下。

作者: dolphincl 时间: 2007-7-31 17:09
自动化测试进行时 sdlkfj5

作者: liulinzhu 时间: 2007-8-8 15:59
3）自动测试类：
这一类是指自动生成测试用例并自动运行。这类自动化测试的最大的优点在于它的无限可能性。另外它通常能发现手工测试极难发现的错误。而且一旦实现了这种自动化，其维护费用实际上是大大低于前两类测试的。不过这类测试自动化的初始投入非常高，而且它的效果受其智能化程度的制约也非常大。除非是专业测试公司或是象微软、IBM这类超大型企业，多半都没有实力来研究这类测试自动化。
不过从长远来说，只要有较好的工具能将这类自动化的初始投入降下来，这类测试自动化才是软件测试发展的必然方向。
这一类测试的基本实现过程通常是：
- 购买或开发基本测试自动化框架
- 编写必要的接口，钩子，及其他公用资源。
- 建立软件、组件、或功能的行为模型
- 设立测试目标等参数
- 自动生成测试用例及测试计划
- 筛选并运行测试用例
- 评估结果

这种有点悬，微软，IBM也没达到这点，身边一个同事就是刚从上海微软出来的，sdlkfj2

作者: liulinzhu 时间: 2007-8-8 16:02
智能化再怎么高，可毕竟还是人设计出来的，并不可能应付实际种种情况，想达到100%自动化，犹如爬梯登天，水中捞月。

作者: shmily8109 时间: 2007-8-17 16:47
Thanks all

作者: smilefox 时间: 2007-8-24 23:26

原帖由 ww0221542 于 2005-8-15 14:43 发表
对楼主所说的第三点不是很明白，怎样可以自动生成测试用例呢？是自动生成测试数据还是什么？微软和IBM可以做到这一点么（像楼主说的自动化测试，如果能，请指出是怎么做到的，谢谢）？
另外微软的测试也不是那 ...

对于第三点，我的理解是数据驱动的测试，面向模型的测试。
简单说，可能是根据典型的输入输出数据，自动建模，自动生成测试用例。
Model-based testing，如果有兴趣可以查一下。
IBM和微软虽然没有大规模推广使用这种方法（成本问题），但是确实有过这方面的研究，而且有论文。有兴趣的网友可以自己Google一下。

作者: efg03 时间: 2007-8-27 11:37
GUI...
刚上路

作者: xianzi 时间: 2007-9-14 18:01
在自学，偶要做自动化测试

作者: yongshenggu 时间: 2007-10-28 16:06
菜鸟,看不懂

作者: hongrong.li 时间: 2008-1-30 11:32
标题: 回复 4# 的帖子
数据驱动

作者: sendyli 时间: 2008-4-14 23:46
gui的自动化测试工具介绍几个。
想了解一下

作者: baby0808 时间: 2008-7-9 10:09
急需自动化测试人员

做测试的兄弟朋友们大家好
1.五百强的it公司-欧美企业
2.急需自动化测试，白盒测试人员
3.地点是上海，成都
4.英语可以沟通

有家是四川的或者是周边地区的测试的朋友，回家发展也是很不错的选择，和家人在一起，生活的舒适惬意。
有感兴趣的朋友可以加我msn：bess.zhang@live.cn详谈，当然有朋友的朋友也可以互相推荐呀！！

作者: lin85210 时间: 2008-9-23 16:22
呵呵，，见长了，不过好像上海这里的公司真正做到的不多，能够把第2做到80%程度就很让人欣慰了。

作者: inoran 时间: 2008-11-10 11:56
3）自动测试类：
这一类是指自动生成测试用例并自动运行。这类自动化测试的最大的优点在于它的无限可能性。另外它通常能发现手工测试极难发现的错误。而且一旦实现了这种自动化，其维护费用实际上是大大低于前两类测试的。不过这类测试自动化的初始投入非常高，而且它的效果受其智能化程度的制约也非常大。除非是专业测试公司或是象微软、IBM这类超大型企业，多半都没有实力来研究这类测试自动化。
不过从长远来说，只要有较好的工具能将这类自动化的初始投入降下来，这类测试自动化才是软件测试发展的必然方向。
这一类测试的基本实现过程通常是：
- 购买或开发基本测试自动化框架
- 编写必要的接口，钩子，及其他公用资源。
- 建立软件、组件、或功能的行为模型
- 设立测试目标等参数
- 自动生成测试用例及测试计划
- 筛选并运行测试用例
- 评估结果

智能化生成测试计划和测试用例，真的是很美妙的构想，但还是没能有机会看到- -
从目前MS成熟的，正在使用的测试框架来看，还是以自动化框架为基础，提供大量的接口和方法，用代码的方式手工的编写自动化测试脚本，并以集成度极高的测试管理工具，提供预置、自动的测试用例管理，环境搭建，测试结果分析等功能来实现高度的自动化。
作为自动化测试从业者，帮助和推动国内自动化框架开发的能力，形成系统的，可持续的自动化流程是当务之急；并非会使用一两个工具录制加强就可以的。
个人见解，请勿拍砖

作者: 里米特 时间: 2009-2-4 15:10
3）自动测试类
可以是可以做，但要看具体的行业、项目和业务情况，比如网络游戏，做起来就很难，银行的一些业务就相对简单些。
不过这肯定是未来的发展方向。

[ 本帖最后由里米特于 2009-2-4 15:12 编辑 ]

作者: zmy5163 时间: 2009-2-5 09:58
学习了..

作者: raistlin_t 时间: 2009-3-5 12:39
学习中，有点启发

作者: Pleany 时间: 2009-3-19 17:41
学习之

作者: xywhite 时间: 2009-3-23 00:02
同意18#的,希望楼主可以分享第二种方法相关的文档.

作者: ospring 时间: 2009-4-11 12:18
标题: 3) 智能测试系统
自动化测试工具结合NN、AI之类的技术，据说同济某教授的学生在研究

作者: 小飞侠007 时间: 2009-4-16 17:06
标题: 谢谢，楼主
谢了，楼主，学习le ................

作者: tottawang 时间: 2009-6-22 11:00
标题: 回复 20# 的帖子
正在实践楼主所说的第三类自动化方案。有研究过的朋友可以讨论一下

作者: douxiance 时间: 2009-6-30 21:19
标题: 楼主总结的不错，给大家的测试指明了方向。
测试就是要平衡质量、进度、效益。用最少的开销做尽可能多的测试。

作者: jasiond120 时间: 2009-10-4 21:03
1）纪录回放类的测试软件最大优点是能节省我们有限的人力，比如我们用winrunner 开1000多个customer 10000多个accout，是不是很省力呢？
2）目前的GUI测试软件的局限性。只能被动捕获被测试系统的执行信息,而不能和被测试系统进行交互,且有选择地捕获被测系统的执行信息; 在面向路径测试用例的生成问题上很有局限性.

第一点：如果你真的要用WINRUNNER开1000个ACCOUNT的意义是什么，为什么不写个存储过程搞定呢？
第二点：这类问题其实在现在的脚本中都可以做到交互。

作者: woza 时间: 2009-10-13 16:51

原帖由 inoran 于 2008-11-10 11:56 发表
3）从目前MS成熟的，正在使用的测试框架来看，还是以自动化框架为基础，提供大量的接口和方法，用代码的方式手工的编写自动化测试脚本，并以集成度极高的测试管理工具，提供预置、自动的测试用例管理，环境搭建，测试结果分析等功能来实现高度的自动化。
作为自动化测试从业者，帮助和推动国内自动化框架开发的能力，形成系统的，可持续的自动化流程是当务之急；并非会使用一两个工具录制加强就可以的。
个人见解，请勿拍砖 ...

我们目前也只做到这种，LZ说的自动产生用例，从来没见过。如果AI能做到这种程度，那测试完全靠AI就能实现了，都不用人工了。

作者: Fastpoint 时间: 2009-10-14 16:13
1）纪录回放类的测试软件最大优点是能节省我们有限的人力，比如我们用winrunner 开1000多个customer 10000多个accout，是不是很省力呢？
2）目前的GUI测试软件的局限性。只能被动捕获被测试系统的执行信息,而不能和被测试系统进行交互,且有选择地捕获被测系统的执行信息; 在面向路径测试用例的生成问题上很有局限性.

第一点：如果你真的要用WINRUNNER开1000个ACCOUNT的意义是什么，为什么不写个存储过程搞定呢？
第二点：这类问题其实在现在的脚本中都可以做到交互。

第一种只不过是通过三方扩展实现跟WR没有一点关系，实际上正如网友所说写个存储过程的形式交给WR调用。

测试用例AI生成基本上目前不太现实，脏数据和生成代码质量欠佳，同样需要人力花大时间筛选，比直接写还要浪费资源。另外如果是你们自己开发对象识别核心另外算，依靠任何市面上现有的商业工具谈这个，基本上是空中楼阁。

作者: qqqfresh 时间: 2009-12-10 17:26
自动生成测试用例，我接触过的，是完全可能的。确实花费相当大的前期投入。
不过是针对白盒测试的。源码完全暴露，代码的逻辑非常清楚且统一。
“统一风格”最重要，这样自动生成测试用例就有据可循。

作者: mentgmery 时间: 2009-12-11 10:17
谁说的,微软N多自动化测试框架,我用过KAF,很不错的平台

作者: carol2000 时间: 2009-12-15 15:53
接触过“ 2）测试用例自动化类：”
第3类我想应该是在第2类测试高度成熟基础上的一次升华吧

- 购买或开发基本测试自动化框架（第2类）
- 编写必要的接口，钩子，及其他公用资源（第2类）
- 建立软件、组件、或功能的行为模型 （这个是难点）
- 自动生成测试用例及测试计划（如果每个自动化测试脚本里的API都有其明确的含义，用例生成应该不难）
- 筛选并运行测试用例（用例和脚本一一对应就行了）
- 评估结果（如果每一个测试用例都有明确的Pass/Fail/ErrorException,那么测试计划的好坏可以判断）

作者: GeorgeWangLC 时间: 2010-1-2 21:00
标题: 回复 1# 的帖子
帮顶

作者: guo24biao 时间: 2010-5-1 14:52
标题: 回复 1# 的帖子
好东西。学习了啊。。。。。

作者: heqingbluesky 时间: 2010-10-19 23:54
现在能够把第二类做好的公司都很少。

我很想亲眼见识一下第三类的实现方式。

作者: 散步的SUN 时间: 2011-2-16 12:50
个人觉得中国如今采用第二种比较好，第三种只是个趋势；稳固第二种，翘首第三种；
就中国而言，大多数公司喜欢的是看到实际效用，包括短期和长期的。而第三种是一个很长期的过程，而且不一定效果能实现多大，所以就近期内，第三种只能是趋势

作者: coolwind09 时间: 2011-2-17 16:25
不懂自动化测试框架

作者: sarahwsn 时间: 2011-3-4 16:52
希望和做自动化测试方面的朋友私聊一下，方便的话可以加我 msn:sarahwangsuna@hotmail.com qq;642403889 电话：13436928295

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