What is the working of Browser and Page in QTP/UFT? - testing

I always get a doubt that:
What exactly is the difference between the working of Browser and Page.
I know it is a hierarchy and that stuff, but how does the tool differentiates the browser and page and what is use of having both of them.
For example, if I use descriptive programming, and type:
Browser("title:=Google").Page("title:=Google").something
irrespective of the Browser (which may be IE / Chrome / Firefox) it will use the browser with the title = Google. And same is for the page.
Please elaborate. I am confused.

There's an explanation of what Browser and Page are supposed to represent on HP's blog.
In short Page has no semantic meaning, it is just used in order to organize the object repository more cleanly (so that you don't get hundreds of objects under one Browser object). If you're using descriptive programming (as I see from your example) then the Page has no meaning (since every browser has only one Page) and having a description for the page adds nothing.
I would replace the line with:
Browser("title:=Google").Page("title:=.*").something
Or
Browser("title:=Google").Page("micclass:=Page").something

Related

What is better test design: Navigate directly to URL or navigate normally by clicking (as a real user would) in selenium tests

Let us say my test wants to see if a user can see an image on XYZ page. And let's say in normal usage, the user can only go to XYZ page by clicking a link on ABC page (might be the home page).
Now assuming the URL to XYZ page is not static, but maybe depends on the image, and can be generated in the code simply, I have two ways of writing the test:
Generate the URL in test and directly navigate to XYZ, and then check if the image is present.
Go to ABC like a normal user would, click on the link which takes you to XYZ and then check for image
For option 1, I feel like I get more test isolation. If the link on ABC page is not generated correctly or is broken for some other reason, this particular test should not fail, right? That should be the responsibility of some other test?
But for option 2, that is how a real user would do it. He would almost never try to guess the pattern of the URL and then navigate to it directly. And I cannot have a huge test that goes to every link and sees if it is not broken, that would be way too complicated. So this much sacrifice in test isolation is needed.
How should I decide between the two options? Is there a right way? Hopefully the question is not too subjective for stackoverflow.
It depends on what you're wanting to test. If you want to test the buttons or links themselves (ie: you're testing the whole user workflow), click on them just like the user would.
If, on the other hand, clicking these links is just a means to an end and that the real target of the test case is deeper into the app, I think it's perfectly fine to skip directly to the part of the app you're actually testing.
As an End User, best approach will be the Option 2 which also widen the coverage of your test hence you can check:
1. Whether links/ buttons are clickable and not throwing exception.
2. Click on above is navigating to correct page.
Option 1, can be used for test scenario where user doesn't bother about how to reach to the page rather focused only on the opened page contents.
Choosing any of these option is depending on your approach of test coverage and its scope.

fixed url on address bar - show only base url http://www.mysite.com

I need to show on the address bar just the first part of the url of my site.
For example for any page with name like
http://www.mysite.com/mypage.php or
everything else
I want to see just http://www.mysite.com on the address bar of the browser.
How this can be achieved?
I tried with apache RewriteRule but with no result.
Apart from being a really bad idea for people actually trying to use your site, there is no way you can do this on the server side, because the server needs to know which page was accessed - that's what a URL is for. What you are looking for is to make it appear to the user that they are still at the same URL.
This is easy enough if you put your entire site in an HTML frameset with one frame, or an iframe sized to fill the browser window. This does require all external links to have target="_top", and without additional JS people can break out of the frame and access the pages individually anyway.
An alternative approach, that will only work on some browsers, would be to use history.pushState to fake the address bar back to / every time a new page loads.

WebKit losing parameters in URLs with skip links

We have some generated pages whose URLs contain parameters, like http://example.com/page.do?param1=hello. These pages contain named anchors inside, <a name="here">like this</a>. And there are corresponding links that reference the named anchors, like this. Most folks today call these "skip links".
Clicking a skip link should result in the browser creating and following a URL that matches the original one, with the named anchor tacked on at the end: http://example.com/page.do?param1=hello#here
On Firefox and IE, this works fine. On Chrome, Safari and other WebKit-based browsers, the parameters are lost, leading to http://example.com/page.do?#here which is invalid for our site, and just causes a 404 error.
Interestingly, if you manually put the full link in the location bar and press Enter, it behaves properly.
I've googled around a while and seen a lot of discussion about WebKit having problems with skip links, but none of them match the situation here where it's losing parameters.
Is this loss of parameters a known bug? Has anyone seen a workaround?
I encountered the same issue. From what I can say this is related to the usage of a meta tag like this: <base href="http://example.com" />. Once it is set my links point to example.com#foo instead of example.com?foo=bar#foo.
Knowing that I found this question. So the anchor tag behavior is a known thing:
Is it recommended to use the <base> html tag?
Since I can't remove the base tag I'll try to handle this with JavaScript.

Google+ : Multiple +1 on same page, different content

