CLIAMS:We claim:
1. A method for identifying impacted test cases due to code changes in software testing, said method comprises:
fetching a target release source code and a reference release source code as input;
identifying whether said input code is a managed code or an unmanaged code;
identifying impacted test cases on said input being an unmanaged code; and
identifying impacted test cases on said input being a managed code.
2. The method as in claim 1, wherein said identifying impacted test cases for unmanaged code further comprises:
parsing said target release source code and a reference release source code;
generating code constructs corresponding to said target release source code and said reference release source code;
generating compiled code corresponding to said target release source code and said reference release source code;
instrumenting said generated compiled code;
executing test cases and recording code coverage hits;
generating code coverage data; and
analyzing code constructs and code coverage data.
3. The method as in claim 2, wherein said instrumenting said compiled code further comprises inserting dynamic instruction to record coverage hits to said compiled code.
4. The method as in claim 2, wherein said test cases are executed in a code execution environment.
5. The method as in claim 2, wherein said generating code coverage data further comprises mapping said recorded code coverage hits and test case data.
6. The method as in claim 1, wherein said identifying impacted test cases for managed code further comprises:
compiling said target release source code and said reference release source code and generating code constructs;
instrumenting compiled intermediate code;
executing test cases and recording code coverage hits;
generating code coverage data; and
analyzing code constructs and code coverage data.
7. The method as in claim 6, wherein said instrumenting said compiled intermediate code further comprises inserting dynamic instruction to record coverage hits to said compiled intermediate code.
8. The method as in claim 6, wherein said test cases are executed in a code execution environment.
9. The method as in claim 6, wherein said generating code coverage data further comprises mapping said recorded code coverage hits and test case data.
10. The method as in claim 6, wherein said instrumenting the compiled intermediate code is executed in parallel to said compiling the target release source code and said reference release source code.
11. The method as in claim 1, wherein a trend analysis is performed based on said identified impacted test cases for an application.
12. The method as in claim 11, wherein said performing trend analysis based on said identified impacted test cases for said application further comprises:
fetching test results corresponding to said identified impacted test cases;
mapping said fetched test results with a code coverage information;
collecting information on at least one affected code area for which said test case failed; and
comparing said identified affected code area information with a plurality of versions of said application.
13. A system for identifying impacted test cases due to code changes in software testing, said system configured for:
fetching a target release source code and a reference release source code as input using a test case impact analyzer;
identifying whether said input code is a managed code or an unmanaged code using said test case impact analyzer;
identifying impacted test cases on said input being an unmanaged code using said test case impact analyzer; and
identifying impacted test cases on said input being a managed code using said test case impact analyzer.
14. The system as in claim 13, wherein said test case impact analyzer is further configured for identifying said impacted test cases for unmanaged code by:
parsing said target release source code and a reference release source code using a language parser;
generating code constructs corresponding to said target release source code and said reference release source code using a lexical analyzer;
generating compiled code corresponding to said target release source code and said reference release source code using a source code compiler;
instrumenting said generated compiled code using a code instrumentor;
executing test cases using a test case runner;
recording code coverage hits using a code coverage register;
generating code coverage data using a coverage analytic engine; and
analyzing code constructs and code coverage data using an impact analytics engine.
15. The system as in claim 14, wherein said code instrumentor is configured for instrumenting said compiled code by inserting dynamic instruction to record coverage hits to said compiled code.
16. The system as in claim 14, wherein said test case runner is configured to execute said test cases in a code execution environment.

17. The system as in claim 14, wherein said coverage analytic engine is further configured to generate said code coverage data by mapping said recorded code coverage hits and test case data.
18. The system as in claim 13, wherein said test case impact analyzer is further configured to identify said impacted test cases for managed code by:
compiling said target release source code and said reference release source code and generating code constructs using a source code compiler;
instrumenting compiled intermediate code using a code instrumentor;
executing test cases and recording code coverage hits using a test case runner;
generating code coverage data using a coverage analytics engine; and
analyzing code constructs and code coverage data using an impact analytics engine.

