Web Target Not Found

Question

question

bbaker asked Dec 2, '09 bbaker posted Dec 2, '09

Web Target Not Found

I am running into a problem where iTest can not find an item on a web page.

I have a table on a page, and each row in that table has a submit button. When recording my steps, I click one of the buttons in this table. The problem is when I replay the test, it triggers the event OnWebTargetNotFound when it tries to click the same button. If I put a breakpoint after the Click command, I can manually use the Describe function to see the attributes of the button and it is contains the same location as the recorded Click command that is failing.

Below is the location for both the Click command and the Describe command. I have also attached a picture of the table. If any additional information is needed, please let me know.

//TR[@onclick='document.forms.formAdd.destination1.value="192"; document.forms.formAdd.destination2.value="168"; document.forms.formAdd.destination3.value="255"; document.forms.formAdd.destination4.value="0"; document.forms.formAdd.destinationMask1.value="255"; document.forms.formAdd.destinationMask2.value="255"; document.forms.formAdd.destinationMask3.value="255"; document.forms.formAdd.destinationMask4.value="0"; document.forms.formAdd.route1.value="10"; document.forms.formAdd.route2.value="22"; document.forms.formAdd.route3.value="154"; document.forms.formAdd.route4.value="1"; document.forms.formAdd.distance.value="1"; document.forms.formAdd.tagValue.value="0"; document.getElementById("route1").disabled=false; document.getElementById("route2").disabled=false; document.getElementById("route3").disabled=false; document.getElementById("route4").disabled=false; document.getElementById("routeInterface").disabled=true; document.forms["formAdd"].routeInterface.selectedIndex = "0" ; document.forms.formAdd.gwType.value=""; document.getElementById("gwAddr").checked = true; document.getElementById("gwIf").checked = false; document.forms["formAdd"].trackUsed.selectedIndex ="0"; return true;']/TD[6]/INPUT[@name='Delete' and @value='Delete' and @type='submit']

iTest GUI Testing(Web-Java Swing-etc)

route_table.png (22.0 KiB)

10 |950

Attachments: Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Answer 1 · 2009-12-02T22:30:17Z

PreetS answered Dec 2, '09 PreetS posted Dec 2, '09

This is one of those bizarre scenarios where the algorithm iTest uses to create a target creates a giant string, and it may not be unique in the subsequent runs.

I suggest you change the target string from what got captured to a new one that you define.

You may be able to replace this with something like:

//TR[XXXX]/TD[6]/INPUT[@name='Delete' and @value='Delete' and @type='submit']

where XXX is the 1-based index of the row in the table

4

10 |950

Attachments: Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

bbaker commented · Dec 02, 2009 at 10:52 PM

Well, that's a problem. This test is inserting a route (table row), verifying it can find the new entry, then deleting that entry. The values that are indicated in that giant string will be required to find that entry in the table since they are read from variables. The value of those variables will determine the location of it's entry in the table. So using XXX to define the table row may end up deleteing the wrong entry.

0 ·

PreetS bbaker commented · Dec 02, 2009 at 11:06 PM

Well the table row was just a suggestion, you can use any xpath to get to the element using deterministic arguments.

XXX could be any condition you want using the standard XPATH.

0 ·

bbaker PreetS commented · Dec 03, 2009 at 04:47 PM

Would this be considered a bug/limitation for GUI testing?

Once we begin rolling out iTest to our testing group, there will be several testers recording different web tests. The majority of them will not have expierience with regular expressions or XPATH. As it is now, this testcase will fail because iTest is not identifying data that was just recorded, and the DUT is working properly. Test cases won't be handed off to the automation team until the recorded sessions work properly. This will be a significant impact to our workflow if a recorded test case is not able to pass on replay.

0 ·

KumarS bbaker commented · Dec 03, 2009 at 10:30 PM

One workflow which I can recommend is the following:

Recorded testcase should be re-run by the person who recorded it to see if there are any "dynamic" targets which fail to replay. If it fails, it is most likely due to target containing some value which is dynamic. User will have to fix this target manually.

iTest has a very sophisticated "target finder" which tries to make sure that targets are chosen properly which will work on replay. Since it does not see two instances of the page during capture, it cannot determine what is static and what is dynamic. So a user help is definitely required in such cases.

In our experience, such cases occur very infrequently due to our target finder logic. So capturing is still the fastest way to create a GUI testcase - but some captured steps may require "tuning" occasionally.

0 ·

question