Users access application processes located on server computers using client computers. Such application processes include web applications. A user's experience depends on the performance of the application when deployed and accessed by the user. Thus, performance testing of the application is important to determine how an application may function when deployed and to make necessary corrections to defects. Test scripts are used to implement testing of applications.
Various embodiments described below were developed to generate enhanced test scripts for application testing. The enhanced test scripts may be used to perform load testing, functional testing, or application programming interface (API) testing. The disclosed embodiments provide enhanced or augmented test scripts that accurately represent real user activity or interaction with an application.
There are numerous challenges to building test scripts for performance testing of applications. One of such challenges is building test scripts that accurately reflect real user activity. Typically, information available for building test scripts include a list of hits and corresponding frequency that represent flows a user goes through when interacting with the application. However, this information is not sufficient to create a realistic test script. User activity in an application comprises multiple paths taken through the application and recreating the different paths in a manner that enables effective testing may be complex. To illustrate the complexity and challenges involved, consider an example application such as an online store web application. The online store may include a login page, an item search page, a view item details page, a checkout page, an add item page, a log-off page, and many more pages. Users may traverse these pages in completely different manners and the manner in which pages are viewed or traversed may constitute completely different business processes. For example, a customer user may login, search for an item, view item details, proceed to checkout, and then log off. Alternately, or in addition, some other customer users may complete a similar purchasing flow without logging off and others may complete the purchase without viewing item details. Further, an administrator user may occur in parallel, where the administrator user may login, add a new item, and then perform a search to verify that the new item shows up. Thus, this example online store application may include a diverse range of users and flows. Moreover, other application may include even more complex number of users and flows.
Basic test scripts may include a series of uniform resource locator (URL) requests that comprise these flows. However, these URL sequences do not provide a working script as they lack script enhancements such as correlations and asynchronous data. Accordingly, the disclosed embodiments describe automatically generating enhanced test script that include correlation data and asynchronous data for accurately testing applications, where real user activity/interaction with the application is accounted for. In addition, the enhanced test scripts are further augmented with advanced pattern matching algorithms to identify parameterization rules, pre-defined correlation rules, pre-defined asynchronous rules, and replacement and adaptation rules for adapting the enhanced test scripts to that of the testing environment. The automated enhanced test scripts, when compared to basic test scripts, provide robust testing of applications.
An example implementation includes receiving production data reflecting real user interaction with an application process and generating test scripts based on the production data, where the generated test scripts simulate behavior relating to execution of the application process. The implementation also includes automatically enhancing the generated test scripts with dynamic data including at least one of correlation data and asynchronous data. The correlation data identifies communication between at least one client computer and a server computer and the asynchronous data includes asynchronous data of a plurality of execution instances of the application process.
The following description is broken into sections. The first, labeled “Environment,” describes an example of a network environment in which various embodiments may be implemented. The second section, labeled “Components,” describes examples of physical and logical components for implementing various embodiments. The third section, labeled “Operation,” describes steps taken to implement various embodiments.
Environment:
In the example of
Components:
Production data extraction engine 202 represents generally any combination of hardware and programming configured to extract production data. The production data reflects real user interaction with application 208. For example, production data extraction engine 202 may record real user activity with the application 208. The production data may include user input, client device 108 generated data, server device 106 generated data, or any combination thereof. To illustrate, production data extraction engine 202 may monitor interaction and traffic between the user (e.g., via client device 108) and server device 106 to extract network traffic data and network load, user click streams, user sessions and process flows (i.e., streams of pages and a user navigates when interacting with application 208), and combination of processes at different times. Thus, production data extraction engine 202 monitors interaction between the user and application 208 to learn behavior or the user and corresponding responses (and behavior) of the application. The extracted production data may be analyzed to produce network load data, performance statistics and metrics (e.g., standard deviation, maximum, minimum, etc), think time (e.g., application response times), and other user and application related performance data. The extracted production data may be stored in data store 104. In one example, production data may be retrieved or received from data store 104. In this example, production data may include previously extracted and stored production data or historical production data for application 208 or another application.
Test script generation engine 204 represents generally any combination of hardware and programming configured to generate test scripts based on the production data, where the test scripts simulate behavior relating to execution of the application process. Further, the test scripts may simulate behavior relating to execution of a plurality of execution instances of the application process. For example, the generated test scripts (e.g., a transport script) may simulate traffic behavior associated with traffic exchange between a client device 108 (or a plurality of client devices 108) and the application process 208 during execution of the application process. The generated test scripts also simulate user behavior to allow a determination of performance of the application process 208 (e.g., application process is running slowly, downtime is experienced, or some other fault or error is present).
Test script enhancement engine 206 represents generally any combination of hardware and programming configured to automatically enhance the generated test scripts with dynamic data, where the dynamic data includes at least one of correlation data and asynchronous data.
Correlation data includes data that is generated by server device 106 and communicated to client device 108 during interaction between the client device 108 and the application process 208 in the server device 106. Correlation data server-generated data) that is provided to the client device 108 may include data that is useable by the server device 106 to associate a particular communication with a given instance of the application process 208. For example, correlation data may include a session identifier for identifying a particular session between the client device 108 and the application process 208 in the server device 106. In other examples, other identifiers relating to communication flow may be used. Further, correlation data may include authentication data that is generated by server device 106 and communicated to client device 108 to allow the client device 108 to use the authentication data for subsequent communications with the application process 208. Thus, the correlation data may include response based correlation (e.g., responses from server device 106 to requests by client device 108). Moreover, static requests by client device 108 may be substituted with parameters that are calculated and generated at runtime from the response data.
Test script enhancement engine 206 may identify correlation data usable to enhance the test scripts. For example, identification of correlation data may be based on correlation rules such as a set of patterns. Thus, data matching the patterns in the set may identified as correlation data. Other examples of identifying correlation data include response-based correlation technique, where information that first arrived from the server device 106 and was later returned to the server device 106 by client device 108 is identified. Moreover, correlation data may be identified using a replay-and-scan technique, where an execution instance of an application process is recorded once, and the corresponding generated script is produced and replayed. When the replay of the script fails, the replay-and-scan technique attempts to look for correlation data by comparing the recorded data to the replayed data until a failure point is identified. It should be noted that other correlation data identification techniques may be implemented by the test script enhancement engine 206.
Asynchronous data includes asynchronous data from a plurality of execution instances of the application process 208. For example, application process 208 may asynchronously provide data that is continually changing to client device 108 (e.g., updated information such as sport scores, news, stock prices, election votes, etc.). Test script enhancement engine 206 may identify asynchronous data usable for enhancing the test script using one or more techniques. For example, a rule-based technique may be implemented to identify asynchronous data, where predefined patterns can be defined and matched to recorded data for the purpose of identifying asynchronous data. As another example, classification-based technique may be implemented, where the time and content of network traffic that was generated by the client device 108 and the server device 106 during an execution instance of the application process 208 is measured. The measured time and content may then be classified to identify asynchronous data. Further, test script enhancement engine 206 may be configured to run asynchronous pattern recognition algorithms to accurately recreate asynchronous calls. For example, recognizing poll and push patterns and replacing different separate requests with special API calls that result in the recreation of asynchronous patterns during script replay.
Test script enhancement engine 206 may also be operable to augment the enhanced test scripts with pattern matching algorithms, pre-defined correlation rules, pre-defined asynchronous rules, and testing environment replacement and adaption rules. Test script enhancement engine 206 may include other enhancement and augmenting data and make necessary adjustments to adapt the enhanced test script to the testing environment and to insert the enhanced test script to the testing environment. For example, the adaption and adjustments may be required to run the enhanced test script for a particular application, a particular server device 106, or any combination thereof. The testing environment may include functional testing, API testing, load testing, some other type of testing, or any combination thereof.
In foregoing discussion, engines 202-206 of
In one example, the program instructions can be part of an installation package that when installed can be executed by processor 304 to implement system 102. In this case, computer-readable storage medium 302 may be a portable medium such as a CD, DVD, or flash drive or a memory maintained by a server from which the installation package can be downloaded and installed. In another example, the program instructions can be part of an application or applications already installed. Here, computer-readable storage medium 302 can include integrated memory such as hard drive, solid state drive, or the like.
In
Operation:
In
Method 400 also includes step 430, where test scripts based on the production data are generated. The test scripts simulate behavior relating to execution of the application process. Referring to
Method 400 may proceed to step 440, where the generated test scripts are automatically enhanced with dynamic data that includes at least one of correlation data and asynchronous data. Referring to
Embodiments can be realized in any computer-readable medium for use by or in connection with an instruction execution system such as a computer/processor based system or an ASIC (Application Specific Integrated Circuit) or other system that can fetch or obtain the logic from computer-readable medium and execute the instructions contained therein. “Computer-readable medium” can be any individual medium or distinct media that can contain, store, or maintain a set of instructions and data for use by or in connection with the instructions execution system. A computer-readable medium can comprise any one or more of many physical, non-transitory media such as, for example, electronic, magnetic, optical, electromagnetic, or semiconductor device. More specific examples of a computer-readable medium include, but are not limited to, a portable magnetic computer diskette such as floppy diskettes, hard drives, solid state drives, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory, flash drives, and portable compact discs.
Although the flow diagram of
The present invention has been shown and described with reference to the foregoing exemplary embodiments. It is to be understood, however, that other forms, details and embodiments may be made without departing from the spirit and scope of the invention that is defined in the following claims.
Number | Name | Date | Kind |
---|---|---|---|
5754760 | Warfield | May 1998 | A |
6549944 | Weinberg et al. | Apr 2003 | B1 |
6792393 | Farel et al. | Sep 2004 | B1 |
6957420 | Hand et al. | Oct 2005 | B2 |
7039899 | Quiroga | May 2006 | B1 |
7185235 | Radestock | Feb 2007 | B2 |
7272753 | Kaplan et al. | Sep 2007 | B2 |
7389216 | Parent et al. | Jun 2008 | B2 |
7587637 | Garakani | Sep 2009 | B2 |
7752607 | Larab et al. | Jul 2010 | B2 |
7757175 | Miller | Jul 2010 | B2 |
8522083 | Cohen et al. | Aug 2013 | B1 |
8522214 | Roth | Aug 2013 | B2 |
8533531 | El Mahdy et al. | Sep 2013 | B2 |
8762113 | Santhosh et al. | Jun 2014 | B2 |
8914679 | Apostoloiu et al. | Dec 2014 | B2 |
20030074606 | Boker | Apr 2003 | A1 |
20060129892 | Diaconu et al. | Jun 2006 | A1 |
20060285665 | Wasserblat et al. | Dec 2006 | A1 |
20080244322 | Kelso | Oct 2008 | A1 |
20080244523 | Kelso | Oct 2008 | A1 |
20080244524 | Kelso | Oct 2008 | A1 |
20090254329 | Thakkar | Oct 2009 | A1 |
20100153087 | Kirtkow et al. | Jun 2010 | A1 |
20100153780 | Kirtkow et al. | Jun 2010 | A1 |
20110145795 | Khanapurkar et al. | Jun 2011 | A1 |
20110271284 | Simonian | Nov 2011 | A1 |
20110314341 | Varadharajan | Dec 2011 | A1 |
20130132774 | Somendra | May 2013 | A1 |
20130282354 | Sayers et al. | Oct 2013 | A1 |
20140033179 | Gustus et al. | Jan 2014 | A1 |
Entry |
---|
The Complete Testing Solution for E-business 2002. |
M. Tomlinson, “How To: Correlate Dynamic Data in a Load Test Transaction”, retrieved Apr. 30, 2012, https://perftesting.codeplex.com/wikipage?title=How%20To%3A%20Correlate%20Correlate%20Dynamic% 20Data%20in%20a%20Load%20Test%20Transaction. |
Number | Date | Country | |
---|---|---|---|
20140040667 A1 | Feb 2014 | US |