Test Cases for Wright Flyer Requirements
R1
The simulation user can specify the conditions under which the simulation will automatically end.
R1.1
The simulation user can specify that the simulation will end when any plane crashes or
lands
Initial State of system: The plane is initially in flight.
Stimulus Given: Make a randomly chosen flyer land.
Response Expected: End of Simulation.
Note: This trace message should be passed to the ITP.
Initial State of system: The plane is initially in flight.
Stimulus Given: Make a randomly chosen flyer crash.
Response Expected: End of Simulation.
Note: This trace message should be passed to the ITP.
R1.2
The simulation user can specify that the simulation will end when all planes have crashed
or landed.
Initial State of the system: The plane is initially in flight.
Stimulus Given: Make all flyers land
Response Expected: End of Simulation.
Note: This trace message should be passed to the ITP.
Initial State of the system: The plane is initially in flight.
Stimulus Given: Make all flyers crash
Response Expected: End of Simulation.
Note: This trace message should be passed to the ITP.
R1.3
The simulation user can specify that the simulation will end when any plane crashes, or
when all planes have landed.
This requirement has already been taken care of in the above test cases.
R2
The user can define the terrain in which the simulation takes place.
R2.1
R2.1.1
The simulation user can select a randomized terrain.
The simulation user can define a minimum and maximum elevation for the
randomized terrain.
Initial State of the system: No values have been assigned for max/min elevation for the
randomized terrain.
Stimulus given: Provide valid values for max/min elevation.
Response Expected: Complied
Note: This test case will have to be handled individually by the group responsible for this
test.
Initial State of the system: No values have been assigned for max/min elevation for the
randomized terrain.
Stimulus given: Provide incorrect values for max/min elevation, i.e. say, the min value is
greater than the max value.
Response Expected: The user is informed that the values are invalid and the simulation
does not execute.
Note: This test case will have to be handled individually by the group responsible for this
test.
R2.2
The simulation user can select a predefined terrain, stored in a terrain description file.
Initial State of the system: No terrain pattern has been selected so far
Stimulus given: Prompt environment script to select a valid terrain description file.
Response Expected: Complied
Note: This test case will have to be handled individually by the group responsible for this
test.
Initial State of the system: No terrain pattern has been selected so far
Stimulus given: Prompt environment script to select an invalid terrain description file.
Response Expected: The user is informed that the file is invalid and the simulation does
not execute.
Note: This test case will have to be handled individually by the group responsible for this
test.
Initial State of the system: No terrain pattern has been selected so far.
Stimulus given: Prompt environment script to select a terrain description file that does
not exist.
Response Expected: The user is informed that the file does not exist and the simulation
does not execute.
Note: This test case will have to be handled individually by the group responsible for this
test.
R3
The terrain includes features.
R3.1
The simulation user can select randomized features.
R3.2
The simulation user can select predefined features, stored in a feature description file.
Initial State of the system: No features have been selected so far
Stimulus given: Prompt environment script to select a valid feature description file.
Response Expected: Complied
Note: This test case will have to be handled individually by the group responsible for this
test.
Initial State of the system: No features have been selected so far
Stimulus given: Prompt environment script to select an invalid feature description file.
Response Expected: The user is informed that the file is invalid and the simulation does
not execute.
Note: This test case will have to be handled individually by the group responsible for this
test.
Initial State of the system: No features have been selected so far.
Stimulus given: Prompt environment script to select a feature description file that does
not exist.
Response Expected: The user is informed that the file does not exist and the simulation
does not execute.
Note: This test case will have to be handled individually by the group responsible for this
test.
R4
The simulation user can define the wind in the environment where the simulation takes place.
R4.1
R4.1.1
The simulation user can select a randomized wind range.
The simulation user can define a minimum and maximum speed for the
randomized wind range.
Initial State of the system: No values have been assigned for max/min speed of wind.
Stimulus given: Provide valid values for max/min elevation.
Response Expected: Complied
Note: This test case will have to be handled individually by the group responsible for this
test.
Initial State of the system: No values have been assigned for max/min speed of wind.
Stimulus given: Provide incorrect values for max/min elevation i.e. say, the min value is
greater than the max value.
Response Expected: The user is informed that the values are invalid and the simulation
does not execute.
Note: This test case will have to be handled individually by the group responsible for this
test.
R4.1.2
The simulation user can define minimum and maximum values for each
component of the wind’s orientation.
Initial State of the system: No max/min values have been assigned for each component
of the wind’s orientation.
Stimulus given: Provide valid max/min values for each component of the wind’s
orientation
Response Expected: Complied
Note: This test case will have to be handled individually by the group responsible for this
test.
Initial State of the system: No max/min values have been assigned for each component
of the wind’s orientation.
Stimulus given: Provide invalid max/min values for each component of the wind’s
orientation, i.e. say, the min value is greater than the max value.
Response Expected: The user is informed that the values are invalid and the simulation
does not execute.
Note: This test case will have to be handled individually by the group responsible for this
test.
R4.2
The simulation user can select a predefined wind, stored in a wind description file.
Initial State of the system: No wind pattern has been selected so far
Stimulus given: Prompt environment script to select a valid wind description file.
Response Expected: Complied
Note: This test case will have to be handled individually by the group responsible for this
test.
Initial State of the system: No wind pattern has been selected so far
Stimulus given: Prompt environment script to select an invalid wind description file.
Response Expected: The user is informed that the file is invalid and the simulation does
not execute.
Note: This test case will have to be handled individually by the group responsible for this
test.
Initial State of the system: No wind pattern has been selected so far.
Stimulus given: Prompt environment script to select a wind description file that does not
exist.
Response Expected: The user is informed that the file does not exist and the simulation
does not execute.
Note: This test case will have to be handled individually by the group responsible for this
test.
R4.2.1
The wind description file can minimally describe different randomized wind
ranges for each region of the terrain.
Cannot provide test cases due to the broad description of these requirements. The
Environments and Scripts group is responsible for checking these requirements and
making they work correctly within the simulation.
R4.2.2
The wind description file can minimally describe different randomized wind
ranges as a function of time.
Cannot provide test cases due to the broad description of these requirements. The
Environments and Scripts group is responsible for checking these requirements and
making they work correctly within the simulation.
R5
The simulation user can define the temperature where the simulation takes place.
R5.1
R5.1.1
The simulation user can select a randomized temperature range.
The simulation user can define a minimum and maximum temperature.
Initial State of the system: No max/min values have been assigned for temperature.
Stimulus given: Provide valid max/min values for temperature.
Response Expected: Complied
Note: This test case will have to be handled individually by the group responsible for this
test.
Initial State of the system: No max/min values have been assigned for temperature.
Stimulus given: Provide invalid max/min values for temperature, i.e. say, the min value
is greater than the max value.
Response Expected: The user is informed that the values are invalid and the simulation
does not execute.
Note: This test case will have to be handled individually by the group responsible for this
test.
R5.2
The simulation user can select a predefined temperature, stored in a temperature
description file.
Initial State of the system: No temperature pattern has been selected so far
Stimulus given: Prompt environment script to select a valid temperature description file.
Response Expected: Complied
Note: This test case will have to be handled individually by the group responsible for this
test.
Initial State of the system: No temperature pattern has been selected so far
Stimulus given: Prompt environment script to select an invalid temperature description
file.
Response Expected: The user is informed that the file is invalid and the simulation does
not execute.
Note: This test case will have to be handled individually by the group responsible for this
test.
Initial State of the system: No temperature pattern has been selected so far.
Stimulus given: Prompt environment script to select a temperature description file that
does not exist.
Response Expected: The user is informed that the file does not exist and the simulation
does not execute.
Note: This test case will have to be handled individually by the group responsible for this
test.
R6
The simulation user can define the atmospheric pressure where the simulation takes place.
R6.1
R6.1.1
The simulation user can select a randomized atmospheric pressure range.
The simulation user can define a minimum and maximum atmospheric pressure.
Initial State of the system: No max/min values have been assigned for atmospheric
pressure.
Stimulus given: Provide valid max/min values for atmospheric pressure.
Response Expected: Complied
Note: This test case will have to be handled individually by the group responsible for this
test.
Initial State of the system: No max/min values have been assigned for atmospheric
pressure.
Stimulus given: Provide invalid max/min values for atmospheric pressure, i.e. say, the
min value is greater than the max value.
Response Expected: The user is informed that the values are invalid and the simulation
does not execute.
Note: This test case will have to be handled individually by the group responsible for this
test.
R6.2
The simulation user can select a predefined atmospheric pressure, stored in an
atmospheric pressure description file.
Initial State of the system: No atmospheric pressure pattern has been selected so far
Stimulus given: Prompt environment script to select a valid atmospheric pressure
description file.
Response Expected: Complied
Note: This test case will have to be handled individually by the group responsible for this
test.
Initial State of the system: No atmospheric pressure pattern has been selected so far
Stimulus given: Prompt environment script to select an invalid atmospheric pressure
description file.
Response Expected: The user is informed that the file is invalid and the simulation does
not execute.
Note: This test case will have to be handled individually by the group responsible for this
test.
Initial State of the system: No atmospheric pressure pattern has been selected so far.
Stimulus given: Prompt environment script to select an atmospheric pressure description
file that does not exist.
Response Expected: The user is informed that the file does not exist and the simulation
does not execute.
Note: This test case will have to be handled individually by the group responsible for this
test.
R7
The simulation pilot can specify the initial conditions of each plane.
R7.1
The simulation pilot can define the initial position (x, y, z) and orientation (, , ) of
each plane.
Initial State of System: Initial position of plane is not defined.
Stimulus given: Prompt pilot script to provision valid values for the initial position in
terms of (x,y,z).
Response expected: Complied
Note: This test case will have to be handled individually by the group responsible for this
test.
Initial State of System: Initial orientation of plane is not defined.
Stimulus given: Prompt pilot script to provision valid values for the initial orientation in
terms of (,,) of the plane.
Response expected: Complied
Note: This test case will have to be handled individually by the group responsible for this
test.
Initial State of System: Initial position of plane is not defined.
Stimulus given: Prompt pilot script to provision invalid values for the initial position of
the plane, i.e. provide co-ordinates that don’t lie within the flying space of the flyer
federate.
Response expected: The user is informed that the values are invalid and the simulation
does not execute.
Note: This test case will have to be handled individually by the group responsible for this
test.
Initial State of System: Initial orientation of plane is not defined.
Stimulus given: Prompt pilot script to provision invalid values for the initial orientation
of the plane, i.e. provide values that are incorrect.
Response expected: The user is informed that the values are invalid and the simulation
does not execute.
Note: This test case will have to be handled individually by the group responsible for this
test.
R7.2
The simulation pilot can define the initial velocity (vx, vy, vz, , , ) of each plane.
Initial State of System: Initial velocity of plane is not defined.
Stimulus given: Prompt pilot script to provision valid values for the initial velocity in
terms of (vx,vy,vz,w,w,w).
Response expected: Complied
Note: This test case will have to be handled individually by the group responsible for this
test.
Initial State of System: Initial velocity of plane is not defined.
Stimulus given: Prompt pilot script to provision invalid values for the initial velocity in
terms of (vx,vy,vz,w,w,w), i.e. say the velocity is too slow for the plane to stay in the
air.
Response expected: The plane should crash and a trace message should be send to the
ITP.
Initial State of System: Initial velocity of plane is not defined.
Stimulus given: Prompt pilot script to provision invalid values for the initial velocity in
terms of (vx,vy,vz,w,w,w), i.e. say the velocity is too fast for the Wright Flyer.
Response expected: The simulation may either fail to execute, prompting the user as to
why, or the simulation may execute and immediately crash.
Note: This test case will have to be handled individually by the group responsible for this
test.
R8
The simulation execution begins once the simulation definition has been done and all the
parameters necessary to set up the execution are available. The simulation user starts the
execution.
Initial State of System: The simulation definition is complete, but simulation execution
has not been initiated.
Stimulus given: Initiate simulation execution
Response Expected: Complied. Send trace message to the ITP regarding this test case.
R9
The simulation can be exited from using simulation user control at any time.
Initial State of System: The simulation is currently in execution stage
Stimulus given: Simulation user terminates the simulation.
Response Expected: No states are saved and the simulation is terminated…. Trace
message to be send to the ITP.
R10
The simulation can be paused and continued by the simulation pilot or simulation user.
Initial State of System: The simulation is currently in execution stage
Stimulus given: Simulation user pauses simulation.
Response Expected: The state of the federates are saved, no events occur till the
simulation user enters command to resume simulation. Trace message send to the ITP.
Initial State of System: The simulation is currently paused.
Stimulus given: Resume simulation.
Response Expected: Complied. Report to ITP via trace message.
R11
The simulation pilot or simulation user can select different types of simulated pilots.
R11.1
It can be a man in the loop pilot, where it is replicates the control signals that are obtained
from the human pilot at an external input device.
R11.2
The simulation does not preclude other types of simulated pilots.
Cannot present test case for these requirements due to the broadness of their scope. The
group responsible for the pilot should test these requirements separately.
R12
The simulated pilot controls the cockpit control mechanisms - the canard control and the hip
saddle.
Cannot present test case for these requirements due to the broadness of their scope. The
group responsible for the pilot should test these requirements separately.
R13
Each plane in the simulation has 2 wings, whose specifications have to be defined.
R13.1
The wings simulate drag and lift.
R13.2
The wings simulation can be made to use wind tunnel data.
Cannot present test case for these requirements due to the broadness of their scope. The
Wing/Canard/Rudder group should test these requirements separately.
R14
Each plane has one rudder.
R14.1
The rudder controls the yaw of the plane.
R14.2
The rudder simulation can be made to use wind tunnel data.
Cannot present test case for these requirements due to the broadness of their scope. The
Wing/Canard/Rudder group should test these requirements separately.
R15
Each plane has 2 canards, whose specifications have to be defined.
R15.1
The canards control the pitch of the flyer.
R15.2
The canards simulation can be made to use wind tunnel data.
Cannot present test case for these requirements due to the broadness of their scope. The
Wing/Canard/Rudder group should test these requirements separately.
R16
Each plane has an engine.
R16.1
The engine can have a constant force vector as an output to other components of the
plane.
R16.2
The engine weight depends on the amount of fuel.
R16.3
When the engine runs out of fuel, it stops producing thrust.
Cannot present test case for these requirements due to the broadness of their scope. The
Control group should test these requirements separately.
R17
The pilot uses the hip saddle in order to control the orientation of the wing and rudder.
Cannot present test case for these requirements due to the broadness of their scope. The
Pilot/Environments/Scripts group should test these requirements separately.
R18
The plane interacts with the simulated pilot via the rudder control and hip saddle in order to get
control input.
Cannot present test case for these requirements due to the broadness of their scope. The
UI, Control, Wing/Canard/Rudder and Pilot/Environments/Scripts group should test these
requirements separately.
R19
There are at-least 4 different kinds of views that can be defined.
R19.1
Pilot view - This is the front view as seen by the pilot flying the plane.
R19.2
Wingman View - This is a view of a particular plane from a position relative to that
plane.
R19.3
Spot view - It is a view of a particular plane from a fixed position
R19.4
Constant view- A view from a constant perspective to a constant point in space.
R19.5
Each view has a zoom control associated with it, by which the scope of the view can be
controlled.
These are just definitions. The test cases follow in the following section.
R20
Views can be added and removed during execution. Additionally it is also possible to change the
parameters that define the view. For instance, the simulation user could change the position
parameters of the wingman view thereby giving the user a different view of the plane.
Initial State of simulation: No views are turned on
Stimulus given: Turn on Pilot View
Response Expected: Complied.
Note: To be handled separately by the UI group.
Initial State of simulation: No views are turned on
Stimulus given: Turn on Wingman View
Response Expected: Complied.
Note: To be handled separately by the UI group.
Initial State of simulation: No views are turned on
Stimulus given: Turn on Spot View
Response Expected: Complied.
Note: To be handled separately by the UI group.
Initial State of simulation: No views are turned on
Stimulus given: Turn on Constant View
Response Expected: Complied.
Note: To be handled separately by the UI group.
Initial State of simulation: The Pilot View is turned on. Everything else is off.
Stimulus given: Zoom in, i.e. take a smaller block of the view and enhance the block to
see more detailed information.
Response Expected: Complied.
Note: To be handled separately by the UI group.
Initial State of simulation: The Spot View is turned on. Everything else is off.
Stimulus given: Zoom in, i.e. take a smaller block of the view and enhance the block to
see more detailed information.
Response Expected: Complied.
Note: To be handled separately by the UI group.
Initial State of simulation: The Constant view is turned on.
Stimulus given: Turn on the Pilot and Wingman view.
Response Expected: Complied.
Note: To be handled separately by the UI group.
R21
During simulation scenario definition, the simulation pilot or simulation user can select whether to
record data for later control playback.
R21.1
Upon completion of the flight, the simulation pilot or simulation user can select whether
to save the recorded data.
Initial State of Simulation: The flight simulation has ended.
Stimulus Given: Choose to save recorded flight data
Response Expected: Complied
Note: To be handled separately by the UI group.
R22
During simulation scenario definition, the simulation user can decide to use control playback.
R22.1
Upon loading the control playback file, the simulation user is presented the simulation
scenario-definition-user-interface.
R22.1.1
All values are as they were when the original simulation scenario was defined,
with the exception of random items.
R22.1.1.1
For items that were random during recording, the simulation user can
choose to:
R22.1.1.1.1
Use the recorded data until they are exhausted.
R22.1.1.1.2
Use the recorded data until the simulation user takes control.
R22.1.1.1.3
Do not use the recorded data.
R22.1.1.2
The simulation user can choose any of the standard methods to produce
data after the recorded data are no longer in use.
R22.1.2
R22.2
R23
The simulation user can vary any of the configurable items.
The simulation user can opt to playback control on each plane in the simulation scenario
on a plane-by-plane basis.
With control playback, during simulation scenario execution, the simulation executes
automatically until the simulation user takes control, until the recorded data are exhausted, or until
the simulation exit conditions are met.
R23.1
The simulation executes according to the parameters defined in the simulation scenario
definition.
R23.2
If the simulation user has not taken control before the recorded data run out, the
simulation is paused until the simulation user or simulation user explicitly continues the
simulation.
R23.3
After the simulation pilot has taken control, control may not be returned to the system.
R24
With control playback, during simulation execution, the simulation user can manipulate views in
the user interface as during regular simulation scenario execution.
Once the simulation user or simulation pilot has wrested or been given control, the
simulation execution proceeds just as any other simulation would. Thus, all requirements
applying to simulation scenario execution apply to the case of regaining control after
control playback.
R25
After the simulation user or simulation pilot has taken control, the simulation executes exactly as a
normal simulation execution.
Cannot come up with test cases for these requirements. UI group will have to test these
requirements from their User Interface directly and make sure that all functionality
available on the UI complies with the requirements. None of the above requirements are
specific to an extent for which test cases can be written
Performance Requirements
We cannot really test to check whether the UI communicates actions and reactions within
.01 seconds. It is quite possible that multiple federated might be executing concurrently
which might have a slowing down effect for the overall simulation.
R26
The simulation has to work under the HLA environment and must follow all HLA rules as defined
below:

