An automated method to generate text-value-independent and I18N-supportable GUI automation scripts
Publication Date: 2010-Jul-29
The IP.com Prior Art Database
The text value of a control could be translated in different locale or be changed from build to build, but the location it stored almost never change unless AUT underwent a severe adjustment. So our core idea is: Based on the stability of location, we let the script ‘remember’ the storing location of text values rather then text value only; during playback, re-achieve translated text value based on the location. By doing this, we can provide more precise I18N script and avoid some affections led by text value changes. We invent Location tag and Multilevel location dictionary to link every GUI controls with their text value storing location. We also invent the format, generation method and using method of this special location tag and dictionary.
An automated method to generate text -
GUI Automation test tools usually record batch of GUI actions, generate some scripts and then playback. But the generated scripts usually can not playback in other locale because some GUI object' properties that playback relays on are translated . That's means those tools can not generate I18N script and tester have to recording on every different locale for same GUI actions.
Besides, automation tool usually use control's text value as one of properties to locate it,
will be broken.
Known Solution and drawbacks:
By now, the common solution for I18N is: before execution, a translation dictionary is generated automatically. The keys of dictionary are English text values of controls; and key's counterpoint is the translated text for another locale. While recording or manually developing the script, the English text value of a control will be recorded in script. During playback on another locale, the automation tool looks up the dictionary with English text value and gets the translated value; then search the control in AUT with translated value. The dictionary is generated based on translation files under application (.properties .XML .JS or .Class.)
This solution's problem is:
1. If any text value changes, the dictionary has to be re-generated. E.g. 'save' is changed to 'Save' or 'saving'.
2. One English text value usually corresponds with more then one translated text. For instance in Chinese locale, 'save' text can be translated to '保保', '提提', '确确', '应应', '使使', '保存'. The Script has to try each candidate one by one until the control can be found. Usually each tentative search at least takes few seconds. Then it will take a long time if there are many candidates.
By now, in my limited sight, there is no good way to deal with text value change.
This disclosure provides a very precise way to get the translated I18N text value.
changes. The process can be performed automatically. If this method can be added to any automation test tools such as RFT, it will make those tools I18N supportable and generate more stable scripts.
How it works
-independent and I
independent and I 18
NN---supportable GUI automation scripts
supportable GUI automation scripts
when text value change, the script
And it will not be affected by text value
The process can be divided into four steps:
Parts of them have been implemented and used in daily production automation development . If this can be integrated to automation tool, all following steps can be implemented.
1. Tag AUT and generate dictionary
Click the 'TAG' button in automation tool.
(By now no tool has integrated this feature, so we do this by executing some independent java codes.)
After tagging, each text value in AUT will be appended with a unique
location tag. This can be observed through GUI.
the same time, a multilevel location dictionaryis generated.
2. Record scripts like befo...