FORM 2
THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENTS RULES, 2003
COMPLETE SPECIFICATION
(See section 10, rule 13)
1. Title of the invention:
PERFORMANCE AND LOAD TESTING SYSTEM
2. Applicant(s)
NAME NATIONALITY ADDRESS
TATA CONSULTANCY Nirmal Buolding, 9th Floor, Nariman Point,
Indian
SERVICES LIMITED Mumbai -400021, Maharashtra, India
3. Preamble to the description
COMPLETE SPECIFICATION
The following specification particularly describes the invention and the manner in which it is to be performed.

FIELD OF INVENTION
The present subject matter, in general, relates to application testing and, in
particular, to performance and load testing of applications.
BACKGROUND
Programs and applications running on a system are tested either on a periodical
basis or after each substantial revision of the program to determine performance of the system under different load patterns. These types of tests are usually referred to as load tests, scalability tests, and stress tests. These tests are designed to test real-world type scenarios by testing the reliability, robustness, performance and scalability of the application.
Web-based systems such as web applications that can retrieve, present and traverse information resources may also be tested through such tests. In general, the time taken, by such systems to service the user requests determines the performance of the web-based systems. The performance can become critical when web systems need to process large volumes of requests at a given point in time, creating a performance bottleneck. Hence, performance tools can test the performance of the web-based systems under load by measuring identified performance indicators, for example, time taken to process the user requests and so on.
Conventionally, the testing used to validate and verify the system's scalability, or
reliability under varied loads and conditions is carried out at different stages and by utilizing numerous tools. Examples of commonly used testing tools include a benchmarking tool, a profiling tool, a working set tool, a communication tracking tool, a file monitoring tool, a legistry monitor, and a network latency tool. On the other hand, open source tools for load and performance testing provide limited functionalities. The testing of a program or an application is also extended for a variety of end purposes, such as to compare two differently-configured systems to find which configuration performs better; or to measure parts of the system or types of workload which are likely to cause the system to perform in an unexpected mariner.
SUMMARY
This summary is provided to introduce concepts related to performance and load
testing of applications. This summary is not intended to identify essential features of the claimed

subject matter nor is it intended for use in determining or limiting the scope of the claimed subject matter.
Embodiments of a system to perform load and performance testing of applications
are described. The method for load and performance testing of the application may include receiving at least one testing parameter associated with load and performance testing of an application, wherein the at least one testing parameter is configurable. The method may further include simulating virtual load based on the at least one testing parameter and profiling the application while simulating virtual load to determine hot spots in the application, where the hotspots are indicative of functions with execution time greater than a pre-defined threshold. The method may also include identifying bottlenecks associated with the application based on the simulated virtual load and in part on the profiling of the application.
BRIEF DESCRIPTION OF THE FIGURES
The detailed description is described with reference to the accompanying figures.
In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The same numbers are used throughout the figure to reference like features and components. Some embodiments of system and/or methods in accordance with embodiments of the present subject matter are now described, by way of example only, and with reference to the accompanying figure, in which:
Fig. 1 schematically illustrates a system for end-to-end load and performance
testing of applications, in accordance with an embodiment of the present subject matter; and
Fig. 2 illustrates a method for end-to-end load and performance testing of an
application, in accordance with an embodiment of the present subject matter.
It should be appreciated by those skilled in the art that any block diagrams herein
represent conceptual views of illustrative systems embodying the principles of the present subject matter. Similarly, it will be appreciated that any flow charts, flow diagrams, state transition diagrams, pseudo code, and the like represent various processes which may be substantially represented in computer readable medium and so executed by a computer or processor, whether or not such computer or processor is explicitly shown.

