Test script transformation analyzer with economic cost engine

CROSS REFERENCE TO RELATED APPLICATIONS

This application is related to following applications, all filed on the same day: <ul><li id="ul0001-0001" num="0002">U.S. patent application Ser. No. 12/038,665, filed Feb. 27, 2008;</li><li id="ul0001-0002" num="0003">U.S. patent application Ser. No. 12/038,672, filed Feb. 27, 2008;</li><li id="ul0001-0003" num="0004">U.S. patent application Ser. No. 12/038,676, filed Feb. 27, 2008;</li><li id="ul0001-0004" num="0005">U.S. patent application Ser. No. 12/038,661, filed Feb. 27, 2008; and</li><li id="ul0001-0005" num="0006">U.S. patent application Ser. No. 12/038,658, filed Feb. 27, 2008.</li></ul>

BACKGROUND OF THE INVENTION

1. Technical Field

This disclosure relates to analysis and generation of cost estimates for testing graphical user interface applications, and in particular relates to estimating the costs to transform a prior test script and to test new application versions.

2. Related Art

The relentless pace of advancing technology has given rise to complex computer software applications to help automate almost every aspect of day-to-day existence. Today applications exist to assist with writing novels to filing income tax returns to analyzing historical trends in baby names. One nearly ubiquitous feature of these applications is that they employ graphical user interfaces (GUIs). Another nearly ubiquitous aspect is that the GUI APplications (GAPs) require thorough testing prior to release.

Nevertheless, in the past it has been easier to implement the GUI to the application than to thoroughly test the GAP. For GAPs of any significant complexity, the permutations and combinations of GUI elements gives rise to an enormous field of potential commands and command sequences that could have bugs of any severity, from insignificant to critical failure. Exacerbating the problem is that application developers are under pressure to continually add new features, update the GUI, and release new versions of applications. As a result, even if a test script for a prior version of a GAP were adequate, it is rarely the case that the original test script can adequately test the subsequent revised application.

Manually testing large-scale enterprise GAPs is tedious, error prone, incomplete, and laborious. Nontrivial GAPs contain hundreds of GUI screens that in turn contain thousands of GUI objects. In order to automate testing of GAPs, test engineers write programs using scripting languages (e.g., JavaScript and VBScript), and these testing scripts drive GAPs through different states by mimicking users who interact with these GAPs by performing actions on their GUI objects. Often test scripts simulate users of GAPs, and their statements access and manipulate GUI objects of these GAPs. For example, the statement:

VbWindow(“Login”).VbEdit(“txtAgentsName”).Set “Shawn”

locates a window whose caption is Login and that is created by a Visual Basic-based control, then it locates a text box whose name is txtAgentsName that is a GUI object whose parent is the login window. By calling the method Set with the parameter “Shawn”, the value of the text box is set to “Shawn”.

Commercial tools such as Quick Test Pro (QTP), Rational Robot, and Compuware Test Partner help generate test scripts by tracking pointing of a cursor at GUI objects and performing desired actions. These tools generate scripting code that can replay captured user actions. The generated code serves as a skeleton for creating scripts to automate script testing. Test engineers add code to the generated scripts so that these scripts can replay using different input values thereby exercising the functionality of the GAP.

Expanding test scripts with manually written code to automate tests makes the test script more complex, difficult to understand, maintain, and evolve. Similarly, estimating the costs to expand test scripts and to perform tests using the expanded test scripts is a difficult and highly technical challenge. Although it is known in advance that the test scripts access and manipulate GUI elements, it is not clear how to detect operations at compile time that lead to runtime errors. Using API calls exported by testing platforms remains a primary mode of accessing and manipulating GUI objects of GAPs, and these API calls lead to various run-time errors in the test scripts. For example, test personnel may use platform API calls incorrectly in the test script source code thereby accessing GUI elements that test personnel did not intend to access.

It is difficult to check test scripts for potential flaws caused by third party API calls that lead to incorrect tests and runtime errors in the test scripts. It is also a difficult technical challenge to estimate the costs in time and resources and time to test a subsequent revised application since these test scripts should be modified to adapt to changes in the GAPs. Furthermore, there are fundamental problems with using API calls to access and manipulate GUI objects. First, the API calls take names and property values of GUI objects as string input parameter variables. The values of these input parameters are often known only at runtime, making it impossible to apply sound checking algorithms. Second, testing platforms export dozens of different API calls, and high complexity of these API calls makes it difficult for programmers to understand which API calls to use and how to combine them to access and manipulate GUI objects. These problems lead to a wide range of bugs in the test scripts, many of which are difficult to detect during the inspection of the test script source code.

A further problem arises because application requirement specifications include high-level concepts that describe GAPs, specifically its GUI objects. Unfortunately, tracing GUI objects of GAPs to these high-level concepts is a difficult problem because programmers poorly document these traces or do not document them at all. Accordingly, when test personnel create GAPs, they spend considerable time to understand how to use these GAPs by reading documentation and talking to subject matter experts. This crucial knowledge is often lost after test personnel are reassigned to other tasks or quit the company.

One of the perceived benefits of existing approaches to creating test scripts is that type checking is not required since the script code is generated directly from GUIs. For example, given certain GUI objects in a GAP, a testing tool can produce corresponding statements that navigate to these objects using API calls with string parameters that describe their properties. However, this perceived benefit in fact gives rise to difficult technical challenges due to semantic inconsistencies between the test script and the GAP. Suppose, for example, that during the maintenance phase the GUI of the GAP changed. The scripting interpreter is not aware of the change and it would run the generated script without producing any compile-time warnings. However, the resulting script either fails at run time or produces incorrect test results because its code attempts to access GUI objects that are either changed or do not exist anymore.

Therefore, a need exists to address the problems noted above and other previously encountered.

SUMMARY

A test script transformation analyzer with economic cost engine (“economic cost engine architecture”) generates accurate test script transformation cost reports for applications with graphical user interfaces that change over time. As the applications change, prior test scripts are rendered unworkable. The economic cost engine architecture facilitates estimating the costs to generate new test scripts and use the new test scripts to reliably test subsequent application versions, and may greatly reduce the time, cost, and resource expenditures needed to deploy subsequent application versions. The test script transformation cost reports may identify the costs to generate new test scripts and use the new test scripts to reliably test subsequent application versions.

The economic cost engine architecture may accept as input a GUI difference model and GUI element metadata. The GUI difference model specifies GUI element differences between a current GAP version and a subsequent GAP version. The economic cost engine architecture further includes an economic cost engine that generates a test script transformation cost report. The test script transformation cost report may include the costs to modify script entries in the current test script to obtain a transformed test script and may include the costs to test the subsequent GAP version using the transformed test script. The economic cost engine may generate the test script transformation cost report based on an abstract syntax tree representation of a current test script and the GUI difference model. The economic cost engine may generate the test script transformation cost report based on GAP change specifiers that describe various proposed changes to a current GAP version and current test script. The economic cost engine may also use the GAP change specifiers, the representation of the current test script and current GAP version to generate the test script transformation cost report.

In one implementation, the economic cost engine architecture provides a product and system for test script transformation cost analysis. The architecture generates a test script transformation cost report for a subsequent graphical user interface application (GAP) version arising from a current GAP version. The architecture determines the resources and time needed to produce a transformed test script and perform testing of the subsequent GAP. The economic cost engine architecture includes an economic cost engine that includes a processor, and a memory coupled to the processor. The memory of the economic cost engine includes economic cost model logic operable to receive a GAP change specifier, search an economic model repository for an applicable GUI element change cost rule, and apply the cost rule to obtain a GUI transformation cost. The economic cost engine generates the test script transformation cost report based on the GUI transformation cost.

The test script transformation cost report may include cost estimates to generate a transformed test script for a subsequent GAP version arising from a current GAP version and cost estimates to test the subsequent GAP using the transformed test script. The economic cost model logic receives a GUI difference model and a current test script representation for a current test script for testing the current GAP. The current test script representation includes a test script statement vector that navigates to GUI objects in the current GAP. The economic cost model logic locates, in an object repository, a GUI object entry matching the test script statement vector and locates, in the GUI difference model, a GUI element difference entry matching the GUI object entry. The GUI element difference entry may identify a specific GUI element that matches between a current GAP version and a subsequent GAP version, but that differs in character between the current GAP version and the subsequent GAP version. The economic cost model logic analyzes the GUI element difference entry to determine whether the specific GUI element has changed, and generates one or more corresponding synthetic GAP change specifiers that reflect the change.

The economic cost model logic locates, in an economic models repository, a GUI element change cost rule, using the received GAP change specifiers and/or synthetic GAP change specifiers. The GUI element change cost rules may include change specifier identifiers, system resource utilization identifiers, GUI change cost estimates that indicate estimated time and/or resources needed to complete a change identified by a change specifier identifier, and dependent change specifier identifiers that identify other changes that depend on the change identified by the change specifier identifier. The GUI element change cost rules may further include dependency rankings, quality rankings, complexity rankings and dependent GUI element change costs.

Other systems, methods, features and advantages will be, or will become, apparent to one with skill in the art upon examination of the following figures and detailed description. All such additional systems, methods, features and advantages are included within this description, are within the scope of the claimed subject matter, and are protected by the following claims.

BRIEF DESCRIPTION OF THE DRAWINGS

The economic cost engine architecture may be better understood with reference to the following drawings and description. The elements in the figures are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the system. In the figures, like-referenced numerals designate corresponding parts throughout the different views.

<figref idrefs="DRAWINGS">FIG. 1</figref> shows a test script transformation analyzer with economic cost engine architecture.

<figref idrefs="DRAWINGS">FIG. 2</figref> shows a GUI of a current GAP version.

<figref idrefs="DRAWINGS">FIG. 3</figref> shows a GUI of a subsequent GAP version.

<figref idrefs="DRAWINGS">FIG. 4</figref> illustrates a current and a subsequent GAP GUI comparison.

<figref idrefs="DRAWINGS">FIG. 5</figref> shows an exemplary GUI element difference entry.

<figref idrefs="DRAWINGS">FIG. 6</figref> shows a current test script.

<figref idrefs="DRAWINGS">FIG. 7</figref> shows a current test script representation.

<figref idrefs="DRAWINGS">FIG. 8</figref> shows an example economic cost engine system.

<figref idrefs="DRAWINGS">FIG. 9</figref> shows a flow diagram for retrieving the properties of a GUI object entry from an object repository (OR).

<figref idrefs="DRAWINGS">FIG. 10</figref> shows a flow diagram for identifying a GUI difference entry corresponding to a GUI object entry.

<figref idrefs="DRAWINGS">FIG. 11</figref> shows a transformed test script.

<figref idrefs="DRAWINGS">FIG. 12</figref> shows a flow diagram for generating a synthetic GAP change specifier.

<figref idrefs="DRAWINGS">FIG. 13</figref> shows a flow diagram for outputting a test script transformation cost report based on a GUI difference model.

<figref idrefs="DRAWINGS">FIG. 14</figref> illustrates another GUI element difference entry.

<figref idrefs="DRAWINGS">FIG. 15</figref> show another example GUI element difference entry.

<figref idrefs="DRAWINGS">FIG. 16</figref> illustrates navigation paths from a source to a destination object.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

<figref idrefs="DRAWINGS">FIG. 1</figref> shows a test script transformation analyzer with economic cost engine (“economic cost engine architecture”) <b>110</b>. Although detailed descriptions of the features of the economic cost engine architecture <b>110</b> will be provided further below, a brief introduction of the economic cost engine architecture <b>110</b> will first be presented. In one implementation, the economic cost engine architecture <b>110</b> receives a GUI difference model <b>162</b> that specifies GUI element differences between a current GAP version <b>150</b> and a subsequent GAP version <b>152</b>. The GUI difference model <b>162</b> may be represented as an XML schema. The GUI element difference model <b>162</b> may include current and subsequent GAP tree models corresponding to the current GAP version <b>150</b> and subsequent GAP version <b>152</b>. In one implementation, the economic cost engine <b>182</b> receives the current GAP tree model from the GUI element difference model <b>162</b>. In another implementation, the current and subsequent GAP tree models, as well as the GUI difference model <b>162</b> are implemented as relational models stored in a database. The economic cost engine architecture <b>110</b> employs an interface <b>190</b> to receive inputs and communicate with various components, including a GUI element metadata repository <b>138</b>. The GUI element metadata repository <b>138</b> may provide detailed information regarding the GUI elements represented in the GUI difference model <b>162</b>, the current GAP <b>150</b> and the subsequent GAP <b>152</b>.

The economic cost engine architecture <b>110</b> includes a script parser <b>166</b> that parses a current test script <b>164</b> to obtain an intermediate representation of the current test script <b>164</b>. The intermediate representation may be an abstract syntax tree (AST) <b>168</b> or other representation of the current test script <b>164</b>. In one implementation, the economic cost engine architecture <b>110</b> employs an economic cost engine <b>182</b> that analyzes the AST <b>168</b> and the GUI difference model <b>162</b>. The economic cost engine <b>182</b> may invoke object repository (OR) lookup logic <b>172</b> to search an object repository <b>174</b> and the GUI difference model <b>162</b> to locate, in the GUI difference model <b>162</b>, the GUI elements identified by the AST <b>168</b>. The economic cost engine <b>182</b> includes economic cost model logic <b>196</b> that uses the GUI elements identified by the AST <b>168</b> and GUI difference model <b>162</b> to generate synthetic GAP change specifiers <b>185</b> that are used to search an economic models <b>176</b> repository for corresponding GUI element change cost rule. In one implementation, the economic cost model logic <b>196</b> uses GAP change specifiers <b>184</b> and synthetic GAP change specifiers <b>185</b> to search an economic models <b>176</b> repository for corresponding GUI element change cost rule. The economic cost engine <b>182</b> applies each GUI element change cost rule to obtain corresponding GUI transformation costs from which a test script transformation cost report <b>186</b> is generated, discussed further below. The economic cost engine <b>182</b> may also use historical testing metrics from a performance metrics repository <b>198</b> and cost reports repository <b>888</b> to facilitate obtaining the GUI transformation costs, discussed below.

The economic cost engine <b>182</b> may generate test script transformation cost reports <b>186</b> based on different combinations of available information, including: 1) GAP change specifiers <b>184</b> and/or synthetic GAP change specifiers <b>185</b>; 2) GAP change specifiers and a current test script <b>164</b>; 3) GAP change specifiers <b>184</b>, a current test script <b>164</b> and a current GAP version <b>150</b> (e.g., a current GAP tree model); 4) a current test script <b>164</b> and a GUI difference model <b>162</b> with GUI element difference entries; and 5) GAP change specifiers <b>184</b>, a current test script <b>164</b>, and a GUI difference model <b>162</b>. Other combinations of the same or different information may also be employed. The various combinations of available information are used by the economic cost engine <b>182</b> to analyze received and/or generate synthetic GAP change specifiers <b>185</b> that are used by the economic cost model logic <b>196</b> to locate and retrieve GUI transformation costs and generate test script transformation cost reports.

The accuracy of the GUI transformation costs may depend in part on how narrow the variance is between the actual costs and the costs indicated by the GUI transformation costs. A large variance corresponds to a lower accuracy, while a narrow variance corresponds to a higher accuracy. In other words, the accuracy of the GUI transformation costs may correspond to the predictability and/or confidence that the actual costs will reflect the GUI transformation costs. In one implementation, the accuracy of the GUI transformation costs varies due to the granularity of the information received by the economic cost engine <b>182</b>. For example, the GUI transformation costs generated as a result of the economic cost engine <b>182</b> receiving GAP change specifiers <b>184</b>, a current test script <b>164</b>, and a GUI difference model <b>162</b> may have a higher level of accuracy than the GUI transformation costs generated based solely on GAP change specifiers <b>184</b>. The economic cost engine <b>182</b> may employ various economic models that compensate for the lack of granularity of information provided to the economic cost engine <b>182</b>, discussed in further detail below.

In one implementation, the economic cost engine <b>182</b> receives GAP change specifiers <b>184</b>, a current test script <b>164</b> and a current GAP version <b>150</b>, and generates a GUI difference model <b>162</b>. In other words, the economic cost engine <b>182</b> may generate the test script transformation cost report <b>186</b> based on the AST <b>168</b>, the current GAP version <b>150</b> and GAP change specifiers <b>184</b>, discussed further below, without relying on an actual subsequent GAP version <b>152</b>. For example, the economic cost engine <b>182</b> analyzes the GAP change specifiers <b>184</b> and the current GAP version <b>150</b> (e.g., a current GAP tree model received from the GUI difference model <b>162</b>), and generates synthetic GAP change specifiers <b>185</b>. In another implementation, the economic cost engine <b>182</b> generates the test script transformation cost report <b>186</b> based on the GAP change specifiers <b>184</b>, without analyzing either the GUI difference model <b>162</b> and/or the AST <b>168</b>. The economic cost engine <b>182</b> may generate the test script transformation cost reports <b>186</b> with change guide messages retrieved from a change guide message repository <b>192</b>. The change guide messages may provide information regarding the various changes corresponding to the GAP change specifiers <b>184</b>, GUI element change cost rules and/or GUI difference entries.

<figref idrefs="DRAWINGS">FIG. 2</figref> shows a GUI of a current GAP version <b>150</b>. Table 1 shows a current GAP tree model representation of the GUI of the current GAP version <b>150</b>. The current GAP tree model shown in Table 1 specifies the GUI elements and attributes of the GUI elements of the current GAP version <b>150</b>. Table 1 illustrates that the current GAP tree model supports GUI elements that include nested GUI elements. For example, StateList window <b>202</b>, shown in <figref idrefs="DRAWINGS">FIG. 2</figref>, corresponds to GUI Element Alias StateList at line <b>11</b> (L<b>11</b>) of Table 1 and nested GUI elements SaveFile, Exit, SaveChange, FileOpen, listbox School, shown at lines <b>18</b>-<b>21</b> and <b>59</b> of Table 1, correspond, respectively, to Save File <b>204</b>, Close Form <b>206</b>, Save Change <b>208</b>, Open File <b>210</b> and listbox School <b>216</b> of <figref idrefs="DRAWINGS">FIG. 2</figref>. In one implementation, the GUI difference model <b>162</b> results from a comparison of the current GAP tree model as shown in Table 1 and a subsequent GAP tree model illustrated below in Table 3.

A GAP, the GUI elements of the GAP, and the values of the GUI elements may be considered state information for the GAP. The current and subsequent GAP tree models capture the states of the current and subsequent GAP versions (e.g., <b>150</b> and <b>152</b>), respectively. In one implementation, GAP states are identified by sequence numbers and alias, as well as other attributes. For example, line <b>1</b> of Table 1 illustrates a ‘state’ that has a SeqNumber with a value of 0. The SeqNumber represents a unique sequence number of the current GAP version. The state is given the name State_—0_—3556. The attributes Alias and Processid represent the alias of the current GAP version <b>150</b> and the instance process identifier for the current GAP version <b>150</b>, respectively. Recall that Table 1 and Table 3 illustrate that the current and subsequent GAP tree models support GUI elements that include nested GUI elements. Although multiple GUI elements may use an identical Alias (e.g., StateList as illustrated in Table 1 at lines <b>2</b> and <b>11</b>) the GUI elements are further distinguished by the UniqueID attribute (e.g., 0x0 and 0x12 as shown at lines <b>3</b> and <b>12</b> of Table 1).

