Lab 3 – Prototype Test Plan
1
RUNNING HEAD: LAB 3 – PROTOTYPE TEST PLAN
Personal Alert and Safety System
Lab 3 – Prototype Test Plan
CS 411 Blue Team:
Dan Cox
Jon Szewczak
Brittany Dufort
Marcus Henry
Gordon Bland
Braden Gibson
Gene H. Price
April 10, 2011
Lab 3 – Prototype Test Plan
2
Table of Contents
1.
Objectives (Dan Cox) ............................................................................................... 4
2.
References (Group) ................................................................................................... 5
3.
Test Plan (Dan Cox).................................................................................................. 6
3.1
Testing Approach (Dan Cox) ................................................................................ 6
3.2
Identification of Tests (Dan Cox).......................................................................... 7
3.3
Test Schedule (Dan Cox) .................................................................................... 10
3.4
Fault Reporting and Data Recording (Dan Cox) ................................................. 10
3.5
Resource Requirements (Dan Cox) ..................................................................... 10
3.6
Test Environment (Dan Cox) .............................................................................. 11
3.7
Test Responsibilities (Dan Cox, Jon Szewczak) ................................................. 12
4.
Test Procedures (Dan Cox) ..................................................................................... 12
4.1
Test Case Names and Identifiers (Dan Cox, Jon Szewczak) .............................. 13
4.1.1 Hardware Test Cases (Marcus Henry) ........................................................... 13
4.1.2 Database Test Cases (Gordon Bland) ............................................................ 17
4.1.3 Radio Device Test Cases (Jon Szewczak) ..................................................... 18
4.1.4 Master Control Module Test Cases (Jon Szewczak) ..................................... 21
4.1.5 Simulation Driver Interface Test Cases (Braden Gibson) ............................. 28
4.1.6 Dispatch User Interface Test Cases (Brittany Dufort) ................................... 31
5.
Traceability to Requirements (Dan Cox, Jon Szewczak) ....................................... 33
Lab 3 – Prototype Test Plan
3
List of Tables
Table 1. PASS Prototype Test Cases by Category ............................................................. 9
Table 2. Test Schedule ...................................................................................................... 10
Table 3. Test Responsibilities Summary .......................................................................... 12
List of Figures
Figure 1. Conference Room Layout.................................................................................. 11
Lab 3 – Prototype Test Plan
4
1. Objectives (Dan Cox)
The Personal Alert and Safety System (PASS) is a complex entity requiring many
different interconnected parts to work in conjunction with each other. The Prototype for said
system then must demonstrate, at some smaller scale, some of the required complexity in order
to be deemed a successful representation of the larger project. Therefore the prototype was
divided into two areas: signal interpretation and network modeling.
Consisting primarily of two major hardware components, the signal interpretation portion
of the prototype will seek to demonstrate the successful capture, translation and display of a
signal sent from a small handheld radio device. Communications between a
microprocessor/transceiver combination and a personal computer shall be expressed through the
execution of four different test procedures. The results will show the importance and
interconnectivity of each part with regard to the greater whole within the hardware configuration.
Each procedure will show, in turn, a selection of signal processing. Upon all procedures being
passed successfully, the signal interpretation portion will demonstrate clearly the ability to
perceive and process a radio signal.
The modeling of a network of transceivers, a major portion of PASS, can be quite
expensive and expansive to construct in physical space, so it was decided that a simulation would
be the best solution. This simulation will demonstrate the perceiving of a radio device similar to
the signal interpretation part, but will go farther in that it will also show, via a reduced
propagation method, the processing of radio signals via simulated interlocking systems. Many of
the same systems that would be physically separated will be running together virtually. The user
is a provided a graphical interface with which to start the initial signaling and, ultimately, see the
results via a neighboring secondary graphical interface. During the simulation, a user is provided
Lab 3 – Prototype Test Plan
5
both of these interfaces as a way of monitoring a signal from a virtual radio device through the
systems as it is finally shown on the previously mentioned secondary graphical interface.
All virtual systems will have their own set of test procedures. These will verify that each
system can perform its necessary functionality. Finally, a fully integrated test will be performed
with all systems running to show that the simulation is functional and successful.
2. References (Group)
Arduino. Retrieved March 16, 2011, from Arduino.cc: http://www.arduino.cc/
Faculty and Staff. (2008, November 13). Retrieved January 30, 2011, from Old Dominion
University: http://www.odu.edu/oduhome/faculty.shtml
Lab 1 – Prototype Description. CS411 Blue Team, Individual. March 2, 2011. Old Dominion
University
Lab 2 – Prototype Specification. CS411 Blue Team, Group. March 30, 2011. Old Dominion
University
Nordic FOB. Retreived March 16, 2011, from SparkFun Electronics:
http://www.sparkfun.com/products/8602
Old Dominion University. (2011, January). Retrieved January 30, 2011, from EducationPortal.com: http://education-portal.com/directory/school/Old_Dominion_University.html
Shrimpton, Aaron. Arduino nRF24L01 Driver. Retrieved March 16, 2011, from Madsie.co.uk
http://www.madsie.co.uk/projects/arduino-nrf24l01
Transceiver nRF24L01+ Module with Chip Antenna. Retrieved March 16, 2011, from
SparkFun Electronics: http://www.sparkfun.com/products/691
Wilson, P. (2010, November 3). ROBBERIES AT ODU ARE DOWN WITH PATROLS NEAR
CAMPUS. The Virginian-Pilot , p. B3.
(This Space Left Intentionally Blank)
Lab 3 – Prototype Test Plan
6
3. Test Plan (Dan Cox)
The following section will discuss all necessary components of the PASS prototype.
Starting with the testing schedule and reporting requirements, it will detail the order and
mechanics of the testing procedures. The section will then proceed to the resource and testing
requirements (i.e. the physical materials present for the demonstration). The conclusion of the
section will be the listing of each team member’s responsibilities during the presentation of the
prototype.
3.1 Testing Approach (Dan Cox)
The demonstration of the PASS prototype will be divided into several hierarchical
component tests, each representing the intention of showing successful execution of individual
parts at each layer of the prototype. The first division comes in the split of the prototype into
signal interpretation and network modeling; each system will be tested separately. The second
division comes from the components of the simulation of network model; each system will be
tested, some together. A final total integration test will be performed showing all the network
model systems working in conjunction with each other.
(This Space Left Intentionally Blank)
Lab 3 – Prototype Test Plan
7
3.2 Identification of Tests (Dan Cox)
The following table shows test cases as grouped by category. Each test case is detailed in
its labeled section. They can be found in section 4.1.
Category
ID
1
2
Description
Signal Capture,
Interpretation and Display
(Hardware)
Subsystem Testing
(Database)
Test
Case
1.1
Description
Establish Connection between the
microprocessor and the Personal
Computer.
1.2
Upload the code to the microprocessor.
1.3
Show that the wireless transceiver works.
1.4
Press a fob button and receive the signal
on the computer.
2.1
Test create, read, update, and delete
stored procedures on the database.
2.2
2.3
2.4
3.1
3
Subsystem Testing (Radio
Device)
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
Test updateable views for functionality
and response/refresh time.
Test triggers for proper functionality on
various create, read, and delete
commands.
Test tables for proper schema,
functionality, and efficiency and ease of
use, and for proper data values.
RadioDevice - Instantiation
RadioDevice - Switch Transmit modes
RadioDevice - Paint
RadioDevice - Transmit
RadioDevice - Receive
RadioDevice - StandByColor
RadioDevice - StandBySize
RadioDevice - TransmitColor
RadioDevice - TransmitSize
RadioDevice - ReceiveColor
RadioDevice - ReceiveSize
Lab 3 – Prototype Test Plan
8
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
4.10
4
Subsystem Testing (Master
Control Module)
4.11
4.12
4.13
4.14
4.15
4.16
MCM Collections TransceiverInfoCollection - Select
MCM Collections TransceiverInfoCollection - Add
MCM Collections TransceiverInfoCollection - Remove
MCM Collections TransceiverInfoCollection - GetByID
MCM Collections - UserInfoCollection Select
MCM Collections - UserInfoCollection Add
MCM Collections - UserInfoCollection Remove
MCM Collections - UserInfoCollection GetByID
MCM Collections - UserInfoCollection GetByName
MCM Collections - FobInfoCollection Select
MCM Collections - FobInfoCollection Add
MCM Collections - FobInfoCollection Remove
MCM Collections - FobInfoCollection GetByID
MCM Collections - FobInfoCollection GetByUserID
MCM Collections IncidentInfoCollection - Select
MCM Collections IncidentInfoCollection - Add
4.18
MCM Collections IncidentInfoCollection - Remove
MCM Collections IncidentInfoCollection - GetByID
4.19
MCM Collections IncidentInfoCollection - GetByUserID
4.20
MCM - Process Alerts
4.17
Lab 3 – Prototype Test Plan
5
6
9
Graphical Systems
(Simulation Driver
Interface)
Graphical Systems
(Dispatch User Interface)
5.1
Inbound Connection
5.2
Outbound Connection
5.3
User Info
5.4
Fob Info
5.5
Transceiver Info
5.6
Alert Signal
5.7
Data Flow
5.8
Maps
5.9
Signal Response
5.10
Transceiver Display
5.11
Fob Creation
6.1
Listening for MCM
6.2
Connection with MCM
6.3
Object is Alert Object
6.4
Display alerts on map
6.5
Display alerts in extended data form
6.6
Displays alerts in alerts information table
Table 1. PASS Prototype Test Cases by Category
(This Space Left Intentionally Blank)
Lab 3 – Prototype Test Plan
10
3.3 Test Schedule (Dan Cox)
The Blue Team, the developers of PASS, have been given a full hour for the presentation
and demonstration of the prototype. However, this also includes all question and answer time, so
a reduced schedule of approximately 45 minutes will be allocated. The following table shows the
division of time without the addition of a five minute setup time that will precede the schedule.
Start Time
(hours:min)
Duration
0:05
0:10
0:15
0:20
0:25
0:35
5
5
5
5
10
10
Test
Category
1
2
3
4
5
6
Dependencies
None
None
None
3,2
4,3,2
4,3,2
Table 2. Test Schedule
3.4 Fault Reporting and Data Recording (Dan Cox)
In order that all test procedures and cases be declared successful, each will need to be
logged and noted as to if it failed or not. One team member will be responsible for this task. This
team member will have a printed list of the test procedures to be covered and their order. Upon
the success or failure of each case, notations will be made of the time taken before proceeding to
the next procedure.
3.5 Resource Requirements (Dan Cox)
Since, as it has been stated in early sections, PASS is divided into main branches from the
tree of test cases, the main requirement of the simulation is that a working computer with at least
.NET Framework 3.5 be installed in a Windows operating system environment. The simulation is
Lab 3 – Prototype Test Plan
11
targeted to that specific environment and, while the software will be brought into the
demonstration room, that main requirement must be met.
The second branch of the test cases, the hardware or signal interpretation one area,
requirements little in the way of resources preexisting in the demonstration room. Both the
hardware involved and a laptop on which to display the necessary outputs will be brought in, run
by and removed from the room by a team member. The team member responsible for this task
will be discussed in a later section.
3.6 Test Environment (Dan Cox)
Figure 1. Conference Room Layout
The environment in which the demonstration of PASS will take place is limited in both
seating and presentation space. Preparations must be made in advance therefore to determine the
location of each piece of hardware that will brought into the room. The simulation portion must
also be accounted for with a predetermined location for presenters to stand and talk to the panel.
Lab 3 – Prototype Test Plan
12
Since the hardware portion of the testing will be first, those components will be placed
opposite the panel in a prominent place. The simulation however will also be queued and ready
for demonstration immediately. Once the hardware portion ends, the projected screens will show
the simulation software running and that part of the demonstration will begin.
3.7 Test Responsibilities (Dan Cox, Jon Szewczak)
Each team member will be responsible for an area of the testing process. The table below
summarizes the duties of each team member.
Name
Title
Marcus Henry
Lead Hardware Developer
Gordon Bland
Database Administrator
Jon Szewczak
Lead Software Developer
Brittany Dufort
User Interface Developer
Braden Gibson
User Interface Developer
Dan Cox
Project Manager
ALL
n/a
Role
Will introduce and demonstrate the process and test
cases involved for testing the Hardware Branch.
Will show that the database is operational and supplied
with the necessary information to support the
simulation.
Will speak of the subsystems that make up the
simulation and overall architecture of the simulation
environment.
Will show that the Dispatch User Interface module
interacts correctly with all other simulation modules.
Will show that the Simulation Driving Interface is fully
functional and working correctly with all other
simulation modules.
Will lead the presentation and log all faults and errors
that may arise during prototype presentation.
Field Questions
Table 3. Test Responsibilities Summary
4. Test Procedures (Dan Cox)
The unique time constraints that PASS was developed under led to some formidable
challenges. As a result, some of the procedures that would normally be associated with test cases
were not available at the time of the writing. In their place are test cases that are, for the most
part, largely unfinished. The editor of this paper would like to note that he included such works
in the state he received them in order to maintain their authenticity.
Lab 3 – Prototype Test Plan
13
4.1 Test Case Names and Identifiers (Dan Cox, Jon Szewczak)
The reader should be aware that many of the following sections are incorrectly formatted,
incomplete, and/or to some degree inaccurate. This is due in large part to the simulation being
far from complete. Without a more complete picture of how the simulation is supposed to
function, creating test cases becomes an exercise in futility for most people.
4.1.1 Hardware Test Cases (Marcus Henry)
Test Case 1.1 -- Establish Connection between the microprocessor and the Personal
Computer
Specification References:
3.1.1.4 Will demonstrate that a microcontroller is controlled by a personal computer
Test Description: This test will ensure that a personal computer is able to establish a connection
with the microprocessor that is used in the prototype.
Test Level: Component
Test Type: Functional
Initialization:
1. Arduino Software must be installed on computer.
2. Arduino Program must be running.
Test Inputs:
1. USB Serial Cord
Test Procedure:
1.
2.
3.
4.
Execute or Double click the Arduino program
Select Board from User Control tab and in the drop down window select Arduino Uno.
Ensure the USB serial cord is connected to the target personal computer’s USB port/
Ensure the USB serial cord is connected to the microprocessor’s serial port.
Expected Results:
Lab 3 – Prototype Test Plan
14
1. The Arduino Uno’s ON LED (Light Emitting Diode) will light up. The micro controller
is receiving power from the computer.
Test Case 1.2 Upload the code to the microprocessor
Specification References:
3.1.1.5 Will show that the computer can run the microcontroller.
Test Description: This test will ensure that a personal computer is able to establish a connection
with the microprocessor that is used in the prototype.
Test Level: Component
Test Type: Functional
Initialization:
1. Arduino Software must be installed on computer.
2. Arduino Program must be running.
Test Inputs:
1. Sample Source Code
Test Procedure:
1.
2.
3.
4.
Run the Arduino program
Ensure the USB serial cord is connected to the target personal computer’s USB port
Ensure the USB serial cord is connected to the microprocessor’s serial port.
Open the “File” tab in the Arduino program and select “Examples” , then select “Basics”
and finally select “Blink”
5. Select Sketch tab and select verify and compile.
Expected Results:
1. The Arduino program will state Uploading to board…. After this it will state" Done
uploading". If this occurs then the PC and Microcontroller are properly synched.
Test Case 1.3 -- Show that the wireless transceiver works.
Specification References:
3.1.1.6 Will demonstrate that source code can be uploaded to the microcontroller.
Lab 3 – Prototype Test Plan
3.1.1.7 Will demonstrate that the microcontroller interfaces with the transceiver.
Test Description: Show that the code uploaded to the transceiver by the Arduino software
program runs the transceiver. This test shows that the transceiver is correctly installed and
running.
Test Level: Component
Test Type: Functional
Initialization:
1.
2.
3.
4.
Arduino Software must be installed on computer.
Arduino Program must be running on the computer.
Arduino Microcontroller must be connected to the computer via USB cable
Wireless transceiver must be properly wired to microcontroller.
Test Inputs:
1. Transceiver Code
Test Procedure:
1.
2.
3.
4.
Run the Arduino program
Ensure the USB serial cord is connected to the target personal computer’s USB port.
Ensure the USB serial cord is connected to the microprocessor’s serial port.
One the “File” select “Upload a Sketch”, for purposes of this prototype select
“Transceiver Code”
5. Select Upload to a Board button.
6. After successful Upload, select Serial Output Monitor.
Expected Results:
2. The serial output monitor should display text as in the figure below. It is important to
note that the rf_setup field should display 111, if it does not then there is some error.
Test Case 1.4 -- Press a fob button and receive the signal on the computer.
Specification References:
3.1.1.1 Will receive a fob signal at a certain frequency
15
Lab 3 – Prototype Test Plan
16
3.1.1.2 Will relay a signal from the transceiver to a personal computer by use of a
microcontroller.
3.1.1.3 Will display relevant information for the User, such as which button is pressed
and how many times this occurs.
Test Description: This test will ensure that when a button on the Nordic fob is pressed, the
hardware and software work together in order to bring that signal to the user.
Test Level: Component
Test Type: Functional
Initialization:
1.
2.
3.
4.
5.
Arduino Software must be installed on computer.
Arduino Program must be running.
Source code that runs the microprocessor and transceiver.
Correctly wired microcontroller and transceiver.
Fob with power(i.e. battery installed)
Test Inputs:
1. Five-button key fob
2. Arduino Program using the Serial Port Monitor.
Test Procedure:
1.
2.
3.
4.
Run the Arduino program
Upload the sketch Transceiver Code
Press the Upload to Board button on the GUI Display.
Upon successful compilation, any button press of the fob is read by the Arduino program.
Expected Results:
1. The Arduino serial output monitor should display the output from Test Case 1.3. It will
state what frequency the transceiver is currently using, the amount of data that is being
transmitted in bytes and the status check. After the Wireless initialized statement, the
testing of the key fob begins. As can be seen below, each button of the Five-Button fob
is pressed and the program should relay which button is pressed by the user.
Lab 3 – Prototype Test Plan
17
4.1.2 Database Test Cases (Gordon Bland)
Description
Database
Database
Database
Database
Test
Case
2.1
2.2
2.3
2.4
Description
Objective &
Setup
Expected Result
Stored
Procedures
Test create,
read, update,
and delete stored
procedures on
the database.
Stored procedures
for CRUD shall
work on all tables in
the PASS database.
Updateable
Views
Test updateable
All updateable views
views for
shall return the
functionality and
expected data within
response/refresh
0.5 ms.
time.
Triggers
Tables
Test triggers for
proper
functionality on
various create,
read, and delete
commands.
Triggers shall
automatically run
scripts to facilitate
database use, and
shall disallow
certain actions
directed via scripts.
Test tables for
proper schema,
functionality,
and efficiency
and ease of use,
and for proper
data values.
Tables each shall
have a primary key.
Tables shall all be
linked by at least
one foreign key to
another table.
Correct Default
values and value
types must be set for
each column on
creation and update.
Each column shall
disallow incorrect
input value types on
update and creation.
Tables shall allow
delete commands on
entire rows.
Lab 3 – Prototype Test Plan
18
4.1.3 Radio Device Test Cases (Jon Szewczak)
3 Description: RadioDevice Purpose: Verify that this abstract base class
Test Category
- Instantiation
cannot have instances created.
3.1
Test Case
Setup Conditions
Test Activity
Expected Results
Pass/Fail Comments
1. Simulation App
Attempt to define a new
Exception is thrown
Running
RadioDevice object in code.
Description: RadioDevice
- Switch
Transmit
3.2
Test Case
modes
Setup Conditions
Test Activity
1. Simulation App
Toggle the Mode property in
Running
all 3 modes
2. Have an object
inherited from
RadioDevice
Purpose: Verify that the property is set and the
information is saved.
3 Description: RadioDevice
- Paint
3.3
Test Case
Setup Conditions
Test Activity
1. Simulation App
1. Instantiate an object
Running
inherited from RadioDevice
2. Place it on the parent
form.
3. Move the form around
Purpose: Verify that the object is drawn when
the windowing system calls the map
repaints itself.
Expected Results
Pass/Fail Comments
The object should
redraw itself at all times
maintaining color
relative position and
size.
Description: RadioDevice
- Transmit
Purpose: Verify that when called the output of
the feature will be a two element array
of integers that make up a transmitted
signal.
Expected Results
Pass/Fail Comments
Will send an array of
size 2 of integers
If the object is not in
transmit mode, then an
exception is thrown.
3
Test Category
Test Category
3
Test Category
Test Case
3.4
Setup Conditions
1. Simulation App
Running
2. Have an object
inherited from Radio
Device.
Test Activity
Call Transmit() method of
object.
Expected Results
Pass/Fail Comments
Property value is saved.
(This Space Left Intentionally Blank)
Lab 3 – Prototype Test Plan
Test Category
Test Case
3
19
Description: RadioDevice
- Receive
3.5
Setup Conditions
1. Simulation App
Running
Test Activity
Call Receive() method of
object.
2. Have an object
inherited from Radio
Device.
Test Category
Test Case
Setup Conditions
1. Simulation App
Running
2. Have an object
inherited from
RadioDevice.
Test Category
Test Case
RadioDevice Purpose: Verify that when this property is
changed that the display of the
StandByColo
graphic representation reflects the
3.6
r
change.
Test Activity
Expected Results Pass/Fail Comments
Call
1. Saves the
obj.StandByColor=Color.<so color for that
meColor>
instance
2. When the
object is redrawn
the new color is
displayed.
3
3
Description:
Description:
RadioDevice
StandBySize
3.7
Setup Conditions
Test Activity
1. Simulation App
Running
Call obj.StandBySize = new
Size()
2. Have an object
inherited from
RadioDevice.
Verify that when called the object
will take an array of integers as it's
input and decipher its contents and
decide what to do with it.
Expected Results
Pass/Fail Comments
Will take an integer
array as input.
It should store the array
in its message private
member variable. If the
object is not in the
Receive mode then an
exception is thrown.
Purpose:
Verify that when this property is
changed that the size of the filled
circle that is the graphic
representation of the of object reflects
the change.
Expected Results Pass/Fail Comments
Uses
1. Saves the size
Drawing.Size
of the object
object
2. When the
object is redrawn
the new size is
used.
Purpose:
(This Space Left Intentionally Blank)
Lab 3 – Prototype Test Plan
Test Category
Test Case
3
20
Description:
3.8
Setup Conditions
RadioDevice
TransmitCol
or
Test Activity
Call
obj.TransmitColor=Color.<s
omeColor>
1. Simulation App
Running
Test Case
3
Description:
RadioDevice
TransmitSize
3.9
Setup Conditions
Test Activity
1. Simulation App
Running
Call obj.TransmitSize = new
Size()
2. Have an object
inherited from
RadioDevice.
Test Category
Test Case
Setup Conditions
1. Simulation App
Running
2. Have an object
inherited from
RadioDevice.
1. Saves the color
for that instance
2. When the
object is redrawn
the new color is
displayed.
2. Have an object
inherited from
RadioDevice.
Test Category
Verify that when this property is
changed that the display of the
graphic representation reflects the
change.
Expected Results Pass/Fail Comments
Purpose:
3
3.10
Description:
RadioDevice
ReceiveColo
r
Test Activity
Call
obj.ReceiveColor=Color.<so
meColor>
Verify that when this property is
changed that the size of the filled
circle that is the graphic
representation of the bject reflects the
change.
Expected Results Pass/Fail Comments
Uses
1. Saves the size
Drawing.Size
of the object
object
2. When the
object is redrawn
the new size is
used.
Purpose:
Verify that when this property is
changed that the display of the
graphic representation reflects the
change.
Expected Results Pass/Fail Comments
Purpose:
1. Saves the color
for that instance
2. When the
object is redrawn
the new color is
displayed.
(This Space Left Intentionally Blank)
Lab 3 – Prototype Test Plan
Test Category
Test Case
3
Description:
21
RadioDevice
ReceiveSize
3.11
Setup Conditions
Test Activity
1. Simulation App
Running
Call obj.ReceiveSize = new
Size()
2. Have an object
inherited from
RadioDevice.
Verify that when this property is
changed that the size of the filled
circle that is the graphic
representation of the object reflects
the change.
Expected Results Pass/Fail Comments
Uses
1. Saves the size
Drawing.Size
of the object
object
2. When the
object is redrawn
the new size is
used.
Purpose:
4.1.4 Master Control Module Test Cases (Jon Szewczak)
Test
Description: TransceiverInfoCollection Purpose: Verfiy that the MCM
4
- Select
communicates with the database
Category
and retrieves transceiver data.
Test
4.1
Case
Setup Conditions Test Activity
Expected Results Pass/Fail Comments
1 . Returns a
1. index =
1. Populated
TransceiverInfo
valid
1. Call MCM.Transceivers[int index]
Database
object to hold the
integer
data
index
2. index =
2. Simulation App
2. Returns an
2. Call MCM.Transceivers[int index]
invalid
Running
Exception
integer
Test
Description: TransceiverInfoCollection Purpose: Verify that the MCM
4
- Add
communicates with the database
Category
and adds a new entry to the
Test
4.2
tables
Case
Setup Conditions Test Activity
Expected Results Pass/Fail Comments
Adds a record to
the database, and
1. Simulation
lat, long are
1. Call MCM.Transceivers.Add(lat, long)
returns a
App Running
double/float
TranscieverInfo
object.
Lab 3 – Prototype Test Plan
Test
Category
4
Test Case
4.3
Setup Conditions
1. Populated
Database
22
Description: TransceiverInfoCollection Purpose:
- Remove
Test Activity
1. Call MCM.Transceivers.Remove(ID)
Verify that the MCM
communicates with the
database and removes an entry
to the tables
Expected Results Pass/Fail Comments
Deletes a record
ID = valid
from the database
integer ID
2. Simulation
App Running
Test
Category
4
Test Case
4.4
Setup Conditions
1. Populated
Database
2. Simulation
App Running
Test
Category
1
Test Case
4.5
Description: TransceiverInfoCollection Purpose:
- GetByID
Test Activity
Verify that the MCM
communicates with the
database and gets a
TransceiverInfo object based
on the TransceiverID.
Expected Results Pass/Fail Comments
1. Call MCM.Transceivers.GetByID(int
ID)
Retrieves a valid
UserInfo object.
Description: UserInfoCollection Select
Purpose:
Setup Conditions
Test Activity
1. Populated
Database
1. Call MCM.Users[int index]
2. Simulation
App Running
2. Call MCM.Users[int index]
ID = valid
integer ID
Verfiy that the MCM
communicates with the
database and retrieves user
data.
Expected Results Pass/Fail Comments
Returns a
index =
UserInfo object
valid
that holds the
integer
data
index
index =
Returns an
invalid
Exception
integer
(This space left intentionally blank)
Lab 3 – Prototype Test Plan
Test
Category
4
Test Case
4.6
Description: UserInfoCollection Purpose: Verify that the MCM
- Add
communicates with the database
and adds a new entry to the tables
Setup Conditions
Test Activity
1. Simulation
App Running
1. Call MCM.Users.Add(name,
sex, age)
Test
Category
4
Test Case
4.7
Setup Conditions
1. Populated
Database
2. Simulation
App Running
23
Expected Results
Adds a record to the
database, and
returns a
TranscieverInfo
object.
Pass/Fail Comments
Description: UserInfoCollection Purpose: Verify that the MCM
- Remove
communicates with the database
and removes an entry to the tables
Test Activity
Expected Results
1. Call MCM.Users.Remove(ID)
Deletes a record
from the database
Pass/Fail Comments
ID = valid
integer ID
Description: UserInfoCollection Purpose: Verify that the MCM
- GetByID
communicates with the database
and gets a UserInfo object based on
4.8
Test Case
the UserID.
Setup Conditions Test Activity
Expected Results
Pass/Fail Comments
1. Populated
Database
1. Call MCM.Users.GetByID(int
Retrieves a valid
ID = valid
ID)
UserInfo
object.
integer ID
2. Simulation
App Running
Test
Category
4
Description: UserInfoCollection Purpose: Verify that the MCM
- GetByName
communicates with the database
and gets a UserInfo object based on
4.9
Test Case
the saved name of the user.
Setup Conditions Test Activity
Expected Results
Pass/Fail Comments
1. Populated
1. Call
Database
Retrieves a valid
MCM.Users.GetByName(string
UserInfo object
2. Simulation
name)
App Running
Test
Category
4
Lab 3 – Prototype Test Plan
Test
Category
4
Test Case
4.10
Description:
24
FobInfoCollection Select
Setup Conditions
Test Activity
1. Populated
Database
1. Call MCM.Fobs[int index]
2. Simulation App
Running
2. Call MCM.Fobs[int index]
Test
Category
4
Test Case
4.11
Description:
FobInfoCollection Add
Setup Conditions
Test Activity
1. Simulation App
Running
1. Call MCM.Fobs.Add(UserID)
Test
Category
4
Test Case
4.12
Setup Conditions
1. Populated
Database
2. Simulation App
Running
Test
Category
4
Test Case
4.13
Setup Conditions
1. Populated
Database
2. Simulation App
Running
Description:
FobInfoCollection Remove
Purpose:
Verfiy that the MCM
communicates with the database
and retrieves Fob data.
Expected Results
Returns a FobInfo
object that holds
the data
Purpose:
index =
invalid
integer
Verify that the MCM
communicates with the database
and adds a new entry to the tables
Expected Results
Adds a record to
the database, and
returns a
TranscieverInfo
object.
Purpose:
1. Call MCM.Fobs.Remove(ID)
Deletes a record
from the database
Test Activity
1. Call MCM.Fobs.GetByID(int ID)
Pass/Fail
Comments
UserID as
integer value
Verify that the MCM
communicates with the database
and removes an entry to the tables
Expected Results
FobInfoCollection GetByID
Comments
index = valid
integer index
Returns an
Exception
Test Activity
Description:
Pass/Fail
Pass/Fail
Comments
ID = valid
integer ID
Verify that the MCM
communicates with the database
and gets a FobInfo object based on
the FobID.
Expected Results
Pass/Fail Comments
Purpose:
Retrieves a valid
FobInfo object.
ID = valid
integer ID
Lab 3 – Prototype Test Plan
Test
Category
Test Case
Test Activity
Verify that the MCM
communicates with the database
and gets a FobInfo object based
on the UserID.
Expected Results
Pass/Fail Comments
1. Call MCM.Fobs.GetByUserID(int
ID)
Retrieves a valid
FobInfo object.
4 Description:
4.14
Setup Conditions
1. Populated
Database
2. Simulation
App Running
Test
Category
4
Test Case
4.15
Setup Conditions
25
FobInfoCollection GetByUserID
Purpose:
Description: IncidentInfoCollection Purpose: Verfiy that the MCM
- Select
communicates with the database
and retrieves Incident data.
Test Activity
Expected Results
1. Populated
Database
1. Call MCM.Incidents[int index]
Returns a
IncidentInfo object
that holds the data
2. Simulation
App Running
2. Call MCM.Incidents[int index]
Returns an
Exception
Test
Category
4
Test Case
4.16
Setup Conditions
1. Simulation
App Running
ID = valid
integer ID
Pass/Fail Comments
index =
valid
integer
index
index =
invalid
integer
Description: IncidentInfoCollection Purpose: Verify that the MCM
- Add
communicates with the database
and adds a new entry to the tables
Test Activity
1. Call MCM.Incidents.Add(UserID)
Expected Results
Adds a record to
the database, and
returns a
TranscieverInfo
object.
(This space left intentionally blank)
Pass/Fail Comments
UserID as
integer
value
Lab 3 – Prototype Test Plan
26
Description: IncidentInfoCollection Purpose: Verify that the MCM
- Remove
communicates with the database
and removes an entry to the
Test Case 4.17
tables
Setup Conditions Test Activity
Expected Results
Pass/Fail Comments
1. Populated
Database
Deletes a record
ID = valid
1. Call MCM.Incidents.Remove(ID)
from
the
database
integer ID
2. Simulation
App Running
Test
Category
4
Description: IncidentInfoCollection Purpose: Verify that the MCM
- GetByID
communicates with the database
and gets a IncidentInfo object
Test Case 4.18
based on the FobID.
Setup Conditions Test Activity
Expected Results
Pass/Fail Comments
1. Populated
Retrieves a valid
Database
1. Call MCM.Incidents.GetByID(int
ID = valid
IncidentInfo
ID)
integer ID
2. Simulation
object.
App Running
Test
Category
4
Description: IncidentInfoCollection Purpose: Verify that the MCM
- GetByUserID
communicates with the database
and gets a IncidentInfo object
Test Case 4.19
based on the Incident RecordID.
Setup Conditions Test Activity
Expected Results
Pass/Fail Comments
1. Populated
Database
1. Call
Retrieves a valid
ID = valid
MCM.Incidents.GetByUserID(int ID) FobInfo object.
integer ID
2. Simulation
App Running
Test
Category
4
(This space left intentionally blank)
Lab 3 – Prototype Test Plan
27
Purpose: Verify that the MCM processing
logic can determine the correct
transceivers from an incoming
array, and find an approximate
Test Case 4.20
location for an alert based on that.
Setup Conditions Test Activity
Expected Results
Pass/Fail Comments
Raises an Event
to listeners
1. Populated
signalling that
Database
processing has
begun.
1. Call
MCM.ProcessAlerts(List<int[]>) When finished it
2. Simulation
will raise an event
App Running
signalling that
3. Passed Tests
processing has
1.1-1.14
finished.
Test
Category
4
Description:
Process
Alerts
(This space left intentionally blank)
Lab 3 – Prototype Test Plan
28
4.1.5 Simulation Driver Interface Test Cases (Braden Gibson)
Test Category:
Test Case
5
5
5
5
Purpose: Test the Connection with the MCM
Test Activity
Expected
Results
Description: User Info
Verify that User Information can
Purpose: successfully be received
Test Activity
Expected
Results
Description: Fob Info
Verify that Fob Information can
Purpose: successfully be received
Test Activity
Expected
Results
Pass/Fail Comments
Pass/Fail Comments
Pass/Fail Comments
Transceiver
Verify that Transceiver Information
Description: Info
Purpose: can successfully be received
5
5.5
Setup Conditions
Test Category
Test Case
Outbound
Description: Connection
Pass/Fail Comments
5.4
Setup Conditions
Test Category
Test Case
Expected
Results
5.3
Setup Conditions
Test Category
Test Case
Test Activity
5.2
Setup Conditions
Test Category
Test Case
Purpose: Listen for a response from the MCM
5.1
Setup Conditions
Test Category
Test Case
Inbound
Description: Connection
5
Test Activity
Expected
Results
Alert
Description: Signal
Verify that a list of transceivers are
Purpose: created once they "hear" an alert
Pass/Fail Comments
5.6
(This Space Left Intentionally Blank)
Lab 3 – Prototype Test Plan
Setup Conditions
Test Category
Test Case
5
5
5
Setup Conditions
Test Activity
Expected
Results
Description: Maps
Test that each of the 5 maps display
Purpose: on the screen
Test Activity
Expected
Results
Signal
Description: Response
Purpose: Test that the alert signal has been set
Test Activity
Expected
Results
Pass/Fail Comments
Pass/Fail Comments
Pass/Fail Comments
Transceiver
Test that the transceivers can be
Description: Display
Purpose: displayed on the screen
5
5.10
Setup Conditions
Test Category
Test Case
Verify that the list of transceivers has
Purpose: been sent to the MCM
5.9
Setup Conditions
Test Category
Test Case
Description: Data Flow
Pass/Fail Comments
5.8
Setup Conditions
Test Category
Test Case
Test Activity
Expected
Results
5.7
Setup Conditions
Test Category
Test Case
29
5
Test Activity
Expected
Results
Fob
Description: Creation
Purpose: Test that a fob object is created
Test Activity
Expected
Results
Pass/Fail Comments
5.11
(This Space Left Intentionally Blank)
Pass/Fail Comments
Lab 3 – Prototype Test Plan
Test Category
Test Case
5
5
Setup Conditions
Test Activity
Expected
Results
Description: Objects
Test that the list of objects are sent to
the MCM once the action listener has
Purpose: been initiated
Test Activity
Expected
Results
Pass/Fail Comments
Pass/Fail Comments
Transceiver
Test that the transceiver object is
Description: Creation
Purpose: created
5
5.14
Setup Conditions
Test Category
Test Case
Purpose: Test that each fob ID is unique
5.13
Setup Conditions
Test Category
Test Case
Description: Unique ID
5.12
Setup Conditions
Test Category
Test Case
30
5
Test Activity
Expected
Results
Description: Input
Test that the button or action listener
Purpose: picks up user input
Test Activity
Expected
Results
Pass/Fail Comments
5.15
(This Space Left Intentionally Blank)
Pass/Fail Comments
Lab 3 – Prototype Test Plan
31
4.1.6 Dispatch User Interface Test Cases (Brittany Dufort)
Test
Listening
Category
6
Description: for MCM
Test Case
6.1
Setup Conditions
Test Activity
Tests that the DUI is constantly listening for
Purpose: the MCM
Test
Connection
Category
6
Description: with MCM
Test Case
6.2
Setup Conditions
Test Activity
Pass alert into DUI
Tests that the DUI is able to receive alerts
Purpose: from the MCM
Test
Category
6
Object is
Alert
Description: Object
Test Case
6.3
Setup Conditions
Test Activity
Pass alert obj into DUI
Pass non-alert obj into
DUI
Display
Test
alerts on
Category
6
Description: map
Test Case
6.4
Setup Conditions
Test Activity
Pass alerts into DUI
Expected Results
Expected Results
DUI will receive the alert
Pass/Fail Comments
P
Pass/Fail Comments
P
Purpose: Tests that the object being passed to the
DUI from the MCM is an actual Alert
Object
Expected Results
Pass/Fail Comments
DUI will recognize as
alert
P
DUI wil reject the nonalert
P
Tests that the DUI can display ALL active
Purpose: alerts on the
map.
Expected Results
Pass/Fail Comments
Map will display each
bubble
P
(This Space Left Intentionally Blank)
Lab 3 – Prototype Test Plan
32
Display
Test
alerts in
Category
6
Description: extended
Test Case
6.5
data form
Setup Conditions
Test Activity
Pass alerts into DUI
Displays
Test
alerts in
Category
6
Description: alerts
information
Test Case
6.6
table
Setup Conditions
Test Activity
Pass alerts into DUI
Tests that the DUI can display ALL active
Purpose: alerts in the
extended data form
Expected Results
Pass/Fail Comments
Extended data form will
display information from
each alert obj
P
display information from
each alert obj
Tests that the DUI can display ALL active
Purpose: alerts in the
alerts information table.
Expected Results
Pass/Fail Comments
Alerts information table
will display
P
information from each
alert
(This Space Left Intentionally Blank)
Lab 3 – Prototype Test Plan
5. Traceability to Requirements (Dan Cox, Jon Szewczak)
33