CLIAMS:We claim:

1. A method for testing an application using at least one virtual user, said method comprising:
preparing a protocol communication channel for a Device Under Test (DUT) to communicate with said at least one virtual user;

receiving a communication request from said DUT to communicate with said at least one virtual user;

identifying an actual destination corresponding to said at least one virtual user, wherein said actual destination is a real user; and

establishing communication between said DUT and said real user.

2. The method as claimed in claim 1, wherein identifying said actual destination of said communication request further comprises of:
extracting protocol header values from said communication request;

generating a key-value pair based on said extracted protocol header values; and

analyzing said key-value pair.

3. The method as claimed in claim 2, wherein analyzing said key-value pair further comprises of comparing a to-header in said key-value pair with a mapping table, wherein said to-header represents address of said virtual user.

4. The method as claimed in claim 3, wherein said mapping table possesses information on real user corresponding to each of the virtual users.

5. The method as claimed in claim 1, wherein establishing communication between said DUT and said real user further comprises of:
modifying a protocol header of said communication request;

converting data received from said DUT to a format that matches communication protocol being supported by said real user; and

converting data received from said real user to a format that matches communication protocol being supported by said DUT.

6. A user emulation system for testing an application using at least one virtual user, said system configured for:
preparing a protocol communication channel for a Device Under Test (DUT) to communicate with at least one virtual user, using a protocol interface;

receiving a communication request from said DUT to communicate with a virtual user, using said protocol interface;

identifying an actual destination corresponding to said virtual user, wherein said actual destination is a real user, using an emulator module; and

establishing communication between said DUT and said real user, using said protocol interface.

7. The system as claimed in claim 6, wherein said emulator module is further configured to identify said actual destination corresponding to said virtual user by:
extracting protocol header values from said communication request, using an emulator core;

generating a key-value pair based on said extracted protocol header values, using said emulator core; and
analyzing said key-value pair, using said emulator core.

8. The system as claimed in claim 7, wherein said emulator core is further configured to analyze said key-value pair by comparing a to-header with a mapping table, wherein said to-header represents address of said virtual user.

9. The system as claimed in claim 6, wherein said protocol interface is further configured to establish said communication between said DUT and said real user by:
modifying protocol header of said communication request, using a service interface;

converting data received from said DUT to a format that matches communication protocol being supported by said real user, using a DUT interface; and

converting data received from said real user to a format that matches communication protocol being supported by said DUT, using said service interface.

Date: 25th September 2014 Signature:
Kalyan Chakravarthy
,TagSPECI:FORM 2
The Patent Act 1970
(39 of 1970)
&
The Patent Rules, 2005

COMPLETE SPECIFICATION
(SEE SECTION 10 AND RULE 13)

TITLE OF THE INVENTION

“Application Cloud Service Integration Stress Testing Framework”

APPLICANTS:
Name Nationality Address
HCL Technologies Ltd. Indian HCL Technologies Ltd.
50-53 Greams Road, Chennai – 600006, Tamil Nadu, India

The following specification particularly describes and ascertains the nature of this invention and the manner in which it is to be performed:-

TECHNICAL FIELD
[001] The embodiments herein relate to software testing and, more particularly, to emulating user to match requirements, in software testing.

BACKGROUND
[002] Testing is an important phase of application development, wherein a developed system is tested to ensure that it meets requirements, and that all components are functioning properly. To test a system/application that is designed to support load from thousands of user systems, to test scalability and product compatibility, the application needs to be tested in real world scenarios where a user interacts with many other users. This type of testing further demands a large user base of thousands or millions of users, as per capability of the system/application being tested.
[003] When thousands of user accounts are required, current systems rely on third party service provides who supply required amount of user accounts. For example, when the application testing requires 1000 user accounts, 1000 user subscriptions need to be purchased.
[004] However, this mode of application/system testing has certain disadvantages. One disadvantage is that the cost incurred in purchasing user subscriptions is very high. For example, if for a user subscription for a limited time period (say, a month) a sum of $10 is charged, and of 5000 user subscriptions are required, total sum would be 50000$ for a month.
[005] An alternate method would be use of simulators instead of purchasing user subscriptions. The simulator simulates specific interfaces to provide appearance of multiple users, and thereby satisfy user account needs. However, the simulator acts as a standalone application, and do not communicate with any real world entity. As a result, the testing process using simulators is not a real time process, when the application is deployed in real world deployment it may results in a number of bugs. Also, if a simulator is used to test a system, the system may require constant modifications based on changes in protocol stack and features of real world entities which the application would interact with.