<tables id="TABLE-US-00001" num="00001"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 1</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Current GAP tree model</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry>− &lt;State SeqNumber=“0” Name=“State_0_3556” Alias=“University</entry></row><row><entry>Directory0” ProcessId=“3556”&gt;</entry></row><row><entry> − &lt;GUIElement Alias=“StateList”&gt;</entry></row><row><entry>  &lt;UniqueID&gt;0x0&lt;/UniqueID&gt;</entry></row><row><entry>  &lt;HWND&gt;0x170a64&lt;/HWND&gt;</entry></row><row><entry>  &lt;Location x=“87” y=“66” width=“792” height=“672” /&gt;</entry></row><row><entry>  &lt;Class&gt;WindowsForms10.Window.8.app4&lt;/Class&gt;</entry></row><row><entry>  &lt;Style&gt;0x16cf0000&lt;/Style&gt;</entry></row><row><entry>  &lt;ExStyle&gt;0xc0050900&lt;/ExStyle&gt;</entry></row><row><entry> + &lt;GUIElement Alias=“System”&gt;</entry></row><row><entry> + &lt;GUIElement Alias=“NAMELESS”&gt;</entry></row><row><entry>L11 − &lt;GUIElement Alias=“StateList”&gt;</entry></row><row><entry>  &lt;UniqueID&gt;0x12&lt;/UniqueID&gt; fs</entry></row><row><entry>  &lt;HWND&gt;0x170a64&lt;/HWND&gt;</entry></row><row><entry>  &lt;Location x=“117” y=“70” width=“784” height=“638” /&gt;</entry></row><row><entry>  &lt;Class&gt;WindowsForms10.Window.8.app4&lt;/Class&gt;</entry></row><row><entry>  &lt;Style&gt;0x16cf0000&lt;/Style&gt;</entry></row><row><entry>  &lt;ExStyle&gt;0xc0050900&lt;/ExStyle&gt;</entry></row><row><entry>L18 + &lt;GUIElement Alias=“SaveFile”&gt;</entry></row><row><entry>L19 + &lt;GUIElement Alias=“Exit”&gt;</entry></row><row><entry>L20 + &lt;GUIElement Alias=“SaveChange”&gt;</entry></row><row><entry>L21 + &lt;GUIElement Alias=“FileOpen”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“Location”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“AcademicEmph”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“QoIScale”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“SocialScale”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“AcadScale”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“EnrolledPerc”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“AdmittancePerc”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“NumApps”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“FinancialAid”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“Expense”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“SATMath”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“SATVerbal”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“SFRatio”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“MFRatio”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“NumStudents”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“Control”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“State”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“School”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“Location”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“Academic Emphasis”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“Quality of Life Scale (1-5)”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“Social Scale (1-5)”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“Academics Scale (1-5)”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“Enrolled %”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“Admittance %”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“# Applicants (1000)”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“Financial Aid %”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“Expenses (1000$)”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“SAT:math”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“Student/Faculty Ratio”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“SAT:verbal”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“Male/Female Ratio”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“Number of Students (1000)”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“Control”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“State”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“SelectSchoolBtn”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“School List”&gt;</entry></row><row><entry>L59 + &lt;GUIElement Alias=“SchoolListbox”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“SelectStateBtn”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“State List”&gt;</entry></row><row><entry>L62 + &lt;GUIElement Alias=“StateListbox”&gt;</entry></row><row><entry> &lt;/GUIElement&gt;</entry></row><row><entry> &lt;/GUIElement&gt;</entry></row><row><entry>&lt;/State&gt;</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

The StateListBox GUI element shown in Table 1 at line <b>62</b> corresponds to the State listbox <b>212</b> shown in <figref idrefs="DRAWINGS">FIG. 2</figref>. <figref idrefs="DRAWINGS">FIG. 2</figref> shows a horizontal navigation bar <b>214</b> as a feature of the State listbox <b>212</b>. Table 2 shows some of the attributes of State listbox <b>212</b> that may be reflected in the GUI difference model <b>162</b> as a result of a comparison between the current GAP tree model and the subsequent GAP tree model shown in Table 3.

<tables id="TABLE-US-00002" num="00002"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 2</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Current GAP StateListbox GUI element schema</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="14pt" align="left" /><colspec colname="2" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>− &lt;GUIElement Alias=“StateListbox”&gt;</entry></row><row><entry /><entry> &lt;UniqueID&gt;0x407&lt;/UniqueID&gt;</entry></row><row><entry /><entry> &lt;HWND&gt;0x90b58&lt;/HWND&gt;</entry></row><row><entry /><entry> &lt;Location x=“173” y=“86” width=“368” height=“274” /&gt;</entry></row><row><entry /><entry> &lt;Class&gt;WindowsForms10.LISTBOX.app4&lt;/Class&gt;</entry></row><row><entry /><entry> &lt;Style&gt;0x56110ac1&lt;/Style&gt;</entry></row><row><entry /><entry>  &lt;ExStyle&gt;0xc0000a00&lt;/ExStyle&gt;</entry></row><row><entry /><entry> − &lt;GUIElement Alias=“StateListbox”&gt;</entry></row><row><entry /><entry>   &lt;UniqueID&gt;0x410&lt;/UniqueID&gt;</entry></row><row><entry /><entry>   &lt;HWND&gt;0x90b58&lt;/HWND&gt;</entry></row><row><entry /><entry>  &lt;Location x=“175” y=“88” width=“364” height=“253” /&gt;</entry></row><row><entry /><entry>  &lt;Class&gt;WindowsForms10.LISTBOX.app4&lt;/Class&gt;</entry></row><row><entry /><entry>  &lt;Style&gt;0x56110ac1&lt;/Style&gt;</entry></row><row><entry /><entry>  &lt;ExStyle&gt;0xc0000a00&lt;/ExStyle&gt;</entry></row><row><entry /><entry> − &lt;Values&gt;</entry></row><row><entry /><entry>  &lt;Value SeqNumber=“0”&gt;Alabama&lt;/Value&gt;</entry></row><row><entry /><entry>  &lt;Value SeqNumber=“1”&gt;Alaska&lt;/Value&gt;</entry></row><row><entry /><entry>  &lt;Value SeqNumber=“2”&gt;Arizona&lt;/Value&gt;</entry></row><row><entry /><entry>  &lt;Value SeqNumber=“3”&gt;Arkansas&lt;/Value&gt;</entry></row><row><entry /><entry>  &lt;Value SeqNumber=“4”&gt;California&lt;/Value&gt;</entry></row><row><entry /><entry>  &lt;Value SeqNumber=“5”&gt;Colorado&lt;/Value&gt;</entry></row><row><entry /><entry>  &lt;Value SeqNumber=“6”&gt;Connecticut&lt;/Value&gt;</entry></row><row><entry /><entry>  &lt;Value SeqNumber=“7”&gt;Delaware&lt;/Value&gt;</entry></row><row><entry /><entry>  &lt;Value SeqNumber=“8”&gt;District of Columbia&lt;/Value&gt;</entry></row><row><entry /><entry>  &lt;Value SeqNumber=“9”&gt;Florida&lt;/Value&gt;</entry></row><row><entry /><entry>  &lt;Value SeqNumber=“10”&gt;Georgia&lt;/Value&gt;</entry></row><row><entry /><entry>  &lt;Value SeqNumber=“11”&gt;Hawaii&lt;/Value&gt;</entry></row><row><entry /><entry>  &lt;Value SeqNumber=“12”&gt;Idaho&lt;/Value&gt;</entry></row><row><entry /><entry>  &lt;Value SeqNumber=“13”&gt;Illinois&lt;/Value&gt;</entry></row><row><entry /><entry>  &lt;Value SeqNumber=“14”&gt;Indiana&lt;/Value&gt;</entry></row><row><entry /><entry>  &lt;Value SeqNumber=“15”&gt;Iowa&lt;/Value&gt;</entry></row><row><entry /><entry>  &lt;Value SeqNumber=“16”&gt;Kansas&lt;/Value&gt;</entry></row><row><entry /><entry>  &lt;Value SeqNumber=“17”&gt;Kentucky&lt;/Value&gt;</entry></row><row><entry /><entry>  &lt;Value SeqNumber=“18”&gt;Louisiana&lt;/Value&gt;</entry></row><row><entry /><entry>  &lt;Value SeqNumber=“19”&gt;Maine&lt;/Value&gt;</entry></row><row><entry /><entry>  &lt;Value SeqNumber=“20”&gt;Maryland&lt;/Value&gt;</entry></row><row><entry /><entry>  &lt;Value SeqNumber=“21”&gt;Massachusetts&lt;/Value&gt;</entry></row><row><entry /><entry>  &lt;Value SeqNumber=“22”&gt;Michigan&lt;/Value&gt;</entry></row><row><entry /><entry>  &lt;Value SeqNumber=“23”&gt;Minnesota&lt;/Value&gt;</entry></row><row><entry /><entry>  &lt;Value SeqNumber=“24”&gt;Mississippi&lt;/Value&gt;</entry></row><row><entry /><entry>  &lt;Value SeqNumber=“25”&gt;Missouri&lt;/Value&gt;</entry></row><row><entry /><entry>  &lt;Value SeqNumber=“26”&gt;Montana&lt;/Value&gt;</entry></row><row><entry /><entry>  &lt;Value SeqNumber=“27”&gt;Nebraska&lt;/Value&gt;</entry></row><row><entry /><entry>  &lt;Value SeqNumber=“28”&gt;Nevada&lt;/Value&gt;</entry></row><row><entry /><entry>  &lt;Value SeqNumber=“29”&gt;New Hampshire&lt;/Value&gt;</entry></row><row><entry /><entry>  &lt;Value SeqNumber=“30”&gt;New Jersey&lt;/Value&gt;</entry></row><row><entry /><entry>  &lt;Value SeqNumber=“31”&gt;New Mexico&lt;/Value&gt;</entry></row><row><entry /><entry>  &lt;Value SeqNumber=“32”&gt;New York&lt;/Value&gt;</entry></row><row><entry /><entry>  &lt;Value SeqNumber=“33”&gt;North Carolina&lt;/Value&gt;</entry></row><row><entry /><entry>  &lt;Value SeqNumber=“34”&gt;North Dakota&lt;/Value&gt;</entry></row><row><entry /><entry>  &lt;Value SeqNumber=“35”&gt;Ohio&lt;/Value&gt;</entry></row><row><entry /><entry>  &lt;Value SeqNumber=“36”&gt;Oklahoma&lt;/Value&gt;</entry></row><row><entry /><entry>  &lt;Value SeqNumber=“37”&gt;Oregon&lt;/Value&gt;</entry></row><row><entry /><entry>  &lt;Value SeqNumber=“38”&gt;Pennsylvania&lt;/Value&gt;</entry></row><row><entry /><entry>  &lt;Value SeqNumber=“39”&gt;Rhode Island&lt;/Value&gt;</entry></row><row><entry /><entry>  &lt;Value SeqNumber=“40”&gt;South Carolina&lt;/Value&gt;</entry></row><row><entry /><entry>  &lt;Value SeqNumber=“41”&gt;South Dakota&lt;/Value&gt;</entry></row><row><entry /><entry>  &lt;Value SeqNumber=“42”&gt;Tennessee&lt;/Value&gt;</entry></row><row><entry /><entry>  &lt;Value SeqNumber=“43”&gt;Texas&lt;/Value&gt;</entry></row><row><entry /><entry>  &lt;Value SeqNumber=“44”&gt;Utah&lt;/Value&gt;</entry></row><row><entry /><entry>  &lt;Value SeqNumber=“45”&gt;Vermont&lt;/Value&gt;</entry></row><row><entry /><entry>  &lt;Value SeqNumber=“46”&gt;Virginia&lt;/Value&gt;</entry></row><row><entry /><entry>  &lt;Value SeqNumber=“47”&gt;Washington&lt;/Value&gt;</entry></row><row><entry /><entry>  &lt;Value SeqNumber=“48”&gt;West Virginia&lt;/Value&gt;</entry></row><row><entry /><entry>  &lt;Value SeqNumber=“49”&gt;Wisconsin&lt;/Value&gt;</entry></row><row><entry /><entry>  &lt;Value SeqNumber=“50”&gt;Wyoming&lt;/Value&gt;</entry></row><row><entry /><entry> &lt;/Values&gt;</entry></row><row><entry /><entry>  &lt;/GUIElement&gt;</entry></row><row><entry /><entry> + &lt;GUIElement Alias=“Horizontal”&gt;</entry></row><row><entry /><entry>&lt;/GUIElement&gt;</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

<figref idrefs="DRAWINGS">FIG. 3</figref> shows a GUI of a subsequent GAP version <b>152</b>. Table 3 illustrates a subsequent GAP tree model representation of the subsequent GAP version <b>152</b>. The subsequent GAP tree model shown in Table 3 includes the GUI elements and the attributes of the GUI elements. For example, the window GUI object School <b>302</b> shown in <figref idrefs="DRAWINGS">FIG. 3</figref> corresponds to GUI Element Alias “School” shown at line <b>11</b> (L<b>11</b>) of Table 3 and nested GUI elements StateListBox and SchoolCombobox shown at lines <b>23</b> and <b>24</b> of Table 3 correspond, respectively, to State listbox <b>304</b> and School combobox <b>306</b> of <figref idrefs="DRAWINGS">FIG. 3</figref>.

In one implementation, the GUI difference model <b>162</b> results from a comparison between the current GAP tree model as shown in Table 1 and a subsequent GAP tree model as shown in Table 3. In another implementation, the economic cost engine <b>182</b> analyzes the current GAP tree model using GAP change specifiers <b>184</b> to determine GAP changes that may produce the subsequent GAP tree model, from which the economic cost engine <b>182</b> generates synthetic GAP change specifiers <b>185</b>. For example, prior to actually building the subsequent GAP version <b>152</b>, a programmer may identify various proposed changes to a current GAP version <b>150</b> using the GAP change specifiers <b>184</b>. The economic cost engine <b>182</b> analyzes the GAP change specifiers <b>184</b> and current GAP tree model to generate synthetic GAP change specifiers <b>185</b> that correspond to a proposed subsequent GAP tree model. In one implementation, the economic cost engine <b>182</b> includes GAP change specifier logic that generates synthetic GAP change specifiers <b>185</b> using the current GAP tree model and the received GAP change specifiers <b>184</b>. In one implementation, the economic cost engine architecture <b>110</b> generates the synthetic GAP change specifiers <b>185</b> as a result of recording various proposed changes identified by the programmer during an interactive session with the current GAP version <b>150</b>.

<tables id="TABLE-US-00003" num="00003"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 3</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Subsequent GAP tree model</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry>− &lt;State SeqNumber=“0” Name=“State_0_3068” Alias=“University</entry></row><row><entry>Directory1” ProcessId=“3068”&gt;</entry></row><row><entry> − &lt;GUIElement Alias=“School”&gt;</entry></row><row><entry>  &lt;UniqueID&gt;0x0&lt;/UniqueID&gt;</entry></row><row><entry>  &lt;HWND&gt;0x80b8&lt;/HWND&gt;</entry></row><row><entry> &lt;Location x=“116” y=“88” width=“915” height=“594” /&gt;</entry></row><row><entry>  &lt;Class&gt;WindowsForms10.Window.8.app.0.378734a&lt;/Class&gt;</entry></row><row><entry>  &lt;Style&gt;0x16cf0000&lt;/Style&gt;</entry></row><row><entry>  &lt;ExStyle&gt;0xc0050900&lt;/ExStyle&gt;</entry></row><row><entry> + &lt;GUIElement Alias=“System”&gt;</entry></row><row><entry> + &lt;GUIElement Alias=“NAMELESS”&gt;</entry></row><row><entry>L11 − &lt;GUIElement Alias=“School”&gt;</entry></row><row><entry>   &lt;UniqueID&gt;0x12&lt;/UniqueID&gt;</entry></row><row><entry>   &lt;HWND&gt;0x80b8&lt;/HWND&gt;</entry></row><row><entry>   &lt;Location x=“146” y=“92” width=“907” height=“560” /&gt;</entry></row><row><entry>   &lt;Class&gt;WindowsForms10.Window.8.app.0.378734a&lt;/Class&gt;</entry></row><row><entry>   &lt;Style&gt;0x16cf0000&lt;/Style&gt;</entry></row><row><entry>   &lt;ExStyle&gt;0xc0050900&lt;/ExStyle&gt;</entry></row><row><entry>L18 + &lt;GUIElement Alias=“menuStrip1”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“States List”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“School List”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“SelectStateIButton”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“SelectSchoolButton”&gt;</entry></row><row><entry>L23 + &lt;GUIElement Alias=“StateListbox”&gt;</entry></row><row><entry>L24 + &lt;GUIElement Alias=“SchoolCombobox”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“School”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“state”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“State”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“location”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“Location”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“control”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“Control”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“Number of Students (1000)”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“NumStudents”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“Male/Female Ratio”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“GenderRatio”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“Student/Faculty Ratio”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“SFRatio”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“SAT Verbal”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“SATVerbal”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“SAT Math”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“SATMath”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“Number of Applicants”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“NumApps”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“Percent of Admittance”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“PercAdmit”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“Percent Enrolled”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“Percent Enrolled”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“Academics (1-5)”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“Academics”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“Social (1-5)”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“Social”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“Quality of Life (1-5)”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“QoLife”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“Academic Emphasis”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“AcadEmphasis”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“Expenses”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“Expense”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“Financial Aid”&gt;</entry></row><row><entry>  + &lt;GUIElement Alias=“FinancialAid”&gt;</entry></row><row><entry> &lt;/GUIElement&gt;</entry></row><row><entry> &lt;/GUIElement&gt;</entry></row><row><entry>&lt;/State&gt;</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

The subsequent GAP menuStrip1 GUI element schema shown in Table 3 at line <b>18</b> corresponds to the WinObject GUI object ‘menu strip’ <b>308</b> shown in <figref idrefs="DRAWINGS">FIG. 3</figref>. The subsequent GAP menuStrip1 GUI element schema shown in Table 4 illustrates the full entry at line <b>18</b> in Table 3 and indicates that the menu strip <b>308</b> includes a nested GUI element Filemenu that includes nest GUI elements OpenFile, SaveFile, SaveAs, and Exit, shown at lines <b>15</b> of Table 4, and <b>22</b>-<b>25</b>, respectively.

