Rational test tools tutorial

In order to look at these reports: 7. All four runtime analysis reports will open. Close the Project Explorer window and the Output Window at the bottom of the UI to create room for the now-opened reports.

You may also want to resize the left-hand window to gain additional room. Select the Runtime Trace tab. As you recall, the Runtime Trace viewer displayed all objects and all method calls involved in the execution of the UMTS base station code.

Using the toolbar Zoom Out button, zoom out from the tracing diagram until you can see at least five vertical bars. Make sure you are looking at the top of the runtime tracing diagram using the slider bar on the right. What you are looking at is a sequence diagram of all events that occurred during the execution of your code. This sequence diagram uses a notation taken from the Unified Modeling Language, thus it can be correctly referred to as a UML-based sequence diagram.

The vertical lines are referred to as lifelines. The very first lifeline, represented by a stick figure, is considered the "world" - that is, the operating system.

In this UMTS base station tracing diagram, the next lifeline to the right represents an object instance named Obj1, derived from the UmtsServer class. Green lines are constructor calls, black lines are method calls, red lines are method returns, and blue lines are destructor calls. Hover the mouse over any method call to see the full text. Notice how every call and call return is time stamped. Everything in the Runtime Trace viewer is hyperlinked to the monitored source code.

For example, if you click on the ObjUmtsServer lifeline, the header file in which the UmtsServer class declaration appears is opened for you, the relevant section highlighted. Close the source file by right-clicking the tab of the Text Editor and selecting Close.

All function calls can be left-clicked as well in order to view the source code. Look at the very top of the ObjUmtsServer lifeline. It's "birth" appears to consist of a List constructor first, then a UmtsServer constructor.

Why a call to the List constructor if the object is an instance of the UmtsServer class? Click on the UmtsServer lifeline again - see how the UmtsServer constructor inherits from the List class?

This is why the List constructor is called first. Click the two constructor calls if you wish to pursue this matter further. Notice how the window on the left-hand side of the user interface - called the Report Window - contains a reference to all classes and class instances. Doubleclicking any object referenced in this window will jump you to its birth in the Runtime Trace viewer. This window can also be used to filter the runtime tracing diagram. H - notice how all objects derived from the NetworkNode class declared in this header file are reduced to a single lifeline.

You've probably noticed the vertical graph with the green bar to the left of the Runtime Trace viewer. This is the Coverage Bar. It highlights, in synchronization with the trace diagram, the percentage of total code coverage achieved during execution of the monitored application. The Coverage Bar's caption states the percentage of code coverage achieved by the particular 25 5.

Scroll down the trace diagram; note how code coverage gradually increases until a steady state is achieved. This steady state is achieved following the moment at which the mobile phone has connected to the UMTS base station.

Dialing the phone number increases code coverage a bit; shutting off the phone creates a last burst of code coverage up until the moment the UMTS base station is shut off. Can you locate where, on the trace diagram, the mobile phone simulator first connected to the UMTS base station?

The Coverage Bar can be toggled on and off using the right-click-hold menu within the Runtime Trace viewer.

A doubleclick on this bar would open a threading window, detailing thread state changes throughout your application's execution.

This thread monitoring feature is also available for the Java language. Continue to look around the trace diagram. You can filter out this loop using a couple of methods. One is to simply hover the mouse over a method or function call you wish to filter, right-click-hold and select Filter Message.

An alternative method would be to build your own filter. You will do both. Select it if necessary. Click the OK button. The loop has been removed. View the very bottom of the runtime tracing diagram using the slider bar.

H node in the left-hand report window will also make things easier to see? This Catch Exception statement is preceded by a diagonal Throw Exception. Why diagonal? Because when the 26 Runtime Analysis exception was thrown, prior to executing the Catch statement, the LostConnection constructor and UmtsMsg destructor were called. Click various elements to view the source code involved in the thrown exception and thus decipher the sequence of events.

Understanding Memory Profiling The Memory Profile viewer displays a record of improper memory usage within the application of interest. To read the Memory Profiling report: 1. Select the Memory Profile tab. First, block and byte memory use is summarized for you in a bar chart, immediately followed by a textual description to the same information.

The Report Window on the left hand side of the screen gives you a quick look at the contents of the report - your manual interaction with the UMTS base station via the simulated mobile phone has resulted in the creation of Test 1.

