• The purpose of class testing is to test each class in isolation.
• Each class in the class diagram must be tested, for class testing to be complete.
• For each class in the diagram, select functional tests (based on the post-conditions & class invariant), Structural tests (based on the actual code), and interaction tests (based on the interaction matrix).
• Organize these tests into suites/scripts, using the PACT architecture (reusing tests where possible).
• Run the tests against the class & log the results. Analyze the results.

Note: Since this system must meet the D.O.T. regulations, it might be desirable to do a guided inspection before selecting testcases, to ensure the specifications are correct.

• The purpose of this type of testing is to test components in clusters after they’ve been tested in isolation.
• For the traffic control system components are the traffic intersection/timing state machine and the sensors (at the intersections & along the road).
• First, two traffic intersections should be tested to ensure they communicate properly. Events could be simulated to cause one traffic intersection to send messages to another. Inputs & outputs would be the states of the traffic intersections & whether or not they are correct after the test, respectively.
• Next the traffic intersection and the sensors should be tested. Again, events could be simulated (e.g. sensor activated) to see if the traffic intersection responds & sensors accordingly.
• Additionally, the design patters of these components could be used as a source of test patterns.
• Results should be recorded/logged & analyzed.

• System testing must ensure the system as a whole works as specified in the use cases.
• The use cases should be used to produce test cases. The use cases can also be broken down into sub-use-cases.
• Each use case (sub-use-case) should then be assigned specific values to produce the test cases.
• Each test case should be run on the traffic control system.
• The results of the tests should be recorded and analyzed.

CLASS– Testing includes 3 types/coverages:

1. functional – all-transitions (of state diagram)
2. structural – all-branches (in code)
3. interaction – all – MOM interactions (from interaction matrix)

• These levels of coverage are effective for class testing in this system, because at the class-level the distributed part doesn’t really show up, thus testing the specification, implementation & interactions thoroughly is a more effective approach.

• Coverage level = all protocols (sequences of messages)
• This level of coverage is effective for this system because each component has already been tested & now we want to know how well (correctly) they work together. Specifically, since this is a distributed system and the only way the components communicate is through messages, all-protocols would be likely to catch faults.

• Coverage = all-use cases (using a risk-driven approach)
• The use cases should first be ordered according to risk Aloysius since some use cases are more vital to the traffic control system.
• High risk cases should be assigned more test cases/scenarios than medium-risk, & medium-risk more than low-risk.
• This is an effective coverage for this system because at the system level the testers may not be experts & exercising whole scenarios on the system will be the best means of finding faults.

• State-based test:

• Put traffic intersection object in initial state (E/W Green, N/S Red)
• Have a car pull up to t he North/South light of the intersection
• The sensor should send a message to the traffic intersection object & its state should change to E/W Yellow & N/S Red, then to E/W Red & N/S Green.
• The car should move through the intersection & the sensor should be deactivated.

• Using the police officer use case for overriding the timing sequence:

• Set all traffic intersections & sensors to initial states
• Allow traffic to proceed as normal
• Police officer then uses the "control box" to override the timing sequence, causing all east west lights to hold on green for 1 hour
• The police officer sets the timing sequence back to normal operation

The technique in this paper could be applied to the traffic control system at the integration level of testing. The technique is specifically designed for distributed systems and uses statecharts (modified to include the communication backbone) to produce event-trees. The event trees are then traversed to produce event sequences which are then used to test the system. Since the reported technique uses nested, concurrent state machines, it is also applicable to the traffic control system as a whole. Each intersection represents a state machine that acts concurrently with the other intersection state machines. By thinking of these as a single machine with 4 concurrent pieces, we can apply the technique and create an interleaved event tree.

For the traffic control systems this works nicely at the integration level because it will use the state charts to automatically produce test sequences that would effectively cover the state charts & give the tester a level of confidence that a certain level of coverage (all messages/all protocols) has been achieved.