Wildcard for querry part of url

Hello Ted,

The suggestion is reasonable if we can find a website that generats a random URL somewhere in the middle, outside of the Query String portion of the URL. I haven't seen one (but I don't claim to be an expert). Do you know of any real production websites that do this? So for I've only seen dynamic URL's within the Query string portion. Our solution to that today is to set the Page Compare Mode to Full Path. This will make Test Studio automatically ignore the query string portion of the URL.

Regards,
Cody
the Telerik team

Hi
Thank you for the reply.

It is a  bit of a preemptive question  as I look over MS Dynamic CRM urls
 I am still in a discovery mode, and don't know enough about the extent of  its queries.

 Its urls are chalked full of  interesting  stuff and not so interesting stuff,as one can see in the examples below.
I am just starting in on it.  I am fearing I may need to  parse out pieces of the Query  and keep other pieces. 
 I will know more over the next few weeks and perhaps I will be able  to provide specific example of the problem.

/_controls/lookup/lookupinfo.aspx?
DefaultType=
&DefaultViewId=577EA96E-B1F6-499b-98A7-ABB5BE8233F9
&LookupStyle=single&ShowNewButton=1
&ShowPropButton=1&browse=0
&listType=static&membertypecode=4
&objecttypes=4300

Another
etc=3&extraqs=%3f_gridType=3   
& etc=3  
& id=%257bAD96E769-7D6E-E211-91A9-005056A5001C%257d   
& pagemode=iframe
& preloadcache=1363718221870   
& rskey=822216927&pagetype=entityrecord

another
?iObjType=4
&iTotal=1&pId=%7bCE53BD41-3480-E211-9033-005056A5001C%7d
&pType=4

Hello Ted,

I agree the query string, which is defined as everything that appears after the ? in the URL, can contain lots of parameters and interesting arguments. So far it's been my experience that when the query string is very dynamic we can simply instruct Test Studio to ignore the query string, only compare on the base part of the URL and the web tests work as expected.

Let me know if you run into a real example where the above won't work nicely as we'd like it to.

Regards,
Cody
the Telerik team

Hi,

I have this same issue and I was wondering what's the way to ignore the query string?

Thanks in Advance and Regards,

Hi Luis,

What exactly you need to change depends on which problem you are running into:

1. If your elements are getting too cluttered you can make duplicate elements merge by following these instructions.
2. If your tests are failing due to dynamic query strings in the URL property of Frame nodes then adjust the Frame Properties as shown in the attached screen shot.

Regards,
Cody
Telerik

Hi Cody - one of our web apps has a number of different screens accessible from the same page name (aspx), but with only some of the query parameters relevant. Examples are:

http://site/pagename.aspx?subid=822200000003&ro=N&pt=hosp&QAsub=
http://site/pagename.aspx?subid=822200000003&qsid=123&ro=N&mult=N&QAsub=&ssid=1064438&pt=sect
http://site/pagename.aspx?subid=822200000003&qsid=125&ro=N&mult=N&QAsub=&pt=sect

I've highlighted the defining query parameters in bold.
For the first screen, the crucial bit of the query string is pt=hosp. In the second and third screens they both have pt=sect, but are further distinguished by the qsid value (123 or 125).

Is there a way to distinguish these screens using only those parts of the query string, and ignoring the other parts - which are completely dynamic and must be ignored?

Hello Vince,

At test execution time Test Studio doesn't use (doesn't even look at) the URL. When locating elements to act on it takes the approach "Given whatever the current page is, locate the element having the specified properties e.g. src value=x, id=y, etc.". With this in mind there should be no need for you to do anything with regard to "distinguish these screens using only those parts of the query string, and ignoring the other parts".

Now having said that, what problem does these dynamic query strings actually cause when you try to execute your tests? Do your tests fail? If so please Export the step failure details to file and attach that file to this ticket for us to analyse and try to determine the root cause.

Regards,
Cody
Telerik

Hi Cody; thanks for that explanation, that helps.

I'm not getting any problems at test execution time; however, the way the fields are organised in the Element explorer is awkward. The application under test has a number of screens making up a large questionnaire; each screen can have dozens of different fields. It would be helpful if we could distinguish the screens as I described above, otherwise we end up with hundreds of fields under a single 'page' node in the element explorer treeview, which makes it difficult to navigate.

Hi Vince,

Ah I see. Thank you for the clarification. You can adjust which pages get merged and which do not by adjusting the Page Compare Mode in the Recording Options (which only affects newly recorded pages/elements) along with manually adjusting the properties of your already recorded pages. Using the combination of the two you should be able to get the elements in our Elements Explorer pane to look the way you prefer.

Does that help?

Regards,
Cody
Telerik

It does not appear to be ignoring the query string for me even though I have the record settings set to FullPath compare mode.  It looks like the .  E.g. For an element found on this page: https://test.auth.com/#/subscriber/identities/?_k=iq4nly

A new Page is added in the Elements tab with the following properties:

- BaseUrl: https://test.auth.com

- Path: /#/subscriber/identities/?_k=iq4nly

- Query:                        < -- this is empty!

So for every new session I get a different query and since the path is including the query portion rather than breaking it off an populating the query field I get a new page if I'm recording or adding elements.  I then need to manually fix it up which is a bit annoying.

Is this a bug?  I'm evaluating the latest available demo of test studio to see if it is a viable automation solution for our project.

Hello Matthew,

Having in mind the URL that you are using, I guess you should set the BaseURL for compare mode. This is the only way that you will be getting proper behavior. Give it a try and let us know if you are still experiencing problems.

Regards,
Ivaylo
Telerik