Abstract:
An automated software resting and validation system allows testing of a software application under test (SAUT) regardless of the dynamic nature of the SAUT. An abstracted set of hierarchal or linear objects model certain regions of the SAUT. Automated test scripts utilize theses regions to intuitively navigate and identify potions of the SAUT to automate. The scripts also access specific SAUT elements contain within each defined region. These elements can then be used to invoke actions or verify outputs there from. The system uses a set of rich identification rules embodied in the system which allow the user to configure the identification of any element within the abstracted region. The rules are customizable to allow the user to configure the desired level of loose coupling between the automated scripts and the target element to adapt the scripts to the nature of the SAUT.

Description:
RELATED APPLICATIONS 
       [0001]    This application is a continuation of U.S. patent application Ser. No. 14/473,500, filed Aug. 29, 2014, titled “System, Method, and Computer Readable Medium for Universal Software Testing”, which is a continuation of U.S. application Ser. No. 13/078,142, filed Apr. 1, 2011, titled “System, Method, and Computer Readable Medium for Universal Software Testing”, which is a continuation of U.S. patent application Ser. No. 11/598,519, Filed Nov. 13, 2006, titled “System, Method, and Computer Readable Medium for Universal Software Testing,” which claims priority to and the benefit of U.S. Provisional Patent Application Ser. No. 60/852,314, filed Oct. 17, 2006, titled “Software System And Method To Abstract Markup Applications For Expediting Test Script Authoring And Loosely Coupling Scripts From The Application Under Test,” each incorporated herein by reference in its entirety. 
     
    
     BACKGROUND OF THE INVENTION 
       [0002]    1. Field of the Invention 
         [0003]    This invention relates in general to software testing, and in particular to abstracting markup applications in order to expedite and render software testing more flexible and efficient. 
         [0004]    2. Description of the Related Art 
         [0005]    Software has become an essential part of everyday life worldwide. Many businesses and individuals relay on software to support their daily activities. The quality and reliability of software has never been as important and critical as it is today. Software providers, whether they provide packaged software products or customized solutions sold to businesses, consider the quality of the software they sell a very serious matter. Software defects can detrimentally impact customer loyalty and trust. 
         [0006]    There are many categories of software applications developed today. One type of application is the markup base application. These applications are defined using markup languages such as, for example, HTML, XHTML, XML, or other similar markup languages. These applications are interpreted using a host that provides the user with elements which the user can use to interact with the application logic. A classic example of these types of applications is a web application. Web applications run in a host like Microsoft&#39;s Internet Explorer™ or Mozilla&#39;s FireFox™ and interpret an HTML document to present it to the user for interaction. 
         [0007]    Many software development companies test their software by compiling a list of test scripts (i.e., test scenarios or test cases) which are run against their software to ensure its quality and to validate its design. A test script must be created for each piece of software to be tested Some companies hire employees or contractors to run the test manually, while others invest in automating the tests in order to avoid the additional costs associated with the manual labor. There are many advantages to test automation, with a few worth noting such as: 1) automation cuts the costs associated with manual execution, 2) automation cuts down on the execution time, which allows for faster turn around on results, and 3) automation allows for more accurate and consistent results. 
         [0008]    With regard to generating automated test scripts for such markup applications, there are increasing challenges and pressures to enhance the efficiency and quality associated with building the test scripts; especially with the increasingly rich content on the web and the wide spread use of dynamic web content, such as ASP.NET or PHP. Some of the key challenges are summarized in the following paragraphs. 
         [0009]    First, the ease of building and crafting automated tests which perform the desired tasks is a challenge. Here, in order to execute actions against the software or to verify its content. It would be very beneficial if one could easily and consistently identify elements within the complex markup of the software application under test (i.e., SAUT). For example, some application&#39;s output changes dynamically between requests and within the same session. Other applications generate dynamic content with variable element IDs which make it difficult to consistently identify the elements. Moreover, such an environment makes it difficult to automate the test scripts against the application throughout the development cycle. 
         [0010]    Second, maintenance and updatability of automated test scripts is a challenge. Depending on how the automated tests are authored, changes to the SAUT can break the functionality of the test scripts because they axe unable to adapt to the nature of the SAUT. This, in torn, adds additional costs to repair and update the tests throughout the life cycle of the application and throughout the different future version releases of the application. 
         [0011]    There are currently several products on the market that attempt to address the above challenges of automated testing for SAUT, such as, for example QuickTest™ and WinRunner™, which are marketed by Mercury Interaction®. Although these took have a record and replay functionality to easily craft automated test scripts, they provide little support to help solve the need for flexible identification of elements and loose coupling of test scripts within the SAUT. Thus, each falls short in addressing the maintenance nightmare that comes with such testing solutions. In fact, due to dynamic changes in the software which require re-recording of the scripts from scratch, record and replay testing is one of the most expensive automated testing techniques. 
         [0012]    Some other tools like TestComplete™ marketed commercially by AutomatedQA™, attempt to record at the elemental level. This, however, enhances the resilience of the tests, but falls short of addressing issues related to the dynamic nature of certain elements and elements that do not have consistent properties between users or requests. For example, most markup applications use two very popular methods to identify elements (especially for non-uniform markups like HTML). The first is an clement ID or name which defines the element and is globally unique within the SAUT. The second is an element tag name occurrence, which is the occurrence index of a specific tag in the order of the elements appearance within the SAUT. 
         [0013]    Information regarding the tag&#39;s occurrence or element ID and name is supported by most tools used today. These tools help identity and locate application elements for the automated test scripts. Automated tools like the prior an described above record this information and store it as part of the automated test script to be used later when the script is executed Although this approach can help in many cases, because its static, it still falls short when the order of elements or the tag&#39;s occurrence is dynamic and changes based upon data entered by a user. A good example of this is a table cell in an HTML table. Depending on what data is requested by the user, there might be one cell or multiple cells in a table and, thus, hard coding any specific tag occurrence or element ID is not feasible. In addition to that, dynamic languages like ASP.NET, generate rich content where users in some cases have no control over the attributes of the elements being emitted. For example, ASP.NET has a calendar control which outputs a very complex set of markups that a user cannot control by annotating the elements with IDs or names. 
         [0014]    To improve test automation, however, there is a need for adaptable and dependable tools that enable one to more efficiently automate the scenarios that one&#39;s software performs in order to generate the automated test scripts. This need has been the key catalyst for innovations the software development lifecycle and, more specifically, in how software is tested throughout the life cycle. In addition, there is increasing pressure for companies to produce software faster and with lower development and maintenance costs. 
         [0015]    Companies have started addressing some of these issues by using abstracted layers that model their specific SAUT built on the top of their automation infrastructure. Automated test scripts go through these abstracted layers to access elements within the application. In the event of a maintenance issue, the use of the abstract model allows the script developer to fix the abstracted layer instead of fixing thousands of automated tests. Although useful, the abstract layers of the conventional systems are hard coded to the specific SAUT. Thus, when any changes are made to the SAUT, the abstract models are rendered useless in most cases. This results in higher development costs due lo the constant maintenance required to keep the models in sync with the SAUT. As such, the inventor of the present invention has recognized the need for a new and improved method of automated testing which addresses these shortcomings. 
       SUMMARY OF THE INVENTION 
       [0016]    In view of the foregoing, various embodiments of the present invention beneficially provide systems, program products, methods, and computer readable media which facilitate software testing and validation. Various embodiments of systems, program products, methods, and computer readable media of the present invention can also advantageously allow users of such to utilize abstract models of a software application under test (i.e., SAUT) to test and validate various regions of the SAUT regardless of the dynamic nature of the SAUT. 
         [0017]    More particularly, an embodiment of the present invention provides a method, system, and computer readable medium for software testing and validation including the computer implemented/assisted steps of: identifying a SAUT; generating from the SAUT, an abstract model of at least one region of the SAUT including data that facilitates adaptation of a test script to the SAUT when changes are made to the SAUT; testing at least one object in the at least one region of the SAUT with the test script utilizing the abstract model to conduct the testing; altering the SAUT by relocating the at least one region of the SAUT and/or redefining the at least one region of the SAUT; and re-executing the test script to test at least one object in the at least one region by navigating the abstract model, performed without regeneration of the abstract model. 
         [0018]    An embodiment of the present invention provides an abstracted set of hierarchal or linear objects that model certain regions of a software application under test, such as, for example, a markup language (i.e., a web application running in a browser or an XML defined application running in a custom host). Automated test scripts can utilize these abstracted regions to help intuitively navigate and identify segments of the SAUT for both action invocation and verification of outputs sad data structures. 
         [0019]    The abstracted regions can be defined and scoped with the SAUT using customizable tags. Each tag defined within the SAUT is independently discoverable using its global unique identifier. Users can define nested objects depending on the need and the design of the SAUT and the level of abstract layering the user&#39;s desires to achieve. The system&#39;s parser automatically builds the abstracted model directly from the SAUT and the test scripts can immediately access them. The abstraction layer is implied directly from the SAUT itself without the need and additional cost of building peripheral abstraction layers in the external test automation framework being used. 
         [0020]    In addition to using the abstracted model to help navigate the SAUT, the automated test scripts can also access specific SAUT elements contained within each region. These elements can then be used to invoke actions on or verily the outputs that persist in the SAUT. The system, also uses a set of rich identification rules embodied in the system, that allow the user to configure the identification of any element within the abstract region. The rules also allow the user to configure the desired level of loose coupling of the automated test script to the target element being automated based upon the complexity and design of the SAUT. Additionally, the location of these elements can be identified using a predefined attribute set of the elements which the system automatically detects and identifies. Various embodiments of the present invention will prove essential when re-architecture of the software application is necessary because it provides the maximum level of ease and the lowest cost for migrating the old automated tests to run against the newly architected software application. In addition, various embodiments of the present invention provides ease of automation and abstraction for maintenance. 
         [0021]    A wide variety of applications and custom tools can be built to leverage various embodiments of the present invention to incorporate in the application life cycle process. For example, development teams can choose to build an early warning system to help predict and identify changes in the SAUT that will affect automated test scripts. Using one or more embodiments of the present invention, such a system can be built without the need to ran all the automated test scripts and analyse their failures (as is done in today&#39;s software development cycles). Instead, one could simply validate the abstracted model structure inferred from the altered SAUT against the last known good version they have stored. 
         [0022]    By providing the before mentioned system, method, and computer readable medium, various embodiments of the present invention provide for software testing and validation having increased flexibility and loose coupling between the automated test script and the target element or region being accessed, thereby adapting the script to the dynamic nature of the SAUT. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0023]    So that the manner in which the features and advantages of the invention, as well as others which will become apparent, may be understood in more detail, a more particular description of the invention briefly summarized above may be had by reference to the embodiments thereof which are illustrated in the appended drawings, which form a part of this specification. It is to be noted, however, that the drawings illustrate only various embodiments of the invention and are therefore not to be considered limiting of the invention&#39;s scope as it may include other effective embodiments as well. 
           [0024]      FIG. 1  illustrates a high level flow chart according to an embodiment of the present invention; 
           [0025]      FIG. 2  illustrates an exemplary mark up language according to an embodiment of the present invention; and 
           [0026]      FIGS. 3-9  illustrate various embodiments of the present invention. 
       
    
    
     DETAILED DESCRIPTION 
       [0027]    The present invention now will be described more fully hereinafter with reference to the accompanying drawings in which embodiments of the invention are shown. This invention may, however, be embodied in many different forms and should not be construed as limited to the illustrated embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. Like numbers refer to like elements throughout. 
         [0028]    Referring to  FIG. 1 , an exemplary embodiment of a high level flow chart of the present invention is illustrated. As shown, the exemplary embodiment of the present invention will first identity a software application to be tested, or a software application under test (i.e., SAUT) at step  100 . The SAUT can be any form of software conceivably used within the scope of this invention, including markup languages. Once identified, the system will then generate an abstract model based upon the SAUT at step  102 . This model can include all or a portion of the SAUT, which ever is desired. Also, as will be discussed later, the abstract model will include data which allows the test script to adapt to the nature of the SAUT. Once the model has been generated, the system will proceed with testing the SAUT with a test script using the abstract model at step  104 . 
         [0029]    In regard to  FIGS. 1-9 , a method of defining an abstracted model of a markup application will now be described. For example, a particular SAUT  20  is an application persisted using a markup language and is shown in  FIG. 2 . The markup language is then interpreted using hosts that present users with data and user interface elements in which users can interact with. Examples of common markup languages are HTML, XML, XHTML, CHTML, XAML, etc. There are slight differences between some of these markup languages in terms of rules of persistence, however, all share the common characteristics of being able to present a hierarchy structure to define the application they are describing or data they are persisting. Although other software languages may be envisioned within the scope of this invention, only markup languages will be discussed throughout the subsequent disclosure. 
         [0030]    Referring to  FIG. 3 , generating an abstract model (step  102  of  FIG. 1 ) to use in the automated testing according to an embodiment of the present invention can be done using tags  22  to outline the desired abstract model. Tags  22  can be predefined and inserted within SAUT hierarchy to define a specific abstract region  24  or element  26 . For example,  FIG. 3  illustrates  FIG. 2  along with three defined abstract regions  24  that describe the overall abstracted model  28 . 
         [0031]    Referring to  FIG. 3 , the predefined tag “&lt;testregion . . . &gt;” is inserted in three locations of SAUT  20 . It is first inserted to outline the region between line  2  and line  23 . This region is identified as “MyApplication” using an ‘id’ attribute. Two other nested abstract regions  24  are defined. The first starting at line  13  to line  17  and is identified as region “Login,” while the other is inserted at line  18  to  21  and is identified as region “DataDisplay.” Given that region “Login” and “DataDisplay” are children of “MyApplication” within the application hierarchy, they are also considered children regions of the “MyApplication” region within abstract model  28 . 
         [0032]    Each abstract region  24  contains a certain set of application elements  26  that become child elements and part of their respective abstract region  24 . For example, region “Login” contains three application elements  26 . The first element is a &lt;label . . . &gt; element at line  14 , the second is an &lt;input type=“text” . . . &gt; element at line  15 , and the third is an &gt;input type=“button” . . . &gt; element at line  16 . Moreover, there are no restrictions to the level of nesting and depth of child elements within a region or of regions nested within other regions. 
         [0033]    Tags  22  are configurable. Users can, for example, change the tag name from “testregion” to any other text. In addition to the tag name, users can configure the tag itself. For users that don&#39;t want to introduce tags into their SAUT test, they can use comment tags to define abstract regions  24 .  FIG. 4  shows the same application of  FIG. 3 , but, instead of using well formed tags like &lt;testregion . . . &gt;, the testing software utilizes a markup comment tag  30  of the form &lt;!--testregion . . . --&gt;. The tag name and format of tags  22 ,  30 , are configured as part of the system that will parse the SAUT. 
         [0034]    In addition to defining abstract model  28 , the exemplary embodiment of the present invention allows for optional lagging of specific elements within each abstract region  24 . This allows the tagged elements to be auto discoverable by the system and available for direct access by test scripts. This also enables a uniform tagging scheme for abstracting the application and tagging its specific elements, which is used by the automated test scripts. In  FIG. 3 , three application elements  26  are tagged with a “testObject” attribute that signifies to the system that this element needs to be auto detected and readily available from within its contained abstracted region  24 . Any elements which are tagged, but do not exist in the abstracted region, will be ignored by the system. For example, the “testObject” attribute value is the unique identifier of that element within its abstracted region. If the “testObject” value is empty, the element is ignored and will not be auto detected by the system. 
         [0035]    In  FIGS. 3 and 5 , three auto discoverable elements are defined. The first is at line  15  within the “Login” region and is identified as “LoginName” by setting the testObject attribute value to “LoginName.” The second is at line  16  and is also within the “Login” region and is identified as “LoginButton.” The third and last element is at line  20  and is identified as “VerifyData.” By defining these elements, they will be readily available and accessible using their identifier directly from their parent abstracted region. 
         [0036]      FIG. 5  illustrates a block diagram of the overall abstracted model  28  and its associated auto discoverable elements  32  that can be accessed as defined by  FIG. 3 . For application elements dial are not fixed and inaccessible, such as dynamically generated languages like ASP.NET, the elements can then be identified using identification rules which are part of the system and are described later in this disclosure. 
         [0037]    After abstracted model  28  and auto discoverable elements  32  are defined using the above method, the system can utilize this data to provide automated test scripts which run against SAUT  20  with an abstraction layer without any additional cost of building dial layer. In addition, the test scripts using the abstracted model  28  will be tied to the abstraction regions regardless of where they are defined or located within the SAUT. This results in a test script having a loose dependency on the SAUT, thus providing the test scripts with added resiliency when dealing with application updates and changes outside of abstracted regions  24 . 
         [0038]    The present invention implements toe method described above using a component called the “TreeBuilder” and two entities: a “TestRegion” and a “TestObject.” These components combined provide the automated test scripts with the access it needs to abstracted model  28  and auto discoverable elements  32 . 
         [0039]    When the test scripts execute the application, it passes its output to the “TreeBuilder.” The “TreeBuilder” contains a markup parser that processes each markup element in the output of the test script. Each tune “TreeBuilder” encounters a &lt;testregion . . . &gt; tag, it will build a TestRegion object representing its respective abstracted region and add it to a flat list of TestRegion collection. The TestRegion collection is directly accessible from the TreeBuilder using the region identifier which is set using the ID attributed on a testregion tag. The TestRegion object stores information about:
       1) The test region location within the application;   2) The parent region that this region is contained in (if any);   3) A collection of sub-regions that might be contained in that region;   4) A reference to all elements contained in that region: and   5) A collection accessible directly by an identifier of all elements that have been tagged with “testObject” to be auto detected by the system. These elements are stored as “TestObject” entities in a collection.       
 
         [0045]    Referring to  FIG. 6 , an exemplary embodiment of a structure of the TestRegions and TestObjects built by the TreeBuilder when processing the markup output modeled in  FIG. 3 , is provided. Note, each TestRegion reflects each abstract region  24  of  FIG. 3 .  FIG. 6  also shows the internal collection of TestObjects built directly within each TestRegion. Also note, each TestObject reflects each auto discoverable element  32 . 
         [0046]    Referring to  FIGS. 6 and 7 , test script  34  can then navigate abstracted model  28  by either (a) directly accessing the TestRegion collection using its identifier, which will locate the TestRegion  24  regardless of its location within abstracted model  28 , or (b) given that each TestRegion entity contains a method to navigate abstracted model  28  up or down the hierarchy, the test script  34  can choose to navigate the model  28  using the model&#39;s hierarchy (i.e., hierarchy access). Users can do this to ensure a certain model&#39;s integrity is present in the SAUT. For example, in  FIG. 6 , test script  34  can access the abstracted region  24  named “Login” by either directly asking for “Login” from the TreeBuilder or first asking for “MyApplication” and then asking the “MyApplication” TestRegion object for its sub-region identified as “Login.” The latter method allows for ensuring the integrity of abstracted model  28  where the “Login” region is contained inside “MyApplication.” Note that accessing regions  24  using the latter approach will result in the test script having a lighter bond to the structure of abstracted model  28 . 
         [0047]    Once test script  34  has access to its desired portion or the SAUT represented as an abstracted TestRegion entity, test script  34  will need to access a specific clement  26 ,  32 , contained within that region  24  in order to invoke actions on or to verify its output. 
         [0048]    Test script  34  can use the system&#39;s Identification Engine to access the elements within the various TestRegions. The identification engine returns an element to automated test script  34  as a TestObject entity. A TestObject entity can represent any element in the SAUT  20 . If the element is auto detected, the TestObject&#39;s auto detected property will be set to true; otherwise, the TestObject auto detected property will be set to false. A TestObject entity contains the following essential information regarding an element:
       (a) The parent TestRegion object that it is contained in (if any); and   (b) A reference to the element (hat this TestObject represents. The reference is represented as either (1) an absolute index of this element within the entire SAUT element&#39;s list, or, (2) the tag name index of this element.       
 
         [0051]    These properties provide the essential information that test script  34  can use to access the elements directly from the host that is currently running the application (e.g., Internet Explorer™, XMLDocument™, etc.). Almost all markup application hosts provide a standard access method to elements using the above information. The system uses this information as the standard set of information to return to test script  34  so it can identify the element and invoke actions on or verify output for these elements. 
         [0052]    Accessing elements from a TestRegion object using the “identification engine” can be performed in two ways:
       1. Directly if the element is set for auto detection using the “testObject” property. For example test script  34  can access the &lt;label . . . &gt; element shown in  FIG. 3  on line  20  by first accessing the TestRegion that this element is contained in (which is: DataDisplay) and then using the TestObject collection that this region contains, test script  34  can access the ‘&lt;label id=“myLabel” . . . &gt;’ test object using its auto detect identifier which is “VerifyData”.  FIG. 7  shows the internal collections built for SAUT  20  defined in  FIG. 3 . Test scripts  34  can first access the “DataDisplay” test region, then access its TestObject collection which contains the “VerifyData” TestObject; and   2. If the element is not set for auto detection, test script  34  can use one of the four identification roles that the identification engine supports. The identification rules provide the test scripts with a rich and a flexible identification mechanism to choose from. The rules are customizable to fit the nature and the characteristics of the SAUT. Test script  34  can also mix these rules to identify any element in a chained identification scheme that is described later in this document.       
 
         [0055]    For each role the Identification Engine requires two pre-requisites:
       1. A reference to an element in the tree to use as a starting point for the search. This reference can be passed to the identification engine as either a TestRegion entity where the search should start or an explicit element represented as a TestObject. When a TestRegion is passed, the identification engine extracts the exact element that this TestRegion starts at and uses it as a starting point; and   2. The target tag name for the element mat you desire to find. This is used as a validation to the success of the search at the end before returning the found element. This is optional. Once these two pre-requisites are met, the rule will return the first element it encounters which matches the identification requirements.       
 
         [0058]    The first identification rule provided by the system is the Hierarchy Identification Rule: This rule searches foe an element using a hierarchy path specified as a string with “/” delimited list of integers. Each “/” represents one depth in the hierarchy and the integer identifies the zero indexed child clement within that hierarchy level. 
         [0059]      FIG. 8  shows an example of how the identification rule can be used to identify a specific element. In this example, the script identities the link element &lt;a . . . &gt; on line  34 . (The element refers to the date “September 30” on a calendar that the script needs to click). The script passes the hierarchy identification rule with string “0/2/6/0” and a starting point as TestRegion: “myCalendar”. The script also passes the tag name of the target clement which is “a”. 
         [0060]    The identification rule embodied in the system starts by splitting the string into a list of four integers “0”, “2”, “6” and “0”. The rule then starts with the left most integer in the list which is “0” and starts by identifying the “0” indexed child element under the starting element TestRegion: “myCalendar”. The “0” indexed element is &lt;table . . . &gt; at line  2 . Once the element, is identified, the rule processes the next integer in the list which is “2”. The rule identifies the element at index “2” under the &lt;table . . . &gt; clement, which is the &lt;tr&gt; element on line  27 . The rule now processes the integer “6”, which is the element &lt;td . . . &gt; at line  34 . The rule then processes the last integer which is “0” and refers to the zero indexed child element of &lt;td . . . &gt; which is the &lt;a . . . &gt; element. Once the rule has reached the last integer, it will verify the tag name with the one passed to it which, in this example, will match and the rule will return a reference to this element (using the information described earlier) to the test script so it can access it. 
         [0061]    This identification rule is very useful when a markup hierarchy (within a region) is fixed but the element types in that hierarchy, including their attributes and ids, are dynamic or consistently changing within the application and users want to shield their test scripts from these application changes. 
         [0062]    The second identification rule provided by the present invention is the Attribute Identification Rule. This rule searches for an element using a certain combination of attributes that are set on each element. The rule can search 1−n attribute combinations. Each combination can be an exact property name/value pairs or property name/partial value pairs. 
         [0063]    For example, in  FIG. 8 , the test scripts can identify the &lt;a . . . &gt; element on line  34 , by simply passing in any of the following attribute combinations, in addition to the starting point which is the TestRegion: “myCalendar” and the target, tag name which is “a”. The following is an example.
       Example 1: Exact property name/value pair   title=“September 30”       
 
         [0066]    In this example, the rule will check every element contained within the starting point and check each element&#39;s attribute list against the one passed in. In  FIG. 8 , only element &lt;a . . . &gt; on line  34  matches the combination above since it is the only element contained in “myCalendar” that has a property named “title” with a value of “September 30”. 
         [0067]    Another example is provided below:
       Example 2: property name/partial value pair   bref=‘2464’       
 
         [0070]    In this example, the rule will use the same logic as in Example 1 but instead or checking the exact value of the attribute, it will check for the partial value. Again in  FIG. 8 , the only element that will match the above pair, is the &lt;a . . . &gt; element on line  34  since it&#39;s the only element that has a “href” property with a value that contains the partial string “‘2464’”. 
         [0071]    The Attribute Identification Rule supports n number of attribute pairs. If more than one pair is present then all combinations need to match the element&#39;s attributes for u to be considered found. For example, if you use the following pairs:
       Exact (title=“September 30”)   Partial (href=‘2464’)       
 
         [0074]    The clement on line  34  will be found. If you change the first pair to be title=“foo”, the element will not be found even though the partial pair (href=‘2464’) matches. As mentioned above, both pairs need to match for the element to be found. 
         [0075]    The third identification rule provided by the present invention is the Tag Index Identification Rule. This is the basic rule that searches a specific tag based on its tag name occurrence. This rule is similar to the standard identification implemented in the core javascript engine and Microsoft HTML Document Object Model. The difference is that this rule takes in, as discussed earlier, a starting point. So the occurrence doesn&#39;t always have to be calculated from the root of the markup application, it can start at any element that is passed in as the starting point. 
         [0076]    For example, in  FIG. 8 , we can identify the &lt;a . . . &gt; element on line  34  by simply using this rule and passing in an index of “8” since the &lt;a . . . &gt; element on line  34  is the 9 th  &lt;a . . . &gt; element that occurs starting at TestRegion: “myCalendar” and, hence, has an index of 8.  FIG. 9  shows the indices of all the &lt;a . . . &gt; elements contained in  FIG. 8 . The rule embodied in the system will search each element and every time it encounters an &lt;a . . . &gt; element, it will increment an internal counter. Once the counter matches the indexed passed in the rule, the element will be returned to the test script that requested it. 
         [0077]    The fourth identification rule provided by the present invention is the Regular Expression Identification Rule. This rule searches for tags using a regular expression passed to the identification engine as a string. If an element matches the regular expression passed in, it is returned as the found element. You have the option to match the element with (a) all its contents or (b) simply the element starting tag. 
         [0078]    For example, in  FIG. 8 , you can simply identify the &lt;a . . . &gt; element on line  34  by using this rule with the following regular expression: “&lt;a*&gt;30&lt;/a&gt;” with the option of matching the element will all its content. Where, in another example, you can identify the &lt;a . . . &gt; element on line  34  by using this rate with the following regular expression; “&lt;a*‘2464’*&gt;” with the option of matching only element starting tag. The rule tests each element contained within the TestRegion: “myCalendar” against the regular expression passed in and given the options set. Once a match is found, the element is returned to the test script as the found element. 
         [0079]    In another exemplary embodiment of the present invention, the rules above can be mixed and matched to offer an even more powerful and flexible identification scheme called, an identification chain. The system supports identifying an element using multiple configured rules from the set described above. Each rule can be used to identify a segment of the path to the targeted element. For example, in  FIG. 8  we can use a chained set of rules to identify the &lt;a . . . &gt; element on line  34 . For example, we will use a Hierarchy Rule to first identify the &lt;tr&gt; element on line  27 , then use an Attribute Rule to identify the &lt;a . . . &gt; clement on line  34 . The Hierarchy Rule will have a hierarchy string: “0/2” and a starting point TestRegion: “myCalendar” and a target clement tag name “tr”. The Attribute Rule will have an exact attribute combination of {title=“September 30”} with a starting point as the &lt;tr&gt; element identified by the previous Hierarchy Rule in the identification chain and the target element tag name of “a”. The identification system supports passing in 1−n chained rules and will automatically use the found element from previous rule as the starling point element of the next rule until all rules are executed. 
         [0080]    It is important to note that while embodiments of the present invention have been described in the context of a fully functional system and method embodying the invention, those skilled in the art will appreciate mat the mechanism of the present invention and/or aspects thereof are capable of being distributed in the form of a computer readable medium storing a set of instructions in a variety of forms for execution on a processor, processors, or the like, and that various embodiments of the present invention apply equally regardless of the particular type of media used to actually carry out the distribution. Examples of such computer readable media can, but need not, include but are not limited to: nonvolatile, hard-coded type media such as read only memories (ROMs), CD-ROMs, and DVD-ROMs, or erasable, electrically programmable read only memories (EEPROMs), recordable type media such as floppy disks, hard disk drives, CD-R/RWs, DVD-RAMs, DVD-R/RWs, DVD+R/RWs, flash drives, and other newer types of memories, and transmission type media such as digital and analog communication links capable of storing instructions. For example, such media can include both operating instructions and/or instructions related  10  the system and the method steps described above. 
         [0081]    While this invention has been shown in only one of its forms, it should be apparent to those skilled in the art that it is not so limited but is susceptible to various changes without departing from the spirit and scope Of the invention. In the drawings and specification, there have been disclosed illustrative embodiments of the invention and, although specific terms are employed, they are used in a generic and descriptive sense only and not for the purpose of limitation, the scope of the invention being set forth in the following claims.