If you click an item in the Report Window, the memory profiling report will scroll to the proper location. This error report is followed by the call stack, with the last function in the call stack listed first. Notice how each function is highlighted; clicking on the functions in the call stack will jump you to the relevant source code.

As for the memory leaks - well it looks like you have some work to do here. Although it is conceivable the memory leak occurs by design e. The memory profile report lists the exit code as a warning if it is of any value other than 0. Notice how easily this information has been acquired; no work was required on your part. A real advantage is that memory leak detection can now be part of your regression test suite.

Traditionally, if embedded developers looked for memory leaks at all, it was done while using a debugger - a process that does not lend itself to automation and thus repeatability.

The memory profiling feature lets you automate memory leak detection. And again, the identical functionality can be used on either your host platform or on your embedded target.

Understanding Performance Profiling The Performance Profile viewer displays the execution time for all functions or methods executing within the application of interest, thereby allowing the user to uncover potential bottlenecks.

This is then followed by a sortable list of every function or method, with timing measurements displayed. To read the Performance Profiling report: 1. Select the Performance Profile tab. By looking at the table, where times are listed in microseconds, we can see that this function's average execution time was between 1 to 2 seconds it will vary somewhat based on your machine and that it has no descendents - i. Is this to be expected?

If you wished, you could click on the function name in the table to jump to that function to see if its execution time can be reduced. Each column can be used to sort the table - simply click on the column heading. The main procedure spends its life waiting for the UMTS base station to exit.

As with the memory profiling feature, notice how easy it was to gather this information. Performance profiling can now also be part of your regression test suite. And again, as with every other runtime analysis feature, performance profiling functionality is identical whether it is used on your host platform or on your embedded target. Understanding Code Coverage And finally, here you have the code coverage analysis report.

The code coverage feature exposes the code coverage achieved either through manual interaction with the application of interest or via automated testing. To view the Code Coverage report: 1. Select the Code Coverage tab. On the left hand side of the screen, in the Report Window, you see a reference to Root and then to all of the source and header files of the UMTS base station.

Root is a global reference - that is, to overall coverage. For each individual source and header file, a small icon to the left indicates the level of coverage green means covered, red means not covered. In the Code Coverage viewer, on the Source tab, a graphical summary of total coverage is presented in a bar chart - that is, information related to Root.

These levels are required by stringent certification standards such as aviation's DOB. Notice how, on the toolbar, there is a reference to these five possible coverage levels 2. Deselect Loops Code Coverage. Notice how the bar chart is updated. The Source tab now displays the source code located in the file PhoneNumber.

Green means the code was covered, red means the code was not covered. In the Report Window, expand the PhoneNumber. Notice how its for instruction is colored orange and sitting on a dotted underline. This is because the for statement was only partially covered. Click on the orange for keyword in the clearNumber function As you can see, the for loop was only executed multiple times, not once or zero times.

Why should you care? Well some certification agencies require that all three cases be covered for a for statement to be considered covered. If you don't care about this level of coverage, just deselect Loops Code Coverage: 7. On the toolbar, deselect Loops Code Coverage. Now the for loop is green. If you would like to add a comment to your code indicating how this loop is not covered by typical use of the mobile phone simulator, have a look at the code by right-clicking the for statement and selecting Edit Source.

Note how a selection of the Root node gives you a summary of the entire application. From the File menu, select Save Project. Conclusion of Exercise Two With virtually minimal effort, you have successfully instrumented your source code for all four runtime analysis features. Manual interaction in your case, via a mobile phone simulator was monitored, and the subsequent runtime analysis results were displayed for you graphically.

Source code is immediately accessible from these reports, so nothing prevents the developer from using the results to correct possible anomalies. In addition, using the Test by Test option provided with each runtime analysis feature introduced in the Further Work section for code coverage , you can easily discern the effectiveness of a test, ensuring maximal reuse without waste.

To locate and fix memory errors: 1. Select the last function first, the one that occurs inside main Within the main procedure a UmtsServer object is instantiated. Nothing looks out of sorts here, so return to the call stack. Close the source file for the main procedure, and then click the second function from the bottom in the call stack referenced by the ABWL error - the UmtsServer constructor.

The next function in the stack is the UmtsServer constructor. The line in the constructor that is flagged, the creation of a NetworkNodes object, is a call to the List constructor.

Continue to follow the sequence of events. Close the source file for the UmtsServer constructor, and then click the top function in the call stack referenced by the ABWL error - the List constructor.