<tables id="TABLE-US-00004" num="00004"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 4</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Subsequent GAP menuStrip1 GUI element schema</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry>− &lt;GUIElement Alias=“menuStrip1”&gt;</entry></row><row><entry>  &lt;UniqueID&gt;0x13&lt;/UniqueID&gt;</entry></row><row><entry> &lt;HWND&gt;0xa0e62&lt;/HWND&gt;</entry></row><row><entry> &lt;Location x=“146” y=“92” width=“907” height=“24” /&gt;</entry></row><row><entry> &lt;Class&gt;WindowsForms10.Window.8.app.0.378734a&lt;/Class&gt;</entry></row><row><entry> &lt;Style&gt;0x56000000&lt;/Style&gt;</entry></row><row><entry> &lt;ExStyle&gt;0xc0010800&lt;/ExStyle&gt;</entry></row><row><entry>  − &lt;GUIElement Alias=“menuStrip1”&gt;</entry></row><row><entry>  &lt;UniqueID&gt;0x1c&lt;/UniqueID&gt;</entry></row><row><entry>  &lt;HWND&gt;0xa0e62&lt;/HWND&gt;</entry></row><row><entry>  &lt;Location x=“146” y=“92” width=“907” height=“24” /&gt;</entry></row><row><entry>  &lt;Class&gt;WindowsForms10.Window.8.app.0.378734a&lt;/Class&gt;</entry></row><row><entry>  &lt;Style&gt;0x56000000&lt;/Style&gt;</entry></row><row><entry>  &lt;ExStyle&gt;0xc0010800&lt;/ExStyle&gt;</entry></row><row><entry>L15 − &lt;GUIElement Alias=“FileMenu”&gt;</entry></row><row><entry>    &lt;UniqueID&gt;0x1d&lt;/UniqueID&gt;</entry></row><row><entry>    &lt;HWND&gt;0xa0e62&lt;/HWND&gt;</entry></row><row><entry>    &lt;Location x=“148” y=“98” width=“35” height=“20” /&gt;</entry></row><row><entry>    &lt;Class&gt;WindowsForms10.Window.8.app.0.378734a&lt;/Class&gt;</entry></row><row><entry>    &lt;Style&gt;0x56000000&lt;/Style&gt;</entry></row><row><entry>    &lt;ExStyle&gt;0xc0010800&lt;/ExStyle&gt;</entry></row><row><entry>L22   + &lt;GUIElement Alias=“OpenFile”&gt;</entry></row><row><entry>L23   + &lt;GUIElement Alias=“SaveFile”&gt;</entry></row><row><entry>L24   + &lt;GUIElement Alias=“SaveAsFile”&gt;</entry></row><row><entry>L25   + &lt;GUIElement Alias=“Exit”&gt;</entry></row><row><entry>  &lt;/GUIElement&gt;</entry></row><row><entry>  &lt;/GUIElement&gt;</entry></row><row><entry> &lt;/GUIElement&gt;</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

<figref idrefs="DRAWINGS">FIG. 4</figref> illustrates a side by side view <b>400</b> of the current and subsequent GAP that helps illustrate GUI element similarities, as well as differences, between successive GAP versions. In the view <b>400</b>, there are several GUI objects that have the same desired functionality between successive GAP versions, although aspects of the GUI object may appear different between successive GAP versions.

For example, referring to <figref idrefs="DRAWINGS">FIG. 4</figref>, differences between the current GAP version <b>150</b> and subsequent GAP version <b>152</b> include the window StateList <b>202</b>, listbox State <b>212</b>, field Academic Emphasis <b>402</b>, and field Quality of Life Scale (1-5) <b>404</b> in the current GAP version <b>150</b> are respectively represented by window School <b>302</b>, listbox State <b>304</b>, field Academic Emphasis <b>406</b>, and field Quality of Life (1-5) <b>408</b> in the subsequent GAP version <b>152</b>. In another example, consider the Save File <b>204</b>, Close Form <b>206</b>, Save Change <b>208</b> and Open File <b>210</b> GUI objects implemented in the current GAP version <b>150</b> that have been implemented in the subsequent GAP version <b>152</b> as child GUI objects of the File <b>410</b>, which is a child GUI object of the menu strip <b>308</b> GUI object.

It can be challenging to locate differences between GUI elements of GAPs. For example, it is not readily evident that the listbox School <b>216</b> and the combobox School <b>306</b> are meant to have the same or similar functionality between successive GAP versions. As another example, the WinObject “Select School” <b>218</b> in the current GAP version <b>150</b> has been removed at location <b>412</b> from the subsequent GAP version <b>152</b>. The GUI difference model <b>162</b> includes GUI element difference entries that list characteristics of GUI elements, for those GUI elements that match between the current GAP version <b>150</b> and the subsequent GAP version <b>152</b>, but that differ in character between the current GAP version <b>150</b> and the subsequent GAP version <b>152</b>. The GUI element difference entries facilitate the economic cost engine <b>182</b> analysis to obtain GUI transformation costs and generate test script transformation cost reports, as described in more detail below.

<figref idrefs="DRAWINGS">FIG. 5</figref> shows an exemplary GUI element difference entry <b>504</b>. <figref idrefs="DRAWINGS">FIG. 5</figref> illustrates a GUI difference model <b>162</b> obtained by comparing a current GAP tree model as shown in Table 1 and a subsequent GAP tree model as shown in Table 3. In one implementation, the GUI difference model <b>162</b> is implemented as an XML schema that specifies each GUI element difference between successive GAP versions with a corresponding GUI element difference entry. In another implementation, the GUI difference model <b>162</b> nests GUI element difference entries to indicate parent and child GUI elements, and the level at which a GUI element difference entry is nested indicates how far the corresponding GUI element is away from a parent GUI element (root) in a navigation path.

In one implementation, the GUI difference model <b>162</b> omits a GUI element difference entry for GUI objects that have been deleted between successive GAP versions. Each GUI element difference entry representing a GUI object that has been modified or added between successive GAP versions includes a tag ‘Version’ that has a value of, as examples, either 0 or 1. In other words, a GUI element difference entry that does not include a Version tag indicates that the GUI object has not been modified between successive GAP versions. The Version values of 0 and 1 indicate whether the children elements of the Version represent the properties of the GUI object in the current GAP version <b>150</b> or the subsequent GAP version <b>152</b>, respectively. For example, the GUI difference entry <b>504</b> shown in <figref idrefs="DRAWINGS">FIG. 5</figref> indicates at line <b>10</b> that the listbox StateListbox value for SeqNumber=“8” implemented in the current GAP version <b>150</b> is “District of Columbia”, while the value in the subsequent GAP version <b>152</b> is “Florida” as indicated at line <b>21</b>. In one implementation, the GUI difference entry <b>504</b> includes a ParentChildIdentifier element, shown in lines <b>2</b> and <b>15</b> of <figref idrefs="DRAWINGS">FIG. 5</figref>, that identifies the relationship between two GUI objects in a given GAP GUI version, so that GUI class and inheritance constraints can be validated (discussed in detail further below).

Referring briefly to <figref idrefs="DRAWINGS">FIG. 14</figref>, the GUI difference entry <b>1404</b> indicates at line <b>1</b> that the window StateList in the current GAP version <b>150</b> corresponds to the window School in the subsequent GAP version <b>152</b> indicated at line <b>22</b> by the Version value equal to 0 and 1, respectively. The StateList and School GUI objects are of the WindowsForm10.Window.8 class, as shown at lines <b>8</b> and <b>28</b>. The sub-class identifier for the StateList and School GUI object distinguish the GUI objects (e.g., app4 and app.0.0378734a, respectively). The GUI difference entry <b>1404</b> indicates that the Location element of the StateList and School windows are different, as shown at lines <b>7</b> and <b>27</b>, respectively. However, the GUI difference entry <b>1404</b> also indicates that the Style and ExStyle elements are identical, as shown at lines <b>9</b>-<b>10</b> and <b>29</b>-<b>30</b>, respectively.

Referring briefly to <figref idrefs="DRAWINGS">FIG. 15</figref>, the GUI difference entry <b>1504</b> indicates at line <b>3</b> that the listbox SchoolListbox in the current GAP version <b>150</b> corresponds to the combobox SchoolCombobox in the subsequent GAP version <b>152</b> indicated at line <b>13</b>. The GUI difference entry <b>1504</b> indicates that the Location element of the SchoolListbox and SchoolCombobox are different, as shown at lines <b>7</b> and <b>18</b>, respectively. The GUI difference entry <b>1504</b> also indicates that the Class, Style and ExStyle elements are different, as shown at lines <b>8</b>-<b>10</b> and <b>19</b>-<b>21</b>, respectively. In particular, one or more of the properties of a WindowsForms10.LISTBOX and a WindowsForms10.COMBOBOX are different, incompatible with the properties of the other class, and child GUI elements of GUI objects of these two classes may have one or more incompatible properties.

<figref idrefs="DRAWINGS">FIG. 6</figref> shows a current test script <b>164</b> for the current GAP GUI. The current test script <b>164</b> includes navigation statements (e.g., L<b>1</b> and L<b>6</b>) that navigate to GUI objects, perform read, write, or other actions (functions) on GUI objects, and the arguments of these functions. For example, line <b>1</b> of the current test script <b>164</b> navigates to a window StateList, locates ‘Open File’ identified as a child GUI object of the window StateList, and performs an action ‘Click’ on the ‘Open File’ GUI object at XY coordinates <b>86</b>, <b>12</b>. Through the series of navigation and action statements, the current test script <b>164</b> opens a file ‘university.data’ as indicated by lines <b>2</b>-<b>3</b>. A ‘State’ is selected from the StateListbox and a SchoolListbox is activated, based on lines <b>4</b>-<b>6</b>. The current test script <b>164</b> successively selects from the SchoolListbox the schools ‘Acme University’ and ‘State University’ located in the ‘State’ by using a ‘For Next Loop’, as a result of the navigation and action statements at lines <b>7</b>-<b>17</b> based on the coordinates <b>67</b>, School_Constant in WinObject “Select School” at line <b>8</b>. The current test script <b>164</b> uses conditional branching at lines <b>11</b>-<b>15</b> to change the academic scale to ‘3’ for ‘Acme University’ and to ‘2’ for ‘State University’, and saves the individual changes as a result of line <b>16</b>. The current test script <b>164</b> saves all the changes to a new file ‘university_revise.data’ as a result of the statements at lines <b>18</b>-<b>20</b>.

<figref idrefs="DRAWINGS">FIG. 7</figref> illustrates a current test script representation <b>700</b> that the script parser <b>166</b> produces as an intermediate representation of the current test script <b>164</b>. In one implementation, the economic cost engine architecture <b>110</b> implements the current test script representation as an abstract syntax tree (AST) <b>168</b>. The current test script representation <b>700</b> represents a vector (e.g., the current test script <b>164</b>) whose elements are vectors that represent navigation statements of the current test script <b>164</b>. In other words, the current test script representation <b>700</b> represents the navigation statements as test script statement vectors that navigate to GUI objects and perform actions on those GUI objects. Table 5 illustrates a grammar the script parser <b>166</b> may use to produce the current test script representation <b>700</b>. The terminals func, action and var represent the names of platform-specific functions that navigate to GUI objects (e.g., Window, VbEdit, and WinObject), perform read, write, or other actions (functions) on GUI objects, and the arguments of these functions, respectively.

<tables id="TABLE-US-00005" num="00005"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 5</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Script Parser Grammar</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="14pt" align="left" /><colspec colname="2" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>navstmt ::= func(arg) | navstmt . Navstmt | navstmt action arg</entry></row><row><entry /><entry>fullnavstmt ::= var = navstmt | navstmt action arg</entry></row><row><entry /><entry>arg ::= expr | “,” arg |</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

The script parser <b>166</b> represents the test script statement vectors as an ordered sequence of nodes that contain function names and the arguments of those functions that navigate to GUI objects. The nodes of a test script statement vector include a source node and a destination. For example, the script parser <b>166</b> may represent the test script statement vector corresponding to line <b>1</b> of the current test script <b>164</b> as source node StateList <b>702</b> and a destination node ‘Open File’ <b>704</b>. The nodes of a test script statement vector may also include intermediate nodes positioned between a source node and a destination node. For example, the script parser <b>166</b> may represent the test script statement vector corresponding to line <b>19</b> of the current test script <b>164</b> as source node StateList <b>702</b>, intermediate node ‘Save a Data Record’ <b>706</b> and destination node ‘File name’ <b>708</b>. The test script statement vector corresponding to line <b>19</b> of the current test script <b>164</b> may be further expressed as (<b>702</b>-<b>706</b>-<b>708</b>-<b>720</b>-<b>722</b>), including the method ‘Set’ <b>720</b> and value ‘university revise.data’ <b>722</b>.

The test script statement vectors may include looping and conditional branching nodes (e.g., loop <b>724</b> and branch <b>726</b>, respectively). In one implementation, the loop <b>724</b> node is followed by a loop variable (e.g., school_constant <b>730</b>) for which a range of values, from a lower to an upper bound (e.g., J <b>732</b> and K <b>734</b>), are evaluated and used in expressions within the scope of the loop <b>724</b> (e.g., <b>67</b>, school_constant coordinates <b>736</b>). The branch <b>726</b> may be followed by one or more conditions (e.g., condition-1 <b>738</b> and condition-2 <b>740</b>). The economic cost engine <b>182</b> may use the loop <b>724</b> and branch <b>726</b> nodes, and range values and conditions (e.g., J <b>732</b>, K <b>734</b>, condition-1 <b>738</b> and condition-2 <b>740</b>) to recursively evaluate the current test script representation <b>700</b>.

In one implementation, the GAP change specifiers <b>184</b> includes a model specifier (discussed in further detail below) that identifies the GUI element change cost rule to use to obtain a GUI transformation cost corresponding to a loop <b>724</b>. The GUI element change cost rule for a loop <b>724</b> may result in the economic cost model logic <b>196</b> obtaining a GUI transformation cost that represents a multiplier equal to the number of values in the range from a lower to an upper bound (e.g., J <b>732</b> and K <b>734</b>) that is applied to the GUI transformation costs for the test script statements within the scope of the loop <b>724</b> (e.g., lines <b>8</b>-<b>16</b> in <figref idrefs="DRAWINGS">FIG. 6</figref>). For example, the GUI transformation cost corresponding to loop <b>724</b>, based on the lower to the upper bound (e.g., J <b>732</b> and K <b>734</b>), may equal 10 and the GUI transformation costs corresponding to the test script statements within the scope of the loop <b>724</b> (e.g., lines <b>8</b>-<b>16</b> in <figref idrefs="DRAWINGS">FIG. 6</figref>) may equal <b>500</b>, resulting in a total GUI transformation cost of 5,000 for the test script statements including loop <b>724</b> (e.g., lines <b>7</b>-<b>17</b>). In another example, the GUI transformation cost obtained by applying the GUI element change cost rule for a loop <b>724</b> may represent a single weighted valued (e.g., 50) that the economic cost model logic <b>196</b> adds to the GUI transformation costs corresponding to the test script statements within the scope of loop <b>724</b> so that the total GUI transformation cost of <b>550</b> results for the test script statements including loop <b>724</b> (e.g., lines <b>7</b>-<b>17</b>).

The GUI element change cost rule for a branch <b>726</b> may result in obtaining a GUI transformation cost that is based on the number of conditions (e.g., condition-1 <b>738</b> and condition-2 <b>740</b>) within the scope of the branch <b>726</b>, and the GUI transformation costs for the branch <b>726</b> and the test script statements within the scope of the branch <b>726</b> are added to obtain the total GUI transformation costs. In another implementation, the GUI transformation cost corresponding to the branch <b>726</b> is a multiplier that is applied to the GUI transformation costs corresponding to the test script statements within the scope of the branch <b>726</b>. For example, two conditions (e.g., condition-1 <b>738</b> and condition-2 <b>740</b>) exist within the scope of the branch <b>726</b>, corresponding to a GUI transformation costs of <b>2</b> for the branch <b>726</b> and the GUI transformation costs of the lines within the scope of the branch <b>726</b> are <b>100</b> resulting in a total GUI transformation cost of <b>200</b> for the test script statements including branch <b>726</b> (e.g., lines <b>11</b>-<b>15</b>).

The script parser <b>166</b> evaluates arguments of navigation and action functions as expressions, variables and constants. The arguments express the physical properties of GUI objects to which the test script statement vectors navigate and values used to perform actions on those GUI objects. For example, the ‘86,12’ coordinates <b>712</b> identify the location for a pointing device to perform an action ‘Click’ <b>710</b> on the ‘Open File’ <b>704</b> GUI object, which is a child GUI Object of the window StateList <b>702</b>. The economic cost engine <b>182</b> uses the names of the GUI objects (e.g., StateList <b>702</b> and ‘Open File’ <b>704</b>) navigated to by the test script statement vectors to locate the corresponding physical properties of the GUI objects stored in an object repository <b>174</b>, identify corresponding GUI difference entries and generate synthetic GAP change specifiers <b>185</b>.

In one implementation, the economic cost engine <b>182</b> uses the OR lookup logic <b>172</b> to locate, in the object repository <b>174</b>, the physical properties of the GUI objects navigated to by a test script statement vector, and locate, in the GUI difference model <b>162</b>, corresponding GUI difference entries. The economic cost engine <b>182</b> generates synthetic GAP change specifiers <b>185</b> and invokes the economic cost model logic <b>196</b> to locate corresponding GUI element change cost rules in the economic models <b>176</b> repository using GAP change specifiers <b>184</b> and synthetic GAP change specifiers <b>185</b>. In one implementation, the OR lookup logic <b>172</b> is divided into two sub-functions: 1) lookup logic adapted to locate and retrieve the physical properties of the GUI objects navigated to by the test script statement vector (e.g., <b>702</b>-<b>704</b>, <b>702</b>-<b>706</b>-<b>708</b>, and <b>702</b>-<b>714</b>); and 2) locator logic that finds and returns a GUI element difference entry (node) in the GUI difference model <b>162</b> that corresponds to the GUI object with the given physical properties. The economic cost model logic <b>196</b> generates synthetic GAP change specifiers <b>185</b> that are used to locate applicable GUI element change cost rules, based on the lookup logic and locator logic results from the OR lookup logic <b>172</b>. The OR lookup logic <b>172</b> may include path traversal logic, discussed in further detail below, to identify possible navigation paths of a test script statement vector between a source node GUI object and destination node GUI object to which a test script statement vector navigates.

Table 6 illustrates one implementation of an object repository <b>174</b>, in the form of an XML schema. The object repository <b>174</b> includes a GUI object entry for each GUI object of the current GAP version <b>150</b> identified in the current test script <b>164</b>. The object repository <b>174</b> may be generated by a script writing tool, such as Quick Test Pro (QTP), Rational Robot, and Compuware Test Partner. The economic cost engine <b>182</b> may query the object repository <b>174</b> to identify the physical properties of the GUI objects navigated to by the test script statement vectors represented by the current test script representation <b>700</b>. Physical properties of a GUI object may indicate whether the GUI object is hidden, read-only, a number and default values, as shown in Table 7.

For example, the economic cost engine <b>182</b> analyzes the GUI objects <b>702</b>-<b>714</b> in the test script statement vector. The ‘19,22’ coordinate <b>718</b> identifies the location for a pointing device to perform an action ‘Click’ <b>716</b> on the GUI object SchooListbox <b>714</b>, which is a child GUI Object of the window StateList <b>702</b>. The economic cost engine <b>182</b> invokes the OR lookup logic <b>172</b> to locate the physical properties of the GUI objects <b>702</b> and <b>714</b>. The OR lookup logic <b>172</b> locates the physical properties of the window StateList <b>702</b> and the WinObject SchoolListbox <b>714</b>, as shown in Table 6 at lines <b>3</b> and <b>12</b>. The economic cost engine <b>182</b> uses the physical properties retrieved from the object repository <b>174</b> to locate corresponding GUI difference entries (e.g., <b>1404</b> and <b>1504</b>) in the GUI difference model <b>162</b>. The GUI difference entries <b>1404</b> and <b>1504</b> indicate that the window StateList <b>702</b> and the WinObject SchoolListbox <b>714</b> in the current GAP version <b>150</b> correspond to the window School <b>302</b> and the WinObject SchoolCombobox <b>306</b> in the subsequent GAP version <b>152</b>, respectively. In one implementation, the economic cost engine <b>182</b> employs the OR lookup logic <b>172</b> to traverse the GUI difference model <b>162</b> using the physical properties of the GUI objects navigated to by the test script statement vector. The OR lookup logic <b>172</b> function returns a GUI element difference entry (e.g., <b>504</b>, <b>1404</b> and <b>1504</b>) from the GUI difference model <b>162</b> that represents the GUI object navigated to by the test script statement vector (e.g., <b>702</b>-<b>704</b>-<b>710</b>-<b>712</b>, <b>702</b>-<b>706</b>-<b>708</b>-<b>720</b>-<b>722</b>, and <b>702</b>-<b>714</b>-<b>726</b>-<b>718</b>), and the economic cost model logic <b>196</b> generates corresponding synthetic GAP change specifiers <b>185</b>.

