Visualization example 1: Code coverage
Runtime analysis with a tool such as PureCoverage® (included in PurifyPlus) provides various views to code coverage information, one of them being Annotated Source. This particular view shows the source file of the examined application; the color of the line indicates the line's status after the executed test case: hit, missed, dead, or partially hit.
As Figure 1 shows, the user can see code coverage and the execution path for this test case.
The code fragment in Figure 1 shows the exact path the application took when executing the switch statement on line 111. This particular line is marked as partially hit because line 122 hasn't been executed.
Figure 1: PurifyPlus display of annotated source for the C#.NET application in Visual Studio.NET
Visualization example 2: Threads
A runtime analysis tool such as Quantify (included in PurifyPlus) provides thread visualization, which can assist in detecting multithreading problems by marking the state of each of the threads while debugging. As Figure 2 shows, this allows you to examine the status of threads visually, while debugging.
Figure 2: Quantify thread analysis view in Visual Studio 6
Visualization example 3: Call graph
Runtime analysis tools can also detect and display performance bottlenecks. The big advantage of this approach, compared to traditional methods, is that you can get an excellent overview of the execution path as well as precise information about the number of calls to the methods involved in the scenario. As Figures 3A and 3B show, the Call Graph in Quantify highlights a chain of calls in the most time-consuming execution path; that is the performance hotspot. The thickness of the line connecting methods is proportional to the ratio between the time (or memory if you are using Purify) spent in this chain of calls and the rest of the application.
Figure 3A: Quantify call graph of a mixed VB.NET and C#.NET application in Visual Studio.NET
Figure 3B: Quantify call graph of a C/C++ application on Solaris
Visualization example 4: Memory usage
The first step in handling memory leaks is to detect them. One very intuitive way to do this is to visualize overall memory usage and take snapshots of memory in the program under test (PUT). This lets you see potential memory leaks in the running application. (This feature is available in Purify for Java and .NET managed applications.) For example, if snapshots of memory usage for the component running on the server show that overall memory usage increases after each client session, then it is very likely that this component leaks memory.
Figure 4: Overview of thread status and memory usage in Purify for Windows