| Icon | Meaning |
| <img src="images/2a05f87a4292bfecb242bff603249f384f86fc8d046326ed5c2af664e82a5224.jpg"/> | Item of special significance or where caution needs to be taken. |
| [YKBX] | Item contains helpful hint or special information. |
| [SYDX] | Information applies to Windows (e.g. XP, 2003, Windows 7) only. |
| <img src="images/55135cc7581523fce7ddd1eb66b08f8e6fd95ab167383231a59a4998a53ee470.jpg"/> | Information applies to Unix-based systems (e.g. Solaris) only. |
| <img src="images/9eae80ba39b971221a39b756acb5003851dffcba4553f7c89fcc83909adcdaea.jpg"/> | Information applies to Linux-based systems (e.g. Ubuntu) only. |
| <img src="images/91471bff6143cec77d9971f90dd0183064b07925feb0bfc5b70d3ca70049d5d0.jpg"/> | C language specific. |
| <img src="images/8fe49bbc4d91c23f63d75b43394c20f1cdf8f4f6a4c730c1d71c4c74c43e09b2.jpg"/> | C++ language specific. |
| <img src="images/6bf857ca65d7ac5e55a881309598e8cd180b5d95dfbdd7bfdf13b4acccb9ab5f.jpg"/> | C# language specific. |
| <img src="images/caf1c16636805907234a94893aca2e9f2dff6f072bd8e1138785df6cbcfa7879.jpg"/> | Java language specific. |
# 2
# Introduction
This section provides a brief introduction to the Vortex OpenSplice Tester.
# 2.1 Features
The Vortex OpenSplice Automated Testing and Debugging Tool provides an easy way of displaying messages produced in Vortex OpenSplice and also provides means to publish messages manually or with a script.
(The OpenSplice Automated Testing and Debugging Tool is usually referred to as Tester; the name ospltest is used when referring to the executable program.)
This tool is made with the software tester, and the way he performs his job, in mind. A pre-defined list of topics of interest can be provided. For all topics a reader is created in the correct partition. Once started, the tool receives all instances of the topics of interest and will display them in the sample list in the order they were produced (using the source time stamp). This makes it very easy to see when topics are produced and in what order. It also provides feedback about unexpected updates.
Other features of Tester include the ability to:
• dump a selection of topic(s) to a file
• dump all logged topic instances to a file
• filter the sample list based on key
• filter the sample list based on key and topic name
• filter the sample list based on key
• create a script with a selection of previously sent or received topics
• compare topic samples
• edit topic samples and then write them or dispose the topic instance
• create new topic samples and write them or dispose the topic instances
# 2.2 Location of Tester in the OpenSplice architecture
Tester is complementary to OpenSplice Tuner (ospltun). Tuner supports ‘white box’ application monitoring and tuning, and Tester supports ‘black box’ system testing, debugging, data capture, analysis, and visualization.
# 2.3 Things to Know
NOTE: Tester uses the internal Control & Monitoring (C&M) API for access to OpenSplice. At this time Tester only supports Vortex OpenSplice systems.
Tester can be used both locally (via shared memory or single process) and/or remotely (via a SOAP connection to the SOAP service).
Tester uses a periodic poll to read data (the default poll period is 250 ms). The normal restrictions for storage scope apply (only keys defined with the topic separate topics for reading, if topics with the same key are produced within a polling period, then only the last topic is read).
Tester uses the default QoS for writing (as provided by the first application which registers the topic) and the weakest QoS for reading. However when specifying the topic in add topic (or add topics) or in the topic file the QoS can be given, this QoS must be compatible with the topic QoS as defined when the topic was registered.
NOTE: In order for the Tester system browser to correctly show the complete system, OpenSplice Durability services have to be properly configured so that the transient ‘built-in-topics’ are properly aligned when new nodes join the system. Monitoring the built-in topic sample set on different nodes will quickly reveal any failure in correct lining-up of transient data (in which case there will be different sets visible on different nodes). Monitoring the DCPSHeartbeat built-in topic will reveal fundamental connectivity issues in your system (you should see as many unique heartbeats as there are interconnected nodes in the system).
# 2.4 Prerequisites
Tester is included in the standard OpenSplice installation.
Tester’s minimum system requirements are the same as for OpenSplice itself; please refer to the Release Notes for both Tester and OpenSplice for details. The Vortex OpenSplice Getting Started Guide contains additional information about installation and configuration on various systems.
Note that to compile plugins you will also need to have ant and JDK1.6 installed (see Getting Started with a Message Interface). Tester has been implemented in the Java Language, and it uses the Vortex OpenSplice Command and Management (C&M) API.
Although Tester uses the C&M API, it doesn’t depend on a locally installed or running instantiation of OpenSplice. It can operate either ‘co-located’ with a running DDS target system, or it can operate in ‘remote-connection’ mode (like the Tuner).
When Tester is run on the same platform as Vortex OpenSplice, it uses the OSPL\_HOME environment variable to find the necessary OpenSplice library files. It also uses OSPL\_URI as its default OpenSplice configuration.
When Tester connects to a remote ‘target’ platform using SOAP it doesn’t use any local environment variables, it just needs to be installed on the machine where you run it.
(Note that the Vortex OpenSplice Tuner can be started with a -uri command-line parameter (see how to start a remote connection ). This is a new feature that is actually used by the Tester in the system browser, where you can spawn a Tuner (see how to spawn a tuner from the system browser) that then connects to the node/application that the browser is pointing to.)
# 3
# Getting Started
This section describes how to use the Tester’s main features.
# 3.1 Starting and Stopping Tester
Tester may be started by running the OpenSplice Tester application or from a command prompt and oslptest with the following command line arguments:
-? or -help Display the command line options
-ns No splash screen
-uri <uri> URI to connect
-nac No auto-connect upon application start
-s <path to script> Script to run
-b <path to batch file> Batch script to run
-noplugins Do not process plugins
-plugindir <dir> Extra plugin directory to search
-headless Run script or batch script without the GUI
-rc <port> Enable remote control (via <port>)
-dsl <language> Default script language
-l <path to topic file> Load topics from file
(These preferences can also be set from the menu File > Preferences.)
# 3.2 Starting - Local Connection
On Windows, use either of the shortcuts created by the installer (on the desktop and in Start > Programs) to start Tester.
Linux On Linux go to the installation directory and execute the command:
% ospltest
This will start Tester with separate windows.
# 3.3 Starting - Remote Connection
To connect to a remote platform, execute the command:
```batch
% ospltest -uri http://perf1.perfnet.ptnl:50000
```
(Port number 50000 is the default port in a standard DDS shared-memory deployment.)
# 3.4 Stopping
Stop Tester either by using the menu option File > Exit or by clicking on the main window ‘close’ button .
# 3.5 Remotely Controlling Tester
Starting Tester in remote control mode e.g. "ospltest -rc <port> -headless" allows Tester to be controlled from another application, shell script, etc..
Use cases for remote control include:
• Using Tester in combination with a commercial or proprietary test system;
• Within a continuous build and test environment this would provide more options to control DDS testing in combination with other application-specific testing;
• In an integrated development environment like Eclipse using Junit for testing.
A Tester instance is controlled via a TCP/IP connection. Text-based commands are sent over this connection.
The remote control application can be used by executing the command:
```txt
ospltestrc [-p <port>] [-h <host>] <command>
```
where
```txt
<host> is the host name of the machine that the Tester you wish to control is running on
<port> is the port that Tester is listening on (specified by the -rc option when Tester was started)
<command> is the command to send to Tester.
```
The remote control commands are:
stop Terminate the Tester instance
```html
batch <batch name> Execute the batch with <batch name>
```
```txt
script <script name> Execute the script with <script name>
```
scenario <scenario> Execute a scenario which is provided in full text on a single line (new lines "\n" are replaced by " ")
connect <optional uri> Connect to a specified or the default Domain uri
# disconnect
When a command is completed the following is reported on a single line:
Done
When a batch is executed, for each scenario two lines are returned to the test controller:
```txt
Scenario: <index> of <count> execute: <scenario name> Scenario: <index> result: <result>
```
# 3.3. Starting - Remote Connection
# 3.6 Trying out Tester
Once you have started Tester, you can get a feeling for how to use it with a few simple exercises:
• Create a default reader for some of the registered topics.
• Double-click one of the samples and see all the fields of the topic.
• Browse through the list of samples using the arrow keys.
• Select a topic in the sample list and press [F9], then select a field for display in the sample list.
• Select another topic (it need not be of the same type as the one displayed in the topic instance window) and press [F2] for a comparison between the two topics.
• Select a topic in the sample list or in the topic list and press [F4], then in the Write topic window set the fields to the desired value and write or dispose the topic.
• Choose File > Dump on the sample list and save the information of the topic samples in the sample list to a file.
• Have a try with the scripting, it can make your life a lot easier (especially with recurring tasks).
The rest of this section describes the features that you will use when you try these exercises.
# 3.7 Tester Windows
# 3.7.1 Main Window
Once started, Tester presents the user with the following main window.
Tester main window
The Command Menu (below) provides direct access to most of the Tester capabilities.
Tester command menu
The Tester main window has three sub-frames:
# 3.6. Trying out Tester
1. Main tabbed frame for selecting items from a list, such as topics, scenarios, and readers or writers.
2. Working area frame where you will do most of your work such as editing scenarios, investigate samples, and capturing statistics
3. Debug frame used to debug scripts and macros.
# 3.7.2 Overview Windows
The user can select the type of resource to work with by selecting tabs. These can be the Services and Topics in the system, the Scripts and Macros they have installed, or the Readers for the current Tester timeline.
Tester resource tabs
# Services
Lists the installed services. This is a read-only list.
Tester Services list