The highlighted line is a call to malloc. A quick look at this function shows that a return to the UmtsServer constructor is fairly quick, and nothing seems unusual.

You should continue to track the string of events as they happened to see if the ABWL error shows itself. Return to the UmtsServer constructor. Close the source file for the List constructor, and then click the second function from the bottom in the call stack referenced by the ABWL error - the UmtsServer constructor. What happens next? The NetworkNodes object was assigned 3 List objects in an array.

Immediately following the call to the List constructor, 4 elements are assigned to this array. Not good. The NetworkNodes object should be an array of 4 List objects, not 3. From the File menu, select Save. The revised file UmtsServer. This should fix the ABWL error. Before redoing you manual test to verify if the memory error was fixed, move on to the Performance Profile viewer and see if you can streamline the performance of the UMTS base station code.

As for the other memory warnings - that's for you to figure out! To locate and fix performance bottlenecks: 1. Within the table, left-click the column title Avg F Time Average Function Time in order to sort the table by this column. You may want to scroll down the report a bit to view more data elements in the table. For this exercise you have sorted by the Average Function Time - that is, you're looking at functions that take, on average, the longest time to execute.

This isn't the only potential type of bottleneck in an application - for example, perhaps it is the number of times one function calls its descendants that is the problem but for this exercise, you will look here first. Instead look at a different function in the table. Select the link for the C function checkUmtsNetworkConnection A quick look at the source code shows you that the developer treated this as a dummy function, inserting a "time-waster" to make it appear as if the function were executing.

Simply comment out the line. There is another UmtsServer class method that also needs to be improved. Have a look, if you wish. Using Code Coverage Analysis to Improve Code Coverage You will now use the information gathered by the code coverage analysis feature to modify the manual test in such a way as to improve code coverage. To improve coverage of your code: 1. In order to improve coverage of this if statement, you need to make the boolean expression evaluate to true. According to this code, the if expression would evaluate to true if mobile phone sends the phone number You should do that.

You will now rerun the UMTS base station executable, restart the mobile phone simulator, and dial this new phone number. When you have finished, you will check the memory profiling, performance profiling, and code coverage analysis reports to see if you have improved matters. The integrated build process of Test RealTime is aware of these changes, so you do not have to specify the particular files that have been modified.

From the Window menu, select Close All. Right-click the BaseStation application node and select Rebuild. When you select Rebuild, all files are rebuilt, whereas Build simply rebuilds those files that have been changed.

If no files had been changed, you could have just selected Execute BaseStation. Once the UMTS base station is running indicated by the appearance of the Runtime Trace viewer , run the mobile phone simulator as before. Wait for the mobile phone to connect to the UMTS base station if you watch the dynamic trace closely, you'll notice a display of all the actions that occur when a phone registers with the server.

The time should appear in the mobile phone window. You have connected to the intended party. Stop right here to see the results of your work. Close the mobile phone window by clicking the button on the right side of its window caption. As you may recall, this action will shut down the UMTS base station as well. Wait for it 8. All four runtime analysis reports will open with refreshed information.

Close the Project Explorer window to the right and the Output Window at the bottom. So have you improved your code and increased code coverage? To check that the memory leak was fixed: 1.

You successfully eliminated the ABWL error. Have you improved performance? To check that performance was improved: 1. You successfully improved performance. Was code coverage improved? To check that code coverage was improved: 1. In the Report Window on the left-hand side of the screen, open the node for UmtsConnection. Has code coverage been improved? You successfully improved code coverage. Note, by the way, that you can discern what this second manual interaction has gained you in terms of code coverage.

However, what tests are listed for the if statement itself? As further proof, do the following. With your mouse anywhere on the Source tab of the Code Coverage viewer, right-click and deselect Cross Reference In the Report Window, on the left-hand side of the screen, open the Tests node and deselect the checkbox next to Test 2.

Since you have deselected Test 2, all you are left with is the code coverage that has resulted from running Test 1, and Test 1 never forced the if statement to evaluate to true.

Thus the newly covered code has become red again - in other words, unevaluated. Conclusion of Exercise Three After correcting the UMTS base station code directly in the Test RealTime Text Editor, you simply rebuilt your application and used the mobile phone simulator to initiate further interaction. A second look at the runtime analysis reports validated the accuracy of your changes.

