External Agent Interface Testing Plan

External Agent Interface Testing Plan
SchemeStation documentation

1 Purpose

This document describes the unit testing of the SCHEMESTATION external agent system. The purpose of the unit testing is to ensure, that the implemented external agent system system corresponds to the specified external agent protocol [External Agent Interface Specification] and that messages can be passed between the SCHEMESTATION domain and the external agents with reasonable performance.

2 Module testing

Testing the overall functionality of the module is dicided in to following categories:

3 Function Testing

Each function is tested separately. For each function the following is tested:

4 Other tests

The external agent system will be flooded with maximum amount of packets that the a test external agent can produce, and with packets that contain illegal headers.

5 The testing program

A separate testing program will be written to test all the external agent operations. The testing involves having two test programs to act as minimal domains and communicate with each other via one test router. The two domains and the router are three instances of one executable, that acts as router, if a specific command line argument is supplied. The two client programs also get their own domain address, the address of the router and the address of the other client program as a command line argument.

5.1 The test program phases

5.1.1 External Agent system initialization

The external agent system is initialized by calling extagent_initialize.

A packet callback is supplied for the system using extagent_registerpacketcallback. Tehe callback dumps the gotten packet on to the screen.

The separate client executable that uses the ssextagent lib is started to test connecting to a SCHEMESTATION domain.

The result of the hand shake initiated between the server and the client will be checked using gdb. Also, a perl script will be written to try to connect to the router with false protocol. The router may neither accept the connections nor stop serving the valid connections.

5.1.2 Sending and receiving the packets

In the sending phase, the client programbasicly executes a thight loop sending packets to the server program. The client program can be set in to this mode with eg. typing a suitable key combination.

The result is verified by counting number of received messages and sent messages. The sending party can be instructed to dump the sent messages to stdout, too, so that the possible errors can be caught using diff(1).

5.1.3 Invalid packet flood

Another of the client programs will be set to "malfunction" mode - it will flood the server with random packets. It will be checked that none of these packets cause denial of service neither for the malfunctional client nor the intact client. All invalid packets have to be ignored.

6 The results

As the external agent system was both spceified and written quite late compared to the rest of the system, we chose to make the testing programs with care in the beginning. The tests begun right after all the functionality was coded. The approach was iterative; we executed the tests knowing that there would be bugs, located the bugs, fixed them and started over.

This iteration stopped when the tested were succesfully passed.

Due to the chosen approach, a huge number of bugs was found and terminated. The most serious and most difficult ones concerned having several high traffic external agents connected to the system in parallel.

To summarize: the external agent system now has functions that have been tested to satisfy the following criteria: