Quick Test Professional is only an average tool as far as functional regression test tools go. Ultimately the most reasonable use seems to be to bypass the features that cause the tool to cost what it does and to use the the functionality that is less advertised.
Of the so-called great features is the store for the objects that comprise the application. The first version I had my hands on was 8.2. It could store objects but maintaining them was not really a part of the feature set. 9.2, the next version I got to use, had corrected this minor oversight. However, given my earlier experience, I didn't immediately explore the changes. Having a little time, I've now done so and ultimately I'm not sure that its worth it.
The object repository is the central store of objects within a script or across multiple scripts. With a pretty GUI interface and, now at least, editing features. The structure is its downfall. All objects in QTP can only be addressed via the parental structure, viz. Browser().Page().Frame().WebElement(). This is all fine and well and admittedly does enable one to more easily access any element in the page fairly simply, it has a major drawback within QTP's design. You cannot access the element without including its parent structure.
Sure you could argue against this as being a drawback. The reason for it being a flaw is in the simplicity of test case design and scripting that is accorded by being able to simply refer to a user key or reference name. So lets contrast conventional design with simple design...
In conventional design, much like a recorded script, for each page you address each object individually with the action you want to perform, viz.
Browser().Page().WebEdit(1).Set 1
Browser().Page().WebEdit(2).Set 2
Browser().Page().WebList(1).Select 3
This is not detrimental in itself but when you have 20-odd fields on a page and 5 pages to cover within a single script it rapidly becomes a sad idea. Since a data table has to be created anyway and that data table will (or at least should) have column names that correspond to the fields within the application its pretty clear that being able to address the OR entry by the column reference would make the entire script simpler and a whole lot easier to maintain, viz.
AListOfColumns = Array("1", "2", "3")
For i = 0 To UBound(AListOfColumns)
PerformActionOn(AListOfColumns, Value)
Next
Being able to reference an element in the OR via a reference key in such a way is seemingly impossible. So far the closest I've been able to come is to pass the parent object along with the reference object string to the PerformActionOn function.
The stumbling block seems to be the identification of the parent when you only have the child. Yes its possible to create an external map of the object using a reference key to its entire parent-child relationship but that defeats the object of this current exercise.
Of the so-called great features is the store for the objects that comprise the application. The first version I had my hands on was 8.2. It could store objects but maintaining them was not really a part of the feature set. 9.2, the next version I got to use, had corrected this minor oversight. However, given my earlier experience, I didn't immediately explore the changes. Having a little time, I've now done so and ultimately I'm not sure that its worth it.
The object repository is the central store of objects within a script or across multiple scripts. With a pretty GUI interface and, now at least, editing features. The structure is its downfall. All objects in QTP can only be addressed via the parental structure, viz. Browser().Page().Frame().WebElement(). This is all fine and well and admittedly does enable one to more easily access any element in the page fairly simply, it has a major drawback within QTP's design. You cannot access the element without including its parent structure.
Sure you could argue against this as being a drawback. The reason for it being a flaw is in the simplicity of test case design and scripting that is accorded by being able to simply refer to a user key or reference name. So lets contrast conventional design with simple design...
In conventional design, much like a recorded script, for each page you address each object individually with the action you want to perform, viz.
Browser().Page().WebEdit(1).Set 1
Browser().Page().WebEdit(2).Set 2
Browser().Page().WebList(1).Select 3
This is not detrimental in itself but when you have 20-odd fields on a page and 5 pages to cover within a single script it rapidly becomes a sad idea. Since a data table has to be created anyway and that data table will (or at least should) have column names that correspond to the fields within the application its pretty clear that being able to address the OR entry by the column reference would make the entire script simpler and a whole lot easier to maintain, viz.
AListOfColumns = Array("1", "2", "3")
For i = 0 To UBound(AListOfColumns)
PerformActionOn(AListOfColumns, Value)
Next
Being able to reference an element in the OR via a reference key in such a way is seemingly impossible. So far the closest I've been able to come is to pass the parent object along with the reference object string to the PerformActionOn function.
The stumbling block seems to be the identification of the parent when you only have the child. Yes its possible to create an external map of the object using a reference key to its entire parent-child relationship but that defeats the object of this current exercise.
No comments:
Post a Comment