Dynamic Code Analysis | Code Profiling and Code Coverage | BEA

Dynamic code analysis
enables a development team to obtain a holistic view of an enterprise application in the running state, contrary to the static code analysis that involves analyzing code without even compiling it.

- Dynamic Code Analysis

Code Profiling

• Code profiling is one of the focus areas of dynamic code analysis, which is primarily concerned with the performance analysis of an application that enables the development team to quantify the performance aspects of an enterprise application.
• Code profiling of an enterprise application is not just limited to the application code for business logic. The underlying database may also have several application components such as stored procedures and triggers. These components are typically written using languages such as PL/SQL and T-SQL, which also may need to be analyzed to further fine tune the performance.
• It is basically Performance-analysis.
• Code Profiling is basically used to improve the performance of the code.
• It helps to analyze the performance of the application and improve poorly performing sections of the code.
• It used by developers, without changing their code, to help identify performance problems.
• It can answer questions like how many times each method in code is called and how long does each of those methods take. It tracks things like memory allocations and garbage collection.
• Profiling is achieved by instrumenting either the program source code or its binary executable form using a tool called a profiler(or code profiler). Profilers may use a number of different techniques, such as event-based, statistical, instrumented, and simulation methods.
• Profilers use a wide variety of techniques to collect data, including hardware interrupts, code instrumentation, instruction set simulation, operating system hooks, and performance counters. Profilers are used in the performance engineering process.

Code Coverage

• Code coverage is a measure used to describe the degree to which the source code of a program is executed when a particular test suite runs. 
• A program with high test coverage, measured as a percentage, has had more of its source code executed during testing, which suggests it has a lower chance of containing undetected software bugs compared to a program with low test coverage.
• This does not check the functionality of an enterprise application, but finds out what percentage of the codebase is not being executed as part of execution of test cases.
• This helps in ensuring that the test cases created for checking the functionality are adequate.
• There are a number of coverage criteria, the main ones being:

1. Function coverage – Has each function (or subroutine) in the program been called?
2. Statement coverage – Has each statement in the program been executed?
3. Edge coverage – has every edge in the Control flow graph been executed?
4. Branch coverage – Has each branch (also called DD-path) of each control structure (such as in if and case statements) been executed? For example, given an if statement, have both the true and false branches been executed? Notice that this one is a subset of Edge coverage.
5. Condition coverage (or predicate coverage) – Has each Boolean sub-expression evaluated both to true and false?