CLIAMS:We Claim
1. A method for device capability based test script selection, said method comprises:
identifying capabilities of device being tested;
comparing said identified capabilities of the device with capabilities of a plurality of test scripts; and
selecting at least one test script from said plurality of test scripts with capabilities that matches said identified capabilities of the device.

2. The method as in claim 1, wherein said identifying capabilities of the device further comprises:
sending a capability check query to said device;
fetching a capability tag as a response from said device; and
comparing said compatibility tag with a device capability database.
3. The method as in claim 2, wherein said device capability database maps device capability tags with corresponding protocol wise mapping to related features.
4. The method as in claim 1, wherein said selected test scripts are executed on said device.
5. The method as in claim 4, wherein results of said executed test scripts are recorded in an associated database.
6. A system for device capability based test script selection, said system provided with means configured for:
identifying capabilities of device being tested using an intelligent test case selector;
comparing said identified capabilities of the device with capabilities of a plurality of test scripts using a script engine; and
selecting at least one test script from said plurality of test scripts with capabilities that matches said identified capabilities of the device using said script engine.

7. The system as in claim 6 is further configured to identify capabilities of said device by:
sending a capability check query to said device using a capability fetch module in said intelligent test case selector module;
fetching a capability tag as a response from said device using said capability fetch module; and
comparing said compatibility tag with a device capability database using an applicability check module in said intelligent test case selector.
8. The system as in claim 7 is further configured to map said device capability tags with corresponding protocol wise mapping to related features in said device capability database using a protocol specification store.
9. The system as in claim 6 is further configured to execute said selected test scripts on said device.

10. The system as in claim 9 is further configured to record results of said executed test scripts in an associated database.

Dated: 2nd May, 2013 Signature
Nishant Kewalramani
Patent Agent
,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

“AUTOMATIC TEST CASE SELECTION BASED ON DEVICE CAPABILITIES”

APPLICANTS:

Name : HCL Technologies Limited

Nationality : Indian

Address : 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 hardware and software testing and, more particularly, to automated test case selection based on device capabilities.

BACKGROUND
[002] Testing is a process used to validate operation of a device and to check whether the device is functioning properly, providing an expected output. When a device is to be tested, specific inputs are fed into the device and corresponding outputs are collected. The person who conducts the testing knows an actual output corresponding to each input for that particular device. Then, the output (s) received from the device is compared with the actual output. If the values are equal, then the device may be considered as functioning properly. Any mismatch may indicate a malfunctioning of the device.
[003] There exists two ways of testing the device, namely manual testing and automated testing. Manual testing requires a user feeding inputs and fetching and checking outputs manually. One disadvantage of the manual testing is that it requires lot of time as complete manual intervention is required. Further, if a mismatch is detected in output, the user may have to manually analyze and determine which section/component of the device is malfunctioning and provided the wrong output.
[004] Testing a network application needs a slightly different approach. Implementations of the most of the network applications are based on some protocol standard. In some other cases, implementation might be based on a proprietary protocol. However, in both the cases, when new versions of the base protocols are made available, the application conformant to the previous version of the protocol needs to be modified too. This requires modifications in the device implementation; which in turn results in implementation gaps. Further, after each modification, the device needs to be tested using suitable test scripts that comprise test cases and scenarios. Out of the large numbers of test cases in the test suite not every test case applies to every device being tested. This is because the device under test may choose to implement some features and do away with others. Thus to get an accurate view of the device’s feature capabilities and maturity of the product in an optimum time period, it is desirable that only the relevant test cases be selected from the test suite.
[005] Further, many a times numerous mature versions of a single protocol are available. Not every device upgrades their product to the latest version. Thus a conformance tool aiming at holistic testing needs to have test cases for multiple versions of the same protocols. This further increases the number of test cases and associated complexities and dilemmas like grouping of test cases according to versions or whether according to the features. Disadvantage of the existing systems is that they need manual intervention to select relevant test suites.
SUMMARY

