如何判断提示框存在？

dycadrtf

如何判断Browser("Microsoft ").Dialog("Microsoft Internet Explorer")提示框存在呢？

zte_boy

Browser("Microsoft ").Dialog("Microsoft Internet Explorer").exist(2)

假装不在

同楼上...

tanky

给你个必杀技：
Browser("XXX").Dialog("object class:=#32770").Exist(3)
对象库都不要了

今天有雾

同意二楼的方法，虽然4楼也可以，不过没必要还是少用描述性编程的好

tanky

想听听5楼的说法，为什么还是少用描述性编程的好。

看来这个争论多年的问题还是没有解决啊

我在一个QQ群里面，有些人说他很少用对象库。

lisilin

我对这个也很好奇，对于维护成本比较，描述性编程好还是利用对象库，请大侠指教啊

假装不在

这个问题昨天和yabest讨论了，未果。

我还是觉得你是4楼写的那个方法好点，起码少去添加对象库的这步操作。以后也可以通用。
例如你还可以添加到场景函数中去。
如果说每次用这个函数都要去添加一个msgbox这样的对象进去，那不是很麻烦，有时候你甚至不知道去哪里点它让它跳出来。

tanky

4楼的写法，最大的优势在于：对一些意料之外了对话框的弹出，也能进行判断，然后由你的代

码去处理这种意外。你的程序如果存在100个有可能出现的对话框，我想问下5楼，你是不是录

100个呢？这一百个对话框，你能保证你在录制的时候都能如你所愿弹出来呢？

假装不在

维护的成本这个，使用描述当然比使用对象库更好。
但是早期你在编写脚本时候，描述的速度自然也没有对象库的快。
有利有弊吧。
说到维护时候，对象库的维护麻烦的地方就是如果做了什么其它小的修改，哪么你就要去再添加一次。
例如这样，你的一个browser,下边有个page，page下有个link，还有许多其它的控件，如果link变化了，你要再去添加（先不说通过手工修改的方法），哪么如果browser识别成一个browser_2时候，在browser下边的其它所有对象都需要重新录（其实也可以不用重新录，不过是看不顺眼罢了，多搞几次估计要到browser_100了。）
哪么原来的代码里面就会出现了例如这样的情况：
browser("browser").page...........
browser("browser_1").page....links....
browser("browser").page
很不好看 ，我个人比较喜欢追求完美，我会把browser的对象干掉，再录一次所有的对象进去一次，这样感觉时间就浪费掉了。
这个只是说到维护时候的一些小毛病。

zte_boy

谁告诉你有100个就要录100个的？
我一个一样解决所有Dialog的问题，稍微处理下就好了
不过就简单方便而言，我还是喜欢假装不在那个

dycadrtf

你是咋一个一样解决的？

tanky

原帖由 zte_boy 于 2008-7-25 11:56 发表
谁告诉你有100个就要录100个的？
我一个一样解决所有Dialog的问题，稍微处理下就好了
不过就简单方便而言，我还是喜欢假装不在那个

这是技术论坛，又不是灌水论坛。有什么好方法你说就是嘛！在这打口水仗有什么意思？

你别告诉我，你的方法是SetTOProperty。这和描述性编程有什么区别？还拐弯抹角的。

lingxin5013

ＬＳ　我顶你！

enjoytest

原帖由 假装不在 于 2008-7-25 11:30 发表
维护的成本这个，使用描述当然比使用对象库更好。
但是早期你在编写脚本时候，描述的速度自然也没有对象库的快。
有利有弊吧。
说到维护时候，对象库的维护麻烦的地方就是如果做了什么其它小的修改，哪么你就要去 ...

同感，这种情况在QTP中经常遇到
这时候也可以将新产生的link对象复制到brower中，把brower_2删掉，这样再修改一下代码就可以了

录制时QTP不能很好的利用已有的对象库资源是QTP自身的缺陷，这个以后可能会改善吧

假装不在

我记得QTP9.5就可以支持自己手工添加，也就是自己直接想添加什么对象都可以添加进去，不管是否存在的。
关于楼上说的，在对象库里面把browser_2的link复制放到browser中，这个我看到里面有个复制功能，但其实我试了很多次没有一次成功的。指点指点。

zte_boy

