13.1 Stress Testing

Due to the complex nature of the Linux kernel, it is too difficult to create drivers and stubs for all the resources the kernel modules use. Hence, apart from compilation, all testing of the two kernel modules will take the form of stress testing. Stress testing will apply loads to the network and ensure that this does not cause a failure of the kernel modules. Varying lengths of time will be used, depending on the level of testing being performed.

13.1.1 Precheckin Testing

Before changes can be made to the source code of the FCM kernel modules, the modules must undergo a short period of stress testing. As a compromise between rigorous testing and the need to not hinder changes, a duration of 5 minutes has been chosen. The standard test load will be applied during this time. If the module is still operating as expected at the end of testing, it is considered to have passed. If however the network no longer works, or the kernel has crashed, it is considered to have failed. In this case, the change must not under any circumstances be committed.

13.1.2 Nightly Testing

As both an indicator of progress, and to ensure new fatal bugs are not introduced, the test load will be run each night. This is to be run for a duration of 1 hour. The same criteria exist for determining success or failure as in Precheckin Testing (see section 13.1.1).

13.1.3 Standard Test Load

To maintain some level of reproducibility, a standard set of network connections will take place as part of the test load. The following types of connections will occur:

1. Standard TCP connections - A series of large HTTP transfers from hosts on the local network will take place. Some of these will run concurrently. The contents of the file being transferred is not important, so a random file, created from /dev/urandom will be used. A 50 Megabyte file will be used for this. It can be created with the following command: dd if=/dev/urandom of=testfile bs=1k count=50k

   This file will then be accessible from an HTTP server located on a host running the Router module. The wget utility will be used to download this file from a host running the Router module.

2. Corrupted TCP packets - To ensure FCM does not crash when corrupted TCP packets are received, some will be sent on the network.
3. Non TCP connections - To ensure FCM handles non-TCP packets correctly, some ICMP and UDP packets will be sent. These will be sent from both the Router and the Receiver, and directed at each other.

These connections will be repeated until the desired duration is reached. It is important to note that these tests are primarily for stability and error handling.