Contents
4. Project Testing
  4.1) Validation
  4.2) Correctness
  4.3) Usability Tests
  4.4) Negative Testing
  4.5) Performance Testing

4. Project Testing

The project needs to be tested to ensure the simulation is valid and correct.

4.1. Validation

Validation is necessary to check that the simulation is realistic and therefore can fit traffic models and data to real traffic situations.

Need to validate:

Observed vehicle behaviour is similar to real world behaviour.
Measurement results are realistic (e.g. Speeds, distances, times, accelerations).
The applications results are useful.

To validate the project the application needs to be tested on each real-world situation it is supposed to be able to handle. The real-world situation (road schematic) should be designed using the application and observed for a length of time to see if any non-normal behaviour occurs. This is an incomplete testing strategy as it will not be possible to test all real-world situations.

Example situations to test:

Give-way Junctions
- Slip road coming off main roads.
- Slip road joining onto a main road.
- T-junction with all turning options possible.
- Crossroads with small road crossing main road.
Signalled Junctions
- Signalled crossroads of various numbers of lanes.
- T-junction with various signalled turning options.
- Signalled junction where one entry has a very low traffic flow.
Other Junctions
- Two lanes changing to one lane and vice versa.
- Over and under passes.

It is also necessary to test how multiple junctions perform when they are composed together.

The best way to validate the application is to obtain real data from a real traffic system and compare the data to results produced by the application running on a similar road network schematic and using identical input data. Highly detailed testing is beyond the scope of the project. The project uses simplified traffic models and is designed for a visual animation display and does not expect to produce accurate-critical results that match government simulations. A set of tests will be created to ensure the simulation produces results within some reasonable bounds.

Test for:

Vehicle size dimensions and road size dimensions.
Maximum vehicle acceleration and speed.
Maximum red light time and minimum green light time.

To validate the projects usefulness I will formulate a toy example to test it on: "The council is planning a new traffic exit road network and has 3 plans. Which plan is best in terms of traffic through-flow and road surface area?" The application should be used to model and simulate the three plans using the same traffic-modelling data. An example of three plans to compare:

Plan 1:

Plan 2:

4.2. Correctness (verification)

Correctness depends on the traffic models used. The application code should implement the traffic model stated in the specification accurately. To test this we can take each individual property of the applications traffic model and design a test to prove that it has been implemented correctly (component testing).

Models to test:

Car-following model.
Car pull-up model.
Car gap-acceptance model.
Car acceleration and top speeds.
Safe traffic light sets and timings.
Safety issues: Collisions

Statistical tests:

Vehicle inputs match what is specified in the traffic-data model provided for the particular road network.
Junctions behave how they were specified to in the traffic-data model.
Data results produced from the application are correct.

Although the design of a road network is the users responsibility it may prove useful to test some liveness issues:

Test for infinite road loops.
Test for un-reachable lanes.

Writing Tests: Testing functions will be written into objects that need testing. As an example the "Car" object should have a function called getCurrentSpeed() and getCurrentLocation() and a junction should also have a function called getCurrentLocation(). The test procedure for acceleration could then monitor one car as it comes to a signalled junction. It could call carX.getCurrentSpeed() at time t and at time t+1,t+2,t+3,etc and work out the cars acceleration from the junction. Real-time information can be found by calling System.currentTimeMillis().

Models such as the car-following model could be tested by calling getNearestCarDistance() continuously for a particular car and monitoring the speed of the car. If the distance values fall into what has been specified then the test is passed.

4.3. Usability tests

As the project evolves and when it is near completion the application should be tested for usability by other students. Feedback should also be sought from the project supervisor. Usability tests are particularly good at testing user-interface features.

Users should be asked:

Whether functions are intuitive.
Whether the graphics are clear.
Whether the speed of animation and application functionality is satisfactory.

4.4 Negative Testing

The application should be tested against miss-use. It should not crash if invalid road-networks are created. If the user makes an error the application should inform them with a helpful error-message.

4.5 Performance Testing