GUI的自动化测试的三种类型

minz32 发表于 2004-6-29 08:19:07

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

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

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

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

Richard 发表于 2004-9-24 16:18:59

现在有个轮廓了

常青藤 发表于 2004-10-7 12:52:37

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

QA_BAY 发表于 2004-11-3 13:19:18

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:54

请问这句话如何理解？

1）纪录回放类：
可考虑在产品开发接近尾声时，用于尚未自动化的已知Bug的回归检验。

常青藤 发表于 2005-3-12 21:00:13

QA_BAY，你想要的例子。由于涉及到公司机密问题，我也没办法给你。sorry

有点眉目了 发表于 2005-4-27 13:43:40

写的好！！顶！！

takiro 发表于 2005-5-31 09:21:02

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

rzm_1974 发表于 2005-6-20 11:00:49

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

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

lvsh11 发表于 2005-8-2 17:48:42

基本了解。~~

xiaoshancom 发表于 2005-8-4 14:55:14

微软现在用的自动化测试策虐是测试开发人员预期最可能出现bug的地方
然后在代码中throws exception
质量的保证完全由测试开发人员自己掌握

竹林发表于 2005-8-11 16:15:11

收获多多：）

ww0221542 发表于 2005-8-15 14:43:59

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

xiaoshancom 发表于 2005-8-25 18:14:49

因为结果是被动的预期
写脚本的要预期最可能出现错误的地方
这样才能生成完整的bug报告

阿不发表于 2006-4-3 01:25:51

有一点点儿懂了～～～

983221wy 发表于 2006-4-5 09:18:06

谢谢了！！！！

貔貅发表于 2006-4-26 17:21:10

人工智能没有成熟前,第三点是不可能实现的.微软及IBM也无非作到第二点而已

xiaocao412 发表于 2006-5-15 14:04:31

搂主可不可以将第2种方法相应的文档给大家分享一下。

dolphincl 发表于 2007-7-31 17:09:48

自动化测试进行时 sdlkfj5

liulinzhu 发表于 2007-8-8 15:59:49

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

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

页: [1] 2 3

51Testing软件测试论坛 's Archiver