Академический Документы
Профессиональный Документы
Культура Документы
GUI Objects, Quicktest Professional by Yaron Assa Before we can move on to some of the more advanced subjects, its probably better if we ensure were all speaking the same language. So now well create a proper base-line for some basic QTP techniques (though even they are sometimes referred to as advanced). One of the most profound techniques necessary for advanced QTP usage is Descriptive Programming (DP).
General Background
When using DP, were bypassing the native object repository (OR) mechanism, which may have many advantages (easy to generate and read code, good data organization, etc.), but is extremely not flexible. Well examine situations in which the ORs advantages are outweighed by the DPs flexibility. In order to fully grasp how DP actually works, its best to first understand how QTPs native OR works. The native OR is not some complex and deep mechanism, but rather a simple way of keeping groups of properties and values. To clarify: Whenever we add a certain window to the OR, QTP gathers the windows properties (e.g. Height=400, Title=New Entity, vbName=NewEntityID), and stores them as a group of propertyvalue pairs. When QTP runs the script, it compares these properties and values to the physical objects, and finds (or fails to find) the object which they describe. Nothing mystical about it.
Usage
In DP, were manually specifying the properties and values by which the relevant object will be identified. This way QTP wont search for the properties data in the OR, but will take it from the DP statement. This can be done in a fast, ad-hoc way, in the very line of the command we want to execute: The syntax is: Class(PROPERTIESSTRINGS).Command, where PROPERTIESSTRINGS specifies the properties and values for the objects identification. For example:
VBWindow("property1:=value1", "property2:=value2").Click
We can even create an object hierarchy (though once we use DP, we must continue to use DP down the hierarchy):
VBWindow("property1:=value1").VBCheckBox("property2:=value2").Click
Of course VBWindow class is just an example for DP with VB objects. DP can be done with SWFWindow, Browser, WinComboBox etc. The only difference between using DP to using the native QTP OR, is in the content within the classs brackets (in this example: VBWindow()). When using the native OR, well put the logical name of the object as defined in the OR. When using DP, well put strings describing the properties and values the object will be identified by (structured as property:=value). This syntax has the benefit of being shot and quick, but may cause problems if well use the object again somewhere else. In this case well have to rewrite the all the description strings, making the code less readable,
and harder to maintain (i.e., if one of the properties were to change, well be forced to make several repairs in different places throughout the code). Luckily, DP allows us to define a static descriptive object, and set its properties once. This way, the script simply refers to the descriptive object:
-Create Object- Dim oDesc Set oDesc = Description.Create -Set ID properties & values oDesc("property1").Value = "value1" oDesc("property2").Value = "value2" -Use and reuse the description object VBWindow(oDesc).Type "Something" VBWindow(oDesc).Close -Release description object Set oDesc = Nothing
Common uses Detailed examples can be found in the attached file: [hideit] Download [/hideit] Well, you might ask yourself why we even bother. QTPs native OR does all these things, is tidier, and up to QTP 9, was the only way to enjoy the benefits of code auto-complete. Well, in some sense, youre right sometimes, the best way to go is to use the OR, straight up. However, in some cases, DP is preferable by far, and sometimes even the only way to go: Easy-breezy coding: if were only going to use an object once or twice, theres no need to use the slow, complex OR, when you can just immediately write the ID string as part of the command. Moreover, with DP you can copy code-snippets between scripts, without having to worry about references to undefined object in the new script. Inherent dealing with double objects: in case the identification properties and values match more than one object, QTP will through an objects description matches more than one of the objects currently displayed in your application error. If were using the native OR, there no easy way to deal with the situation (we could use a complex Recovery Scenario, but it gets very ugly, very soon). However, DP easily deals with double objects by using the index property. We can add index:=X to the description strings (when X is a zero -based counter), and QTP will point to object #X. Object reference in external functions: when using external functions, you can never count on the relevant object being defined in the calling actions OR. And even if the object is defined there, its logical name might be different, so really, DP remains the only option.
Objects that change hierarchies: sometime an object will appear under a different parent each time (e.g. a popup which appears under the initiating sub-window). In some applications, the only way to work with such objects is with DP.
As you may have noticed, the .ChildObjects command must be executed on a top-level window. This means that you cant get a collection of the top-level windows of an app, only a collection of child-objects In a certain top-level window. This was true until QTP 9, which introduced the Desktop utility object. This allows us to execute Desktop.ChildObjects(oDesc), which returns a collection of top-level windows, so all is well.