Patent Application
20090106764
In the world of software development, it is common for software companies to sell their products in multiple countries that span multiple languages. A different compiled version of the software can be created for each distinct language or culture, but this is inefficient because multiple versions of the same software have to be maintained. These inefficiencies in maintaining multiple versions of the same software led to the development of software globalization and localization techniques. Using globalization techniques, a software program can be developed in a language-neutral and culturally-neutral way so that it is usable across multiple languages and cultures. The aspects of a software program that are specific to a given language or culture are extracted out of the main program and included in resource files. For example, the text that corresponds to the menu items can be contained in the resource files as opposed to being compiled within the main software program. Then, when loading the software for a specific region or language, the resource file(s) containing the specific details for that region or language are loaded along with the rest of the application. This process of loading the software for a specific region or language is called localization.
After creating a software program that is localized to support one or more particular language(s) or region(s), tests need to be performed to ensure that the localized software program operates correctly. In fact, testing needs to be performed on any type of software program, whether it is localized or not. Automated testing programs have been created that allow for tests to be run by a computer without requiring human interaction throughout the test. These automated testing programs allow test scripts to be specified and then executed at selected times. With software programs that have been localized to enable support for multiple languages and regions, it becomes challenging to automate the testing of the software program. A common way of providing automated testing for software that has been globalized is to create a separate test script for each localized version of the software program, thereby resulting in a duplication of testing effort.
Various technologies and techniques are disclosed for supporting globalization in user interface automation. A resource key is provided that contains at least three data elements. A resource type data element contains data representing a resource type, a resource location data element contains data representing a location to a resource file, and a resource identifier data element contains data representing a resource identifier. During a resource file extraction operation, the resource file data element is used to locate the resource file, and the resource type data element and the resource identifier data element are used to locate a resource within the resource file that matches the resource type and the resource identifier.
In one implementation, a process is provided for resolving a full path name to a resource file. A determination is made that a resource file is needed for an extraction operation. A key signature contained in a resource key is accessed. If the key signature contains enough information to indicate a first location to search for the resource file, then the first location is searched for the resource file, and if the resource file is found in the first location, then the resource file found in the first location is used for the extraction operation.
However, if the key signature does not contain enough information to indicate the first location, or if the resource file is not found in the first location after searching, then a resource file location value contained in the resource key is accessed to determine a second location to search for the resource file. The second location is searched for the resource file. If the resource file is found in the second location, then the resource file found in the second location is used for the extraction operation.
In another implementation, a process is provided for performing a post-extraction action on an extracted resource string. A resource string that was extracted from a resource file during an extraction action is received. A resource key associated with the resource string is accessed. One or more modifications described in the resource key that need to be made to the resource string are identified. The one or more modifications are performed to the resource string.
This Summary was provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.
The technologies and techniques herein may be described in the general context as an application that facilitates globalization of automated test scripts, but the technologies and techniques also serve other purposes in addition to these. In one implementation, one or more of the techniques described herein can be implemented as features within an automated testing program, or from any other type of program or service that interacts with resource files containing localized specific information.
In one implementation, the technologies and techniques described herein provide a way for supporting globalization of test scripts. The term “globalization” as used herein means a manner of providing neutrality that enables support for multiple languages or cultures. The term “globalization of test scripts” means a manner of providing neutrality that allows the same test script(s) to be used across multiple localized versions of a given software application. When the term globalization is used throughout the rest of this specification in a shorthand fashion, the term is referring to globalization of one or more test scripts. By globalizing test scripts, multiple versions of test scripts do not have to be created for each different localization. The term “test script” as used herein is meant to include a script or another means of specifying automation data that is used to test the functionality of a software program in an automated fashion. The technologies and techniques that enable support for globalization of test scripts will be described in further detail in
As shown in
Additionally, device 100 may also have additional features/functionality. For example, device 100 may also include additional storage (removable and/or non-removable) including, but not limited to, magnetic or optical disks or tape. Such additional storage is illustrated in
Computing device 100 includes one or more communication connections 114 that allow computing device 100 to communicate with other computers/applications 115. Device 100 may also have input device(s) 112 such as keyboard, mouse, pen, voice input device, touch input device, etc. Output device(s) 111 such as a display, speakers, printer, etc. may also be included. These devices are well known in the art and need not be discussed at length here.
Turning now to
In the diagram 200 shown, an example resource key is shown that contains at least three data elements. The resource key can be stored in a text file, in a database, or any other suitable storage structure, and then later accessed by an automated test program to test the functionality of the specific software program. The first data element shown for the resource key is a resource type 202, the second data element shown is a resource file location 204, and the third data element shown is a resource identifier 206. The terms first, second, and third are simply meant for sake of illustration, and other orderings of the information in the resource key could also be used. Other details 208 can optionally be included in the resource key in addition to the other three data elements. The resource type 202 is used to store details about a type of resource being represented, such as a dialog, dialog caption, message, string, and so on. The resource file location 204 represents a location to a resource file. In one implementation, the resource file location 204 represents a relative path to the resource file that is relative to some other path location, such as the current directory. In another implementation, the resource file location 204 represents an absolute path to the resource file that gives an entire path needed to locate the resource file.
The resource identifier 206 represents one or more values that are used to identify a given resource. In one implementation, the resource identifier 206 is a unique identifier for the resource that is unique across all languages and localizations. By using a unique identifier for the resource identifier 206, the proper resources can be located in their respective resource files directly, regardless of the language/localization to which they are directed. In other words, if a unique resource identifier is used, less information can be stored within the resource key in order to facilitate the later location of the proper resource. During a resource file extraction operation, the resource file location is used to locate the resource file. The resource type and the resource identifier are then used to locate a corresponding resource within the resource file that matches that resource type and the resource identifier. In one implementation, a test script requires a specific resource, and an extraction operation is performed at run-time to retrieve the resource and properly globalize the automation to access the additional details that need to be tested for the program.
Turning now to
A simple resource key 222 contains minimal information necessary to extract the string that corresponds to this key. An example of a simple resource key 222 is shown below:
In the above example, the friendly string contains a user friendly name for referring to the string. The resource type, resource file, and resource identifier were described in detail in
An extended resource key 224 contains a simple key with additional information. An example of an extended resource key 224 is shown below:
RKB1[target process name] Simple Resource Key.
In one implementation, an extended resource key 224 starts with the signature RKB1 (Resource Key Binary Version 1), and whenever the format of extended resource keys is changed, the version is incremented. The letter “B” in the signature means that the resource string is found in or extracted from a binary file. If the resource string is found in or extracted from a data source listing globalizable resources (such as an LCX file), then the signature starts with RKL. The target process name shown in the above example is used to resolve the full path to a file that contains resources. The specific example of an extended resource key 224 described in this paragraph is just for illustration, and numerous other variations could be used in other implementations to provide an extended resource key 224.
A composite resource key 226 combines simple or extended resource keys, such as using a % s syntax or another syntax. The following example shows how a string that corresponds to one resource key (resKeyIsnotrunning) is used as a formatting string for the actual string that is “Magnifier is not running”.
As another example, a user can combine any number of strings by providing a formatting string as a parameter for CompositeResourceKeyNative constructor (or other suitable constructor) and embracing it with “{ }”. For example, to concatenate two strings that correspond to langNeutralCodetxt and resKeyDashNotepad (which corresponds to “code.txt—Notepad”), code such as the following could be used:
In one implementation, when a user calls a method such as ExtractResourceString(complexResKey), the resource extractor will automatically extract strings that correspond to resource keys that compose the complex key and combine them using the formatting string.
If a user explicitly needs to extract a string that corresponds to a resource key of any type, then code such as the following can be used:
String actualString=ExtractResourceString(resKey);
Continuing the discussion on example resource key types, a language neutral resource key 228 represents a string that is language neutral, such as a file name of a critical dependency in the operating system. An example of a language neutral resource key 228 is shown below:
A criteria matching resource key 230 can be used to cover the situation when a user needs to run a test script against multiple product SKUs or needs to run the tests against different environments. For example, the user may have a retail version of a product and a debug version of a product. In the first case, resources may come from a first DLL, and in the second case, the resources may come from a second DLL. An example of a criteria matching resource key 230 is shown below:
The criteria matching resource key 230 can work in the following way: the system attempts to extract the string that corresponds to the resKey1, and if this extraction returns an empty string, then the system attempts to extract the string that corresponds to the resKey2, and so on. In other words, the system extracts strings in the order provided by the user in the code. When a non-empty string is extracted, that string is returned and the remaining resKeys are ignored. This allows a single resource key to be used to handle tests for multiple SKUs of the same product (such as the production and debug versions as described previously).
Turning now to
During a resource file extraction operation, there may be times when a full path name needs to be resolved. An example of when this may be necessary includes when only partial path information for the resource file has been provided, as opposed to the absolute path.
If the resource file is not found (decision point 280), or if the key signature did not contain information that indicated the search location (decision point 276), then a resource file location data element is accessed in the resource key (stage 284). The location indicated by the location data element is searched to see if the resource file exists in that location (stage 286). If the resource file was found in that location (decision point 288), then that resource file is used for the extraction operation (stage 290). If the resource file was not found in that location (decision point 288), then additional location(s) to search for resource files are determined (stage 292). Those additional locations are searched for the resource file (stage 294). If the resource file was found in the additional location(s) (decision point 296), then that resource file is used for the extraction operation (stage 290). If the resource file was not found in the additional location(s) (decision point 296), then the appropriate next action is taken (stage 298), such as to skip the testing of that operation, to report an error, and so on.
Turning now to
Some non-limiting examples will now be provided to further illustrate this post-extraction action process. In the first example provided below, a post extraction action is a part of a resource key that appears in angle brackets. For instance, to trim ‘\0’, a format such as the following can be used:
RKB2<TRIMEND(‘\0’)>[wordpad]; Wordpad; Win32String; wordpad.exe; 128”)
As another example, to split the located string into components and get the second components a format such as the following can be used (where ‘\n’ is used as a delimiter):
RKB2<SPLIT(‘\n’, 2)>[wordpad]; Wordpad; Win32 String; wordpad.exe; 128”)
The above resource key reads as (from right to left): use this simple resource key (; Wordpad; Win32String; wordpad.exe; 128) and process name [wordpad] to locate the resource file, extract the string and then apply rules contained in the <SPLIT(‘\n’, 2)> part of the resKey to this string.
As another example, the resource can be combined with another data source (e.g. “Copy % d files . . . ” becomes “Copy 252 files . . . ”). Yet another example can include modifying the string by interpreting the string as the target system would do (e.g. “Save &As . . . ” becomes “Save As . . . ”).
Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims. All equivalents, changes, and modifications that come within the spirit of the implementations as described herein and/or by the following claims are desired to be protected.
For example, a person of ordinary skill in the computer software art will recognize that the examples discussed herein could be organized differently on one or more computers to include fewer or additional options or features than as portrayed in the examples.