<tables id="TABLE-US-00006" num="00006"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 6</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Object Repository</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry>− &lt;XYZRep:ObjectRepository</entry></row><row><entry> xmlns:XYZRep=“http://www.vendorXYZ.com/XYZ/ObjectRepository”&gt;</entry></row><row><entry>− &lt;XYZRep:Objects&gt;</entry></row><row><entry>L3 − &lt;XYZRep:Object Class=“Window” Name=“StateList”&gt;</entry></row><row><entry>+ &lt;XYZRep:Properties&gt;</entry></row><row><entry>+ &lt;XYZRep:BasicIdentification&gt;</entry></row><row><entry>+ &lt;XYZRep:CustomReplay&gt;</entry></row><row><entry>L7 − &lt;XYZRep:ChildObjects&gt;</entry></row><row><entry>  + &lt;XYZRep:Object Class=“WinObject” Name=“Open File”&gt;</entry></row><row><entry>  + &lt;XYZRep:Object Class=“WinObject” Name=“StateListbox”&gt;</entry></row><row><entry>  + &lt;XYZRep:Object Class=“WinObject” Name=“Select State”&gt;</entry></row><row><entry>  + &lt;XYZRep:Object Class=“WinObject” Name=“Select School”&gt;</entry></row><row><entry>  + &lt;XYZRep:Object Class=“WinObject” Name=“SchoolListbox”&gt;</entry></row><row><entry>  &lt;/XYZRep:ChildObjects&gt;</entry></row><row><entry> &lt;/XYZRep:Object&gt;</entry></row><row><entry> &lt;/XYZRep:Objects&gt;</entry></row><row><entry> &lt;XYZRep:Parameters /&gt;</entry></row><row><entry> &lt;XYZRep:Metadata /&gt;</entry></row><row><entry> &lt;/XYZRep:ObjectRepository&gt;</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

Table 7 illustrates the physical properties that may be located in the object repository for the GUI object entry corresponding to the SchoolListbox <b>714</b>.

<tables id="TABLE-US-00007" num="00007"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="301pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 7</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>GUI object entry WinObject (“SchoolListbox”)</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="301pt" align="left" /><tbody valign="top"><row><entry>− &lt;XYZRep:Object Class=“WinObject” Name=“SchoolListbox”&gt;</entry></row><row><entry>L2 − &lt;XYZRep:Properties&gt;</entry></row><row><entry> − &lt;XYZRep:Property Name=“y” Hidden=“0” ReadOnly=“0” Type=“NUMBER”&gt;</entry></row><row><entry>  &lt;XYZRep:Value RegularExpression=“0”&gt;86&lt;/XYZRep:Value&gt;</entry></row><row><entry>  &lt;/XYZRep:Property&gt;</entry></row><row><entry> − &lt;XYZRep:Property Name=“x” Hidden=“0” ReadOnly=“0” Type=“NUMBER”&gt;</entry></row><row><entry>  &lt;XYZRep:Value RegularExpression=“0”&gt;420&lt;/XYZRep:Value&gt;</entry></row><row><entry>  &lt;/XYZRep:Property&gt;</entry></row><row><entry> − &lt;XYZRep:Property Name=“windowstyle” Hidden=“0” ReadOnly=“0” Type=“NUMBER”&gt;</entry></row><row><entry>  &lt;XYZRep:Value RegularExpression=“0”&gt;1442906305&lt;/XYZRep:Value&gt;</entry></row><row><entry>  &lt;/XYZRep:Property&gt;</entry></row><row><entry> − &lt;XYZRep:Property Name=“windowextendedstyle” Hidden=“0” ReadOnly=“0” Type=“NUMBER”&gt;</entry></row><row><entry>  &lt;XYZRep:Value RegularExpression=“0”&gt;512&lt;/XYZRep:Value&gt;</entry></row><row><entry>  &lt;/XYZRep:Property&gt;</entry></row><row><entry> − &lt;XYZRep:Property Name=“window id” Hidden=“0” ReadOnly=“0” Type=“NUMBER”&gt;</entry></row><row><entry>  &lt;XYZRep:Value RegularExpression=“0”&gt;1182924&lt;/XYZRep:Value&gt;</entry></row><row><entry>  &lt;/XYZRep:Property&gt;</entry></row><row><entry> − &lt;XYZRep:Property Name=“width” Hidden=“0” ReadOnly=“0” Type=“NUMBER”&gt;</entry></row><row><entry>  &lt;XYZRep:Value RegularExpression=“0”&gt;336&lt;/XYZRep:Value&gt;</entry></row><row><entry>  &lt;/XYZRep:Property&gt;</entry></row><row><entry> − &lt;XYZRep:Property Name=“visible” Hidden=“0” ReadOnly=“0” Type=“BOOL”&gt;</entry></row><row><entry>  &lt;XYZRep:Value RegularExpression=“0”&gt;−1&lt;/XYZRep:Value&gt;</entry></row><row><entry>  &lt;/XYZRep:Property&gt;</entry></row><row><entry> − &lt;XYZRep:Property Name=“regexpwndclass” Hidden=“0” ReadOnly=“0” Type=“STRING”&gt;</entry></row><row><entry>  &lt;XYZRep:Value RegularExpression=“0”&gt;WindowsForms10.LISTBOX.app4&lt;/XYZRep:Value&gt;</entry></row><row><entry> &lt;/XYZRep:Property&gt;</entry></row><row><entry> − &lt;XYZRep:Property Name=“object class” Hidden=“0” ReadOnly=“0” Type=“STRING”&gt;</entry></row><row><entry>  &lt;XYZRep:Value RegularExpression=“0”&gt;WindowsForms10.LISTBOX.app4&lt;/XYZRep:Value&gt;</entry></row><row><entry>  &lt;/XYZRep:Property&gt;</entry></row><row><entry> − &lt;XYZRep:Property Name=“nativeclass” Hidden=“0” ReadOnly=“0” Type=“STRING”&gt;</entry></row><row><entry>  &lt;XYZRep:Value RegularExpression=“0”&gt;WindowsForms10.LISTBOX.app4&lt;/XYZRep:Value&gt;</entry></row><row><entry>  &lt;/XYZRep:Property&gt;</entry></row><row><entry> − &lt;XYZRep:Property Name=“height” Hidden=“0” ReadOnly=“0” Type=“NUMBER”&gt;</entry></row><row><entry>  &lt;XYZRep:Value RegularExpression=“0”&gt;260&lt;/XYZRep:Value&gt;</entry></row><row><entry>  &lt;/XYZRep:Property&gt;</entry></row><row><entry> − &lt;XYZRep:Property Name=“enabled” Hidden=“0” ReadOnly=“0” Type=“BOOL”&gt;</entry></row><row><entry>  &lt;XYZRep:Value RegularExpression=“0”&gt;−1&lt;/XYZRep:Value&gt;</entry></row><row><entry>  &lt;/XYZRep:Property&gt;</entry></row><row><entry>L39  &lt;/XYZRep:Properties&gt;</entry></row><row><entry> − &lt;XYZRep:BasicIdentification&gt;</entry></row><row><entry>  &lt;XYZRep:PropertyRef&gt;y&lt;/XYZRep:PropertyRef&gt;</entry></row><row><entry>  &lt;XYZRep:PropertyRef&gt;x&lt;/XYZRep:PropertyRef&gt;</entry></row><row><entry> &lt;XYZRep:PropertyRef&gt;windowstyle&lt;/XYZRep:PropertyRef&gt;</entry></row><row><entry>  &lt;XYZRep:PropertyRef&gt;windowextendedstyle&lt;/XYZRep:PropertyRef&gt;</entry></row><row><entry> &lt;XYZRep:PropertyRef&gt;width&lt;/XYZRep:PropertyRef&gt;</entry></row><row><entry> &lt;XYZRep:PropertyRef&gt;visible&lt;/XYZRep:PropertyRef&gt;</entry></row><row><entry> &lt;XYZRep:PropertyRef&gt;regexpwndclass&lt;/XYZRep:PropertyRef&gt;</entry></row><row><entry> &lt;XYZRep:PropertyRef&gt;object class&lt;/XYZRep:PropertyRef&gt;</entry></row><row><entry>  &lt;XYZRep:PropertyRef&gt;nativeclass&lt;/XYZRep:PropertyRef&gt;</entry></row><row><entry> &lt;XYZRep:PropertyRef&gt;height&lt;/XYZRep:PropertyRef&gt;</entry></row><row><entry>  &lt;XYZRep:PropertyRef&gt;enabled&lt;/XYZRep:PropertyRef&gt;</entry></row><row><entry>  &lt;/XYZRep:BasicIdentification&gt;</entry></row><row><entry> − &lt;XYZRep:CustomReplay&gt;</entry></row><row><entry>  &lt;XYZRep:Behavior Name=“simclass”</entry></row><row><entry>       Type=“STRING”&gt;WindowsForms10.LISTBOX.app4&lt;/XYZRep:Behavior&gt;</entry></row><row><entry>  &lt;/XYZRep:CustomReplay&gt;</entry></row><row><entry> − &lt;XYZRep:Comments&gt;</entry></row><row><entry>  &lt;XYZRep:Comment Name=“miccommentproperty” /&gt;</entry></row><row><entry>  &lt;/XYZRep:Comments&gt;</entry></row><row><entry> &lt;XYZRep:ChildObjects /&gt;</entry></row><row><entry>&lt;/XYZRep:Object&gt;</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

<figref idrefs="DRAWINGS">FIG. 8</figref> shows an example economic cost engine system <b>800</b> that may implement the economic cost engine <b>182</b>. The economic cost engine <b>182</b> includes a memory <b>802</b> coupled to a processor <b>804</b>, and an interface <b>190</b>. In one implementation, the interface <b>190</b> communicates with the GUI element metadata repository <b>138</b> and the GUI difference model <b>162</b> to receive GUI element metadata <b>140</b> and GUI difference entries <b>810</b>, respectively. The interface <b>190</b> is connected to a network <b>806</b> (e.g., the Internet) in communication with various other systems and resources. In another implementation, the memory <b>802</b> includes the GUI element metadata <b>140</b>, and GAP change specifier logic <b>890</b> that produces the GUI difference model <b>162</b> and the GUI element difference entries <b>810</b>. The memory <b>802</b> also includes script parser logic <b>812</b> that receives the current test script <b>164</b> and produces the AST <b>168</b>, processes the AST <b>168</b> as a current test script representation <b>814</b>, and produces the test script statement vectors <b>816</b> (e.g., <b>702</b>-<b>704</b>-<b>710</b>-<b>712</b>, <b>702</b>-<b>706</b>-<b>708</b>-<b>720</b>-<b>722</b>, and <b>702</b>-<b>714</b>-<b>726</b>-<b>718</b>).

The memory <b>802</b> further includes economic cost model logic <b>196</b> that, in one implementation, invokes the OR lookup logic <b>172</b> to locate, in the object repository <b>174</b>, a GUI object entry <b>822</b> referred to by the test script statement vector <b>816</b>. In another implementation, the economic cost engine <b>182</b> invokes the OR lookup logic <b>172</b> to locate, in various external sources, a GUI object entry <b>822</b> matching the test script statement vector <b>816</b>. When the test script statement vector <b>816</b> (e.g., <b>702</b>-<b>704</b>-<b>710</b>-<b>712</b>, <b>702</b>-<b>706</b>-<b>708</b>-<b>720</b>-<b>722</b>, and <b>702</b>-<b>714</b>-<b>726</b>-<b>718</b>) employs constants to identify GUI object names, rather than expressions whose values can only be determined at runtime, the OR lookup logic <b>172</b> function may use the GUI object name and properties of the GUI object to efficiently locate the correct GUI object entry <b>822</b> and locate, in the GUI difference model <b>162</b>, a GUI element difference entry <b>810</b> matching the GUI object entry <b>822</b>.

For example, the test script statement vector represented by <b>702</b>-<b>704</b>-<b>710</b>-<b>712</b> identifies the window GUI object StateList <b>202</b> and the listbox GUI object SchoolListbox <b>216</b>, shown in the current test script <b>164</b> navigation statement shown at line <b>6</b> of <figref idrefs="DRAWINGS">FIG. 6</figref>:

Window(“StateList”).WinObject(“SchoolListbox”).Click <b>19</b>,<b>22</b>.

The OR lookup logic <b>172</b> locates each GUI object entry <b>822</b> for GUI objects <b>202</b> and <b>216</b>, using the known names of the GUI objects, StateList and SchoolListbox, respectively. The OR lookup logic <b>172</b> locates the corresponding GUI element difference entries <b>1404</b> and <b>1504</b>, in the GUI difference model <b>162</b>. In one implementation, the economic cost model logic <b>196</b> analyzes the GUI element difference entries <b>1404</b> and <b>1504</b> and generates one or more corresponding synthetic GAP change specifiers <b>185</b>. Using the GAP change specifiers <b>184</b>, the economic cost model logic <b>196</b> locates, in the economic models <b>176</b> repository, one or more corresponding GUI element change cost rules <b>846</b> and applies the cost rules to obtain GUI transformation costs <b>848</b>. The GUI transformation costs <b>848</b> may include costs corresponding to changing the current test script <b>164</b> and testing the subsequent GAP version <b>152</b>. In other words, the economic cost model logic <b>196</b> determines the costs to generate a transformed test script statement that corresponds to GUI objects School <b>302</b> and SchoolCombobox <b>306</b> and the costs to test the subsequent GAP version <b>152</b> using the transformed test script statement:

Window(“School”).WinObject(“SchoolCombobox”).Click <b>294</b>,<b>14</b>.

Each GUI element change cost rule <b>846</b> may include various attributes, including: a change specifier identifier <b>850</b>, system resource utilization identifiers <b>852</b>, a GUI change cost estimate <b>854</b> that indicates the estimated time and/or resources needed to test a corresponding GUI element change, dependent change specifier identifiers <b>856</b>, dependency ranking <b>858</b>, quality ranking <b>860</b>, complexity ranking <b>862</b>, and dependent GUI element change costs <b>864</b>. Each economic model, residing in the economic models <b>176</b> repository and/or external to the economic models <b>176</b> repository that is available to the economic cost model logic <b>196</b> through the interface <b>190</b>, may include more, fewer, or different GUI element change cost rule <b>846</b> attributes.

The economic cost model logic <b>196</b> uses GAP change specifiers <b>184</b> and synthetic GAP change specifiers <b>185</b> to locate applicable GUI element change cost rules <b>846</b>, in the economic models <b>176</b> repository, corresponding to change specifier identifiers <b>850</b>. The system resource utilization identifiers <b>852</b> indicate the resources used to test a particular GUI element change. In one implementation, the system resource utilization identifiers <b>852</b> have values from 1 to 10 that identify the amount of a test environment's processing and infrastructure capacity needed to test a corresponding GAP change. For example, a system resource utilization identifier <b>852</b> with a value of 3, corresponding to the test environment's processing capacity, may indicate that one-third of the available processing capacity is needed to test a corresponding GAP change. A system resource utilization identifier <b>852</b> with a value of 10, corresponding to the test environment's processing capacity, may indicate that most of the available computing resources (e.g., processing capacity) will be needed to test a corresponding GAP change.

In another implementation, the system resource utilization identifiers <b>852</b> provide descriptions of the resources needed to test a corresponding GAP change. For example, the system resource utilization identifiers <b>852</b> may itemize the skills of testers, system components (e.g., input and output devices, and network bandwidth) and the priority settings to be assigned to system processes used to test a corresponding GUI element change. In one implementation, the system resource utilization identifiers <b>852</b> provide a combination of discrete values that indicate the test environment's processing capacity and the itemized descriptions of the various resources needed to test the corresponding GUI element change.

The economic cost model logic <b>196</b> may locate other applicable GUI element change cost rules <b>846</b> that depend from a particular GUI element change cost rule <b>846</b> identified by a change specifier identifier <b>850</b>, using dependent change specifier identifiers <b>856</b>. The dependent change specifier identifiers <b>865</b> may identify one or more corresponding GUI element change cost rules <b>846</b> that depend from the GUI element change corresponding to the change specifier identifier <b>850</b>. For example, a change in the class of a parent GUI object from a listbox to a combobox (e.g., SchoolListbox <b>216</b> and SchoolCombobox <b>306</b>) may impose GUI element changes to children GUI objects of the parent GUI object, so that a change specifier identifier <b>850</b> corresponding to a particular GAP change specifier <b>184</b> and/or synthetic GAP change specifier <b>185</b> identifies one or more dependent change specifiers identifiers <b>856</b>.

In one implementation, the dependency ranking <b>858</b> is a value from 0 to 10 that indicates the level of dependency a GAP may have on a particular GUI element. The dependency ranking <b>858</b> may correspond to the visibility and scope of a GUI element. For example, the change of the window StateList <b>202</b> in the current GAP <b>150</b> to School <b>302</b> in the subsequent GAP <b>152</b>, as shown in <figref idrefs="DRAWINGS">FIG. 14</figref>, may correspond to a dependency ranking <b>858</b> of 10, while the change of a value in the StateListbox <b>212</b> to a value in the StateListbox <b>304</b>, as shown in <figref idrefs="DRAWINGS">FIG. 5</figref>, may correspond to a dependency ranking <b>858</b> of 4. The economic cost model logic <b>196</b> uses the dependency ranking <b>858</b> to facilitate obtaining the GUI transformation costs <b>848</b>. In one implementation, the economic cost model logic <b>196</b> uses the dependency ranking <b>858</b> to determine how and/or whether to use the GUI change efficiency factor <b>886</b>, discussed in further detail below.

In one implementation, the quality ranking <b>860</b> is a value from 1 to 10 that indicates the contribution to the quality of the subsequent GAP version <b>152</b> made by the GUI element change. For example, a particular GUI element change that enforces integrity checking on a GUI element corresponding to a high dependency ranking <b>858</b> value may correspond to a quality ranking <b>860</b> of 10. In another example, a GUI element change that is unperceivable and/or corresponds to a low dependency ranking <b>858</b> value may correspond to a quality ranking <b>860</b> of 0. In one implementation, the economic cost model logic <b>196</b> uses a user selectable quality preference identifier to generate the test script transformation cost report <b>186</b> with GUI transformation costs <b>848</b> corresponding to quality rankings <b>860</b> meeting or exceeding the quality preference identifier, so that test plans may be evaluated based on quality factors.