Consider the speed with which you could perform these monitoring activities once you are familiar with the user interface Conclusion Conclusion - with a Word about Process Automated memory profiling, performance profiling, runtime tracing, and code coverage analysis - no less important in the embedded world than elsewhere in software. So why is it done less often? Why is it so much harder to find solutions for the embedded market?

Rational Test RealTime and Rational PurifyPlus RealTime have been built expressly with the embedded developer in mind, so all of the above complications have been overcome. Nothing stands between you and the use of a full complement of runtime analysis features in both your native and target environment.

So use them! It should be automatic - part of all your regression testing efforts discussed in greater detail in the Tutorial conclusion. As you have seen, these functions are only a mouse-click away so there is absolutely no drain on your time. You may be concerned about the instrumentation - "But I don't want my final product to be an instrumented application. Doesn't it have to be if I'm testing instrumented code?

Time to ship Make it part of your development process, just another step before you check in code for the night. Does this mean you, as a developer, no longer have any responsibility regarding your software's usage of memory?

Not in the traditional way, where memory is no longer referenced by your application and yet not accessible by the system OS - such a problem can not occur. However, if you allocate memory, use it, then fail to free i.

Do this enough and your system will still run out of memory. Excessive memory usage can result in application slowdown. Do you know how much memory your application is using at any given time? If you have access to limited memory, do you know how much your application has allocated? Are there places in your code that could be optimized to use less memory, thereby freeing systems resources for other activities? Such information can be used to ensure all unnecessary memory has been dereferenced and that memory usage has been optimized.

This function is provided in Rational Test RealTime by the memory profiling feature for the Java language. Performance Profiling 38 Runtime Analysis Optimal performance is, needless to say, crucial for real-time embedded systems.

This function is provided in Rational Test RealTime by the performance profiling feature for the Java language. In addition, product managers need a concrete measurement to determine where the team is in the development cycle - in particular, how much more testing needs to be done.

This function is provided in Rational Test RealTime by the code coverage feature for the Java language. This problem becomes more severe when the code is inherited. This function, using the industry standard Unified Modeling Language for its graphical display, is provided in Rational Test RealTime by the runtime tracing feature for the Java language. Runtime Analysis Exercises The following exercises will walk you through a typical use case involving the four runtime analysis features of Test RealTime and PurifyPlus RealTime to which you have just been introduced.

For the tutorial, it is assumed that the test project will be stored in a folder called tmp Do you have JDK 1. This is necessary for performance of the tutorial. Open the. To create a project: 1. This Tutorial will assume that the project has been stored in the tmp folder. This is the same TDP you configured earlier in the tutorial. In this tutorial you are starting with a focus on the runtime analysis features, so select the Runtime Analysis link.

Select the Add button. You should see these eleven files listed in the large listbox of the Application Files window. This process is used to extract the various methods and classes located within each source file, simplifying code browsing within the UI. For this Tutorial, you will be monitoring everything, so simply click the Next button. In the window entitled Configuration Settings for Java, you need to define your application's class path as well as the fully qualified name of the main class for your application.

The package used by the Java-based UMTS base station is named baseStation, and it's located in the src folder you just referenced. Note For Windows users, if a folder in the path has a name containing a space, change that name following the DOS 8. Your screen should look like this: 6. Now click the Next button. Enter the name of the application node that will be created at the conclusion of the Runtime Analysis Wizard; since you will be monitoring execution of the Javabased UMTS base station, type the word BaseStation within the text field labeled Name.

You also need to make some minor changes to the way you would like the TDP to be used. These modifications are specifically aimed at the memory profiling feature and are being used simply to illustrate additional concepts within the Tutorial. The following custom changes should be made to the Configuration for the purposes of this tutorial: On the right-hand side of the window, set the Value of the Take a Snapshot setting to After Each Garbage Collection. Though it is possible to interactively take memory snapshots during execution, setting this option ensures you will have sufficient data to work with in this tutorial.

This setting ensures you filter out references to objects derived from classes not explicitly defined within the application-undertest. In the Configuration Settings window, click Ok. In the Application Node Name window, click Next. Everything should be in order, so click Finish. The BaseStation application node has now been created in the Project Explorer window, on the Project Browser tab, located on the right-hand side of the user interface.

If you expand the BaseStation application node, you should see the following: 44 Runtime Analysis Why is the exclude status indicated for all but one. This is because the build process need only reference the source file containing the main Java class when calling the Java compiler. This source file is BaseStation. Note how each source file can be expanded to display every class declaration and method definition within them.

