I was trying to use Insight feature of UFT to avoid using the build configuration of libraries from development side for a flex based application. When i tried using the method "GetVisibleText" UFT 12.01 returns "The system cannot find the file specified". But i was click on different buttons in the same page Example buttton x, Button y at my wish. So it means UFT is distinguishes the objects. My purpose is to check on the dynamic text objects in the page. Note : "GetRoProperty" returned nothing and there is only one property called "similarity" and its returning a constant value at all the times immaterial of different pages.
UFT's Insight technology uses images in order to identify objects, the fact that it identifies button x does not mean that it has any intrinsic understanding that it contains the text "x".
In Insight the similarity property is used in order to decide how dissimilar a control has to be from the captured image in order for it not to constitute a match. Similarity isn't a regular identification property as we are used to. This is why you get the same value for each test object (it doesn't mean that the specific object supports this property).
Regarding GetVisibleText, UFT uses OCR in order to extract the text. You can specify which language you're expecting in the last parameter.
In any case none of these things should fail due to not being able to find a file. I have two thoughts on the matter:
Are you using descriptive programming to identify the InsightObject (see link further on) if so perhaps the image file you specified isn't found?
What OCR Mechanism are you using? (Tools ⇒ Options ⇒ GUI Testing ⇒ Text Recognition), perhaps the mechanism you're using isn't installed correctly and this is causing the failure, try using a different OCR mechanism.
You can read a bit more about Insight here.
Related
My team supports a mobile app that is offered in several languages. I asked the team to implement AccessibilityIDs so that I can run Appium tests, which they did. (Why did I ask this? Because everyone in Appium testing is conveying that this is the best approach.)
Later - testing of the app's real world accessibility (using assistive technology - aka talkback or screenreader) revealed that using contextual information is desired. For example, if a button has text "Submit your order" ideally the Accessibility ID should be "Submit your order" not something like "form_page_submit_button"
The team brainstormed and the solution was to create a lang file for an obscure language that we don't plan to support. We settled on "pt-PT" so all the elements could have an accessibility ID that was not likely to change for some time.
This is now becoming a problem as I would like to have visual automated tests in English and French, not just Portuguese, and I am hoping to not have to maintain xpaths with ORs in it. For example, //*[contains(text(),'Submit') or contains(text(),'Soumettre')] ie, English and French.
In light of the fact that my app needs to be accessible to users more than it needs to be accessible for test script, I am evaluating which element selector strategy to recommend going forward. I am prepared to recommend using ID or name to alleviate this issue, but would like to get more thoughts on what others are doing in this space.
Going with ID's and names sort out the situation as mentioned in this answer.
If you like to use the XPath then you can use a dictionary variable to store the text based on the region i.e. [EN='Submit', FR='Soumettre'] and set the locators with the text-based on the region by using the dictionary values using the region as key and appending the text to the locator i.e. framing the locator dynamically based on the region might work out.
As I worked on Robot framework, using some piece of code to depict it and using collections and string library of robot framework
*** Variables ***
${region} EN #set this var as per region
${loc} xpath = //*[contains(text(),'replace_text')
&{submit_loc_text} EN=Submit
... FR=Soumettre
*** Keywords ***
implementation
${text_asper_region} Get From Dictionary ${submit_loc_text} ${region}
${loc} Replace String ${loc} replace_text ${text_asper_region}
Set Test Variable ${loc} ${loc}
If you still prefer to use accessibility ids and support all languages, I would suggest to create interface for every language to get the relevant accessibility locators. This will be easy to understand and maintain ofcourse efforts will be little more but I think it will be worth.
I am recently brushing up my skills in TOSCA, I was working on it 2 years ago and switched to Selenium, I noticed that the new TOSCA allows identification using Xpath, and I am really familiar with it now, however, I cannot make it work in TOSCA and I am sure the object identification works because I am testing my xpath in google chrome developer tools.
Something as simple as (//*[text()='Forgot Password?'])[1] does not seem to be working. Could I be missing something?
This is the webpage I am using as reference for this example:
https://www.freecrm.com/index.html
XPath certainly can be used to identify elements of an HTML web UI in Tosca.
Since the question was originally posted, the "Forgot Password?" link at https://www.freecrm.com/index.html appears to have changed so that it's text is now "Forgot your password?" and is actually located at https://ui.freecrm.com/.
To account for that change, this answer uses "(//*[text()='Forgot your password?'])[1]" instead of the expression provided in the original post.
With the text modification, the expression works to idenfity the element in XScan after wrapping it in double quotes:
"(//*[text()='Forgot your password?'])[1]"
Some things to keep in mind when using XPath in Tosca:
It seems that XPath expressions need to be wrapped in double quotes (") so that XScan knows when to start evaluating XPath instead of using its normal rules. Looking closely at the expression that is pregenerated when XScan starts, we see that it is wrapped in double quotes:
"id('ui')/div[1]/div[1]/div[1]/a[1]"
A valid XPath expression doesn't necessarily guarantee uniqueness, so it is helpful to pay attention to any feedback messages at the bottom of XScan. There is a significant difference between "The selected element was not found" and "The selected element is not unique". The former simply indicates XScan can't find a match, the latter indicates that XScan matches successfully, but cannot uniquely identify the element.
My experience has been that it helps to explicitly identify the element to reduce the possibility of ambiguity. If the idea is to target the anchor element in order for tests to click a link, then reducing scope from any element i.e. "(//*[text()='Forgot your Password?'])[1]" to only match anchor elements with that text "//a[text()='Forgot your password?']".
In general, Tricentis (or at least the trainers with whom I have spoken) recommends using methods other than XPath to identify a target if they are available. That said, in my experience I've had better luck with XPath than with "Identify by Anchor".
An XPath expression is visible and editable in the XModuleAttribute properties without having to rescan. Personally, I find it easier to work with than the XML value of the RelativeId property that is generated when using Identify by Anchor.
With Anchor, I've had issues where XModuleAttributes scanned in one browser can no longer be found when switching to another browser, specifically from IE to Chrome. With XPath, I've not had these issues.
While XPath works well to identify the properties of one element with attributes of another because it can identify the relationship between them (very common with controls in Angular applications), the same can often be accomplished by adapting the engine layer using the TBox API (i.e. building a custom control). This requires some initial work up front from developer resources, but it can significantly improve how tests steer these controls in addition to reducing the need for Automation Specialists to have to rely on XPath.
What I know is that you can identify elements with XPath when working with XML messages in Tosca API testing. Your use case seems to be UI testing, but I am not sure about that.
Did you try to use XScan to scan the page? Usually Tosca automatically calculates an XPath expression for you that you can use immediately.
Please see the manual for details.
If it still does not work please try to be more specific? What isn't working? Error message? Unexpected behavior? ...
Tosca provides its set of attributes for locating any type of elements. You can directly select any number of attributes you want to make your element unique along with index of that element. Just make sure that you are not using any dynamic values in 'id' or 'class-name' of that element, also the index range is not so large like 20 out of 100; it could be 5 out of 10, which will be helpful if you need to update it in future.
Also take help of parent elements which will be uniquely located easily and then locate your expected element.
TOSCA provide various ways to locate an element just like selenium plus in addition it will provide other properties also.Under transition properties you will find x path and it will be absolute x path since you know selenium you know the difference between absolute and relative x path. I would suggest you to go with.
1.Identify by ID OR name
2. Identify by anchor
if your relative x path is not working
Try load all properties on the right side bottom. But it showed for me without clicking on it. See here
Full disclosure: I'm working on my libui GUI framework's text API. This wraps DirectWrite on Windows, Core Text on OS X, and Pango (which uses HarfBuzz for OpenType shaping) on other Unixes. One of the text formatting attributes I want to specify is a collection of OpenType features to use, which all three provide; DirectWrite's is IDWriteTypography.
Now, when you draw some text with these libraries, by default you'll get a few useful OpenType features enabled, such as the standard ligatures (liga) like the f+i ligature. I thought this was font-specific, but it turns out this is specific to the script of the text being shaped. Microsoft provides guidelines for all the scripts supported by OpenType (under "Script-specific Development"), and I can see rather complex logic for doing it all in HarfBuzz itself to confirm it.
On Core Text and Pango, if I enable other attributes, they'll be added on top of these defaults. But with DirectWrite, in particular IDWriteTextLayout::SetTypography(), doing so removes the defaults:
The program that produces this output is can be found here.
Obviously my first option would be to ask how to get the default features on DirectWrite. Someone did so already on this site, though, and the answer seems to be "no".
I am guessing that DirectWrite is allowing me to be in complete control of the list of features to apply to some text. This is nice, except that I can't do this with the other APIs unless I explicitly disable the default features somehow! Of course, I don't know if this list will ever change, so hardcoding it might not be the best idea.
Even if hardcoding is an option, I could just grab HarfBuzz's list for each script, but a) it's rather complicated b) there are multiple possible shapers for a script, depending on (I think) version compatibility (for instance, Myanmar).
So why not use HarfBuzz's lists to recreate the default list of features for DirectWrite anyway? It seems to want to be accurate to other shapers anyway, so this should work, right? Well I would need to do two things: figure out what script to use, and figure out which attributes to use on which characters for script where the position of a character in the word matters.
DirectWrite provides an interface IDWriteTextAnalyzer that provides facilities to perform shaping. I could use this, but it seems the script data is returned in a DWRITE_SCRIPT_ANALYSIS structure, and the description for the script ID says "The zero-based index representation of writing system script.".
This doesn't help, so I wrote a program to just dump the script numbers for text I type in. Running it on the input string
لللللللللللللاااااااااالا abcd محمد ابن بطوطة Отложения датского яруса
yields the output
0 - 26 script 3 shapes 0
26 - 5 script 49 shapes 0
31 - 14 script 3 shapes 0
45 - 2 script 1 shapes 1
47 - 25 script 22 shapes 0
I cannot match these script numbers to anything in any of the Windows headers: if there is a defined number for Arabic, Latin, or Cyrillic in any API, they don't match these. And even if I did get a mapping between script and script number, that still doesn't give me the data to apply intra-word features.
What about Uniscribe? Well, the documentation for the equivalent SCRIPT_ANALYSIS type says that its script ID is an "[opaque] value" whose "value for this member is undefined and applications should not rely on its value being the same from one release to the next". And while I can get a language code to identify the script by, there's still no defined value other than LANG_ENGLISH for "Western" (Latin?) scripts. Are the DirectWrite values the same as the Uniscribe ones? And it seems like I can at least figure the initial and final states of words by looking at the fLinkBefore and fLinkAfter fields, but is this enough to properly apply attributes per-script?
HarfBuzz does have an experimental DirectWrite backend that isn't intended to be used by real programs; I'm not yet sure whether it has the same feature-clobbering I specified above. If I find out, I'll update this part here.
Finally, if I enter the following equivalent test case to the first one above in something like kaxaml:
<Page
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
<Grid>
<FlowDocumentPageViewer>
<FlowDocument FontFamily="Constantia" FontSize="48">
<Paragraph>
afford afire aflight 1/4<LineBreak/>
<Run Typography.Fraction="1">afford afire aflight 1/4</Run>
</Paragraph>
</FlowDocument>
</FlowDocumentPageViewer>
</Grid>
</Page>
I see the ligatures being applied properly, even in the latter case:
(The fraction at the end is just to prove that that attribute is being applied.) If I assume XAML uses DirectWrite, then that proves my first option (simply overlaying my custom attributes on top of the defaults) should be possible... (I make this assumption based on the idea that XAML provides a strikingly similar API to Direct2D for drawing 2D graphics, and has a lot of holes filled in where I had to manually write a lot of glue code to do the same things with vanilla Direct2D, so I assume whatever is possible in XAML is possible with Direct2D, and by extension DirectWrite since they were technically introduced together...)
At this point I'm completely lost. I want to at least be predictable across platforms, and I'm not sure how programs are even supposed to, let alone going to, use OpenType features directly or not anyway. Am I making bad expectations of text layout APIs? Will I have to drop IDWriteTextLayout and do all the text shaping and layout myself if I want this?
Or do I have to drop vanilla Windows 7 support and upgrade to the Platform Update DirectWrite feature set? Or even Windows 7 entirely?
After some discussions with Peter Sikking and Ebrahim Byagowi, I went and debugged a more general-purpose program I built quickly to test things, and I figured out what's going on internally.
First, however, I will say this applies to Uniscribe and DirectWrite equally.
As it turns out, DirectWrite is always providing a set of default OpenType features, regardless of what feature set I use! The situation is that the list of default features provided differs depending on whether I load my own features or not, and depending on the shaping engine. For the latn script in horizontal writing mode and for English, this is done with the "generic engine".
If I don't provide any features, the generic engine will load script-specific features. For horizontal latn, this list is
locl
ccmp
rlig
rclt
calt
liga
clig
If I do provide features, the generic engine will use the same default list for all scripts:
locl
ccmp
rclt
rlig
mark
mkmk
dist
So I don't know what to do about this. I could probably just provide liga and a few others myself in libui code (marked as a HACK of course), but this is still weird. I'm not sure what the motivation is either. Either way, this explains the behavior I'm seeing.
Supposing your question in general is about programming or at least concerns programming, I will try and give answers to some of your interrogative sentences.
would I have to drop the use of IDWriteTextLayout entirely in my code if I want to be able to add typographical features on top of the defaults?
It depends. If an IDWriteTextLayout interface suits well your project tasks in all ways except ease of variation of DirectWrite default typographic features, learn what you should about typography and create an IDWriteTypography instance suitable for your needs. Developing a custom text layout for the program may require substantial time and effort, especially if the program is supposed to render bidirectional texts, complex scripts, inline objects, etc.
It may happen that the tasks of your project require to develop a text layout engine for reasons other than just controlling typographic features used in rendered text. For example, your manager/customer may ask for implementation of customized linebreaking opportunities or a glyph advance justification algorithm. In this scenario, you will implement an IDWriteTextAnalizer::GetGlyphs method. This method has parameters DWRITE_TYPOGRAPHIC_FEATURES ** features, const UINT32 * featureRangeLengths, UINT32 featureRanges, and this parameters enable you to supersede a set of "default" typography features for a range of the text to be rendered (see my answer to the other question What are the default typography settings used by IDWriteTextLayout?). Only affected features will be altered; the other features has their "default" values. Morever, if you omit this parameters in a GetGlyphs call for the next text range (for example, use values of NULL, NULL, 0), the features altered in the previous GetGlyphs call will not be altered by the call for this next range.
the documentation for the equivalent SCRIPT_ANALYSIS type says that its script ID is an "[opaque] value" whose "value for this member is undefined and applications should not rely on its value being the same from one release to the next". And while I can get a language code to identify the script by, there's still no defined value other than LANG_ENGLISH for "Western" (Latin?) scripts.
Strictly speaking, this is not an interrogative statement, but I guess you are dissatisfied with how these Unicode script IDs are defined and how one can use the API with so vaguely defined structures and constants.
It may be off topic, but I risk to hypothesize on the origin of the "Unicode script ID" values. As of 2010-07-17, the Unicode, Inc. published The Unicode 6.0 version. The standard contained the document
http://www.unicode.org/Public/6.0.0/ucd/PropertyValueAliases.txt, with a section containing a list of scripts. The list went so:
# Script (sc)
sc ; Arab ; Arabic
sc ; Armi ; Imperial_Aramaic
etc.
The Arabic script is #1, the Cyrillic script is #20, the Latin script is #47 in this list. Furthermore, elsewhere I saw this list starting with scripts Common and Inherited. It places the Arabic script to the 3rd, the Cyrillic to the 22nd, and the Latin to the 49th place. These ordinals are familiar to you, aren't they?
Fortunately, we need not rely on the "Unicode script ID" values; we need script properties, not script IDs or abbreviations. The API is self-consistent in that it gives actual script properties for the text range, when we pass to a GetScriptProperties method the number derived from an AnalyzeScript call.
I want to get textbox's object ID which is dynamic
Application is windows application developed in c#.net
how to record and get object ID using QTP??
There is no straight answer to your question unless one personally analyzes the scenario, however below are some solutions which may be applicable.
Try to identify any unique property of the object other than one, which qtp recognizes while recording and do descriptive programming. (In your case if object ID is a number then go for some text describing the textbox).
If this is not possible do descriptive programming with regular expression matching all the property value that the object have.
Thanks
identify unique property of the object, which qtp recognizes while recording and do programming.If not possible do with regular expression matching all the property of the object.
Option 1: Reconfigure your object identification configuration so QTP uses different identification properties (see documentation).
Option 2: Use descriptive programming to address the control using an appropriate (unique) combination of attributes (see documentation).
Use option 1 if the control type always needs nonstandard handling in terms of identification. Use option 2 for exceptions.
In general how does one test a various parts of a GUI? What are good practices? (Yes I am being overly general here).
Let take for Notepad's Find dialog box:
Notepad's Find dialog box http://img697.imageshack.us/img697/5483/imgp.png
What are some things that can be tested? How does one know its working correctly? What are edge cases to look out for? Stress tests?
Here.
I doubt any good generalization can be made about this - it always depends on the situation.
When someone asks for tests for GUI I always assume that that mean 'this part of application that is accessible via this GUI'. Otherwise it would mean testing the only the GUI without any logic hooked. Dunno why no one never actually asked for testing if the events are fired when button is pressed or is displayed window acquiring focus.
Anyway back to the question. First of all find out about equivalence classes, boundary conditions other testing techniques. Than try to apply it for given problem. Than try to be creative.
All those should be applied when creating following tests:
1) happy path tests - application acts right when given input is good
2) negative tests - application acts right when given input is bad
3) psychotic user behavior (I saw someone use this term, and I find it to be great) - that one user that has nothing better to do than break your application or is to stupid to actually know how bad and horrible things he is doing with your app.
After all this if all tests are passing and you can't figure out other, than you don't know is it working properly, but you can say that it passed all tests and it seems to be working correctly.
As for given GUI example.
1)
Is the application finding string that is in opened file?
Is the application finding character that is in opened file?
How is it reacting to reaching end of file during search?
Is it finding other appearances of given string/character or just one, when there are many of those appearances ?
Is it handling special search characters like * or ? correctly?
Is it searching in desired direction?
Is it 'Mach case ' option working properly?
When opening find setting some criteria, canceling search and launching it again - are search criteria back to default values? Or are they set as you left them when clicking Cancel?
2)
Is it informing user that no mach was found when trying to search for data that is not in opened file?
Is it reacting properly when trying to search down form end of file?
Is it reacting properly when trying to search up form beginning of file?
How search feature is reacting when no file is loaded? (in MS notepad it can be done, but in other editors you can launch editor without opening a file hence this test)
Can I mark both Up and Downs search direction?
3)
Is it working properly on 4GB file?
Can I load 4 GB string in 'Find What:' field and search for it?
Can I provide as input special characters by providing ASCII codes? (it was done like pressing Alt and number of character... or something like that)
Can I search for empty character (there was something like that in character table).
Can I search for characters like end of line or CarretReturn?
Will it search for characters form different languages? (Chinese, or other non-english alphabet characters)
Can I inject something like ') DROP ALL TABLES; (if that would be web based search).
Will I be able to launch proper event twice by really fast double click on search button? (easier on web apps)
With reasonable test suite you know it seems to work correctly.
I think it is better to separate out functional aspects and the usability aspects for the GUI testing.
Let us say in the above example take the use case of user entering some text and hitting the Find button. From the functional aspect I would say your tests should check whether this user action (event) calls the appropriate event handler methods. These can be automated if your code has good separation between the GUI display code and the
functional part.
Testing of usability aspect would involve checking things like whether the display occurs correctly in multiple platforms. I think this needs to be verified manually. But I think there are some tools that automate this kind of GUI testing as well but I've no experience with them.
It's difficult and error-prone to test finished UIs.
But if you are more interested form the programmer's perspective, please have a read of the paper The Humble Dialog. It presents an architecture for creating UIs whose functionality can be tested in code using standard testing frameworks.