In one implementation, the complexity ranking <b>862</b> is a value from 1 to 10 that indicates the difficulty level of testing the corresponding GUI element change, where a complexity level of 10 is a high level of complexity and a level of 0 is a low level of complexity. In another implementation, the complexity ranking <b>862</b> indicates the contribution to the level of complexity of the subsequent GAP version <b>152</b> made by the GUI element change. For example, a particular GUI element change that enforces integrity checking on a GUI element corresponding to a high dependency ranking <b>858</b> value may correspond to a complexity ranking <b>862</b> of 10. In another example, a GUI element change that is unperceivable and/or corresponds to a low dependency ranking <b>858</b> value may correspond to a complexity ranking <b>862</b> of 0. In one implementation, the economic cost model logic <b>196</b> uses a user selectable complexity preference identifier to generate the test script transformation cost report <b>186</b> with GUI transformation costs <b>848</b> to complexity rankings <b>862</b> meeting or exceeding the complexity preference identifier, so that test plans may be evaluated based on complexity.

The dependent GUI element change costs <b>864</b> may represent an aggregated GUI transformation cost <b>848</b> corresponding to the dependent change specifier identifiers <b>856</b>. In one implementation, the economic cost model logic <b>196</b> uses the dependent GUI element change costs <b>864</b>, rather than retrieving each GUI element change cost rule <b>846</b> corresponding to the one or more dependent change specifier identifiers <b>856</b>, to generate the test script transformation cost report <b>186</b>.

In one implementation, the economic cost model logic <b>196</b> uses user selectable preference identifiers <b>866</b> to locate GUI element change cost rules <b>846</b> based on discrete values and/or ranges of values for one or more of the system resource utilization identifiers <b>852</b>, GUI change cost estimate <b>854</b>, dependency ranking <b>858</b>, quality ranking <b>860</b>, complexity ranking <b>862</b> and dependent GUI element change costs <b>864</b>. The preference identifiers <b>866</b> identify the GUI transformation costs <b>848</b> used to generate the test script transformation cost report <b>186</b>, based on one or more of the change specifier identifier <b>850</b>, a system resource utilization identifier <b>852</b>, a GUI change cost estimate <b>854</b> that indicates the estimated time and/or resources (e.g., money and labor) to test a corresponding GUI element change, dependent change specifier identifiers <b>856</b>, dependency ranking <b>858</b>, quality ranking <b>860</b>, complexity ranking <b>862</b>, and dependent GUI element change costs <b>864</b>.

The GUI transformation cost <b>848</b> may include a time component and resource component. The time component of the GUI transformation cost <b>848</b> may indicate the elapsed time needed to change a test script statement and/or test a corresponding GUI element change. The resource component of the GUI transformation cost <b>848</b> may indicate the money, areas of skill and/or system infrastructure (e.g., human and technological units) needed to change a test script statement and/or test a corresponding GUI element change.

Recall that the economic cost engine <b>182</b> may generate test script transformation cost reports <b>186</b> based on multiple combinations of available information, including: 1) GAP change specifiers <b>184</b>; 2) GAP change specifiers <b>184</b> and a current test script <b>164</b>; 3) GAP change specifiers <b>184</b>, a current test script <b>164</b> and a current GAP version <b>150</b> (e.g., a current GAP tree model); 4) a current test script <b>164</b>, and a GUI difference model <b>162</b> with GUI element difference entries; and 5) GAP change specifiers <b>184</b>, a current test script <b>164</b>, and a GUI difference model <b>162</b>. The various combinations of available information are used by the economic cost engine <b>182</b> to analyze received GAP change specifiers <b>184</b> and/or generated synthetic GAP change specifiers <b>185</b> that are used by the economic cost model logic <b>196</b> to locate and retrieve GUI transformation costs <b>848</b> and generate test script transformation cost reports <b>186</b>.

In one implementation, the economic cost engine <b>182</b> receives GAP change specifiers <b>184</b> that the economic cost engine <b>182</b> uses to locate and retrieve GUI element change cost rules <b>848</b> from the economic models <b>176</b> repository. The received GAP change specifiers <b>184</b> may have resulted from prior analysis of a current GAP version <b>150</b>, a current test script <b>164</b> and/or a GUI difference model <b>162</b>. In one implementation, the economic cost engine <b>182</b> may receive GAP change specifiers <b>184</b> and a current test script <b>164</b>. The script parser logic <b>812</b> produces the test script statement vectors <b>816</b> based on the current test script <b>164</b>. The economic cost model logic <b>196</b> analyzes the test script statement vectors <b>816</b> to generate synthetic GAP change specifiers <b>185</b>. The economic cost model logic <b>196</b> uses the received GAP change specifiers <b>184</b> and generated synthetic GAP change specifiers <b>185</b> to locate and retrieve GUI element change cost rules <b>848</b> from the economic models <b>176</b> repository. In one implementation, the received GAP change specifiers <b>184</b> and generated synthetic GAP change specifiers <b>185</b> are indistinguishable as to their origin such that the economic cost model logic <b>196</b> processes the received GAP change specifiers <b>184</b> and generated synthetic GAP change specifiers <b>185</b> uniformly, regardless of their origin.

In another implementation, the economic cost engine <b>182</b> receives GAP change specifiers <b>184</b>, a current test script <b>164</b> and a current GAP version <b>150</b>. The economic cost engine <b>182</b> analyzes the GAP change specifiers <b>184</b> and the current GAP version <b>150</b> (e.g., current GAP tree model) to generate synthetic GAP change specifiers <b>185</b>. The economic cost engine <b>182</b> analyzes the test script statement vectors <b>816</b> corresponding to the current test script <b>164</b> and the GUI difference model <b>162</b> to generate synthetic GAP change specifiers <b>185</b>. The economic cost model logic <b>196</b> uses the received GAP change specifiers <b>184</b> and generated synthetic GAP change specifiers <b>185</b> to locate and retrieve GUI element change cost rules <b>848</b> from the economic models <b>176</b> repository and generate the test script transformation cost report <b>186</b>.

In one implementation, the economic cost engine <b>182</b> receives a current test script <b>164</b> and a GUI difference model <b>162</b>, without GAP change specifiers <b>184</b>. The economic cost engine <b>182</b> analyzes the test script statement vectors <b>816</b> corresponding to the current test script <b>164</b> and the GUI difference model <b>162</b> to generate synthetic GAP change specifiers <b>185</b>.

In one implementation, the economic cost engine <b>182</b> receives GAP change specifiers <b>184</b>, a current test script <b>164</b>, a GUI difference model <b>162</b> corresponding to the GAP version <b>150</b> and a subsequent GAP version <b>152</b>. The economic cost engine <b>182</b> analyzes the test script statement vectors <b>816</b> corresponding to the current test script <b>164</b> and the GUI difference model <b>162</b> to generate synthetic GAP change specifiers <b>185</b>. The economic cost engine <b>182</b> uses the received GAP change specifiers <b>184</b> and generated synthetic GAP change specifiers <b>185</b> to locate and retrieve GUI element change cost rules <b>848</b> from the economic models <b>176</b> repository and generate the test script transformation cost report <b>186</b>.

In one implementation, the accuracy of the GUI transformation costs <b>848</b> varies due to the granularity of the information received by the economic cost engine <b>182</b>. For example, the GUI transformation costs <b>848</b> generated as a result of the economic cost engine <b>182</b> receiving GAP change specifiers <b>184</b>, a current test script <b>164</b>, and a GUI difference model <b>162</b> may have a higher level of accuracy than the GUI transformation costs <b>848</b> generated based solely on received GAP change specifiers <b>184</b>. The economic cost engine <b>182</b> may employ various economic models to preserve the accuracy of the GUI transformation costs <b>848</b> and compensate for the varying granularities of information provided to the economic cost engine <b>182</b>.

In one implementation, GAP change specifiers <b>184</b> and/or synthetic GAP change specifiers <b>185</b> include a model specifier <b>868</b>, a GUI change frequency <b>870</b>, skill coefficients <b>872</b>, complexity identifier <b>874</b>, quality identifier <b>876</b>, percent of change <b>878</b>, wrong path-delete type <b>880</b>, wrong path-same type <b>882</b> and changed element type <b>884</b> specifiers. The model specifier <b>868</b> specifies one or more economic models to use from among multiple economic models accessible by the economic model logic <b>196</b>. In one implementation, the model specifier <b>868</b> specifies one or more economic models for the economic cost model logic <b>196</b> to use corresponding to the varying granularities of information provided to the economic cost engine <b>182</b>, so that the accuracy of the GUI transformation costs <b>848</b> are preserved. For example, the model specifier <b>868</b> may specify models corresponding to one or more of the multiple combinations of available information received by the economic cost engine <b>182</b>, including: 1) model-1 for GAP change specifiers <b>184</b>; 2) model-2 for GAP change specifiers <b>184</b> and a current test script <b>164</b>; 3) model-3 for GAP change specifiers <b>184</b>, a current test script <b>164</b> and a current GAP version <b>150</b>; 4) model-4 for a current test script <b>164</b> and a GUI difference model <b>162</b> with GUI difference entries <b>810</b>; and 5) model-5 for GAP change specifiers <b>184</b>, a current test script <b>164</b>, and a GUI difference model <b>162</b> with GUI difference entries <b>810</b>.

The GUI change frequency <b>870</b> indicates the number of occurrences of a particular GUI element change. In one implementation, the economic cost model logic <b>196</b> includes a user adjustable GUI change efficiency factor <b>886</b> that indicates whether a GUI change frequency <b>870</b> above a particular threshold results in a lower GUI transformation cost <b>848</b>. For example, a GUI change efficiency factor <b>886</b> of 0.50 indicates that the GUI transformation cost <b>848</b> for each change above a threshold of 100 occurrences for a given GUI element change are adjusted by 50 percent. In other words, where a particular GUI element change is identified to have 120 occurrences, the economic cost model logic <b>186</b> applies the GUI change efficiency factor <b>886</b> of 0.50 to the GUI transformation cost <b>848</b> for the 20 changes above the threshold of 100. In another example, a GUI change efficiency factor <b>886</b> of 0.00 may indicate that no efficiency is realized regardless of the GUI change frequency <b>870</b> value.

In one implementation, the skills coefficients <b>872</b> include one or more coefficients that are used to describe the level of experience of the testers who are expected to test the subsequent GAP version <b>152</b>. The skills coefficients <b>872</b> may include individual coefficients for specific areas of testing experience. For example, the skills coefficients <b>872</b> may correspond to the skill and experience level of testers according to particular phases of testing such as unit, integration, system and final test phase so that each phase is represented by one or more coefficients. In another example, the skills coefficients <b>872</b> may correspond to skills and experience corresponding to testing particular aspects of the subsequent GAP version <b>152</b>, such as security and user authentication, numerical computations specific to the GAP, and network and infrastructure.

In another implementation, the skills coefficients <b>872</b> are calibrated based on performance metrics located in a performance metrics repository <b>198</b> and/or cost reports repository <b>888</b>. GAP change specifiers <b>184</b> and/or synthetic GAP change specifiers <b>185</b> may be constructed and/or generated from historical performance metrics found in a performance metrics repository <b>198</b> and/or cost reports repository <b>888</b>. The skills coefficients <b>872</b> of the constructed GAP change specifiers <b>184</b> and/or synthetic GAP change specifiers <b>185</b> may be adjusted over multiple iterations to obtain GUI transformation costs <b>848</b> and test script transformation cost reports <b>186</b> that are within acceptable margins of variance to the actual costs reflected in the performance metrics repository <b>198</b>. The accuracy of the GUI transformation costs <b>848</b> obtained by the economic cost model logic <b>196</b> may be based on how well the skills coefficients <b>872</b> are calibrated to reflect the testing resources available to test the subsequent GAP version <b>152</b>. In one implementation, the skills coefficients <b>872</b> influence the complexity identifier <b>874</b>, discussed in further detail below.

The economic cost model logic <b>196</b> uses the skills coefficients <b>872</b> to obtain the GUI transformation costs <b>848</b>. For example, a skills coefficient <b>872</b> value of 1.0 may indicate that testers with little experience are expected to be used to test the subsequent GAP version <b>152</b> and higher GUI transformation costs <b>848</b> may result to reflect the low experience. In another example, a skills coefficient <b>872</b> value of 8.0 may indicate testers with higher than average testing experience and lower GUI transformation costs <b>848</b> may result that reflect the higher than average experience. The economic cost model logic <b>196</b> may analyze whether the skills coefficients <b>872</b> and complexity ranking <b>862</b> correlate, and obtain correspondingly higher or lower GUI transformation costs <b>848</b>. For example, the skills coefficients <b>872</b> may indicate that the testers are capable of testing a GAP with a particular level of complexity, as indicated by the complexity ranking <b>862</b>, so that lower GUI transformation costs <b>848</b> are obtained. In another example, the skills coefficients <b>872</b> may indicate that the testers lack a skill and experience level for testing a GAP with a particular level of complexity corresponding to the complexity ranking <b>862</b>, so that higher GUI transformation costs <b>848</b> are obtained to reflect the lack of skills and experience of the testers and the expected time and resources to test the subsequent GAP version <b>152</b>.

In one implementation, the complexity identifier <b>874</b> numerically identifies the level of complexity of a GUI element change (e.g., values 0 to 10), determined by the economic cost model logic <b>196</b>, corresponding to a generated synthetic GAP change specifier <b>185</b>. In another implementation, the complexity identifier <b>874</b> identifies the level of complexity determined by a tester and received by the economic cost model logic <b>196</b> with the GAP change specifier <b>184</b>. Distinguishing the complexity identifier <b>874</b> of the GAP change specifier <b>184</b> and/or synthetic GAP change specifier <b>185</b> from the complexity ranking <b>858</b> of the GUI element change cost rule <b>846</b>, the complexity identifier <b>874</b> represents analysis that is external to the economic models <b>176</b> repository. The economic cost model logic <b>196</b> may analyze the complexity ranking <b>862</b> and complexity identifier <b>874</b> to assess the accuracy of the GUI transformation costs <b>848</b> obtained by applying the GUI element change cost rule <b>846</b>.

For example, the economic cost model logic <b>196</b> may determine that the complexity ranking <b>862</b> and complexity identifier <b>874</b> corresponding to a particular GUI element change are within an acceptable margin of variance such that the GUI transformation cost <b>848</b> is not adjusted as a result. In another example, the economic cost model logic <b>196</b> may determine that the complexity ranking <b>862</b> and complexity identifier <b>874</b> corresponding to a particular GUI element change are outside of an acceptable margin of variance and the GUI transformation costs <b>848</b> are adjusted upward by a multiplier. The margin of variance and the multiplier, determined by analyzing the complexity ranking <b>862</b> and complexity identifier <b>874</b>, may be user selectable and/or adjustable. In one implementation, the complexity identifier <b>874</b> is based on the skills coefficients <b>872</b> such that the complexity of a GUI element change is assessed relative to the skills and experience of the available testers. The skills coefficients <b>872</b> may be calibrated so that the complexity ranking <b>862</b> and the complexity identifier <b>874</b> generated by the economic cost model logic <b>196</b> are within an acceptable margin of variance.

In one implementation, the quality identifier <b>876</b> numerically identifies the level of quality contributed to by a GUI element change (e.g., values 0 to 10), determined by the economic cost model logic <b>196</b>, corresponding to a generated synthetic GAP change specifier <b>185</b>. In another implementation, the quality identifier <b>876</b> identifies the level of quality determined by a tester and received by the economic cost model logic <b>196</b> with the GAP change specifier <b>184</b>. Distinguishing the quality identifier <b>876</b> of the GAP change specifier <b>184</b> and/or synthetic GAP change specifiers <b>185</b> from the quality ranking <b>860</b> of the GUI element change cost rule <b>846</b>, the quality identifier <b>876</b> represents analysis that is external to the economic models <b>176</b> repository. The economic cost model logic <b>196</b> may analyze the quality ranking <b>860</b> and quality identifier <b>876</b> to assess the accuracy of the GUI transformation costs <b>848</b> obtained by applying the GUI element change cost rule <b>846</b>. For example, the economic cost model logic <b>196</b> may determine that the quality ranking <b>860</b> and quality identifier <b>876</b> corresponding to a particular GUI element change are within an acceptable margin of variance such that the GUI transformation cost <b>848</b> is not adjusted as a result. In another example, the economic cost model logic <b>196</b> may determine that the quality ranking <b>860</b> and quality identifier <b>876</b> corresponding to a particular GUI element change are outside of an acceptable margin of variance and the GUI transformation costs <b>848</b> are adjusted upward by a multiplier. The margin of variance and the multiplier, determined by analyzing the quality ranking <b>860</b> and quality identifier <b>876</b>, may be user selectable and/or adjustable.

In one implementation, the economic cost engine <b>182</b> receives a GAP change specifier <b>184</b> that includes a percent of change <b>878</b> value, a current test script <b>164</b> and a current GAP tree model corresponding to a current GAP version <b>150</b> that the economic cost engine <b>182</b> uses to generate synthetic GAP change specifiers <b>185</b>, and locate and retrieve GUI element change cost rules <b>848</b> from the economic models <b>176</b> repository. For example, the economic cost model logic <b>196</b> analyzes the current GAP version <b>150</b> (e.g., represented by a current GAP tree model) and generates synthetic GAP change specifiers <b>185</b> that reflect a percentage of change to the current GAP version <b>150</b> corresponding to the percent of change <b>878</b> value (e.g., ranging from 1 to 100). The economic cost model logic <b>196</b> analyzes the current GAP version <b>150</b> and identifies a set of proposed GUI elements changes that correspond to the percent of change <b>878</b> value. The economic cost model logic <b>196</b> may identify the proposed GUI elements by analyzing the GUI elements in the GAP tree model of the current GAP version <b>150</b> in a random order, the order in which the GUI elements are presented in the tree model from top to bottom or from bottom to top.

In one implementation, the proposed GUI element changes may be determined based on the complexity identifier <b>874</b> and/or quality identifier <b>876</b> included in the received GAP change specifier <b>184</b>. For example, the economic cost model logic <b>196</b> receives a GAP change specifier <b>184</b> that includes a complexity identifier <b>874</b> value of 1 and quality identifier <b>876</b> value of 2, and for each of the proposed GUI elements to be changed, determines proposed changes corresponding to the complexity identifier <b>874</b> value of 1 and the quality identifier <b>876</b> value of 2. The economic cost model logic <b>196</b> may locate, in the performance metrics repository <b>198</b> and/or cost reports repository <b>888</b>, proposed GUI element changes corresponding to the complexity identifier <b>874</b> values and the quality identifier <b>876</b> values. In one implementation, the economic cost model logic <b>196</b> generates synthetic GAP change specifiers <b>185</b>, as a result of analyzing the proposed GUI element changes. In another implementation, the economic cost model logic <b>196</b> identifies proposed GUI element changes corresponding to the complexity identifier <b>874</b>, the quality identifier <b>876</b> and skill coefficients <b>872</b>.

