TestExpert features

A tool for testing client and server applications

TestExpert is a tool which gives an answer on some of the questions which come up when dealing with software test:

  • My application lives in a distributed environment and must implement a communication interface towards a server/client. How can I test my software against an external device which is still in development, doesn’t support all of my features, or is too expensive to buy?
  • How can I repeat previous tests when my software is getting into shape as a result of incremental development steps?
  • How much can I adapt test cases for different test scenarios?
The tool allows a software developer or tester to define all kinds of test scenario’s, execute them, and evaluate the test results. It interfaces with the System Under Test (SUT) through an IP network through which it exchanges message data either directly on UDP or TCP, or through HTTP.

Support for behavioral testing by means of functional test scenarios

In contrast with other test tools TestExpert doesn't rely on a scripting or programming language which the user must learn to develop test cases. The app presents itself as a GUI application in which the user enters the test scenarios in the form of State/Event/Action items as on finds in Finite State Machines (FSM).

  • 'States’ represent the different phases in which a test is.
  • ‘Events’ represent the signals which are being sent/returned by the application under test or by TestExpert itself (e.g. a timeout) in a given state during the execution of the test.
  • 'Actions’ are associated with 'events' and define the signals and commands which have to be executed when the event has fired. Actions can have a 'Condition' property that enables or disables its execution.
A test scenario therefore describes how the System Under Test will be stimulated (typically by 'Actions') and what the expected responses will be (as defined by 'Events').

Possible 'events' that are supported by TestExpert are:

  • Start scenario
  • A message has been received from the system under test
  • A timeout has occurred

The 'actions' which the user can assign to 'events' are:

  • Start a timer
  • Stop a running timer
  • Send a message to the system under test
  • Change the scenario state
  • Give a user prompt
  • Call another scenario
  • Assign a value to a runtime variable
  • Start a communication server/listener
  • Stop execution

During the execution of the test all events which are coming from the system under test, are validated against what the scenario is expecting in its current state. When the event is accepted the scenario proceeds by triggering all the actions that have been registered for the event.

Execution of the test can both be done manually (one test at a time) or in batch mode (multiple scenarios are running after each other).

Create and manage scenarios with a powerfull Scenario Editor

TestExpert’s scenario editor allows you to create and modify a scenario. Using the editor is very intuitive as it only requires from the user that he or she selects the FSM item that needs editing and then pressing the required button on the toolbar.

  • Adding a FSM item pops up a view where the user must provide data for one or more properties that are important for the newly created item.
  • Adapting an already existing FSM item is done within a Properties View that is shown when the item is selected.

Have full control over the content of outgoing and incoming messages

TestExpert's Message Editor allows the user to fully customize the content of protocol messages. Both binary messages and text-based messages are supported by choosing from a set of Templates. Editing of text messages is facilitated by the template driven editor letting the user pick and choose the necessary message information elements.

The user can select to edit a message from the following type of templates:

  • Raw messages - This gives full freedom over the message's content as it allows the user to enter information both in binary (byte, word, integer, long) and text (string) format. There is a configuration option to tell TestExpert to use either little or big endian with respect to numeric values while encoding or decoding such type of message.
  • Text messages using ABNF syntax - With this type of template the Message Editor reads the syntax of the message from an ABNF text file. This allows for an editing experience where fixed content can simply be presented and selected by the user and user-defined data can be inputted as required.

Verify the message payload

While working with the Message Editor you can verify what the resulting payload will be of the message. With some type of messages this can be trivial but, especially with binary messages which are constructed by means of dynamic and/or parameterized data fields, this is extremmely usefull.

Execute scenarios and verify all interactions with the System Under Test

A special Scenario Execution View provides feedback to the user when a scenario is executed.

Configurable transport connections

In order to connect with the System Under Test the app must create a suitable transport connection. Because TestExpert can play either the client role or the server role options are available to configure target endpoints (as a client) or listenening endpoints (as a server).

Target endpoints can be configured to run on the following transport layer:

  • UDP - Messages will be sent (and received) as UDP datagrams.
  • TCP - Messages will be sent (and received) as streams over a TCP connection that will be established by TestExpert.
  • HTTP-POST - Messages will be sent in the body part of a HTTP POST request. A response 'message' must come in the body part of a 200 OK HTTP response message.

Listener/Server endpoints can be configured to run on the following transport layer:

  • UDP - Messages will be received (and sent) as UDP datagrams.
  • TCP - Messages will be received (and sent) as streams over a TCP connection that is established by the remote system.
    You can configure the type of message framing to be: none, a fixed length indicator, a header-type of length field (like a 'Content-Length' header), and a tail marker.
  • HTTP - Messages are expected to be received in the body part of an incoming HTTP POST request. A response 'message' triggered by a scenario will be sent in the body part of a 200 OK HTTP response message.