Automated Test Process

The process for automated testing follows.

1. Identify the aspects of the driver to be tested.

   Test all aspects of the driver that interact with the hardware:

   • Attach and detach

   • Plumb and unplumb under a stack

   • Normal data transfer

   • Documented debug modes

   A separate workload script (fixup_script) must be generated for each mode of use.

2. For each mode of use, prepare an executable program (fixup_script) that configures and unconfigures the device, and creates and terminates a workload.

3. Run th_define with the errdefs, together with an access type of -a log.

4. Wait for the logs to fill.

   The logs contain a dump of the bofi driver's internal buffers. This data is included at the front of the script.

   Because it can take from a few seconds to several minutes to create the logs, use the th_manage broadcast command to check the progress.

5. Change to the created test directory and run the master test script.

   The master script runs each generated test script in sequence. Separate test scripts are generated per register set.

6. Store the results for analysis.

   Successful test results, such as success (corruption reported) and success (corruption undetected), show that the driver under test is behaving properly.

   It is fine for a few test not triggered failures to appear in the output. However, several such failures indicate that the test is not working properly. These failures can appear when the driver does not access the same registers as when the test scripts were generated.

7. Run the test on multiple instances of the driver concurrently to test the multithreading of error paths.

   For example, each th_define command creates a separate directory that contains test scripts and a master script:

   # th_define -n xyznetdrv -i 0 -a log -e script # th_define -n xyznetdrv -i 1 -a log -e script

   Once created, run the master scripts in parallel.

   ---

   Note –

   The generated scripts produce only simulated fault injections that are based on what was logged during the time the logging errdef was active. When you define a workload, ensure that the required results are logged. Also analyze the resulting logs and fault-injection specifications. Verify that the hardware access coverage that the resulting test scripts created is what is required.

   ---