The economic cost model logic <b>196</b> analyzes the current test script <b>164</b> and GUI difference model <b>162</b> to generate synthetic GAP change specifiers <b>185</b> based on validated GUI element changes (e.g., GUI element difference entries). For example, the economic cost model logic <b>196</b> determines test script statement vectors <b>816</b> that need modification because GUI objects that are referenced in the current test script <b>164</b> and exist in the current GAP version <b>150</b> that do not exist in the subsequent GAP version <b>152</b>, and the economic cost model logic <b>196</b> generates synthetic GAP change specifiers <b>185</b> that reflect the needed changes to the current test script <b>164</b>. The economic cost model logic <b>196</b> identifies changes to test script statement vectors <b>816</b> that set the values of GUI objects that are compatible with the class of that GUI objects, so that constraints imposed on the GUI objects as a result of a change are not violated. In one implementation, the economic cost model logic <b>196</b> verifies that incorrect operations are not specified by GAP change specifiers <b>184</b> and/or synthetic GAP change specifiers <b>185</b> used to obtain GUI transformation costs <b>848</b>.

The economic cost model logic <b>196</b> may infer GUI class information regarding a GUI object that is present in a navigation path of test script statement vectors <b>816</b>, and whose presence is not explicitly defined. For example, when the test script statement vector <b>816</b> employs expressions that identify GUI objects whose values can only be determined at runtime, the OR lookup logic <b>172</b> may use path traversal logic <b>824</b> to identify the possible corresponding GUI object entries <b>822</b> and GUI element difference entries <b>810</b> in the object repository <b>174</b> and GUI difference model <b>162</b>, respectively. The economic cost model logic <b>196</b> then identifies the valid GUI object entries <b>822</b> that may substitute for the expressions and GUI element difference entries <b>810</b> that satisfy valid test script statement vectors <b>816</b>, and the economic cost model logic <b>196</b> generates corresponding synthetic GAP change specifiers <b>185</b>.

For example, consider the test script statement vector <b>816</b>: VBWindow(“s”).VBWindow(e1).VBWindow(e2).VBWindow(“d”), where the source node GUI object is named “s”, the destination node GUI object is named “d”, but expressions e1 and e2 compute values of intermediate nodes in the navigation path at runtime. The traversal logic <b>824</b> determines intermediate nodes (GUI objects) that may be included in the possible navigation paths identified by the source node “s” and destination node “d”. The path traversal logic <b>824</b> analyzes the GUI difference model <b>162</b> to identify possible constant substitutions for e1 and e2, for example, “a” and “f”, so that the test script statement vector <b>816</b> formed by the substitute GUI objects in the navigation path expression “s.a.f.d” can be validated by economic cost model logic <b>196</b>. By identifying the possible navigation paths leading to the destination node d starting with the source node ‘s’ the economic cost model logic <b>196</b> can conclude whether to generate a synthetic GAP change specifier <b>185</b> based on the substitute GUI objects. In the event the traversal logic <b>824</b> does not identify at least one navigation path, then the transformed test script statement <b>828</b> is invalid. Alternatively, in the event the traversal logic <b>824</b> identifies navigation paths leading from ‘s’ to ‘d’ by traversing two objects (e.g., e1 and e2), then the transformed test script statement <b>828</b> may be valid provided that expressions e1 and e2 evaluate to the names of the nodes in the discovered navigation paths. The traversal logic <b>824</b> infers the possible names computed by expressions e1 and e2 at compile time. In other words, there is a direct correlation between the complexity of test scripts and the economic cost to transform test scripts and use those test scripts to test subsequent GAP versions <b>152</b>. The complexity is a function of the number of referenced GUI objects and operations on the GUI objects, as well as the amount of logic needed to process the data that is extracted and placed into those GUI objects.

A formal description of the traversal logic <b>824</b> is provided with reference to <figref idrefs="DRAWINGS">FIG. 16</figref>. Expressions e1 and e2 may be replaced with the object name variables a and β correspondingly, and the original expression is converted into traversal strategy S=s→═→β→d. The function ‘first(s)’ computes a set of edges that can be traversed from node s. These edges lead to a set of objects designated by the variable a. Function ‘first(s)’ may be computed using a graph reachability algorithm, included in the path traversal logic <b>824</b>, and the path traversal logic <b>824</b> returns edges that may navigate to the destination node. According to <figref idrefs="DRAWINGS">FIG. 16</figref>, α={a, b, c}. Then for each element of a, function ‘first’ may be computed. As a result, β={e, f, g} are obtained, where ‘first(a)’={e, g}, ‘first(b)’={e}, and ‘first(c)’={f}, and ‘first(e)’={Ø}, ‘first(f)’={d}, and ‘first(g)’={d}. From the computed node values the path traversal logic <b>824</b> forms a work-list W that includes a set of all computed paths, W={(s, a, e), (s, a, g, d), (s, b, e), (s, c, f, d)}. The path traversal logic <b>824</b> analyzes each navigation path of W to determine whether the navigation path contains nodes ‘s’ and ‘d’. Navigation paths identified by the path traversal logic <b>824</b> to include nodes ‘s’ and ‘d’, as source and destination nodes, are considered as valid navigation paths. In the event no navigation paths are identified by the traversal logic <b>824</b>, then the test script statement vector <b>816</b> is invalid because the target GUI element cannot be reached starting from the specified beginning GUI element.

Referring again to <figref idrefs="DRAWINGS">FIG. 16</figref>, an example of an invalid expression is VBWindow(“s”).VBWindow(e1). VBWindow(e2).VBWindow(e3).VBWindow(“d”). All navigation paths between nodes s and d have at most two objects. Therefore, no matter what values are computed at runtime for expressions e1, e2, and e3 the expressions cannot represent objects in a valid navigation path between the source and the destination objects. Another example of an invalid expression is VBWindow(“s”).VBWindow(“b”).VBWindow(e1).VBWindow(“d”), because no value for the expression e1 exists that makes the navigation path valid (i.e. that forms a complete path from ‘s’ to ‘d’).

The economic cost model logic <b>196</b> may infer GUI class information regarding GUI objects that are present in the navigation path of test script statement vectors <b>816</b>. The economic cost model logic <b>196</b> identifies GAP change specifiers <b>184</b> and/or synthetic GAP change specifiers <b>185</b> that resolve test script statement vectors <b>816</b> that attempt to access GUI objects that do not exist in a subsequent GAP version <b>152</b> and/or attempt to set a value of a GUI object that is not compatible with the type of the GUI object. The economic cost model logic <b>196</b> type checks test script statement vectors <b>816</b> against the GUI difference model <b>162</b> before generating corresponding GAP change specifiers <b>184</b>.

The economic cost model logic <b>196</b> uses inheritance and sub-typing relations between classes of GUI objects to validate received GAP change specifiers <b>184</b> and generate valid synthetic GAP change specifiers <b>185</b>. The concept of class includes hierarchical containments (e.g., GUI scopes and system hierarchies). The object repository <b>174</b> and the GUI difference model <b>162</b> include GUI class information (e.g., annotating the classes of GUI objects) for each GUI object entry <b>822</b> and GUI element difference entry <b>810</b>. For example, referring to line <b>1</b> of Table 7, the SchoolListBox is a WinObject class with properties listed at lines <b>3</b>-<b>39</b>. In another example, referring to <figref idrefs="DRAWINGS">FIGS. 5</figref>, <b>14</b> and <b>15</b>, at line <b>1</b> of each GUI difference entry (e.g., <b>504</b>, <b>1404</b> and <b>1504</b>) the GUIElement Type is indicated. The class of each GUI object is indicated as shown in <figref idrefs="DRAWINGS">FIGS. 5</figref>, <b>14</b> and <b>15</b> at lines <b>7</b>, <b>8</b> and <b>8</b>, respectively. The class of a GUI object indicates that the GUI object includes particular attributes, properties and/or traits in common with other GUI objects of the same class that may be extended to and/or inherited by child GUI objects. For example, <figref idrefs="DRAWINGS">FIG. 5</figref> at line <b>7</b> indicates that the StateListbox GUI object is of a WindowsForms10.ListBox.app4 class that includes values, as indicated at line <b>11</b> of <figref idrefs="DRAWINGS">FIG. 5</figref>. In other words, one property of GUI objects of WindowsForms10.ListBox.app4 is that these GUI objects are expected to have values. Class is a concept that a GUI framework uses to classify GUI objects. For example, class ListBox defines shape, functionality, and the rules of interactivity for GUI objects of this class. Assigning classes to GUI objects facilitates the economic cost model logic <b>196</b> to trace changes between successive GAP versions (e.g., <b>150</b> and <b>152</b>) and perform extended checking on the correctness of operations on GUI objects.

Referring again to <figref idrefs="DRAWINGS">FIG. 8</figref>, in one implementation, the economic cost model logic <b>196</b> determines whether a GUI object has changed and sets the GUI element change status <b>834</b>. For example, the GUI element change status <b>834</b> may use a numerical indicator of 0, 1, and 2, respectively, to indicate no change, and a change with and without a particular constraint violation. The economic cost model logic <b>196</b> may use the GUI element change status <b>834</b> to facilitate identifying the appropriate GAP change specifiers <b>184</b> and/or synthetic GAP change specifiers <b>185</b>.

In another implementation, the GUI element change status <b>834</b> is a message that provides a detail description of a change. The GUI element change status <b>834</b> may also indicate with a numerical indicator (e.g., −1) that the GUI object has been deleted from the subsequent GAP version <b>152</b>. When a GUI object has been deleted from the subsequent GAP version <b>152</b>, the economic cost model logic <b>196</b> generates one or more synthetic GAP change specifiers <b>185</b> that specify corresponding changes to the current test script <b>164</b> and the current GAP version <b>150</b>. In one implementation, the economic cost model logic <b>196</b> generates synthetic GAP change specifiers <b>185</b> that correspond to different, but programmatically equivalent, approaches to changing the current test script <b>164</b> and the current GAP version <b>150</b>, so that a programmer may evaluate the GUI transformation costs <b>848</b> and test script transformation cost report.

<figref idrefs="DRAWINGS">FIG. 9</figref> shows a flow diagram <b>900</b> for retrieving the properties of a GUI object entry <b>822</b> from an object repository (OR) <b>174</b>. The script parser logic <b>812</b> parses the test script statement vector <b>816</b> into an ordered sequence of nodes that represent functions and arguments that navigate to GUI objects (<b>902</b>). The script parser logic <b>812</b> evaluates the first node of the ordered sequence of nodes (<b>904</b>), and identifies the first node as the source node and assigns a sequence identifier indicating the position of the source node in the ordered sequence (<b>906</b>). The script parser logic <b>812</b> evaluates the next node of the order sequence of nodes to determine whether the next node is the last node (<b>908</b>), and identifies the next node as an intermediate node when the next node is not the last node (<b>910</b>). The intermediate node is assigned a sequence identifier indicating the position of the intermediate node in the ordered sequence. The script parser logic <b>812</b> may identify all intermediate nodes between the source node and the destination node.

The script parser logic <b>812</b> identifies the last node in the ordered sequence as the destination node and assigns a sequence identifier to the destination node that indicates the position of the destination node in the ordered sequence (<b>912</b>). The OR lookup logic <b>172</b> performs an object repository lookup for each GUI object corresponding to the ordered sequence of nodes to which the test script statement vector navigates so that each GUI object entry <b>822</b> is identified (<b>914</b>). In one implementation, the ordered sequence of nodes is used by the path traversal logic <b>824</b> and economic cost model logic <b>196</b> to validate the statements of the current test script <b>164</b>, and/or validate received GAP change specifiers <b>184</b> and generate valid synthetic GAP change specifiers <b>185</b>. In one implementation, the economic cost engine <b>182</b> uses the ordered sequence of nodes to infer GUI class and inheritance (subclass) information for GUI objects. Where at least one of the source, destination and/or the intermediate nodes are expressions that can only be identified at run-time, the path traversal logic may identify possible GUI object entries <b>822</b>, and the economic cost model logic <b>196</b> determines the GUI object entries <b>822</b> that satisfy the test script statement vector <b>816</b>. The OR lookup logic <b>172</b> retrieves the properties of the GUI object entries <b>822</b> to which the test script statement vector navigates (<b>916</b>).

<figref idrefs="DRAWINGS">FIG. 10</figref> shows a flow diagram <b>1000</b> for identifying a GUI difference entry <b>810</b> corresponding to a GUI object entry <b>822</b>. The OR lookup logic <b>172</b> receives the properties of the GUI objects corresponding to the source, destination and all intermediate nodes of the test script statement vector <b>816</b>. In one implementation, the OR lookup logic <b>172</b> employs the path traversal logic <b>824</b> to identify possible GUI difference entries <b>810</b> corresponding to the navigation paths identified by a source node and a destination node to which a test script statement vector navigates (<b>1002</b>). Where at least one of the GUI element difference entries <b>810</b> is an expression that can only be identified at run-time, the path traversal logic <b>824</b> identifies one or more possible GUI difference entries <b>810</b> that form a navigation path between the source node and the destination node (<b>1004</b>). The path traversal logic <b>824</b> determines whether the GUI difference entries <b>810</b> form a valid navigation path between corresponding source and destination nodes GUI difference entries <b>810</b> (<b>1006</b>). The GUI economic cost model logic <b>196</b> determines whether the GUI difference entries <b>810</b> that form the navigation path are valid (<b>1008</b>).

The economic cost model logic <b>196</b> identifies the GUI element difference entries <b>810</b> that correspond to each of the GUI object entries <b>822</b> forming a valid navigation path (<b>1010</b>). The economic cost model logic <b>196</b> determines the synthetic GAP change specifiers <b>185</b> to generate and/or validates the GAP change specifiers <b>184</b> based on the type of GUI element change (e.g., <b>880</b>, <b>882</b>, <b>884</b> and/or GUI element change status <b>834</b>), based on analyzing the GUI object entry <b>822</b> and GUI element difference entry <b>810</b> (<b>1012</b>). The economic cost model logic <b>196</b> generates valid synthetic GAP change specifiers <b>185</b> corresponding to the type of GUI element change identified. When the path traversal logic <b>824</b> identifies a navigation path that traverses an invalid number of GUI element difference entries <b>810</b> between corresponding source and destination node GUI difference entries <b>810</b>, the path traversal logic <b>824</b> indicates that the navigation path is invalid (<b>1014</b>).

<figref idrefs="DRAWINGS">FIG. 11</figref> shows a transformed test script <b>178</b> for the subsequent GAP version <b>152</b>. The economic cost model logic <b>196</b> may generate synthetic GAP change specifiers <b>185</b> that specify the changes needed to obtain the transformed test script <b>178</b>. For example, the economic cost model logic <b>196</b> generates synthetic GAP change specifiers <b>185</b> for lines <b>1</b>-<b>3</b> of the current test script <b>164</b>, shown in <figref idrefs="DRAWINGS">FIG. 6</figref>, corresponding to transformed test script lines <b>1</b>, <b>5</b>-<b>7</b>, shown in <figref idrefs="DRAWINGS">FIG. 11</figref>. In one implementation, the GUI difference model <b>162</b> and the GUI element metadata provide the GUI class, GUI typing and mapping information necessary for the economic cost model logic <b>196</b> to infer lines <b>2</b>-<b>4</b> of the transformed test script <b>178</b>, given that the “university.data” in line <b>6</b> represents a destination in a path traversal from which valid GAP change specifiers <b>184</b> and/or synthetic GAP change specifiers <b>185</b> may be determined. In another example, the GUI difference model <b>162</b> and/or the GUI element metadata include GUI class and mapping information that the economic cost engine <b>182</b> uses to generate one or more synthetic GAP change specifiers <b>185</b> that specify how to transform line <b>16</b> of the current test script <b>164</b>, as shown in <figref idrefs="DRAWINGS">FIG. 6</figref>, that refers to WinObject “Save File” into lines <b>24</b>-<b>25</b> that refer to a “Save File” child GUI object of the WinObject “menuStrip1”.

<figref idrefs="DRAWINGS">FIG. 12</figref> shows a flow diagram <b>1200</b> for generating a synthetic GAP change specifier <b>185</b>. In one implementation, the economic cost model logic <b>196</b> validates GAP change specifiers <b>184</b> and/or generates synthetic GAP change specifiers <b>185</b> that specify the type of GUI object changes between successive releases of GAPs, including: (A) a new GUI object added to a subsequent GAP version <b>152</b>; (B) a GUI object is deleted from a subsequent GAP version <b>152</b>; (C) the values of one or more attributes of a GUI object are modified; (D) the values of a GUI object are modified between successive GAP versions; and (E) the type of a GUI object is different. The economic cost engine <b>182</b> analyzes the GUI objects referred to in the current test script <b>164</b>, the current GAP version <b>150</b> and the GAP change specifiers <b>184</b> (<b>1202</b>). The economic cost engine <b>182</b> retrieves the properties of each GUI object (e.g., GUI object entries <b>822</b>) from the object repository <b>174</b>, and locates a corresponding GUI element difference entry <b>810</b> in the GUI difference model <b>162</b> (<b>1204</b>). In one implementation, the economic cost engine <b>182</b> receives a current GAP tree model representation of a current GAP version <b>150</b> from the GUI difference model <b>162</b> and GAP change specifiers <b>184</b>, and generates synthetic GAP change specifiers <b>185</b>, using GAP change specifier logic <b>890</b>. The economic cost model logic <b>196</b> analyzes the GUI object changes (<b>1206</b>).

GUI object changes of types A (<b>1208</b>) and B (<b>1210</b>) occur when GUI objects are added and removed correspondingly from current GAP version <b>150</b> and subsequent GAP version <b>152</b>. For example, adding the WinObject menustrip1 <b>308</b> to the subsequent GAP version <b>152</b> is a type A change, while removing the WinObject “Select School” <b>204</b> is a type B GUI object change. Referring to <figref idrefs="DRAWINGS">FIG. 4</figref>, notice that the “Select School” has been removed at <b>412</b>.

An example of a type C change (<b>1212</b>) is the change of the window name from StateList <b>202</b> to School <b>302</b>. Adding or removing values from GUI objects such as list and combo boxes are examples of modifications of the type D change (<b>1212</b>). For example, the listbox StateListbox <b>212</b> in current GAP version <b>150</b> is identified in the subsequent GAP version <b>152</b> as StateListbox <b>304</b>, and referring to the GUI difference entry <b>504</b> the values for SeqNumber=“8” are “District of Columbia” and “Florida” for successive GAP versions, respectively. Changing the “type” of a GUI object may include replacing a class of the window that is used to represent the object and/or changing the high-level concept that describes the values that the GUI object takes. For example, changing the type of the static label to a read-only combo box is a modification of the type E (<b>1212</b>). Another example of a type E change includes the change of the listbox “SchooListbox” <b>216</b> to a combobox “SchoolCombobox” <b>306</b>.

The economic cost model logic <b>196</b> receives GAP change specifiers <b>184</b> and generates synthetic GAP change specifiers <b>185</b> that include wrong path-delete type <b>880</b> wrong path-same type <b>882</b> and changed element type <b>884</b> specifiers. Wrong path-delete type <b>880</b> specifies that a GUI object in the current GAP version <b>150</b> may have been deleted in the subsequent GAP version <b>152</b> (e.g., see “Select School” <b>218</b> and <b>412</b> as shown in <figref idrefs="DRAWINGS">FIG. 4</figref>), although the current test script <b>164</b> refers to the GUI object (<b>1214</b>). Wrong path-same type <b>882</b> specifies that a GAP change may result in a read and/or write to the wrong GUI object. For example, a method may be invoked on the wrong GUI object based on a particular GAP change. Wrong path-same type <b>882</b> specifies that a GUI object in a current GAP version <b>150</b> has been modified and/or another GUI object has been added to the subsequent GAP version <b>152</b> that may result in the wrong GUI object being navigated to by a test script statement (<b>1216</b>).