I've tried to find an answer to this (both in the dev docs and here), but with no luck.
The "+1 button" works fine on normal pages (where there's just the single +1). But I have a page with multiple entities (to use the terms of Drupal: A View displaying multiple nodes) where I'd like to add "share buttons". So far I've added Twitter and Facebook.
Twitter is the simplest as it just takes the string you give it..
Facebook takes an url, but you can specify your own url.
When I try to specify my own url for +1 I get this Error:
Unsafe JavaScript attempt to access frame with URL http://one80.seasites.se/whats-up from frame with URL https://plusone.google.com/_/+1/hover?hl=sv&url=http%3A%2F%2Fone80.seasites.se%2Fwhats-up%2Fl%25C3%25B6rdag&t=1342724634133&source=widget&isSet=false&referer=http%3A%2F%2Fone80.seasites.se%2Fwhats-up&jsh=m%3B%2F_%2Fapps-static%2F_%2Fjs%2Fgapi%2F__features__%2Frt%3Dj%2Fver%3Dr4LFRxx-_oY.sv.%2Fsv%3D1%2Fam%3D!ZCfx2q5v6YmYvWjcTQ%2Fd%3D1%2Frs%3DAItRSTNI50TT3SY8R9klRLc_1sBJ5_Rp3g#id=I3_1342724634541&parent=http%3A%2F%2Fone80.seasites.se&rpctoken=619983104&_methods=mouseEvent%2CtrackingEvent%2ConVisibilityChanged%2C_onopen%2C_ready%2C_onclose%2CcloseOrHideThisBubble%2C_close%2C_open%2C_resizeMe%2C_renderstart. Domains, protocols and ports must match.
rs=AItRSTOQ10u7fGwgD-LqzsOa-fsgdlhDCg:173
ec.a.v rs=AItRSTOQ10u7fGwgD-LqzsOa-fsgdlhDCg:173
xh rs=AItRSTOQ10u7fGwgD-LqzsOa-fsgdlhDCg:203
q.get rs=AItRSTOQ10u7fGwgD-LqzsOa-fsgdlhDCg:211
ec.w rs=AItRSTOQ10u7fGwgD-LqzsOa-fsgdlhDCg:173
Rh rs=AItRSTOQ10u7fGwgD-LqzsOa-fsgdlhDCg:208
q.w rs=AItRSTOQ10u7fGwgD-LqzsOa-fsgdlhDCg:220
Rb rs=AItRSTOQ10u7fGwgD-LqzsOa-fsgdlhDCg:30
Xg rs=AItRSTOQ10u7fGwgD-LqzsOa-fsgdlhDCg:187
(anonymous function) rs=AItRSTOQ10u7fGwgD-LqzsOa-fsgdlhDCg:226
To explain why I want to use separate URL:
every node is something like an event, every node has it's own url (which contains an image and text/info). So when you click Like (for FB) it gets the title, info & image and includes it in the post (So it says "What's up - Gathering", instead of a generic "What's up" and no/the same image).
I'd like to accomplish the same with G+.
Is there a way to accomplish this for G+?? Have I missed something??
I guess one way to do this is by using an iframe for each of the nodes and pull in a special version of the "node page" with just the g+-button. But that's a pretty nasty hack (and not that fun to set up).
Any ideas are welcome!
The error you're seeing is actually due to an issue in Chrome. The +1 button should automatically recover.
You can explicitly specify target pages by using the href attribute. Your markup will look like this in practice:
<g:plusone href="http://example.com/targeturl"></g:plusone>
Or like this with HTML5 syntax:
<div class="g-plusone" data-href="http://example.com/targeturl"></div>
If these don't work, can you share a link to a page where you're seeing it not work? I can take a look :)

Bring Safari to front

I'd like to bring Safari to the front (switch to) but without using a URL, instead I'd like to see the "pages" view so the user can pick an already loaded page. Is this possible?
We open links in Safari and if the user returns to the app and selects the link again, I'd rather let them pick which Safari page to browse instead of opening a new one. I know that if the same URL is called it will open the correct page but the user may have navigated within the original site so the url no longer matches.
Thanks,
Rick
I don't think that its possible, i would use a UIWebView inside your app in order to get that experience you want, you can find the UIWebView apple docs here (http://developer.apple.com/library/ios/documentation/uikit/reference/UIWebView_Class/Reference/Reference.html) and also the equivalence of c# methods here (http://tirania.org/tmp/rosetta.html) hope this helps
Alex
Your app doesn’t get control of Safari’s UI. You might, however, be able to design your site so that it handles navigation via Javascript—AJAX and whatnot—so that the actual page URL doesn't change, and thus so that the page, re-opened from your app, brings up the existing Safari page. Of course that introduces further problems with your pages no longer being bookmarkable, but you might find that an acceptable tradeoff.