SUMMARY
[006] In view of the foregoing, an embodiment herein provides a method for testing an application using at least one virtual user. In this method, a protocol communication channel is prepared for a Device Under Test (DUT) to communicate with at least one virtual user. Further, upon receiving a communication request from the DUT to communicate with a virtual user, an actual destination corresponding to the virtual user is identified, wherein the actual destination is a real user. Further, a communication is established between the DUT and the real user.
[007] Embodiments further disclose a user emulation system for testing an application using at least one virtual user. The system is configured for preparing a protocol communication channel using a protocol interface, for a Device Under Test (DUT) to communicate with at least one virtual user. Further, the system, using the protocol interface, receives a communication request from the DUT to communicate with a virtual user. Further, the system, using an emulator module, identifies an actual destination corresponding to the virtual user, wherein the actual destination is a real user. Further, the system establishes communication between the DUT and the real user, using the protocol interface.
[008] These and other aspects of the embodiments herein will be better appreciated and understood when considered in conjunction with the following description and the accompanying drawings.

BRIEF DESCRIPTION OF THE FIGURES
[009] The embodiments herein will be better understood from the following detailed description with reference to the drawings, in which:
[0010] FIG. 1 illustrates a block diagram of a virtual testing framework, as disclosed in the embodiments herein;
[0011] FIG. 2 is a block diagram that depicts various components of a user emulation system, as disclosed in the embodiments herein;
[0012] FIG. 3 is a block diagram that depicts various components of a protocol interface, as disclosed in the embodiments herein;
[0013] FIG. 4 is a block diagram that depicts various components of an emulator module, as disclosed in the embodiments herein; and
[0014] FIG. 5 is a flow diagram which depicts various steps involved in the process of performing virtual testing of an application using the virtual testing framework, as disclosed in the embodiments herein.