19. The system as in claim 13, wherein said code instrumentor is further configured to instrument said compiled intermediate code by inserting dynamic instruction to record coverage hits to said compiled intermediate code.
20. The system as in claim 18, wherein said test runner is further configured to execute said test cases in a code execution environment.
21. The system as in claim 18, wherein said coverage analytics engine is configured to generate said code coverage data by mapping said recorded code coverage hits and test case data.
22. The system as in claim 18, wherein said code instrumentor and said source code compiler functions in parallel.
23. The test case impact analyzer as in claim 13 is further configured to perform a trend analysis based on said identified impacted test cases for an application.

24. The test case impact analyzer as in claim 23 is configured to perform said trend analysis based on said identified impacted test cases for said application by:
fetching test results corresponding to said identified impacted test cases using a trend analysis module;
mapping said fetched test results with a code coverage information using said trend analysis module;
collecting information on at least one affected code area for which said test case failed using said trend analysis module; and
comparing said identified affected code area information with a plurality of versions of said application using said trend analysis module.

Dated : 21st June, 2013 Signature
Vikram Pratap Singh Thakur ,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
System and Method for identification of impacted test cases Due to code changes
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 software testing and, more particularly, to identify impacted test cases due to code changes in software testing.

BACKGROUND
[002] Software testing is an important part of SDLC for identifying the correctness, completeness, and quality of developed computer software. Before any software is released, it undergoes a complete software test cycle which involves execution & validation of multiple manual / automated test cases. This can be a very time taking procedure especially for large software involving thousands of test cases.
[003] Advanced versions of softwares are released by making minor modifications to codes of previous version of software. Even if there are only partial code changes, in the current scenario, the whole software release needs to be tested therefore executing the complete test cases which can be a considerable effort resulting in software release delays. When the number of test cases is more i.e. when thousands of test cases are there for the software, execution of all test cases becomes a time consuming process.

SUMMARY

[004] In view of the foregoing, an embodiment herein provides a method for identifying impacted test cases due to code changes in software testing, the method comprises fetching a target release source code and a reference release source code as input; identifying whether the input code is a managed code or an unmanaged code; identifying impacted test cases on the input being an unmanaged code; and identifying impacted test cases on the input being a managed code.
[005] Embodiments further disclose a system for identifying impacted test cases due to code changes in software testing, the system configured for fetching a target release source code and a reference release source code as input using a test case impact analyzer; identifying whether the input code is a managed code or an unmanaged code using the test case impact analyzer; identifying impacted test cases on the input being an unmanaged code using the test case impact analyzer; and identifying impacted test cases on the input being a managed code using the test case impact analyzer.
[006] 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
[007] The embodiments herein will be better understood from the following detailed description with reference to the drawings, in which:
[008] FIG. 1 illustrates block diagram of the impact analysis engine, as disclosed in the embodiments herein;
[009] FIG. 2 is a flow diagram that shows various steps involved in the process of identifying impacted test cases for unmanaged codes, as disclosed in the embodiments herein; and
[0010] FIG. 3 is a flow diagram that shows various steps involved in the process of identifying impacted test cases for managed codes, as disclosed in the embodiments herein.

