GUI的自动化测试的三种类型 - 第3页 - [自动化测试工具及框架] - 51Testing软件测试论坛

jasiond120 发表于 2009-10-4 21:03:05

woza 发表于 2009-10-13 16:51:01

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

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

Fastpoint 发表于 2009-10-14 16:13:54

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

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

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

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

qqqfresh 发表于 2009-12-10 17:26:27

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

mentgmery 发表于 2009-12-11 10:17:17

谁说的,微软N多自动化测试框架,我用过KAF,很不错的平台

carol2000 发表于 2009-12-15 15:53:16

接触过“ 2）测试用例自动化类：”
第3类我想应该是在第2类测试高度成熟基础上的一次升华吧

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

GeorgeWangLC 发表于 2010-1-2 21:00:23

回复 1# 的帖子

帮顶

guo24biao 发表于 2010-5-1 14:52:21

回复 1# 的帖子

好东西。学习了啊。。。。。

heqingbluesky 发表于 2010-10-19 23:54:33

现在能够把第二类做好的公司都很少。

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

散步的SUN 发表于 2011-2-16 12:50:41

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

coolwind09 发表于 2011-2-17 16:25:57

不懂自动化测试框架

sarahwsn 发表于 2011-3-4 16:52:35

希望和做自动化测试方面的朋友私聊一下，方便的话可以加我 msn:sarahwangsuna@hotmail.com qq;642403889 电话：13436928295

页: 1 2 [3]

51Testing软件测试论坛 's Archiver

回复 1# 的帖子

回复 1# 的帖子