DETAILED DESCRIPTION OF EMBODIMENTS
[0015] The embodiments herein and the various features and advantageous details thereof are explained more fully with reference to the non-limiting embodiments that are illustrated in the accompanying drawings and detailed in the following description. Descriptions of well-known components and processing techniques are omitted so as to not unnecessarily obscure the embodiments herein. The examples used herein are intended merely to facilitate an understanding of ways in which the embodiments herein may be practiced and to further enable those of skill in the art to practice the embodiments herein. Accordingly, the examples should not be construed as limiting the scope of the embodiments herein.
[0016] The embodiments herein disclose a mechanism for testing an application with less number of real users than actually required, by emulating functionality of real users. Referring now to the drawings, and more particularly to FIGS. 1 through 5, where similar reference characters denote corresponding features consistently throughout the figures, there are shown embodiments. The term ‘Virtual Testing’ used throughout the description refers to a process of testing an application using at least one virtual user, wherein the virtual user emulates functionality of a real user.
[0017] FIG. 1 illustrates a block diagram of a virtual testing framework, as disclosed in the embodiments herein. The virtual testing framework 100 comprises of a Device Under Test (DUT) 103, a user emulation system 102, and a plurality of Real users 101. The DUT 103 may represent an application, a device, or a combination of a suitable application and a device, which is being tested for performance assessment. For example, the DUT 103 may be a device which is designed to supports load from 1000 user accounts. So, during the performance assessment, the DUT 103 is checked to see if it is supporting load from 1000 user accounts.
[0018] The real users 101 refer to actual user accounts which may be used for performance testing of the DUT 103. The user emulation system 102 is configured to communicate with the DUT 103, and at least one real user 101 and using suitable communication channels, and facilitate performance testing of the DUT 103.
[0019] The user emulation system 102, by processing request received from the DUT 103, identifies real user 101 to whom the request is addressed to, and further establishes a communication between the DUT 103 and the real user 101 to facilitate the performance testing.
[0020] FIG. 2 is a block diagram that depicts various components of a user emulation system, as disclosed in the embodiments herein. The user emulation system 102 comprises of a protocol interface 201, and an emulator module 202. The protocol interface 201 is responsible for establishing a suitable communication channel between the DUT 103 and the real user 101 to facilitate communication. This is essential because in some scenarios, the DUT 103 and the real user 101 may be supporting and communicating using different protocols. In such scenarios, a direct channel cannot be established as the DUT 103 will not understand data transmitted by the real user 101, and vice versa. The protocol interface 201 ensures that proper data translation is done to establish proper communication between the DUT 103 and the real user 101. The protocol interface 201 may also process request received from the DUT 103 and identify, by analyzing header of the received signal, a virtual user the request is addressed to.
[0021] The emulator module 202 is responsible for identifying a real user 101 whom the request is addressed to. The emulator module 202 may possess information on mapping between a plurality of virtual users and a real user 101. Upon identifying the real user 101, the emulator module 202 modifies header of the request received from the DUT 103, and routes the request to corresponding real user 101.
[0022] FIG. 3 is a block diagram that depicts various components of a protocol interface, as disclosed in the embodiments herein. The protocol interface 201 further comprises of a DUT interface 301, and a service interface 302. The DUT interface 301 communicates with the DUT 103 using a suitable channel. The DUT interface 301 is responsible for receiving request from the DUT 103 and transmitting the received request to the emulator module 202 for further processing. Similarly, the DUT interface 301 receives data transmitted by a real user 101, from the emulator module 202, and transmits the data to the DUT 103 through a suitable communication channel.
[0023] The service interface 302 communicates with at least one real user 101, using a suitable communication channel, and acts as an interface between the emulator module 202 and at least one real user 101. The service interface receives data transmitted by the DUT 103, from the emulator module 202, and transmits the data to corresponding real user 101.
[0024] FIG. 4 is a block diagram that depicts various components of an emulator module, as disclosed in the embodiments herein. The emulator module 202 further comprises of an emulator core 401, and a memory module 402. The memory module 402 is used to store data required for emulating functionality of real users for the purpose of testing the application, For example, one database stored in the memory module 402 may possess information on mapping between real users and corresponding virtual users, as a mapping table. An example of the mapping table is given below:

Virtual Users' ID Real user ID
U1, U2, U3, U4 R1
U5, U6, U7, U8 R2
U9, U10, U11, U12 R3
U13, U14, U15, U16 R4

