features

Salient Features in SunVTS 7.0

The major components that form a part of the SunVTS7.0 as shown from the Architecture diagram (Figure 1) are as mentioned below .

Browser user interface & Middle Server:

VTSMS provides a uniform application programming interface (API) which will allow the SunVTS BUI and any other user interface application to interact with the VTS middle server (VTSMS). This will also allow third party applications to communicate with the VTSMS. VTSMS would receive commands from the UI, translate them and send them to the agents. At the same time it would send to the UI the replies, status updates and messages that it is getting from the agents.

Each VTSMS message consists of a command and the data needed for that command. The return value for some commands is the data to be displayed on the UI, for others it is the status indicating whether or not the command succeeded. The command conflicts between multiple UIs will be resolved as follows: The middle server will send the VTSK, one command at a time. i.e. It will send a command only after the execution of the previous command has completed. The VTSK will ignore irrelevant commands (e.g.- It will ignore a Start command when tests are already running). Also, the VTSK will accept connection from only one middle server at a time.

Logical Test :

The logical tests are nothing but a configuration of what actual physical tests are going to be run.

The SunVTS7.0 architecture provides a test abstraction called "Logical Test" by abstracting the details of underlying complexity of existing SunVTS tests. It provides a very flexible infrastructure to represent a logical test as a combination of physical tests executed in parallel / sequence. The new infrastructure maintains a rules files for each Logical Test. This is used to run a logical test where test time, scheduling mechanism , platform name, stress level etc. are defined by the Logical test developer.
The logical test rules file, would in essence provide a way for the logical tests to specify which physical tests (with their options) it wants to run and in what combination.
Rules file represent Logical Test a set of tasks that will be run sequentially or in parallel. Each “task” in turn is defined as a set of physical tests.
XML will be used to specify the rules file. The goal is to use file formats which are extensible in future. These test rules files are going to be the cornerstone of this architecture. They should be easy enough to use by the test developers and the advanced users (users who would want to create their own rules file).
The harness will log complete profile of the logical test before it starts executing it. Users can check what is being run by the harness.

SunVTS Kernel :
The SunVTS harness (vtsk) is the main entity that controls and manages the test execution session. This is in addition to the chores of management of the messaging, handling commands from the clients, system resource management, scheduling capabilities etc. In a sense it is the operating system for SunVTS, hence called the SunVTS kernel (vtsk).

Physical Test:

The physical test are nothing but the current SunVTS tests. Each of them can be developed for a very specific hardware or functionality coverage. They would be encouraged to provide as many options as possible to give full controllability to the logical tests. One of the basic requirement of this architecture is that the current SunVTS tests should be able to plug into this architecture without any modification.

Some of the current existing tests will fit better into the new architecture than others. Eventually recommendation would be made to make the physical tests more conducive to the Logical test structure. The vision is that the combination of logical and physical tests must take care of the platform/hardware dependencies and the complexities of the test algorithm. So a test would better fit into the new architecture if it takes care of all the hardware dependencies within itself, without relying on the user to make the right choices.

Command Line Interface

vts_cmd is a UNIX shell application that allows you to send a single command to the SunVTS kernel (vtsk). The test machine's SunVTS kernel will send the response to the standard output.

The SunVTS application programming interface (API) is character based, which means that a string of characters (in the form of a command) can be sent to the SunVTS kernel, which then returns a reply back in the form of a string of characters.
vts_cmd allows the user to send commands and receive replies from a UNIX command line.