In scenario-based testing, the test author configures the input data to “move” the system through a set of desired states or maneuvers.  A simple example of this would be a “wide-open throttle” scenario for automobiles

1. Key set to crank
   1. Hold .1 second
2. Key set to run
3. Together
   1. Brake to 100%
   2. PRNDL to Drive
4. Together
   1. Brake to 0%
   2. Throttle to 100%
      Measure time to 60 MPH

Reusing scenarios

In scenario-based testing, there are often common “starting points”.  In our example above the common starting point would be the first 3 steps.  In the example that follows, using a Test Sequence block I implemented the common steps as a single, grouped, step.

When the common setup is complete the sequence block then moves onto another “grouped” step which implements the specific test.  Optionally a second or third “common setup” sequence could be defined before the actual test begins.

Chained data

Another method of reusing scenarios is to “chain data” together.  In this case, a series of input data files are concatenated and played in sequence into the simulation.  To continue this example the first three steps would be one data file and then either the “WOT” or “idelWarmUp” would contribute to the next data file.  (Please imagine the image is of a fat cat named “Nate”  (Con-Cat-Ton-Nate)

Why perform scenario-based testing?

Scenario-based testing allows us to validate that models behave in the way we expect and the way we designed, if I “put the pedal to the metal” the car accelerates quickly.  Most frequently I use them to

• Validation of state machine behavior
• Exercising diagnostic code
• Validate requirements
• Debug models under development