Table. 1
[0025] As shown in Table. 1, virtual users are mapped to corresponding real users 101. For the DUT 103, each virtual user appears to be real user 101, and hence the DUT 103 tries to establish communication between certain users which actually are, virtual users. The emulator core 401, using the data in the mapping table, identifies real user 101 corresponding to a virtual user, and establishes communication between the real users who handles the selected virtual users. For example, assume that the DUT 103 tries to establish communication between the virtual users U1 and U9. The emulator core 401, based on the data in the mapping table, identifies that U1 is virtual ID of the real user R1, and that U9 is the virtual ID of the real user R3. Further, the emulator core 401 establishes communication between the R1 and R3.
[0026] The memory module 402 may also a second detail store, which may be termed as "Message detail store", which possesses information on unique transaction/communication identifiers of the DUT interface 301, and the service interface 302. For example, assume that 2 emails are sent between U1 and U9 i.e. between R1 and R3. For each such communication, a unique ID may be generated. For example, in this case, two unique strings, say msgid1 and msgid 2 may be generated which are unique identifiers which represent the emails sent from U1 to U9. Similarly, as the communication happens between R1 and R3, two unique identifiers, say msgid 3 and msgid 4 may be generated which represents the mails sent from R1 to R3. All such entries may be stored in the Message detail store.
[0027] FIG. 5 is a flow diagram which depicts various steps involved in the process of performing virtual testing of an application using the virtual testing framework, as disclosed in the embodiments herein. In order to test the performance of the DUT 103, the DUT 103 is connected to the user emulation system 102, which in turn is connected to a plurality of real users 101. Further, initial configurations are made, during which the DUT 103 is assigned resources which are intended to provide load required for the performance assessment. In an embodiment, the resources may be virtual users, wherein the virtual users are created by emulating functionality of real users 101. Further, the mapping table is created and stored in a memory module 402 which possesses mapping information between different sets of a plurality of virtual users and corresponding real users 101.
[0028] Now, assume that the DUT 103 communicates in protocol 'X', and the real users 101 in a protocol 'Y'. Then, a selection is made from a list of protocols a protocol that the DUT 103 understands, and a protocol the real users 101 understand. In an embodiment, the selection of protocols may require user assistance and the user may have to manually make the selection. In another embodiment, the selection of protocols may be automatically done by the user emulation system 102, by analyzing associated parameters, which are collected as inputs. When the selection of protocols is made, the emulator module 202 prepares (502) a protocol communication channel by invoking the DUT interface 301 which understands the protocol ‘X’, and the service interface 302 which understands the protocol ‘Y’.
[0029] The DUT 103 can, for the purpose of performance testing, initiate a communication between at least two user accounts, wherein the user account may refer to that of virtual users. The DUT interface 301 receives (504) the communication request. The communication request is further processed by the DUT interface 301 to extract information such as protocol header values such as protocol version, from header, to header, subject, content length and contact to be extracted and maintained as key-value pair, against respective header fields. The generated (506) key-value pair is then transmitted to the emulator core 401.
[0030] The emulator core 401, by processing the received key-value pair, identifies (508) actual destinations of both the sender and receiver of the received packet, wherein the actual destination refers to at least one real user 101. Processing the key-value pair to identify the actual destination involves identifying destination of the packet, and identifying real user who is responsible for managing the identified virtual user. This is done by comparing the key-value pair against the mapping table which possesses mapping information on virtual users and corresponding real users.
[0031] Further, the emulator core 401 modifies (510) header values of the communication signal according to that of the real users 101. For example, for data flow from U1 to U9, ‘to’ address is modified as real user ID of R3 and ‘from’ address is modified as real user ID of R1. Similarly for data flow back from U9 to U1, ‘from’ address is modified as that of R3, and ‘to’ address is modified as that of R1.
[0032] Further, based on the header value modifications made by the emulator core 401, the protocol interface 201 establishes (512) communication between targeted virtual users and real users 101 which handles corresponding communication on behalf of the virtual users. Further, the protocol interface 201 receives data from the DUT 103 and converts the received data to a format that matches the communication protocol being supported by the real user 101, so that the real user 101 can understand the data coming from the DUT 103. Likewise, the protocol interface 201 converts the data from real user 101 to a format that matches the communication protocol being supported by the DUT 103, so that the DUT 103 can understand communications from the real user 101. In this testing process, the DUT 103 believes that required number of real users are actually available to support the testing process, however, only a few real users are supporting the testing process by emulating functionality of remaining required number of real users, as virtual users. The various actions in method 500 may be performed in the order presented, in a different order or simultaneously. Further, in some embodiments, some actions listed in FIG. 5 may be omitted.
[0033] The embodiments disclosed herein can be implemented through at least one software program running on at least one hardware device and performing network management functions to control the network elements. The network elements shown in Fig. 1 include blocks which can be at least one of a hardware device, or a combination of hardware device and software module.
[0034] The embodiments disclosed herein specify a system for testing an application. The mechanism allows testing of an application using less number of real resources, providing a system thereof. Therefore, it is understood that the scope of protection is extended to such a system and by extension, to a computer readable means having a message therein, said computer readable means containing a program code for implementation of one or more steps of the method, when the program runs on a server or mobile device or any suitable programmable device. The method is implemented in a preferred embodiment using the system together with a software program written in, for ex. Very high speed integrated circuit Hardware Description Language (VHDL), another programming language, or implemented by one or more VHDL or several software modules being executed on at least one hardware device. The hardware device can be any kind of device which can be programmed including, for ex. any kind of a computer like a server or a personal computer, or the like, or any combination thereof, for ex. one processor and two FPGAs. The device may also include means which could be for ex. hardware means like an ASIC or a combination of hardware and software means, an ASIC and an FPGA, or at least one microprocessor and at least one memory with software modules located therein. Thus, the means are at least one hardware means or at least one hardware-cum-software means. The method embodiments described herein could be implemented in pure hardware or partly in hardware and partly in software. Alternatively, the embodiment may be implemented on different hardware devices, for ex. using a plurality of CPUs.
[0035] The foregoing description of the specific embodiments will so fully reveal the general nature of the embodiments herein that others can, by applying current knowledge, readily modify and/or adapt for various applications such specific embodiments without departing from the generic concept, and, therefore, such adaptations and modifications should and are intended to be comprehended within the meaning and range of equivalents of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and not of limitation. Therefore, while the embodiments herein have been described in terms of preferred embodiments, those skilled in the art will recognize that the embodiments herein can be practiced with modification within the spirit and scope of the claims as described herein.