DETAILED DESCRIPTION OF EMBODIMENTS
[0011] 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.
[0012] The embodiments herein disclose means for identifying impacted test cases due to code changes by comparing and analyzing a target release code and a reference release code. 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.
[0013] FIG. 1 illustrates block diagram of the impact analysis engine, as disclosed in the embodiments herein. The impact analysis engine comprises a code release block 101 and a test impact analyzer 102. The code release block 101 further comprises a source code database 101.a and a compiled intermediate code database 101.b. The test impact analyzer 102 further comprises a compiled code disassembler 102.a, a language parser 102.b, a code instrumentor 102.c, a source code compiler 102.d, a source code instrumentor 102.e, a code construct store 102.f, a lexical analyzer 102.g, a code coverage register 102.h, a test case runner 102.i, a coverage analytics engine 102.j, a code coverage analytics store 102.k, an impact analytics engine 102.l, and a trend analysis module 102.m.
[0014] The code release block 101 fetches and stores code that needs to be tested so as to identify impacted test cases. In various embodiments, the codes may be managed or unmanaged codes. If the input code is unmanaged code, source codes may be directly analyzed and the source codes corresponding to the target release source and the reference release source are saved in the source code database 101.a. If the input is managed code, the source codes are compiled and corresponding compiled intermediate codes are stored in the compiled intermediate code database 101.b. In another embodiment, the source and compiled codes may not be stored in the source and compiled code repository always and may be fed as direct inputs.
[0015] The test case impact analyzer 102 fetches codes from the code release block and analyzes the fetched codes to identify impacted test cases due to change in codes. The compiled code disassembler 102.a fetches and analyzes compiled intermediate code from the compiled intermediate code database 101.b and disassembles and extracts abstract intermediate code constructs. The extracted abstract intermediate code constructs are then stored in the code construct store 102.f.
[0016] If the input is a unmanaged release source code, the test case impact analyzer 102 parses the source code using the language parser 102.b. The parsed data is then fed to the lexical analyzer 102.g which processes the data and extracts intermediate code constructs. The code instrumentor 102.c may be used to instrument the compiled intermediate code. During the code instrumentation process, the code instrumentor 102.c inserts dynamic instructions to record code coverage hits to the compiled intermediate code.
[0017] If input is managed release source code, the test case impact analyzer 102 may use a combination of source code compiler 102.d and source code instrumentor 102.e so as to process input source codes. The source code compiler 102.d compiles the source code and the source code instrumentor 102.e instruments instructions to record coverage hits to the compiled code. The test case runner 102.i is used to execute test cases in a code execution environment so as to generate coverage hits. In various embodiments, the code execution may take place in a code execution environment which provides a necessary run time environment for executing the software release. Execution of the instrumented code generates coverage hits. The coverage hits are then stored in the code coverage register 102.h. The coverage analytics engine 102.j generates a test case to code coverage mapping by analyzing coverage data and test cases stored in corresponding databases. The mapped code coverage data is then stored in the code coverage analytics store 102.k. The impact analytics engine 102.i analyzes the code constructs stored in the code construct store 102.f and the code coverage data stored in the code coverage analytics store 102.k and identifies impacted test cases. The impact analytics engine 102.i may also identify uncovered code coverage blocks.
[0018] In a preferred embodiment, the system can perform trend analysis using the impacted test case information. The trend analysis is performed to identify or predict any future issues that the particular application under test may have in future and is also used to identify current areas which need to be re-structured so as to eliminate any flaw. The trend analysis is further used to assess quality/stability of the application being analyzed.
[0019] The trend analysis is performed by mapping impacted test case results with various versions of build test cases. While mapping, the system identifies code areas for which test results got failed. This information is further analyzed and compared with other versions of the build. Based on the identified data, a trend analysis report is generated and provided to the user. In another embodiment, in addition to the trend analysis report, a separate bug analysis report also is generated which provides information on areas of the application under test, which is prone to malfunction.
[0020] The impact analysis engine 100 is also used to generate test case intermediate code coverage from compiled machine code. In various embodiments, the test case intermediate code coverage may be generated with or without debug information available. In various other embodiments, the test case intermediate code coverage may be generated with or without Instrumenting the application to be tested, depending upon whether the compiled machine code comprises debug information or not. Further, the trend analysis module 102.m may be used to perform a trend analysis so as to check stability of the application under test and to identify any possible areas of failure with the application in future.
[0021] FIG. 2 is a flow diagram that shows various steps involved in the process of identifying impacted test cases for unmanaged codes, as disclosed in the embodiments herein. Release source codes to be tested are stored in the source code database 101.a of the code release block 101. In order to identify impacted test cases due to code changes, the test impact analyzer 102 fetches target release source and reference release source of an application as inputs. The target release source may refer to code of an improved version of an application (say; Version 2) whereas reference release resource may refer to code of a previous version of the same application (say; Version 1).
[0022] The unmanaged code directly gets compiled to target platform machine level instructions. So in order to analyze this code further, the input source code is initially parsed (201). The parsed data is then fed to the lexical analyzer 102.g. The lexical analyzer 102.g analyzes the parsed data and extracts (202) code constructs. The code constructs may provide minute level information such as classes, method, method instructions code and so on related to the code being analyzed. The extracted code constructs are then stored in the code construct store 102.f.
[0023] The target and reference source codes are then compiled (203) by the source code compiler 102.d. The compiled code output is then fed as input to the source code instrumentor 102.e which instruments (204) the compiled code. During the instrumentation process, the source code instrumentor 102.e inserts dynamic instructions to record coverage hits. In an embodiment, the code instrumentation may take place parallel to the code compilation process. The instrumented codes are then fed as input to the test case runner 102.i. The test case runner 102.i executes (205) the instrumented code in a code execution environment. In a preferred embodiment, the code execution environment provides necessary runtime environment for executing software release. Execution of instrumented code generates coverage hits. These coverage hits are recorded (206) in the code coverage register 102.h.
[0024] Further, the coverage analytics engine 102.j generates a test case to code coverage mapping by analyzing coverage data and test cases stored in corresponding databases. The mapped code coverage data is then stored in the code coverage analytics store 102.k. The impact analytics engine 102.i analyzes the code constructs stored in the code construct store 102.f and the code coverage data stored in the code coverage analytics store 102.k and identifies (207) impacted test cases. The impact analytics engine 102.i may also identify uncovered code coverage blocks. The various actions in method 200 may be performed in the order presented, in a different order or simultaneously. Further, in some embodiments, some actions listed in FIG. 2 may be omitted.
[0025] FIG. 3 is a flow diagram that shows various steps involved in the process of identifying impacted test cases for managed codes, as disclosed in the embodiments herein. If the input is managed code, the test case impact analyzer 102 compiles (301) the source code using the source code compiler 102.d. Output of the compiler is compiled code binaries. The compiled code is then directly instrumented (302) using the code instrumentor 102.c. During the instrumentation process, the code instrumentor 102.c inserts dynamic instructions to record coverage hits. In an embodiment, the code instrumentation may take place parallel to the code compilation process. The instrumented codes are then fed as input to the test case runner 102.i. The test case runner executes (303) the instrumented code in a code execution environment. In a preferred embodiment, the code execution environment provides necessary runtime environment for executing software release. Execution of instrumented code generates coverage hits. These coverage hits are recorded (304) in the code coverage register 102.h.
[0026] Further, the coverage analytics engine 102.j generates a test case to code coverage mapping by analyzing coverage data and test cases stored in corresponding databases. The mapped code coverage data is then stored in the code coverage analytics store 102.k. The impact analytics engine 102.i analyzes the code constructs stored in the code construct store 102.f and the code coverage data stored in the code coverage analytics store 102.k and identifies (305) impacted test cases. The impact analytics engine 102.i may also identify uncovered code coverage blocks. 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.
[0027] 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.
[0028] The embodiment disclosed herein specifies a system for identifying impacted test cases due to code changes. The mechanism allows identification of impacted test cases and uncovered code coverage blocks, 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.
[0029] 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 identifying impacted test cases due to code changes in software testing, said method comprises:
fetching a target release source code and a reference release source code as input;
identifying whether said input code is a managed code or an unmanaged code;
identifying impacted test cases on said input being an unmanaged code; and
identifying impacted test cases on said input being a managed code.
2. The method as in claim 1, wherein said identifying impacted test cases for unmanaged code further comprises:
parsing said target release source code and a reference release source code;
generating code constructs corresponding to said target release source code and said reference release source code;
generating compiled code corresponding to said target release source code and said reference release source code;
instrumenting said generated compiled code;
executing test cases and recording code coverage hits;
generating code coverage data; and
analyzing code constructs and code coverage data.
3. The method as in claim 2, wherein said instrumenting said compiled code further comprises inserting dynamic instruction to record coverage hits to said compiled code.
4. The method as in claim 2, wherein said test cases are executed in a code execution environment.
5. The method as in claim 2, wherein said generating code coverage data further comprises mapping said recorded code coverage hits and test case data.
6. The method as in claim 1, wherein said identifying impacted test cases for managed code further comprises:
compiling said target release source code and said reference release source code and generating code constructs;
instrumenting compiled intermediate code;
executing test cases and recording code coverage hits;
generating code coverage data; and
analyzing code constructs and code coverage data.
7. The method as in claim 6, wherein said instrumenting said compiled intermediate code further comprises inserting dynamic instruction to record coverage hits to said compiled intermediate code.
8. The method as in claim 6, wherein said test cases are executed in a code execution environment.
9. The method as in claim 6, wherein said generating code coverage data further comprises mapping said recorded code coverage hits and test case data.
10. The method as in claim 6, wherein said instrumenting the compiled intermediate code is executed in parallel to said compiling the target release source code and said reference release source code.
11. The method as in claim 1, wherein a trend analysis is performed based on said identified impacted test cases for an application.
12. The method as in claim 11, wherein said performing trend analysis based on said identified impacted test cases for said application further comprises:
fetching test results corresponding to said identified impacted test cases;
mapping said fetched test results with a code coverage information;
collecting information on at least one affected code area for which said test case failed; and
comparing said identified affected code area information with a plurality of versions of said application.
13. A system for identifying impacted test cases due to code changes in software testing, said system configured for:
fetching a target release source code and a reference release source code as input using a test case impact analyzer;
identifying whether said input code is a managed code or an unmanaged code using said test case impact analyzer;
identifying impacted test cases on said input being an unmanaged code using said test case impact analyzer; and
identifying impacted test cases on said input being a managed code using said test case impact analyzer.
14. The system as in claim 13, wherein said test case impact analyzer is further configured for identifying said impacted test cases for unmanaged code by:
parsing said target release source code and a reference release source code using a language parser;
generating code constructs corresponding to said target release source code and said reference release source code using a lexical analyzer;
generating compiled code corresponding to said target release source code and said reference release source code using a source code compiler;
instrumenting said generated compiled code using a code instrumentor;
executing test cases using a test case runner;
recording code coverage hits using a code coverage register;
generating code coverage data using a coverage analytic engine; and
analyzing code constructs and code coverage data using an impact analytics engine.
15. The system as in claim 14, wherein said code instrumentor is configured for instrumenting said compiled code by inserting dynamic instruction to record coverage hits to said compiled code.
16. The system as in claim 14, wherein said test case runner is configured to execute said test cases in a code execution environment.

