The Light Coverage profiler lets you determine whether a routine or a line was executed during the profiler run. The following sections provide an overview of the Light Coverage profiler:
General Information
The Light Coverage profiler tracks one thing: whether a routine or a line was called during the run. This lets you keep track of untested code as testing progresses over time. It may also let you find unnecessary code that you can remove, once you see that the method or line remains unexecuted under all possible conditions.
The Light Coverage profiler has some specifics that makes it especially suitable for using in daily regression tests. Since it does not allocate results by threads, it allows you to collect mass statistics with ease. We recommend using the Light Coverage profiler with the Auto-merge option enabled to have results merged automatically after every profiler run. For more details on the Light Coverage profiler specifics, see below.
The Light Coverage profiler can analyze the application code (32-bit and 64-bit) at two levels of detail: routine and line.
-
If a routine was added to the routine-level area, the Light Coverage profiler collects information for the entire routine. To make the Light Coverage profiler track all application routines, check the All Project Modules (Routines only) area in the Code to Profile pane of the Setup panel.
-
If a routine was added to the line-level area, the Light Coverage profiler collects information for each line of source code within it. To make Light Coverage profiler track all application routines by lines, check the All Project Modules (Collect info about lines) area in the Code to Profile pane of the Setup panel. Note, however, that profiling a large amount of code at the line level can significantly slow down the profiling speed.
To profile managed routines at the line level, you have to compile the application with debug information. See How AQTime Profilers Use Metadata and Debug Information.
The Light Coverage profiler operates during the entire application run. It takes no account of triggers and actions, and disables the Enable/Disable Profiling button.
Note on script profiling: In some cases results of script profiling may contain duplicated items in the Report panel for some script routines (this may happen due to some specifics of the script engine's and the Light Coverage profiler's functioning). To learn how you can solve this problem, see Profiling Scripts - Troubleshooting.Profiling Modes
The Light Coverage profiler can run in one of two profiling modes: Profile code in debuggee process and Profile code in any process. The main difference between these modes is the type of modules to which the modes are applied:
-
The Profile code in debuggee process mode is used to profile all types of code (both managed and unmanaged), except for hooks. It tracks when the profiled modules are loaded by the application (that is known beforehand) and then provides you with the information received from this application after the profiling is over.
-
The Profile code in any process mode is typically used for profiling hooks. The main character in profiling hooks is the fact that it is not known beforehand which process exactly loads this hook. To handle such situations, AQTime provides you with the mentioned mode that does not require knowing the name of the process or application that will load the profiled module. It just needs the name of the module so it can access it and modify.
When you start profiling, AQTime searches for the profiled module, modifies its source so it automatically collects needed information from the moment it has been loaded. The original version of the module is not deleted from the disk. AQTime just renames and saves it in the same folder where it has been located. After that, you need to run the application that will load the profiled module so that the module starts collecting profiling information and then passes it to AQTime after the profiling is terminated. Right after AQTime has received all the needed information, it deletes the modified module from the disk and restores the original version of the file under the initial name.
Note: | If you try using the Profile code in any process mode for profiling any other type of modules (not hooks), the profiling results will be the same as if you used the Profile code in debuggee process mode. Another characteristic feature of using the Profile code in any process mode is the fact that this mode does not allow profiling managed code. If you try using it to profile any managed code, the profiling results will be empty. |
To change the currently used mode, use the Profile code option in the Light Coverage Profiler Options dialog.
Light Coverage vs. Coverage
The Light Coverage profiler is very similar to the Coverage profiler. Both profilers perform the same task but there are some differences between them. Generally, the Light Coverage profiler works faster and consumes less memory, that is why it is especially useful in daily regression testing.
When profiling a native-code (unmanaged) application, the Light Coverage profiler works faster in general. However, the Light Coverage profiler does not provide any advance in time or resource usage when profiling .NET, Java applications and scripts due to their certain specifics. |
In comparison to the Coverage profiler, the Light Coverage profiler also has some specifics:
-
The Light Coverage profiler does not track the hit count.
-
The Light Coverage profiler does not trace partially executed lines. If at least one block of a line was executed, the profiler treats the entire line as executed.
-
The Light Coverage profiler does not collect profiling results by threads.
This feature may be a benefit if you use the Light Coverage profiler to profile your application when testing it with TestComplete. Application threads typically have different names between different application runs and AQTime cannot determine that this thread is the same. This complicates merging results. Unlike the Coverage profiler, the Light Coverage profiler does not organize results by threads, so you can enable Auto-merge and collect mass statistics for your daily regression tests with ease.
To measure code coverage in large applications, you can first profile your application with the Light Coverage profiler, find the most problematic areas and then profile these areas with the Coverage profiler and get more detailed information. For more tips on coverage profiling, see Coverage Profiling - Tips.
See Also
Light Coverage Profiler
Coverage Profiler - Overview
Comparing Results
Merging Results
Profiling .NET Applications - Specifics