Tool Mentor: Executing
Developer Tests Using Rational Test RealTime
Purpose
This tool mentor describes how to execute a test campaign created with Rational Test RealTime.
This activity consists in building and executing the test campaign. Test RealTime
automatically compiles and runs the test application from the implemented test
components.
This section provides links to additional information related to this tool mentor.
Overview
Every organizational entity (referred to as a "node") supported by
Test RealTime can be built and executed as if it were a single test.
At the highest level, Rational Test RealTime supports the notion of a project.
A project is not wedded to any particular notion - that is, the project can
be put to use at the user's discretion. Projects can be linked to other projects,
forming logically nested sub-projects.
At the next level of detail is the Group node. This is an optional type of
node that can be used to group related child nodes (discussed in a moment).
The Group node, when built and executed, causes each associated child node to
be sequentially built and executed.
Within Project or Group nodes, a developer creates Application and Test nodes.
These are the nodes that perform the actual work. An Application node is a node
designed simply for the acquisition of runtime analysis information - that is,
no Test RealTime tests are executed as part of an Application node. A Test node
can be a component test for C, C++, Ada or Java or a system test for C.
The code harness - that is, the code required to enable execution of an Application
or Test node on the intended embedded target - is the responsibility of the
selected Target Deployment Port (TDP) and is independent of the Test node. However,
the Configuration Settings for an Application or Test node can be used to modify
certain settings pertaining to the TDP. For more information, see the Tool Mentor
"Configuring the Test Environment in Rational Test RealTime".
It should be noted that a third type of node does exist - referred to as an
External Command. This node is used to launch executables that might be required
for your test or runtime analysis efforts. Uses might include running external
tests or running simulators
For detailed
information refer to the Rational Test RealTime User Guide, the chapter
Graphical User Interface->Activity Wizards->Component Testing Wizard.
For information on implementing test components, refer to the Tool Mentor titled
Implementing Test Components Using Rational Test RealTime.
Types of Reports
To execute any node within Rational Test RealTime, the developer can use one
of two methods:
All nodes are located on the Project Browser tab of the Project Window located,
by default, on the right-hand side of the GUI.
The right-click menu of a Project, Group, Application and Test node lets the
user Build, Rebuild, Clean and Execute that node. Each has a default definition:
- Build: Recompile only those files who time stamp is later than preexisting
object code, link all code, execute the resulting executable and then generate
the applicable runtime analysis/test reports
- Rebuild: Recompile all source files, link all code, execute the resulting
executable and then generate the applicable runtime analysis/test reports
- Clean: Remove all object code and executables
- Execute: Run the preexisting executable:
Various methods exist for altering the default behavior of Build, Rebuild,
Clean and Execute.
- Select the menu item Build->Options.
The user can select or deselect those phases of the Build process that should
and should not occur. This also gives the user a quick method for shutting
off some or all of the runtime analysis features.
- Right-clicking a node and select Properties.
This brings up a window that can be used to exclude that node from the build
process. Thus, if one of ten child Test nodes of a Group node is excluded
from the build process, then Building the Group node would result in the build
and execution of nine Test nodes.
This right-click menu also enables the execution of a node in the background.
This setting is typically used with External Commands that may precede other
nodes in the build chain. Since the build process also works sequentially,
from the top to the bottom of the Project Browser, running an External Command
in the background prevents subsequent Test, Application and External Command
nodes from having to wait for its completion
Once a node has been built and run, all resulting reports can then be reviewed.
For information on implementing test components, refer to the Tool
Mentor: Analyzing Test Results Using Rational Test RealTime.
For detailed
information refer to the Rational Test RealTime User Guide, the chapter
Graphical User Interface->Working with Projects.
The simplest approach to executing a Rational Test RealTime node from the command
line assumes that all configuration settings are set using the GUI, ensuring
that the only phase left to perform is executing the node of interest. Under
these circumstances, the syntax for running a node from the command line is:
studio -r [node.node.node.<....>node] <project file>
In this case, each child node of the project, include sub-projects., can be
specified using a "dot" notation - that is, separating the name of
each child node from its parent using a period. The project file must always
be listed; if listed by itself, without any child node listed, then the entire
project is built.
When not using the studio command to execute a node, the
user must create source files that can execute Test RealTime tests or acquire
runtime analysis data without conflicting with the user's native compiler and
linker. In both cases - that is, regardless of whether the user is attempting
to execute a Test or Application node - the user's native compiler and linker
do the true work. (In fact, all build activities performed by Test RealTime
are simply command line activities triggered from the GUI.)
For Test nodes, the following commands convert Test RealTime test scripts into
source files supported by the user's native compiler and linker:
- for the C language:
attolpreproC
- for the C++ language:
atoprepro
- for the Ada language:
attolpreproADA
Java does not require a special command because the test scripts are already
.java files
For runtime analysis, the primary choice is whether or not the user wishes
to perform source code insertion as an independent activity or as part of the
compilation and linkage process. (Of course, if no runtime analysis is required,
source code insertion is unnecessary and should not be performed.) To simply
perform source code insertion, use the binaries:
- for the C language:
attolcc1
- for the C++ language:
attolccp
- for the Ada language:
attolada
- for the Java language:
javi
However, if the user would like compilation and linkage to immediately follow
source code insertion, use the binaries:
- for the C and C++ languages:
attolcc
- for the Java language for standard compilation:
javi
inclusion of the javic.jar library, and calls to javic.jar classes, as part
of an ant-facilitated build process
For detailed
information refer to the Rational Test RealTime User Guide, the chapter
Command Line Reference, and in the Rational Test RealTime Reference Guide,
the chapters Command Line Reference->Component Testing and Command Line Reference->Runtime
Analysis
For More Information
|