17. The system as in claim 14, wherein said coverage analytic engine is further configured to generate said code coverage data by mapping said recorded code coverage hits and test case data.
18. The system as in claim 13, wherein said test case impact analyzer is further configured to identify said impacted test cases for managed code by:
compiling said target release source code and said reference release source code and generating code constructs using a source code compiler;
instrumenting compiled intermediate code using a code instrumentor;
executing test cases and recording code coverage hits using a test case runner;
generating code coverage data using a coverage analytics engine; and
analyzing code constructs and code coverage data using an impact analytics engine.

19. The system as in claim 13, wherein said code instrumentor is further configured to instrument said compiled intermediate code by inserting dynamic instruction to record coverage hits to said compiled intermediate code.
20. The system as in claim 18, wherein said test runner is further configured to execute said test cases in a code execution environment.
21. The system as in claim 18, wherein said coverage analytics engine is configured to generate said code coverage data by mapping said recorded code coverage hits and test case data.
22. The system as in claim 18, wherein said code instrumentor and said source code compiler functions in parallel.
23. The test case impact analyzer as in claim 13 is further configured to perform a trend analysis based on said identified impacted test cases for an application.

24. The test case impact analyzer as in claim 23 is configured to perform said trend analysis based on said identified impacted test cases for said application by:
fetching test results corresponding to said identified impacted test cases using a trend analysis module;
mapping said fetched test results with a code coverage information using said trend analysis module;
collecting information on at least one affected code area for which said test case failed using said trend analysis module; and
comparing said identified affected code area information with a plurality of versions of said application using said trend analysis module.

Dated : 21st June, 2013 Signature
Vikram Pratap Singh Thakur

ABSTRACT

The embodiments herein relate to software testing and, more particularly, to identify impacted test cases due to code changes in software testing. When an application has to be tested for identifying impacted test cases, corresponding release source code and target source code are fetched as inputs. Further, the system checks whether the fetched code is managed code or unmanaged code. Managed code directly gets compiled into intermediate code which may be analyzed further whereas the unmanaged code gets compiled into machine specific codes. So the unmanaged code is initially processed using a combination of compiler and instrumentor to convert to a form that may be analyzed further. Then instructions to record coverage hits are inserted to the codes which are then executed. Coverage hits produced during code execution are recorded and analyzed further to identify impacted test cases.

Fig. 1