For example, consider the statement in lines <b>2</b> and <b>6</b> of the current test script <b>164</b> and transformed test script <b>178</b>, respectively:

Window(“StateList”).Dialog(“Open”).WinListView(“SysListView32”).Select “university.data”.

The statement selects “university.data” from a WinListView “SysListView32”. However, lines <b>2</b>-<b>4</b> of the transformed test script <b>178</b> may navigate to and invoke the Select method on the wrong GUI object “university.data”, because the GUI objects referenced in lines <b>2</b>-<b>4</b> of the transformed test script <b>178</b> are new GUI objects that are not referenced in the current test script <b>164</b>. Thus, when the properties of existing GUI objects are modified and/or other GUI objects are added into a subsequent GAP version <b>152</b>, the result of interference of these operations is that transformed test script statements that result from applying GAP change specifiers <b>184</b> and/or synthetic GAP change specifiers <b>185</b> to current test script statement vectors <b>816</b> may access and read values of objects that are different from those as originally intended.

Changed-element <b>884</b> specifies that the type, properties, and/or default values of a GUI object referenced by a test script statement vector <b>816</b> have changed in the subsequent GAP version <b>152</b> (<b>1218</b>). For example, the GUI difference entry <b>504</b> indicates that there are different values for SeqNumber=“8” are “District of Columbia” and “Florida” for successive GAP versions, and the economic cost model logic <b>196</b> may generate a synthetic GAP specifier <b>185</b> that includes a change-element <b>884</b> correspondingly. Change-element <b>884</b> may also specify that new constraints have been imposed on a GUI object that conflict with test script statement vectors <b>816</b>, for example, attempting to write data to a previously writable text box that has been changed to a read-only text box. Referring to the GUI element difference entry shown in Table 8, the WinObject “AcadScale” referred to in the current test script <b>164</b> at line <b>8</b> is an editable object that has been transformed into the WinObject “Academics (1-5)” in the subsequent GAP version <b>152</b> where the object is read-only. The economic cost model logic <b>196</b> validates GAP change specifiers <b>184</b> and/or generates the synthetic GAP change specifier <b>185</b> with the GAP change type specified (<b>1220</b>) and the GUI element change status <b>834</b> is updated (<b>1222</b>). In one implementation, the economic cost model logic <b>196</b> does not generate synthetic GAP change specifiers <b>185</b> for GUI objects that have not changed between successive GAP versions (<b>1224</b>).

<tables id="TABLE-US-00008" num="00008"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 8</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>GUI Element Difference entry for AcadScale</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="14pt" align="left" /><colspec colname="2" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>&lt;GUIElement Type = “AcadScale Textbox”&gt;</entry></row><row><entry /><entry>&lt;Version&gt; 0</entry></row><row><entry /><entry> − &lt;GUIElement Alias=“AcadScale”&gt;</entry></row><row><entry /><entry>  &lt;UniqueID&gt;0xcb&lt;/UniqueID&gt;</entry></row><row><entry /><entry>  &lt;HWND&gt;0x1a0b3c&lt;/HWND&gt;</entry></row><row><entry /><entry>  &lt;Location x=“573” y=“790” width=“32” height=“23” /&gt;</entry></row><row><entry /><entry>  &lt;Class&gt;WindowsForms10.EDIT.app4&lt;/Class&gt;</entry></row><row><entry /><entry>  &lt;Style&gt;0x560100c0&lt;/Style&gt;</entry></row><row><entry /><entry>  &lt;ExStyle&gt;0xc0000a00&lt;/ExStyle&gt;</entry></row><row><entry /><entry>− &lt;GUIElement Alias=“AcadScale”&gt;</entry></row><row><entry /><entry>  &lt;UniqueID&gt;0x4&lt;/UniqueID&gt;</entry></row><row><entry /><entry> &lt;HWND&gt;0x1a0b3c&lt;/HWND&gt;</entry></row><row><entry /><entry>  &lt;Location x=“575” y=“792” width=“28” height=“19” /&gt;</entry></row><row><entry /><entry> &lt;Class&gt;WindowsForms10.EDIT.app4&lt;/Class&gt;</entry></row><row><entry /><entry>  &lt;Style&gt;0x560100c0&lt;/Style&gt;</entry></row><row><entry /><entry>  &lt;ExStyle&gt;0xc0000a00&lt;/ExStyle&gt;</entry></row><row><entry /><entry>  − &lt;Values&gt;</entry></row><row><entry /><entry>  &lt;Value SeqNumber=“3” /&gt;</entry></row><row><entry /><entry>  &lt;/Values&gt;</entry></row><row><entry /><entry>  &lt;/GUIElement&gt;</entry></row><row><entry /><entry> &lt;/GUIElement&gt;</entry></row><row><entry /><entry>&lt;/Version&gt;</entry></row><row><entry /><entry>&lt;Version&gt; 1</entry></row><row><entry /><entry>− &lt;GUIElement Alias=“Academics (1-5)”&gt;</entry></row><row><entry /><entry> &lt;UniqueID&gt;0x2ff&lt;/UniqueID&gt;</entry></row><row><entry /><entry> &lt;HWND&gt;0x70d0e&lt;/HWND&gt;</entry></row><row><entry /><entry> &lt;Location x=“597” y=“388” width=“111” height=“17” /&gt;</entry></row><row><entry /><entry> &lt;Class&gt;WindowsForms10.STATIC.app.0.378734a&lt;/Class&gt;</entry></row><row><entry /><entry> &lt;Style&gt;0x5600000d&lt;/Style&gt;</entry></row><row><entry /><entry> &lt;ExStyle&gt;0xc0000800&lt;/ExStyle&gt;</entry></row><row><entry /><entry>− &lt;GUIElement Alias=“Academics (1-5)”&gt;</entry></row><row><entry /><entry> &lt;UniqueID&gt;0x308&lt;/UniqueID&gt;</entry></row><row><entry /><entry> &lt;HWND&gt;0x70d0e&lt;/HWND&gt;</entry></row><row><entry /><entry> &lt;Location x=“597” y=“388” width=“111” height=“17” /&gt;</entry></row><row><entry /><entry> &lt;Class&gt;WindowsForms10.STATIC.app.0.378734a&lt;/Class&gt;</entry></row><row><entry /><entry> &lt;Style&gt;0x5600000d&lt;/Style&gt;</entry></row><row><entry /><entry>  &lt;ExStyle&gt;0xc0000800&lt;/ExStyle&gt;</entry></row><row><entry /><entry> − &lt;Values&gt;</entry></row><row><entry /><entry>  &lt;Value SeqNumber=“3”&gt;Academics (1-5)&lt;/Value&gt;</entry></row><row><entry /><entry>  &lt;/Values&gt;</entry></row><row><entry /><entry>  &lt;/GUIElement&gt;</entry></row><row><entry /><entry> &lt;/GUIElement&gt;</entry></row><row><entry /><entry> &lt;/Version&gt;</entry></row><row><entry /><entry>&lt;/GUIElement&gt;</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

Knowing the modification type for a GUI object facilitates the economic cost model logic <b>196</b> to determine the appropriate synthetic GAP change specifiers <b>185</b> to generate and/or validate received GAP change specifiers <b>184</b>. For example, the economic cost model logic <b>196</b> may validate GAP change specifiers <b>184</b> and/or generate one or more synthetic GAP change specifiers <b>185</b> that specify changes to test script statement vectors <b>816</b> that attempt to set values in a text box object that has been changed to a read-only combo box. GAP change specifiers <b>184</b> and/or synthetic GAP change specifiers <b>185</b> may specify that the test script statement vector <b>816</b> be modified (transformed) to select values in the combo box using appropriate interfaces rather than attempting to set values in the text box.

The economic cost model logic <b>196</b> determines whether GUI objects have been removed from a current GAP version <b>150</b> and locates the test script statement vectors <b>816</b> that reference these removed objects in the current test script <b>164</b>. The economic cost engine <b>182</b> refers to these statements as first-reference statements (FRS). The variables used in these statements are obtained, and the statements that use the variables whose values are defined in the FRSs are referred to as secondary reference statements (SRS). The economic cost model logic <b>196</b> determines whether GUI objects may have been deleted in the subsequent GAP version <b>152</b>, and validates received GAP change specifiers <b>184</b> and generates one or more corresponding synthetic GAP change specifiers <b>185</b> with a wrong path-delete <b>884</b>. When a statement of the current test script <b>164</b> refers to a variable whose value points to a removed GUI object, the statement of the current test script <b>826</b> is considered an SRS. In one implementation, the economic cost engine <b>182</b> generates one or more synthetic GAP change specifiers <b>185</b> and/or validates received GAP change specifiers <b>184</b> corresponding to the identified SRSs.

When the values of one or more attributes of a GUI object are modified, a type C modification is performed. FRSs and SRSs are identified for the GUI object with the modified attributes, and corresponding synthetic GAP change specifiers <b>185</b> are generated and/or received GAP change specifiers <b>184</b> are validated. When the values of GUI objects are added or removed, modifications of the type D occur. After locating FRSs that reference GUI objects whose values have been changed, SRSs are found and the economic engine <b>182</b> determines the impact due to the SRSs. When the type of a GUI object is modified then a modification of the type E occurs that involves locating FRSs, checking the new types of the GUI object, invoking corresponding type sub-sumption rules. The economic cost model logic <b>196</b> may analyze the modified GUI objects to determine whether to generate synthetic GAP change specifiers <b>185</b> with change-element type <b>884</b> where GUI objects whose types, properties, or default values are changed in a subsequent GAP version <b>152</b>, and/or attempting an operation on a GUI object that does not take into consideration new constraints imposed on the elements of the GUI object.

The economic cost model logic <b>196</b> analyzes each GUI object referred to in the current test script <b>164</b>, the current GAP version <b>150</b>, received GAP change specifiers <b>184</b>, generated synthetic GAP change specifier <b>185</b>, and/or GUI element change status <b>834</b>. The economic cost model logic <b>196</b> locates, in the economic models <b>176</b> repository, the economic model specified by the model specifier <b>868</b>, and retrieves a GUI element change cost rule <b>846</b> with a change specifier identifier <b>850</b> corresponding to the GAP change specifier <b>184</b> and/or synthetic GAP change specifier <b>185</b>. In one implementation, the economic cost model logic <b>196</b> combines one or more attributes of a GUI object (e.g., type and/or class) with the GUI element change status <b>834</b>, the model specifier <b>868</b>, the wrong path-delete type <b>880</b>, wrong path-same type <b>882</b> and/or changed element type <b>884</b> to form a unique identifier used to locate a corresponding change specifier identifier <b>850</b> in the economic model specified by the model specifier <b>868</b>.

The economic model logic <b>196</b> analyzes the GUI element change cost rule <b>846</b> components, GAP change specifier <b>184</b> and/or synthetic GAP change specifier <b>185</b> components, preference identifiers <b>866</b> and GUI change efficiency factor <b>886</b> to determine whether to adjust the GUI change cost estimate <b>854</b>. For example, the economic cost model logic <b>196</b> adjusts the GUI change cost estimate <b>854</b> based on whether the skills coefficients <b>872</b>, complexity identify <b>874</b>, quality identifier <b>876</b>, system resource utilization identifiers <b>852</b>, quality ranking <b>860</b>, and/or complexity ranking <b>862</b> are within an acceptable variance as specified by the preference identifiers <b>866</b>. The economic cost model logic <b>196</b> obtains the GUI transformation cost <b>848</b> based on the adjusted GUI change cost estimate <b>854</b>. In other words, the GUI change cost estimate <b>854</b> is adjusted to obtain the GUI transformation cost for the GAP change specifier <b>184</b> and/or synthetic GAP change specifier <b>185</b>. The economic cost model logic <b>196</b> processes each received GAP change specifier <b>184</b> and/or generated synthetic GAP change specifier <b>185</b> to obtain the corresponding GUI transformation costs <b>848</b> and generates the test script transformation cost report <b>186</b> with the GUI transformation costs <b>848</b>.

<figref idrefs="DRAWINGS">FIG. 13</figref> shows a flow diagram for outputting a test script transformation cost report <b>186</b> based on a GUI difference model <b>162</b>. The economic cost engine <b>182</b> receives the GUI difference model <b>162</b> and GUI element metadata <b>140</b> (<b>1304</b>). The economic cost engine <b>182</b> receives a current test script representation <b>814</b> that includes a test script statement vector <b>816</b> (<b>1306</b>). The script parser logic <b>812</b> parses the test script statement vector <b>816</b> into vector nodes to determine the GUI objects to which the test script statement vector <b>816</b> navigates (<b>1308</b>). The economic cost engine <b>182</b> invokes the OR lookup logic <b>172</b> for each GUI object identified by the test script statement vector <b>816</b> to retrieve the properties of the GUI objects from the object repository <b>174</b> (<b>1310</b>). The path traversal logic <b>824</b> analyzes the navigation path of the GUI element difference entries <b>810</b> that correspond to the GUI objects identified by the test script statement vector <b>816</b> (<b>1312</b>). The economic cost model logic <b>196</b> validates a GAP change specifier <b>184</b> and/or determines the type of synthetic GAP change specifier <b>185</b> to generate (<b>1314</b>). The economic cost model logic <b>196</b> generates a synthetic GAP change specifier <b>185</b> corresponding to the type of GUI element change identified by analyzing the current test script <b>164</b>, current GAP version <b>150</b> (e.g., current GAP tree model) and GUI difference model <b>162</b> (<b>1316</b>). The economic cost model logic <b>196</b> locates, in the economic model specified by the model specifier <b>868</b>, the GUI element change cost rule <b>846</b> corresponding to the GAP change specifier <b>184</b> and/or synthetic GAP change specifier <b>185</b> and applies the GUI element change cost rule <b>846</b> to obtain the GUI transformation cost <b>848</b> (<b>1318</b>). The economic cost model logic <b>196</b> generates the test script transformation cost report <b>186</b> based on the GUI transformation cost <b>848</b> (<b>1320</b>).

In one implementation, the economic cost engine architecture <b>110</b> uses adaptive programming including class and object graphs and an abstraction that treats all objects uniformly. The path traversal logic <b>824</b> and the economic cost model logic <b>196</b> may distinguish complex and simple types of GUI objects. Complex types contain fields while simple types do not. Let T be finite sets of type names and F of field names or labels, and two distinct symbols this ∈ F and ⋄ ∈ F. Type graphs are directed graphs G=(V, E, L) such that:

V<u>⊂</u>T, the nodes are type names;

L<u>⊂</u>F, edges are labeled by field names, or “⋄” where fields do not have names. Edges that are labeled by “⋄” are called aggregation edges, and edges that are labeled by field names reference edges. The difference between aggregation and reference edges becomes clear with the following example. Fields of classes in object-oriented languages designate instances of some classes, and these fields have names that are used to reference the fields. Each field of a class is defined by the name of the field and the name of the class (type) that this field is an instance of. The name of a field is the label of the corresponding reference edge in the type graph.

When a class designates a GUI object o_kand the other class designates a GUI object o_nthat is contained in the object o_k, the type graph has two nodes, one for the object o_kand the other for the object o_nthat the object o_kcontains. The names of the corresponding classes serve as their types. The relation between two nameless objects is represented using the edge labeled with the “⋄” in the type graph.

E<u>⊂</u>L×V×V, edges are cross-products of labels and nodes;

for each v ∈ V, the labels of all outgoing edges with the exception of “⋄” are distinct;

for each v ∈ V, where v represents a concrete type,

<chemistry id="CHEM-US-00001" num="00001"><img id="EMI-C00001" he="4.32mm" wi="17.70mm" file="US08458662-20130604-C00001.TIF" alt="embedded image" img-content="chem" img-format="tif" orientation="portrait" inline="no" /><attachments><attachment idref="CHEM-US-00001" attachment-type="cdx" file="US08458662-20130604-C00001.CDX" /><attachment idref="CHEM-US-00001" attachment-type="mol" file="US08458662-20130604-C00001.MOL" /></attachments></chemistry>

An object graph is a labeled directed graph O=(V′, E′, L′) that is an instance of a type graph G=(V, E, L) under a given function Class that maps objects to their classes, if the following conditions are satisfied:

for all objects o ∈ V′, o is an instance of the concrete type given by function Class(o);

for each object o ∈ V′, the labels of its outgoing reference edges are exactly those of the set of labels of references of Class(o) including edges and their labels inherited from parent classes;

for each edge

<chemistry id="CHEM-US-00002" num="00002"><img id="EMI-C00002" he="4.49mm" wi="18.97mm" file="US08458662-20130604-C00002.TIF" alt="embedded image" img-content="chem" img-format="tif" orientation="portrait" inline="no" /><attachments><attachment idref="CHEM-US-00002" attachment-type="cdx" file="US08458662-20130604-C00002.CDX" /><attachment idref="CHEM-US-00002" attachment-type="mol" file="US08458662-20130604-C00002.MOL" /></attachments></chemistry><br /> Class(o) has a reference edge

<chemistry id="CHEM-US-00003" num="00003"><img id="EMI-C00003" he="4.32mm" wi="12.62mm" file="US08458662-20130604-C00003.TIF" alt="embedded image" img-content="chem" img-format="tif" orientation="portrait" inline="no" /><attachments><attachment idref="CHEM-US-00003" attachment-type="cdx" file="US08458662-20130604-C00003.CDX" /><attachment idref="CHEM-US-00003" attachment-type="mol" file="US08458662-20130604-C00003.MOL" /></attachments></chemistry><br /> such that v is a parent type of Class(o) and u is a parent type of Class(o′).

An object graph is a model of the objects, represented in GAPs, and their references to each other. A collection of fields in an object graph is a set of edges labeled by field names. A collection of aggregated objects in an object graph is a set of edges labeled by “⋄”. A path in a type graph G=(V, E, L) is a sequence of nodes and labels p_G=(v₀e₁,v₁e₂, . . . e_nv_n), where v_i∈ V and

<chemistry id="CHEM-US-00004" num="00004"><img id="EMI-C00004" he="4.23mm" wi="26.50mm" file="US08458662-20130604-C00004.TIF" alt="embedded image" img-content="chem" img-format="tif" orientation="portrait" inline="no" /><attachments><attachment idref="CHEM-US-00004" attachment-type="cdx" file="US08458662-20130604-C00004.CDX" /><attachment idref="CHEM-US-00004" attachment-type="mol" file="US08458662-20130604-C00004.MOL" /></attachments></chemistry><br /> for 0≦i≦n. A concrete path is defined as an alternating sequence of type names and labels designating reference edges. In general a concrete path p_cis a subset of the corresponding type path p_G, i.e. p_c<u>⊂</u>p_G.

An object graph has the special object o_r∈ V′, Or is a collection of root objects o_r<u>⊂</u>V′ in the object graph O given by function root: O→o_r. This object has type Class(o_r)=root and its relation with objects in its collection is expressed via o_r→⋄→o′∈ E′.