DETAIL DESCRIPTION OF DRAWINGS
Systems for end-to-end load and performance testing of applications are described
herein. In one implementation, the end-to-end load and performance testing include, but are not limited to, scheduling of transaction requests received by an application from one or more servers, profiling of the application's program code, application's load testing, and reporting of performance results. In one implementation, such systems can be implemented in a variety of computing-based devices, such as a desktop computer, a notebook, or a mobile computing environment like a smart phone, a PDA or other such mobile devices.
Generally, for load and performance testing purposes, a number of industry
standard tools and methods are utilized. Such tools and methods typically cater to applications supporting a particular platform, such as mobile platform, web platform, or cloud platform, and offer limited functionalities. Methods used for the purpose of load and performance testing require use of multiple tools to perform different testing functions. For example, tools implemented to test the load and performance might be different from the tools implemented to profile the program code. Similarly, the tools utilized for the purpose of scheduling are separate from the tools required to collect and analyze the load testing data. Furthermore, the tools to test the load and performance of software applications have different functional implementation than the tools implemented to test web applications.
Typically, the standard industry testing tools are designed to load test functional
behavior and measure the performance of applications. The tools are used to simulate load on a server, network or object to test the applications strength and to analyze overall performance under different load types. For example, an application may cater to multiple users utilizing the functionality of the application concurrently. To test such an application, the testing tools may simulate a load of a specific number of transactions within the set duration and analyze the performance of the application.
Alternatively, open source testing tools are available to provide capability of
performance testing for free of cost. However, such open source testing tools do not provide enhanced capabilities for testing applications under different and varied conditions. Also the open source tools lack extensive support and the ability to scale up for load and performance testing purposes. On the other hand, the standard industry testing tools, which provide enhanced

capabilities, are expensive both in terms of their development and licensing. Moreover, industry standard testing tools with enhanced capabilities to test an application are field specific and multiple packages need to be integrated together to form a unified framework for optimized and effective end-to-end performance testing.
During the process of load and performance testing of an application, it is desired
to profile the program code of the software application, or profile the communication of web services and web applications to determine bottlenecks. The identification of bottlenecks at the time of load and performance testing may provide the capability to the developers to built scalable applications. Further, during testing, it is desired to be able to scale the virtual user load to multiple thousands to examine the performance of the applications at extreme conditions and adverse work environments,
Also, the testing of software applications and web service are based on the testing
parameters that are pre-defined and available to a testing tool. The testing parameters may include the configuration parameters, profiling parameters, scheduling parameters, performance control parameters, and the like. Various testing methods carry out load and performance testing based on such pre-defined testing parameters which can be carried out in a definite format that may vary from one testing tool to the other.
Furthermore, the ability of testing web services using tools capable of testing
software applications may provide a complete testing platform capable of analyzing web services along with software applications. The capability of testing tools to perform load test for web services can provide with different functionality bottlenecks which upon identification can be eliminated by the developers to improve the performance of the entire application.
A system to perform end-to-end load and performance testing with capability to
scale up the virtual user load to multiple thousands, profile the software application programme code during load testing, load test web services, and generate detailed and comprehensive reports in user friendly formats is described herein. The system can be implemented in a variety of devices. The devices include, but are not limited to, desktop computers, hand-held devices, laptops or other portable computers, mobile phones, and the like.
In one implementation, the system performs end-to-end load and performance
testing. The system is configured to manage tasks related to the load and performance testing.

For example, for load testing of a web application, the servers may be allocated and initiated to receive requests corresponding to the web application by the system. In another implementation, the system may test the performance of the application based on the ability of the application to cater to multiple user requests and its load handling capabilities. For this purpose, the system may simulate virtual users. In said implementation, each virtual user may be configured to perform certain transaction which may increase the load on the application, its server processing capabilities, and its request handling efficiency.
For example, to test the load of an application, the load and performance testing
system may simulate m virtual users. Each of the m virtual users may send at least one transaction request to the application. In such a scenario, the application will utilize certain percentage of its capability to cater to different request from multiple concurrent users. Any new user sending a new request would in turn increase the resource utilization percentage of the application, and would effectively decrease the further load handling capability of the application.
According to one implementation, the load and performance testing of an
application is based on the testing parameters where the testing parameters are configurable. The testing parameters may be based on Extensible Markup Language (XML) where using the XML, the testing parameters are configured based on the testing requirement of the application, for example, the level of load to be generated for the application, the duration of the load and performance testing, the number of parallel users to be initiated, the number of transactions to be requested per unit time, and the like.
The system for load and performance testing not only simulates the environment
of virtual users generating load for the application according to industry standards, but also scales up the virtual user load to multiple of thousands. The scaling of virtual load to multiple of thousands allows the load and performance testing of the application under extreme load conditions. In such an environment, the results of the load handling capability of the application may provide with a more descriptive ability of the application to handle load. With such a determination, the developers may be enabled towards building more scalable application.
In another implementation, the profiling of a program code of an application is
done. During the testing process, the program path of the application may be monitored to