[006] In view of the foregoing, an embodiment herein provides a method for device capability based test script selection, the method comprises identifying capabilities of device being tested; comparing the identified capabilities of the device with capabilities of a plurality of test scripts; and selecting at least one test script from the plurality of test scripts with capabilities that matches the identified capabilities of the device.
[007] Embodiments further disclose a system for device capability based test script selection, the system provided with means configured for identifying capabilities of device being tested using an intelligent test case selector; comparing the identified capabilities of the device with capabilities of a plurality of test scripts using a script engine; and selecting at least one test script from the plurality of test scripts with capabilities that matches the identified capabilities of the device using the script engine.
[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 the test case selection system, as disclosed in the embodiments herein;
[0011] FIG. 2 is a block diagram that shows various components of the intelligent test case selector, as disclosed in the embodiments herein; and
[0012] FIG. 3 is a flow diagram that shows various steps involved in the process of selecting test script based on device capabilities, as disclosed in the embodiments herein.

DETAILED DESCRIPTION OF EMBODIMENTS
[0013] 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.
[0014] The embodiments herein disclose an automated test script selection system by dynamically identifying device capabilities. Referring now to the drawings, and more particularly to FIGS. 1 through 3, where similar reference characters denote corresponding features consistently throughout the figures, there are shown embodiments.
[0015] FIG. 1 illustrates a block diagram of the test case selection system, as disclosed in the embodiments herein. The system comprises a test device 101 and a test script selector module 102. The device testing module 102 further comprises an intelligent test case selector 102.a, a device configuration module 102.b, a protocol encode/decode library 102.c, a protocol specification store 102.d, a script engine 102.e, a script store 102.f, a test execution engine 102.g and a test result repository 102.h.
[0016] The test device 101 refers to the device whose functionalities are to be tested and validated. A user may manually connect the test device 101 to the test script selector module 102 using a suitable interface. While connecting the test device 101 to the device testing module 102, a user may also enter/configure various parameters related to the test device 101 with the device configuration module 102.b. The configured test device parameters may comprise IP address of the test device 101 and/or a target server, type of authentication supported by the test device 101 and so on. The device configuration module 102.b further prepares a setup environment based on the configured data.
[0017] The intelligent test case selector 102.a fetches information regarding capability tag associated with the test device 101. Every capability tag (tag) present in the network packets emitted from test device 101 is mapped to a specific feature(s). In an embodiment, different test devices having same set of features may have same capability tag. Further, the intelligent test case selector 102.a, using the fetched tag and data available in the protocol specification store 102.d, identifies functionalities/features of the test device 101. In an embodiment, the protocol specification store 102.d possesses information on test cases and scenarios divided into groups and sub-groups. The intelligent test case selector 102.a may also fetch inputs related to protocol parameters and headers, which may help the system to automatically take care of network protocols such as UDP, TCP, SIP and so on, scripts and packets for handling core networks.
[0018] The identified information is then sent to the script engine 102.e. The script engine 102.e, based on the inputs from the intelligent test case selector 102.a, selects test scripts suitable for the test device 101 from the script store 102.f. Further, the selected test cases are sent to the test execution engine 102.g. Further, the test execution engine 102.g prepares an execution environment and executes the selected test scripts and logs results of the executed tests in the test result repository 102.h. After successfully executing a test script, the script engine 102.e may deinitialize the test script. In an embodiment, the test case selection system may provide an “override test case auto-select function” option if the user intends to disable the automatic test case selection function.
[0019] FIG. 2 is a block diagram that shows various components of the intelligent test case selector, as disclosed in the embodiments herein. The intelligent test case selector 102.a further comprises a capability fetch module 201 and an applicability check module 202. The capability fetch module 201 is responsible for performing a capability check against the test device 101 and retrieving the protocol tags from the network packets received from the test device 101. Further, the capability fetch module 201 compares the fetched tag with protocol specifications present in the protocol specification store 102.d. The capability fetch module 201 also saves the fetched tag in any associated database.
[0020] The applicability check module 202 queries the database i.e. the script store 102.f to check applicability of a test script to run. In response to this query, the database may return a value that indicates whether the test script needs to be run or not.
[0021] FIG. 3 is a flow diagram that shows various steps involved in the process of selecting test script based on device capabilities, as disclosed in the embodiments herein. The test device 101 is connected to the device testing module 102 so as to test and validate its functionality. While connecting the test device 101 to the device testing module 102, various parameters related to the test device 101 may be configured with the device configuration module 102.b in the device testing module 102. The configured test device parameters may comprise IP address of the test device 101 and/or a target server, type of authentication supported by the test device 101 and so on. The device configuration module 102.b in the device testing module 102 further prepares a setup environment based on the configured data.
[0022] In order to select test scripts suitable to the device under test i.e. the test device 101, capabilities/ features of the test device 101 has to be identified. Each test device 101 has a set of tags associated with it, which are mapped to a specific feature(s). So as to fetch the tag, the intelligent test case selector module 102.a sends (301) a capability check query to the test device 101. Further, the intelligent test case selector module 102.a fetches response message from the test device 101 and identifies a capability tag associated with the test device 101 by analyzing the fetched response message. The response message may even have capability indication fields.
[0023] Further, the intelligent test case selector module 102.a identifies (302) capabilities of the test device 101 using the fetched device tag. In this step, the device tag is sent from the intelligent test case selector module 102.a to the protocol specification store 102.d where device capability database that possesses information on tags and protocol wise mapping to related features is maintained. The protocol specification store 102.d may also possess information on specifications; RFCs related to standards, network traces containing the message flows, lists of tags specific to the test device 101 and so on. So as to identify the device capabilities, the fetched tag may be compared with the database in the protocol specification store 102.d and when a match is found, corresponding capabilities/functionalities are selected. Further, information on the selected/identified device capabilities is sent to the script engine 102.e.
[0024] The script engine 102.e compares (303) the fetched device capability information against a database of test scripts and corresponding capabilities stored in the script store 102.f. The script engine 102.e checks whether the fetched device capabilities match with capabilities of any of the test scripts. If capabilities of one test script is not matching capabilities of one test script, the script engine 102.e fetches (305) next test script and repeats processes 303 and 304. Further, the script engine 102.e selects test scripts whose capabilities matches with the fetched device capabilities and executes (306) the selected test scripts. In various embodiments, Boolean values may be generated after every comparison that indicates whether a test script has to be run or not. After successfully completing execution of the selected test cases, corresponding results may be stored/recorded (307) in an associated database and may be displayed to the user. In a preferred embodiment, the system may provide an option to override automatic test case selection when the user intends to use a manual mode. The various actions in method 300 may be performed in the order presented, in a different order or simultaneously. Further, in some embodiments, some actions listed in FIG. 3 may be omitted.
[0025] 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.
[0026] The embodiment disclosed herein specifies a system for automated device testing. The mechanism allows device capability based test script selection, providing a system thereof. Therefore, it is understood that the scope of the protection is extended to such a program and in addition to a computer readable means having a message therein, such computer readable storage means contain program code means 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 through or together with a software program written in e.g. 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 e.g. any kind of computer like a server or a personal computer, or the like, or any combination thereof, e.g. one processor and two FPGAs. The device may also include means which could be e.g. hardware means like e.g. an ASIC, or a combination of hardware and software means, e.g. 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 and/or at least one software means. The method embodiments described herein could be implemented in pure hardware or partly in hardware and partly in software. The device may also include only software means. Alternatively, the invention may be implemented on different hardware devices, e.g. using a plurality of CPUs.
[0027] 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.