bbaker avatar image
bbaker asked bbaker posted

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']



iTestGUI Testing(Web-Java Swing-etc)
route_table.png (22.0 KiB)
10 |950

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

1 Answer

PreetS avatar image
PreetS answered PreetS posted

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

10 |950

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

bbaker avatar image bbaker commented ·

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 Likes 0 ·
PreetS avatar image PreetS bbaker commented ·

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 Likes 0 ·
bbaker avatar image bbaker PreetS commented ·

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 Likes 0 ·
KumarS avatar image KumarS bbaker commented ·

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 Likes 0 ·

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

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