Given an object o of some type the traversal logic <b>824</b> and the economic cost model logic <b>196</b> work together to identify one or more reachable objects that satisfy certain criteria. The task performed is equivalent to determining whether test script statement vectors <b>816</b> that describe navigation paths are valid. Navigation paths specified in test script statement vectors <b>816</b> can be thought of as specification of constraints for the object reach-ability problem. Finding reachable objects is done via traversals. The traversal of an edge labeled e corresponds to retrieving the value of the e field. Every edge in the object graph is an image of a has-part edge in the type graph: there is an edge e(o₁, o₂) in O only when there exist types v₁and v₂such that object o₁ is of type v₁, v₁has an e-part of type v₂, and o₂is of type v₂.

The first node of a path p is called the source of p and the last node is called the destination of p. A traversal of an object graph O started with an object v_iand guided by paths from a set of paths p is done by performing depth-first search on O with p used to prune the search. The resulting traversal history is a depth-first traversal of the object graph along object paths agreeing with the given concrete path set.

The problem of identifying all reachable objects from a given object o that satisfy certain criteria is formalized as follows. For each pair of classes c and c′, a set of edges e may be identified by computing FIRST(c, c′) if it is possible for an object of type c to reach an object of type c′ by a path beginning with an edge e. More precisely, FIRST(c, c′)=e ∈ E, such that there exists an object graph O of C and objects o and o′ such that: 1) Class(o)=c; 2) Class(o′)=c′; and 3) o e*o′.

The last condition, o e* o′ indicates that there is (<img id="CUSTOM-CHARACTER-00001" he="3.13mm" wi="1.78mm" file="US08458662-20130604-P00001.TIF" alt="custom character" img-content="character" img-format="tif" orientation="portrait" inline="no" />) a path from o to o′ in the object graph, consisting of an edge labeled e, followed by any sequence of edges in the graph. The lack of information about the actual graph is represented by the existential operator <img id="CUSTOM-CHARACTER-00002" he="3.13mm" wi="4.23mm" file="US08458662-20130604-P00002.TIF" alt="custom character" img-content="character" img-format="tif" orientation="portrait" inline="no" />.

The task of static checking of test scripts (e.g., transformed test scripts <b>178</b>) is greatly simplified when the names of foreign components names are defined as string constants. When the names of GUI objects are specified using expressions, the values of these expressions may not be determined until run-time. Type graphs facilitate the economic engine system <b>800</b> to infer types of expressions and variables that hold the names of GUI objects. The economic engine system <b>800</b> applies concepts based on the Traversal Graph Analysis (TGA) defined in adaptive programming to infer types of expressions and variables.

An adaptive strategy S=(R, π, δ) represents paths in an object graph, where R={s, d}, where s and d are the source and destination GUI objects of a path in an object graph, and R<u>⊂</u>O, where O is the set of objects in a type graph, π={e, α}, where e is a set of fields and α is a set of variables that designate a set of some edges α<u>⊂</u>e, and δ=<img id="CUSTOM-CHARACTER-00003" he="3.13mm" wi="9.14mm" file="US08458662-20130604-P00003.TIF" alt="custom character" img-content="character" img-format="tif" orientation="portrait" inline="no" /> is a set of transition edges representing objects and attributes respectively. Each element in a strategy S is either the name of some object or a variable designating an object and/or attributes.

The expression π(o, o′) designates a set of objects {o′}, such that each object o′ of the set is a part of the object o expressed by some edge e ∈ π such that e(o, o′). For example, test script statements may be considered strategies that define strategy graph edges a<img id="CUSTOM-CHARACTER-00004" he="2.46mm" wi="2.46mm" file="US08458662-20130604-P00004.TIF" alt="custom character" img-content="character" img-format="tif" orientation="portrait" inline="no" />b and a<img id="CUSTOM-CHARACTER-00005" he="2.46mm" wi="2.46mm" file="US08458662-20130604-P00005.TIF" alt="custom character" img-content="character" img-format="tif" orientation="portrait" inline="no" />b for test script statements Window(“a”).VBWindow(“b”) and Window(“a”).VBWindow(“b”).property(“ReadOnly”), respectively. Thus, a strategy is an abstraction of test script statements, as well as an abstraction of a set of paths in a type graph.

For example, a type graph of an organizational structure of a company may include: a CEO as a root type of some GUI object that contains the GUI object stock of type integer and aggregates type CTO. CTO is a type that has GUI objects salary of type Check and boss of type CEO. Type Check has in turn fields amount of type float and issuer of type CEO. A strategy CEO<img id="CUSTOM-CHARACTER-00006" he="2.46mm" wi="2.46mm" file="US08458662-20130604-P00004.TIF" alt="custom character" img-content="character" img-format="tif" orientation="portrait" inline="no" />α1<img id="CUSTOM-CHARACTER-00007" he="2.46mm" wi="2.46mm" file="US08458662-20130604-P00004.TIF" alt="custom character" img-content="character" img-format="tif" orientation="portrait" inline="no" />α2<img id="CUSTOM-CHARACTER-00008" he="2.46mm" wi="2.46mm" file="US08458662-20130604-P00005.TIF" alt="custom character" img-content="character" img-format="tif" orientation="portrait" inline="no" /> amount for the test script statement:

Window(“CEO”).Window(strex1).Window(strexp2).property(“amount”) for the type graph described above designates strategy S, where s=CEO, d=amount, α1 is a variable designating objects computed via string expression strexp1, and α2 is a variable designating attribute object computed via string expression strexp2. Computing π(CEO, o′) the type {CTO} is obtained, and computing π(CTO, o′) the types {CEO,check} are obtained.

Each node in a strategy is assigned a distinct sequence number, and nodes are expressed as pairs (i, π). Given functions Δi: N×N→δ and Δπ: π×π→δ and two sequential natural numbers k and k+1, the function Δi computes the transition edge between nodes that are assigned these numbers in S, and Ø if there is no transition edge. Correspondingly, given two nodes π_qand π_rin some type graph, function Δπ computes the transition edge between nodes, and Ø if there is no transition edge.

When the values of string expressions in test scripts statements cannot be computed until run-time, the string expressions may be inferred. The path traversal logic <b>824</b> and the economic cost model logic <b>196</b> work together to analyze test script statements vectors <b>816</b>, using type graphs by transforming test script statements vectors <b>816</b> into an adaptive strategy with variables replacing string expressions. The economic cost model logic <b>196</b> computes possible values for each variable and generates traversal paths for each strategy. Where at least one path is identified, then a corresponding GAP change specifier <b>184</b> is validated and/or a synthetic GAP change specifier <b>185</b> is generated, since values of expressions that compute names of objects may not be in the computed paths.

The path traversal logic <b>824</b> identifies one or more possible paths, while the economic cost model logic <b>196</b> validates paths for the expressions and statements. The economic cost model logic <b>196</b> computes the set of edges e for each pair of classes c and c′, by computing FIRST(c, c′) where an object of type c exists that can reach an object of type c′ by a path beginning with an edge e. Recall from above that FIRST(c, c′)=e ∈ E, such that there exists an object graph O of C and objects o and o′ such that: 1) Class(o)=c; 2) Class(o′)=c′; and 3) o e* o′.

The last condition, o e* o′ says that there is (<img id="CUSTOM-CHARACTER-00009" he="3.13mm" wi="1.78mm" file="US08458662-20130604-P00001.TIF" alt="custom character" img-content="character" img-format="tif" orientation="portrait" inline="no" />) a path from o to o′ in the object graph, consisting of an edge labeled e, followed by any sequence of edges in the graph. In one implementation, the method FIRST is implemented using two sets of logic: path traversal logic <b>824</b> and GUI class rules logic <b>828</b>.

The path traversal logic <b>824</b> takes the set R of source and destination components in S and set π as input parameters. The path traversal logic <b>824</b> outputs a tree of valid paths in a type graph that satisfy a given strategy. Some of the input components may not make it into the path tree because they do not start any valid paths.

In one implementation, the path traversal logic <b>824</b> invokes the economic cost model logic <b>196</b>, which in turn recursively calls itself. The economic cost model logic <b>196</b> uses three parameters: a component o that is a potential current node in the path, sequence number i of the node in the strategy S, and the transition edge δ between nodes in S that are assigned two sequential natural numbers i and i+1. The goal of the GUI class rules logic <b>828</b> is to color the potential current node o in the path as either red or blue. Where colored red object o is considered a dead end on the path in the type graph that does not lead to the designated destination nodes. Otherwise, the node is colored blue and this color is propagated up to the source nodes which are subsequently included in the path tree.

The economic cost model logic <b>196</b> completes when the sequence number i is equal to or the greater of the number of nodes in the strategy, |π|, and/or where there is no transition edge from the current node. When the economic cost model logic <b>196</b> completes, the economic cost model logic <b>196</b> colors the current node blue. In the calling procedure the color of the node is checked, and where the node is blue, then node is attached to its parent node in the path tree.

In one implementation, the economic cost model logic <b>196</b> computes the set of edges e for each pair of classes c and c′, where an object of type c is identified that can reach an object of type c′ by a path beginning with an edge e. The logic is applied individually to each test script statement vector <b>816</b> in which foreign GAP objects are specified using string expressions whose values are not known before the current test script <b>164</b> is executed. The economic cost model logic <b>196</b> infers possible names of foreign objects that string expressions may evaluate to at runtime.

<tables id="TABLE-US-00009" num="00009"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 9</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Path Traversal and GUI class rules logic</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="28pt" align="left" /><colspec colname="2" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry> Path traversal logic (R ε S, π ε S)</entry></row><row><entry /><entry>for all s ε R do</entry></row><row><entry /><entry> economic cost model logic (s, 0, Δi(0,1))</entry></row><row><entry /><entry> if color(s) = red then</entry></row><row><entry /><entry> remove s from R</entry></row><row><entry /><entry> end if</entry></row><row><entry /><entry>end for</entry></row><row><entry /><entry>economic cost model logic (o ε O, i ε N, <img id="CUSTOM-CHARACTER-00010" he="2.46mm" wi="1.44mm" file="US08458662-20130604-P00006.TIF" alt="custom character" img-content="character" img-format="tif" orientation="portrait" inline="no" />   ε δ)</entry></row><row><entry /><entry>if i ≧|π| or <img id="CUSTOM-CHARACTER-00011" he="2.46mm" wi="1.44mm" file="US08458662-20130604-P00006.TIF" alt="custom character" img-content="character" img-format="tif" orientation="portrait" inline="no" />  = Ø then</entry></row><row><entry /><entry> color(o) <img id="CUSTOM-CHARACTER-00012" he="2.12mm" wi="2.46mm" file="US08458662-20130604-P00007.TIF" alt="custom character" img-content="character" img-format="tif" orientation="portrait" inline="no" />  blue</entry></row><row><entry /><entry>else</entry></row><row><entry /><entry> for all o′ ε πi(o, o′) do</entry></row><row><entry /><entry> if Δπ(o,o′) = <img id="CUSTOM-CHARACTER-00013" he="2.46mm" wi="1.44mm" file="US08458662-20130604-P00006.TIF" alt="custom character" img-content="character" img-format="tif" orientation="portrait" inline="no" />  then</entry></row><row><entry /><entry>  economic cost model logic (o′, i + 1, Δi(i, i + 1))</entry></row><row><entry /><entry>  if color(o′) = blue then</entry></row><row><entry /><entry>  AddChildToTree(o, o′)</entry></row><row><entry /><entry>  end if</entry></row><row><entry /><entry> end if</entry></row><row><entry /><entry> end for</entry></row><row><entry /><entry> if children(o) = Ø then</entry></row><row><entry /><entry> color(o) <img id="CUSTOM-CHARACTER-00014" he="2.12mm" wi="2.46mm" file="US08458662-20130604-P00007.TIF" alt="custom character" img-content="character" img-format="tif" orientation="portrait" inline="no" />  red</entry></row><row><entry /><entry> else</entry></row><row><entry /><entry> color(o) <img id="CUSTOM-CHARACTER-00015" he="2.12mm" wi="2.46mm" file="US08458662-20130604-P00007.TIF" alt="custom character" img-content="character" img-format="tif" orientation="portrait" inline="no" />  blue</entry></row><row><entry /><entry> end if</entry></row><row><entry /><entry>end if</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

Often the same string expressions are used in different statements in the same scripting scope. The same expressions compute the same values, where the expressions are located in the same scope, provided that the values of the variables used in these expressions are not changed. Using program analysis techniques the path traversal logic <b>824</b>, and the economic cost model logic <b>196</b> work together to detect expressions at compile time whose variables are not changed at run-time. The path traversal logic <b>824</b> identifies one or more possible names of foreign GUI objects that may be substituted for string expressions in test script statements. While the economic cost model logic <b>196</b> identifies from among the possible names of foreign GUI objects, valid GUI objects. Given the same expression used in different test script statements in the same script scope, and provided that the values of the variables used in these expressions are not changed by other expressions executed between these statements, the economic cost model logic <b>196</b> identifies a set of names of foreign GUI objects computed by these string expressions. This set of GUI objects is obtained by taking the intersection of the sets of names computed by the path traversal logic <b>824</b>.

For example, consider the strategy graph S<b>1</b> CEO<img id="CUSTOM-CHARACTER-00016" he="2.46mm" wi="2.46mm" file="US08458662-20130604-P00004.TIF" alt="custom character" img-content="character" img-format="tif" orientation="portrait" inline="no" />α1<img id="CUSTOM-CHARACTER-00017" he="2.46mm" wi="2.46mm" file="US08458662-20130604-P00004.TIF" alt="custom character" img-content="character" img-format="tif" orientation="portrait" inline="no" />α2<img id="CUSTOM-CHARACTER-00018" he="2.46mm" wi="2.46mm" file="US08458662-20130604-P00005.TIF" alt="custom character" img-content="character" img-format="tif" orientation="portrait" inline="no" /> amount for the type graph for the test script statement expression: Window(“CEO”).Window(strexp1).Window(strexp2).property(“amount”). The economic cost model logic <b>196</b> computes values for type scheme variables α1={CTO} and α2={boss, salary}.

Suppose a different strategy graph S<b>2</b> exists, where Programmer<img id="CUSTOM-CHARACTER-00019" he="2.46mm" wi="2.46mm" file="US08458662-20130604-P00004.TIF" alt="custom character" img-content="character" img-format="tif" orientation="portrait" inline="no" />α2<img id="CUSTOM-CHARACTER-00020" he="2.46mm" wi="2.46mm" file="US08458662-20130604-P00005.TIF" alt="custom character" img-content="character" img-format="tif" orientation="portrait" inline="no" />bonus for y[“Programmer”][strexp2].attribute(“bonus”) for some other type graph. Notice that the string expression variable strexp2 is the same in both statements, and because of that the string expression variable strexp2 is designated by the same type scheme variables in both the strategy graphs. Suppose that by applying the path traversal logic <b>824</b> that values for type scheme variable α2={salary} are computed. In one implementation, in order to determine the value of variable α2 that satisfies both S<b>1</b> and S<b>2</b>, the economic cost model logic <b>196</b> identifies the intersection of the sets of values of α2 computed for these two strategies. The resulting set α2={salary} is the result of pruning the navigation paths.

This example illustrates the idea of pruning navigation paths using context-sensitive dataflow analysis that may be used by the economic cost model logic <b>196</b>. By determining definitions and uses of a variable that designate names of GUI objects in a given scope, sets of values are computed for each transformed test script statement in which a variable is used. Then the intersection of these sets is taken to determine common values that this variable can take in the scope considered.

The economic engine system <b>800</b> provides modularization integrity as a mechanism for ensuring the validity of GAP change specifiers <b>184</b> and/or synthetic GAP change specifiers <b>185</b>. Modularization integrity specifies that each current test script statement identified by a GAP change specifier <b>184</b> and/or a synthetic GAP change specifier <b>185</b> to be changed may only communicate directly with the objects that belong to GUIs for which the current test script statement, as changed by the GAP change specifier <b>184</b> and/or a synthetic GAP change specifier <b>185</b>, is created. Compositions of current test script statements changed as specified by GAP change specifiers <b>184</b> and/or synthetic GAP change specifiers <b>185</b>, in which GUI objects are accessed by calling functions exported by the current test script statements changed as specified, should not violate modularization integrity. The economic engine system <b>800</b> ensures the modularization integrity of GAP change specifiers <b>184</b> and/or synthetic GAP change specifiers <b>185</b> by analyzing compositions of current test script statements changed as specified by GAP change specifiers <b>184</b> and/or synthetic GAP change specifiers <b>185</b> to build the transitive relations between the current test script <b>164</b> and the current test script <b>164</b> changed as specified by the GAP change specifiers <b>184</b> and/or synthetic GAP change specifiers <b>185</b>.

For example, a statement Func(“y”, “z”), found in a suite of related test scripts, navigates to the field z of foreign GUI object y in some test scripts that export function Func. Thus, the some test scripts in the suite of related test scripts may violate the modularization integrity by implicitly interoperating the test scripts via the function Func even though this communication may be prohibited by the constraints of a given test suite. In one implementation, the economic engine system <b>800</b> encodes modularization constraints when defining test scripts using the keyword constraints as part of a global comment in each test script. These constraints define GAPs and their GUI screens as well as other test scripts with which a given test script may communicate. An example is a statement that specifies a constraint is constraints screen(“Q”) test_scripts(“P, S”). This constraint effectively prohibits a given test script from communicating with other GAPs, GUI screens, and test scripts, except the screen Q and test scripts P and S, explicitly or implicitly.

The time complexity of the path traversal logic <b>824</b> and the economic cost model logic <b>196</b> is exponential to the size of the type graph for each test script <b>164</b>. Because the path traversal logic <b>824</b> and the economic cost model logic <b>196</b> involve the search of one or more nodes and edges in the type graph that contains cycles for each node in the strategy, the time complexity is O((V+E)^max(|π|)) where V is the number of nodes, E is the number of edges in the type graph, and max(|π|) is the maximum number of nodes in strategies. The operations of storing successors in the table of variables take O(1). In general, the number of nodes max(|π|) in strategies is much smaller than the number of nodes in type graphs. All graph nodes may not need to be explored for each node in a strategy.

The systems may be implemented in many different ways. For example, although some features are shown stored in computer-readable memories (e.g., as logic implemented as computer-executable instructions or as data structures in memory), all or part of the systems, logic, and data structures may be stored on, distributed across, or read from other machine-readable media. The media may include hard disks, floppy disks, CD-ROMs, a signal, such as a signal received from a network or partitioned into sections and received in multiple packets communicated across a network. The systems may be implemented in software, hardware, or a combination of software and hardware.

Furthermore, the systems may be implemented with additional, different, or fewer components. As one example, a processor or any other logic may be implemented with a microprocessor, a microcontroller, a DSP, an application specific integrated circuit (ASIC), program instructions, discrete analog or digital logic, or a combination of other types of circuits or logic. As another example, memories may be DRAM, SRAM, Flash or any other type of memory. The systems may be distributed among multiple components, such as among multiple processors and memories, optionally including multiple distributed processing systems. Logic, such as programs or circuitry, may be combined or split among multiple programs, distributed across several memories and processors, and may be implemented in or as a function library, such as a dynamic link library (DLL) or other shared library.

While various embodiments have been described, it will be apparent to those of ordinary skill in the art that many more embodiments and implementations are possible within the scope of the invention. Accordingly, the invention is not to be restricted except in light of the attached claims and their equivalents.