CLAIMS
We claim:

1. A method for testing an application using at least one virtual user, said method comprising:
preparing a protocol communication channel for a Device Under Test (DUT) to communicate with said at least one virtual user;

receiving a communication request from said DUT to communicate with said at least one virtual user;

identifying an actual destination corresponding to said at least one virtual user, wherein said actual destination is a real user; and

establishing communication between said DUT and said real user.

2. The method as claimed in claim 1, wherein identifying said actual destination of said communication request further comprises of:
extracting protocol header values from said communication request;

generating a key-value pair based on said extracted protocol header values; and

analyzing said key-value pair.

3. The method as claimed in claim 2, wherein analyzing said key-value pair further comprises of comparing a to-header in said key-value pair with a mapping table, wherein said to-header represents address of said virtual user.

4. The method as claimed in claim 3, wherein said mapping table possesses information on real user corresponding to each of the virtual users.

5. The method as claimed in claim 1, wherein establishing communication between said DUT and said real user further comprises of:
modifying a protocol header of said communication request;

converting data received from said DUT to a format that matches communication protocol being supported by said real user; and

converting data received from said real user to a format that matches communication protocol being supported by said DUT.

6. A user emulation system for testing an application using at least one virtual user, said system configured for:
preparing a protocol communication channel for a Device Under Test (DUT) to communicate with at least one virtual user, using a protocol interface;

receiving a communication request from said DUT to communicate with a virtual user, using said protocol interface;

identifying an actual destination corresponding to said virtual user, wherein said actual destination is a real user, using an emulator module; and

establishing communication between said DUT and said real user, using said protocol interface.

7. The system as claimed in claim 6, wherein said emulator module is further configured to identify said actual destination corresponding to said virtual user by:
extracting protocol header values from said communication request, using an emulator core;

generating a key-value pair based on said extracted protocol header values, using said emulator core; and
analyzing said key-value pair, using said emulator core.

8. The system as claimed in claim 7, wherein said emulator core is further configured to analyze said key-value pair by comparing a to-header with a mapping table, wherein said to-header represents address of said virtual user.

9. The system as claimed in claim 6, wherein said protocol interface is further configured to establish said communication between said DUT and said real user by:
modifying protocol header of said communication request, using a service interface;

converting data received from said DUT to a format that matches communication protocol being supported by said real user, using a DUT interface; and

converting data received from said real user to a format that matches communication protocol being supported by said DUT, using said service interface.

Date: 25th September 2014 Signature:
Kalyan Chakravarthy

ABSTRACT
Disclosed herein are a method and a system for testing an application with less number of real resources than required. A user emulation system is configured to communicate with a Device Under Test (DUT), and provide necessary user accounts required for testing the DUT. The user emulation system receives a request received from the DUT which is targeted to a user. Here, the user may be a virtual user in real sense. However, for the DUT, the virtual user may appear to be a real user. The user emulation system identifies a real/actual user who represents the virtual user with whom the DUT is trying to establish communication with, prepares a protocol communication channel between the DUT and the actual user identified, and establishes communication between the DUT and the real user.

FIG. 1