determine the bottleneck in the entire path. Based on the bottlenecks determined, the hot spots in the application can be identified. The identification of bottlenecks again provides the ability to developers to build efficient and scalable applications. In one implementation, the load and performance testing of web services is also done.
Further, in one implementation, the physical resources required for the testing of
the application are managed remotely based on the scheduling of transaction requests. The system which may run the application to be tested may contain different processing servers to handle concurrent user requests. During the load and performance testing, the testing system may simulate multiple thousands of virtual users and initiate several different transaction requests. In such a scenario, the load and performance testing system may schedule to generate the transaction requests from different servers depending upon the processing capability of each Individual server. It would be understood by those skilled in the art that in said implementation, the scheduling of transaction requests is done remotely by the system for load and performance testing and no physical login or authorization is required by the application hosting servers for scheduling purposes.
Additionally, the data generated during the load and performance testing of the
application is collected and a report reflecting the load and performance results is generated. In one implementation, the report may include the performance counters, details of profiling and latency over varied load conditions, values and metrics of performance data, and other results. In said implementation, the report may include the above mentioned data in the form of charts and graphs to represent the load and performance results of the application in pictorial form. Further, the reporting of the data can also be done in user friendly formats, such as 'pdf, 'excel sheet', 'word document', etc. It would be understood that the load and performance testing results can be crucial for further analysis and tuning of the overall application system.
It should be noted that the description merely illustrates the principles of the
invention. It will thus be appreciated that those skilled in the art will be able to devise various arrangements that, although not explicitly described herein, embody the principles of the invention and are included within its spirit and scope. Furthermore, all examples recited herein are principally intended to express concepts only for pedagogical purposes to aid the reader in understanding the principles of the invention and the concepts contributed by the inventor(s) to