To close a Text Editor window, right-click its associated tab and select Close. The first, By Object, lists classes and methods independent of their associated source files. The second, By Directory, sorts source files based on their associated Java packages. The runtime analysis features do not have to be used at the same time; this Build options window provides a quick and simple method for deselecting undesired runtime analysis features immediately prior to execution of the build process.

In order to instrument, compile and execute the UMTS base station application in preparation for runtime analysis, simply ensure the BaseStation application node is selected on the Project Browser tab of the Project Explorer window, and then click the Build button. Notice that in the Output Window at the bottom of the screen, on the Build tab, you can see the instrumentation and compilation phases of the build process as they occur.

A double-click on an error listed within any of the Output Window tabs opens the relevant source code file to the appropriate line in the Test RealTime Text Editor. If you wish, use the Pause toolbar button to stop the dynamic trace for a moment the trace is still being recorded, just no longer displayed in real time.

Through this manual interaction you will expose careless memory usage, performance bottlenecks, incomplete code coverage, and dynamic runtime sequencing. Linux Linux Redhat: MobilePhone. Alternatively, you could have just used the Stop Build button in the toolbar. Close the Project Explorer window to create room for the now-opened reports. Understanding Runtime Tracing The sequence diagram produced by the Runtime Tracing feature uses a notation taken from the Unified Modeling Language, thus it can be correctly referred to as a UML-based sequence diagram.

To view the UML sequence diagram report: 1. Using the toolbar 48 Runtime Analysis buttons , zoom out from the tracing diagram until you can see at least four vertical bars. Right-click within the runtime tracing diagram and select Hide Memory Usage Bar. You will return to these bars in a moment. Each lifeline represents a Java object instance. In this UMTS base station tracing diagram, the next lifeline to the right represents an object instance named Obj0, derived from the UmtsServer class.

For example, if you click on the ObjUmtsServer lifeline, the source file in which the UmtsServer class definition appears is opened for you, the relevant section highlighted. It's "birth" consists of a UmtsServer constructor. Left-click the constructor if you wish to view the steps that occur when an object of the UmtsServer class is instantiated. Double-clicking any object referenced in this window will jump you to its birth in the Runtime Trace viewer.

This window can also be used to filter the runtime tracing diagram; closing a node associated with a source file or class will collapse all of the associated lifelines into a single, consolidated lifeline. Filters Continue to look around the trace diagram.

Can you locate the repetitive loop in which the UMTS base station looks for attempted mobile phone registration it always starts with a call to the method baseStation. An alternative method would be to use a predefined filter. Hover the mouse over any call of the baseStation. Memory Usage Bar The Memory Usage Bar is a graphical representation of the amount of memory allocated by the monitored application at any moment represented within the runtime tracing diagram.

To use the Memory Usage bar: 1. You can now see, along the left-hand side of the runtime tracing diagram, a red, vertical bar. The caption of the Memory Usage Bar indicates the maximum amount of allocated memory that occurred during execution, while the mouse tool tip can be used to discern the amount of allocated memory at any moment along the graph.

Depending on your JVM, you may also notice garbage collection, indicated by areas where there is a sudden drop in the number of allocated bytes.

This diagram can be used to expose memory intensive parts of your program that may in fact be needless churn that slows down overall execution time. You could trigger garbage collection immediately prior to suspect moments within your application, using the Runtime Trace viewer to help you decide where the garbage collection should occur, to study whether or not memory usage has become excessive.

Note that this feature is specific to Java support. The Coverage Bar's caption states the overall percentage of code coverage achieved by the particular interaction presently displayed in the Runtime Trace viewer. To use the Coverage bar: 1. Scroll down the runtime tracing diagram; note how code coverage gradually increases until a steady state is achieved. Can you locate where, on the runtime tracing diagram, the mobile phone simulator first connected to the UMTS base station?

Note that the Coverage Bar is available for all supported languages. Thread Bar The UMTS base station is actually a multi-threaded application; the Thread Bar graphically indicates the active thread at any given moment within the runtime tracing diagram.

To use the Thread bar: 1. Now you are looking at the Thread Bar. Hovering your mouse over the Bar reveals the name of the active thread within a tool tip. A left-click on the Thread Bar opens a threading window, detailing thread state changes throughout your application's execution. Pressing the Filter button in this detail window specifies the state of each thread within the region of the Thread Bar that was double-clicked.