9.x以上的版本对象库都支持对象拖动，在对象库里吧新的对象拖动到父对象下，把那个有编号后缀的删掉就好

yabest

原帖由 假装不在 于 2008-7-25 11:30 发表
维护的成本这个，使用描述当然比使用对象库更好。
但是早期你在编写脚本时候，描述的速度自然也没有对象库的快。
有利有弊吧。
说到维护时候，对象库的维护麻烦的地方就是如果做了什么其它小的修改，哪么你就要去 ...

晕啊，晕啊！
真奇怪，Browser对象从一个变成两个，你遇到这个问题，怎么不去想办法解决，怎么不去研究问题的根源呢？
这个Browser问题不解决，反而跑去怪罪、折腾Browser下面的其它对象干嘛呢？！多累啊！
这就有点象什么，上梁不正下梁歪，上梁不正了你不去纠正，那下梁再怎么弄也是歪的，再怎么纠正也是够痛苦的！



[ 本帖最后由 yabest 于 2008-7-26 22:39 编辑 ]

yabest

对象库 vs 描述性编程， 建议大家好好看下QTP帮助里对描述性编程的阐述和定位

Using Programmatic Descriptions

When you record an operation on an object, QuickTest adds the appropriate test object to the object repository. Once the object exists in the object repository, you can add statements in the Expert View to perform additional methods on that object. To add these statements, you usually enter the name (not case sensitive) of each of the objects in the object's hierarchy as the object description, and then add the appropriate method.

For example, in the statement below, username is the name of an edit field. The edit field is located on a page with the name Mercury Tours and the page was recorded in a browser with the name Mercury Tours.

Browser("Mercury Tours").Page("Mercury Tours").WebEdit("username")

Because each object in the object repository has a unique name, the object name is all you need to specify. During the test run, QuickTest finds the object in the object repository based on its name and parent objects, and uses the stored test object description for that test object to identify the object in your Web site or application.

You can also instruct QuickTest to perform methods on objects without referring to the object repository or to the object's name. To do this, you provide QuickTest with a list of properties and values that QuickTest can use to identify the object or objects on which you want to perform a method.

Such a programmatic description can be very useful if you want to perform an operation on an object that is not stored in the object repository. You can also use programmatic descriptions in order to perform the same operation on several objects with certain identical properties, or in order to perform an operation on an object whose properties match a description that you determine dynamically during the run session.

For example, suppose you are testing a Web site that generates a list of potential employers based on biographical information you provide, and offers to send your resume to the employer names you select from the list. You want your test to select all the employers displayed in the list, but when you design your test, you do not know how many check boxes will be displayed on the page, and you cannot, of course, know the exact object description of each check box. In this situation, you can use a programmatic description to instruct QuickTest to perform a Set "ON" method for all objects that fit the description: HTML TAG = input, TYPE = check box.

There are two types of programmatic descriptions. You can either list the set of properties and values that describe the object directly in a test statement, or you can add a collection of properties and values to a Description object, and then enter the Description object name in the statement.

Entering programmatic descriptions directly into your statements may be the easier method for basic object-description needs. However, in most cases, the Description object method is more powerful and more efficient.

[ 本帖最后由 yabest 于 2008-7-26 22:11 编辑 ]

yabest

原帖由 tanky 于 2008-7-25 11:30 发表
4楼的写法，最大的优势在于：对一些意料之外了对话框的弹出，也能进行判断，然后由你的代

码去处理这种意外。你的程序如果存在100个有可能出现的对话框，我想问下5楼，你是不是录

100个呢？这一百个对话框，你 ...

你这个是典型的适用于描述性编程的地方！

对象属性动态变化不确定的，或者要对多个对象做同样操作的，
如不同窗口里的确认、成功、失败对话框的处理都一样的，
如同一窗口里多个对象的处理都一样的，
这些都是最适合使用描述性编程的地方，这也是如上面QTP帮助里所说的，QTP提供描述性编程的目的！

除了这些特定的情况，其他地方还是用对象库的好，对象库是QTP的精华，是王道！

不然QTP干嘛缺省使用对象库，而对描述性编程的推荐这么少啊。
正是QTP对描述性编程推荐这么少，导致有人发现了描述性编程，就像发现了绝世武林秘籍似的，而看不起大路货的对象库了！

[ 本帖最后由 yabest 于 2008-7-26 22:43 编辑 ]