furthering the art, and are to be construed as being without limitation to such specifically recited examples and conditions. Moreover, all statements herein reciting principles, aspects, and embodiments of the invention, as well as specific examples thereof, are intended to encompass equivalents thereof.
The manner in which the systems for load and performance testing are
implemented shall be explained in details with respect to the Fig. 1. While aspects of described systems for load and performance can be implemented in any number of different computing systems, environments, and/or configurations, the embodiments are described in the context of the following exemplary system(s).
Fig. 1 illustrates exemplary components of the load and performance testing
System 102, according to an implementation of the present subject matter. The load and performance testing system 102 includes interface(s) 104, one or more processor(s) 106, and a memory 108 coupled to the processor(s) 106.
The interface(s) 104 may include a variety of software and hardware interfaces,
for example, interfaces for peripheral device(s), such as a keyboard, a mouse, an external memory, and a printer. Further, the interface(s) 104 may enable the load and performance testing system 102 to communicate with other computing systems, such as web servers and external databases. The interface(s) 104 can facilitate multiple communications within a wide variety of networks and protocol types, including wired networks, for example, local area network (LAN), cable, etc., and wireless networks, such as Wireless LAN (WLAN), cellular, or satellite. For the purpose, the interface(s) 104 may include one or more ports for connecting a number of (computing systems to each other or to another server computer.
The processor(s) 106 can be a single processing unit or a number of units, all of
which could include multiple computing units. The processor(s) 106 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the processor(s) 106 is configured to fetch and execute computer-readable instructions and data stored in the memory 108.
The memory 108 may include any computer-readable medium known in the art
including, for example, volatile memory, such as static random access memory (SRAM) and

dynamic random access memory (DRAM), and/or non-volatile memory, such as read only memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes. The memory 108 includes module(s) 110 and data 112. The module(s) 110, amongst other things, include routines, programs, objects, components, data structures, etc., which perform particular tasks or implement particular abstract data types. The data 112 serves, amongst other things, as a repository for storing data processed, received and generated by one or more of the module(s) 110.
The module(s) 110 further include, for example, a master control module 114,
load testing module 116, profiling module 118, analysis module 120, and other module(s) 122. The other modules 122 may include programs that supplement applications and functions on the Joad and performance testing system 102, for example, programs in the operating system. The rdata 112 includes data generated as a result of the execution of one or more module(s) 110. The data generated as a result of the load and performance testing is stored in performance data 124, and the report generated based on the performance data 124 is stored in the report data 126. The data 124 also includes other types of data which may be used by the load and performance testing system 102, stored in other data 128.
The load and performance testing system 102, hereinafter referred to as system
102, performs an end-to-end load and performance testing of an application and web services. The master control module 114 controls the overall execution and load testing of an application. The master control module 114 also ensures the integrity of the end-to-end load and performance testing of the application. For this purpose, the master control module co-ordinates between different modules, such as the load testing module 116, profiling module 118, and the analysis module 120.
In operation, the master control module 114 initializes the load testing module
116 for the purpose of load testing of an application. For this purpose, the master control module 114 is configured to receive testing parameters for the load and performance testing of the application. The testing parameters may include, but are not limited to, configuration parameters, profiling parameters, scheduling parameters, performance control parameters, and report generation parameters. In one implementation of the present subject matter, the master control module 114 is configured to receive the testing parameters based on XML where the testing

parameters are configurable. Based on XML, a user or an administrator may define the testing parameters and configure them according to the load and performance testing needs. For example, a user may define the testing parameters based on XML to define the load to be generated during the load testing of the application. Similarly, the user may also define other testing parameters to outline the kind of load and performance testing to be performed.
Following the initialization of testing parameters, the load testing module 116
simulates virtual users, which may perform various transactions on the application. For each transaction performed by any user, different requests are generated and processed by the application, which creates an artificial load on the application. To test the application for extreme conditions and monitor its real-time behavior, the load testing module 116 simulates virtual user to the multiple of thousands. Therefore, with increased number of users, the transactions being performed increase, which in turn increase the load on the application. The analysis module 120 monitors the performance of the application under such loads and records the performance parameters of the application. In an example, the performance parameters may include behavior of the application under varied load, its resource utilization at different load conditions, etc.
The master control module 114 is also configured to manage the physical
resources required for the testing of the application in case the simulated virtual load is generated through multiple servers. For this purpose, the master control module 114 may remotely perform the scheduling of transaction requests. The concurrent user requests may be scheduled to different servers depending upon the processing capability of each and individual server. In said implementation, the scheduling of transaction requests is done remotely by the system for load fend performance testing and no physical login or authorization is required by the application hosting servers.
In one implementation, the load testing module 116 may also create custom
scenarios while load testing an application. The application under testing may provide multiple functionalities with ability to cater to different kind of transactions, for example, an application for banking purposes may provide functionalities like account creation, account deletion, transfer of funds, fund deposit, fund withdrawal, etc. Also, as described before, during load testing of an application, the load testing module 116 simulates virtual users. Each virtual user may perform one or more transactions. The load testing module 116 is configured to create custom

transactions for different users for the purpose of load and performance testing. In the above mentioned example, one virtual user may perform a fund withdrawal transaction while another user may perform a fund deposit transaction. It would be appreciated by those skilled in the art that the custom scenarios can be user defined and can be inputted to the system 102 through the interface 104,
In one implementation, the system 102 determines the bottlenecks in the program
of the application during the process of end-to-end testing of an application. The profiling module 118 is configured to profile the program of the application by examining the time taken by the different functions of the program during execution. The master control module 114, in one implementation, may initiate the profiling module 118 at the same instance when the load Jesting module is initiated. In such a scenario, while the application is tested for different and varied loads, the profiling module 118 examines the time taken by each function of the program by going through the code path of the application.
In said implementation, the profiling module 118 may examine an inclusive as
well as an exclusive time taken by the function of the program. The inclusive time may represent the time taken by the function to complete the task, whereas the exclusive time may represent the time spent by a function waiting for inputs from other functions. Both the inclusive and exclusive time taken by a function is examined at different and varied loads, and similarly at varied and different loads, inclusive and exclusive load of each function of the program is examined. In one implementation, the profiling module 118 may store the inclusive and exclusive time of each function in performance data 124.
Based on the time taken by different functions of the program to execute requests at varied and different loads, the analysis module 120 may identify the function where the program execution takes maximum time and also the function of the program which takes minimum time. The system 102 may define a threshold value based on which the analysis module 120 would identify the hotspots of the application. The functions taking time, including the inclusive and the exclusive time, greater than that of the threshold time may be marked as the hotspots of the application.
The analysis module 120 may further identify the bottleneck based on load and
performance testing and the execution time taken by different functions. The identification of

bottlenecks based on the profiling along with the load and performance testing may allow the developers to identify the exact locations of the application which can be modified or scaled to improve the performance of the complete application. In one implementation, the analysis module 120 stores the details of the identified hotspots and the bottlenecks in the performance data 124.
The analysis module 120 may generate reports based on the results of the load and
performance testing of the application, stored in the performance data 124. The performance data 124 may include the statistics about the performance of the application under varied and different load, performance counters, details of profiling and latency, values and metrics of performance data, and other results. In one implementation, the analysis module 120, based on the data stored in the performance data 124, generates reports. The reports may include the analytical view of the load and performance testing results. For example, the report may include a graph of resources utilized by the application at different loads. Similarly, the report may include the performance of the application at different instances of time and at different load situations. In one implementation, the analysis module 120 may generate the report in Hyper Text Markup Language (HTML) format or in SharePoint dashboards. It would be understood by those skilled in the art that the report may also be generated in other formats, such as 'word files', 'excel documents', 'pdf, etc. In another implementation, the modules, such as the master control module 114, the load testing module 116, the profiling module 118, and the analysis module 120 may also act as a plug-in interface to other testing and profiling tools to enhance the load and performance testing capability and generate more accurate results.
The implementation of the load and performance testing system as described above provides flexibility, reusability, and scalability to the load and performance testing systems by enabling functionalities, such as configurability of test scenarios, load testing of applications, execution of profiling engines, analysis of the generated results, and ability to report such results in different formats and at different platforms. Further, since the load and performance testing system is capable of performing end-to-end load and performance testing of an application, the system provides a holistic framework for pre and post analysis of the performance of the application. Also, the system described herein is flexible and can be leveraged for web application and web services performance and load testing.

Fig. 2 illustrates a method 200 to perform end-to-end load and performance
testing of an application, in accordance with an implementation of the present subject matter. The method is presently provided for software and web application, however, it would be appreciated that the same method can also be implemented for testing of other softwares and applications without deviating from the scope of the present subject matter.
The order in which the method is described is not intended to be construed as a
limitation, and any number of the described method blocks can be combined in any order to implement the method, or an alternative method. Additionally, individual blocks may be deleted from the method without departing from the spirit and scope of the subject matter described herein. Furthermore, the methods can be implemented in any suitable hardware, software, firmware, or combination thereof.
A person skilled in the art will readily recognize that steps of the method can be
performed by programmed computers. Herein, some embodiments are also intended to cover program storage devices, for example, digital data storage media, which are machine or computer readable and encode machine-executable or computer-executable programs of instructions, wherein said instructions perform some or all of the steps of the described method. The program storage devices may be, for example, digital memories, magnetic storage media, such as a magnetic disks and magnetic tapes, hard drives, or optically readable digital data storage media.
At block 202, at least one of the testing parameters associated with load and
performance testing of an application are received which are configurable. According to an implementation, the system 102 may receive the testing parameters from a user or an administrator of the system 102. The testing parameters may include, but are not limited to, configuration parameters, profiling parameters, scheduling parameters, performance control parameters, and report generation parameters. The parameters may define the conditions of load and performance testing an application. In one implementation, the testing parameters are received in XML and are also configurable based on the testing requirement of the application or according to the business needs.
At block 204, virtual load based on the at least one testing parameter for load and
performance testing of the application is simulated. According to an implementation of the

present subject matter, the system 102 is configured to simulate virtual load for load and performance testing of the application. The simulated virtual load may include generation of parallel users to perform multiple transactions allowed by the application. The simulated virtual load may also allow the response determination of the application for different and varied load situations based on the configured testing parameters.
Profiling of the application under test while simulating virtual load to determine
hotspots in the application is done at block 206. In one implementation, during the profiling of an application, the execution time of the functions in a program code is analyzed under varied load conditions. In said implementation, the execution time of the functions include the inclusive time and exclusive time, i.e., the time taken by the function during execution of its own code and the time taken by the function while waiting response from any other function of the program code, functions that have an execution time greater than a pre-defined threshold execution time are identified as the hotspots and hence, the hotspots are indicative of functions with greater execution time.
At block 208, bottlenecks associated with the application based on the simulated
virtual load and the profiling of the application are identified. In one implementation, the system 102 analyzes the hotspots identified for various load situations and the response of the application on various load situations and different user transactions to identify the bottleneck in the execution of the application.
At block 210, at least one analysis report based on the analysis of the load and
performance testing and the profiling of the application is generated. The reports may be nerated based on the statistics about the performance of the application under varied and different loads, performance counters, details of profiling and latency, values and metrics of performance data, and other results generated during load testing and profiling of the application.
The reports may include the analytical view of the load and performance testing
results. For example, the report may include a graph of resources utilized by the application at different loads. On the other hand, the report may also include the performance of the application at different instances of time and at different load situations. In one implementation, the report may be generated in HTML format or in SharePoint dashboards. It would be understood by those skilled in the art that the report may also be generated in other formats, such as 'word files',

'excel documents', 'pdf, etc. Further, the report may also map the results back to the profiled program code to mark their association with the application.
Although implementations for load and performance testing systems have been
described in language specific to structural features and/or methods, it is to be understood that the appended claims are not necessarily limited to the specific features or methods described. Rather, the specific features and methods are disclosed as exemplary implementations for load and performance testing of an application.

I/We claim:
1. A method for load and performance testing of an application, the method comprising:
receiving at least one testing parameter associated with load and performance testing of the application, wherein the at least one testing parameter is configurable;
simulating virtual load based on the at least one testing parameter;
profiling the application while simulating virtual load to determine hot spots in the application, wherein the hotspots are indicative of functions with execution time greater than a pre-defined threshold; and
identifying bottlenecks associated with the application based on the simulated virtual load and in part on the profiling of the application.
2. The method as claimed in claim 1, wherein the method further comprises generating at least one analysis report based on analysis of one or more of the load and performance testing, and the profiling.
3. The method as claimed in claim 1, wherein the at least one testing parameter include one or more of configuration parameters, profiling parameters, scheduling parameters, performance control parameters, and report generation parameters.
4. The method as claimed in claim 1, wherein the testing parameters are defined and based
on extensible markup language (XML) scripts.

5. The method as claimed in claim 1, wherein the execution time includes one or more of an inclusive time of execution, and an exclusive time of execution utilized by a function of the application.
6. The method as claimed in claim 0, wherein the at least one analysis report is generated in one of hyper text markup language (HTML), spread sheet format, word format, pdf format, and SharePoint dashboard format.

7. A system (102) for load and performance testing, the system comprising:
a processor (106); and
a memory coupled to the processor, wherein the memory comprises:
a master control module (114) configured to receive at least one testing parameter associated with load and performance testing of an application, wherein the at least one testing parameter is configurable;
a load testing module (116) configured to simulate virtual load based on the at least one testing parameter;
a profiling module (118) configured to profile the application while simulating virtual load to determine hot spots in the application, wherein the hotspots are indicative of functions with execution time greater than a predefined threshold; and
an analysis module (120) configured to identify bottlenecks associated with the application based on the simulated virtual load and in part on the profiling of the application.
8. The system (102) as claimed in claim 7, wherein the analysis module (120) is further configured to generate at least one analysis report based on analysis of one or more of the load and performance testing, and the profiling.
9. The system (102) as claimed in claim 7, wherein one or more of the master control module (114), the load testing module (116), the profiling module (118), and the analysis module (120) act as a plug-in interface.
10. The system (102) as claimed in claim 7, wherein the testing parameters include one or more of configuration parameters, profiling parameters, scheduling parameters, performance control parameters, and report generation parameters.
11. The system (102) as claimed in claim 7, wherein the testing parameters are based on extensible markup language (XML) scripts.

12. The system (102) as claimed in claim 7, wherein the execution time includes one or more of an inclusive time of execution, and an exclusive time of execution utilized by a function of the application.
13. The system (102) as claimed in claim 8, wherein the at least one analysis report is generated in one of hyper text markup language (HTML), spread sheet format, word format, pdf format, and SharePoint dashboard format.
14. A computer-readable medium having embodied thereon a computer program for executing a method comprising:
receiving at least one testing parameter associated with load and performance testing of the application, wherein the at least one testing parameter is configurable;
simulating virtual load based on the at least one testing parameter for load and performance testing of the application;
profiling the application while simulating virtual load to determine hot spots in the application, wherein the hotspots are indicative of functions with execution time greater than a pre-defined threshold; and
identifying bottlenecks associated with the application based on the simulated virtual load and in part on the profiling of the application.