Federations shall have an HLA Federation Object Model (FOM), documented in accordance with the
HLA Object Model Template.

In a federation, all object representation shall be in the federates, not in the runtime infrastructure
(RTI).

During a federation execution, all exchange of FOM data among federates shall occur via the RTI.

During a federation execution, federates shall interact with the RTI in accordance with the HLA
interface specification.

During a federation execution, an attribute of an instance of an object shall be owned by only one
federate at any given time.

Federates shall have an HLA Simulation Object Model (SOM), documented in accordance with the
HLA OMT.

Federates shall be able to update and/or reflect any attributes of objects in their SOM and send and/or
receive

SOM object interactions externally, as specified in their SOM.

Federates shall be able to transfer and/or accept ownership of attributes dynamically during a
federation execution, as specified in their SOM.

Federates shall be able to vary the conditions (e.g., thresholds) under which they provide updates of
attributes of objects, as specified in their SOM.

Federates shall be able to manage local time in a way which will allow them to coordinate data
exchange with other members of a federation.
R27
The interaction between simulated objects, also called federates is achieved through the HLA RTI.
R28
The simulation has to run under the Windows NT environment.
We will not be testing these requirements during this iteration of the project (this
semester), due to the amount of overhead involved.
R29
The system is capable of completing simulation scenario definition and execution no less than
90% of the time.
R30
When the system fails, it fails gracefully as described below.
R30.1
The system never causes an unhandled exception.
R30.2
If the system encounters an internal error, the system produces a diagnostic error message
before exiting.
Upon running our test cases, if we find that successful completion rate of all test cases
run, is over 90%, then that is a good yardstick to use in order to measure system
reliability.
R31
The source code adheres to the coding standards defined in the Software Quality Assurance Plan.
R32
The implementation is documented according to the standards defined in the Software Quality
Assurance Plan.
Can’t really write a test case for this.