Do you see the icons for the catch statement? The second Catch Exception statement is preceded by a diagonal Throw Exception. Understanding Memory Profiling The Memory Profile viewer displays a memory usage report for the application of interest. To view a Memory Profile report: 1. The Report Window on the left-hand side of the UI displays a list containing each memory snapshot and the time at which they occurred; as you may recall, the TDP Configuration was updated so that a snapshot would occur immediately following each garbage collection.

The Memory Profile tab contains a sortable table i. A left-click on any method names brings you to the portion of source code in which this method has been defined. Referenced Object Class - If any method in the first column continues to reference an object at the time of the snapshot, the object is listed in this column.

Of course, many objects are allocated and deallocated before a snapshot - in this case, the object allocation is recorded but the object reference is not. Allocated Objects- Total number of objects created by a method throughout execution of the monitored application.

Allocated Bytes - Total number of bytes associated with the objects created by a method. A user is able to predefine moments at which a memory snapshot should take place - this is done via Configuration Settings. For example, if you have designed a particular, cyclic portion of your code to deallocate all unnecessary memory prior to each iteration, set a snapshot to occur each time the cycle is entered.

The Memory Profile report contains diff functionality - you will explore this capability later - that can tell you if additional memory remains allocated when the cycle is reentered.

A real advantage is that memory profiling can now be part of your regression test suite. Understanding Performance Profiling The Performance Profile viewer displays the execution time for all methods executing within the application of interest, thereby allowing the user to uncover potential bottlenecks. First, the one or more methods requiring the most amount of time are displayed graphically in a pie chart.

This is then followed by a sortable list of every method, with timing measurements displayed. To view the Performance Profile report: 1. By looking at the table, where times are listed in milliseconds, we can see that this function's average execution time was between 6 to 7 seconds it will vary somewhat based on your machine and that it has no descendents - i.

If you wished, you 53 Rational Test RealTime - Online Tutorial could click on the function name in the table to jump to that function to see if its execution time can be reduced. That distinction goes to readMsg ; though quick by itself, it's execution time when including descendants is the slowest of all. However, a quick investigation of the readMsg function would reveal that this function calls - and that awaits the return of - readString , which explains why the execution time of readMsg takes longer than readString.

Of course, since this is a multi-threaded application, it is possible for one function to reveal itself as the slowest performer while, overall, the monitored application is typically busy doing other things. To view the code coverage report: 1. On the left hand side of the screen, in the Report Window, you see a reference to Root and then to all of the source files of the UMTS base station.

For each individual source file, a small icon to the left indicates the level of coverage green means covered, red means not covered. Five levels of code coverage are accessible for Java, and those five levels are represented here. Notice how, on the toolbar, there is a reference to these five possible coverage levels F, E, B, I and L toolbar buttons. Deselect the L toolbar button to disable Loops Code Coverage.

Select Loops Code Coverage again by selecting the L button. In the Report Window to the left, select the HardwareMonitor. The Source tab now displays the source code located in the file HardwareMonitor. This code is colored to reflect the level of coverage achieved.

Within the run method you should see a while statement that is colored orange and sitting on a dotted underline. This is because the while statement was only partially covered. Click on the orange while keyword in the run method. As you can see, the while loop was only executed multiple times, not once or zero times. Well some certification agencies require that all three cases be covered for a while loop to be considered covered. If you don't care about this level of coverage, just deselect Loops Code Coverage: 6.

Resources Main-content. Environment Setup 2 Lectures. Recording a Script 8 Lectures. Verification Point 6 Lectures. Test Object Map 4 Lectures. Managing Object Repository 2 Lectures. Data-Driven Tests 7 Lectures. Description Rational Functional Tester is an object-oriented automated functional testing tool capable of performing automated functional, regression, GUI, and data-driven testing.

Feedbacks 0 No Feedbacks Yet..! Rational Performance Tester - IBM Rational Performance Tester is a load and performance testing solution for teams concerned about the scalability of their Web-based applications.

Combining ease of use with deep analysis capabilities, Rational Performance Tester simplifies test creation, load generation, and data collection to help ensure that applications can scale to thousands of concurrent users. Rational Purify - Advanced runtime and memory management error detection. Does not require access to source code and can thus be used with third-party libraries in addition to home-grown code. Rational Test RealTime - Cross-platform solution for component testing and runtime analysis.

Designed specifically for those who write code for embedded and other types of pervasive computing products.