Lab 3 – AIR Tracker Prototype Test Plan/Procedure – Casper 1
Lab 3 – AIR Tracker Prototype Test Plan/Procedure
Ashley Casper
CS 411W
Professor Janet Brunelle
13 April 2009
Lab 3 – AIR Tracker Prototype Test Plan/Procedure – Casper 2
Table of Contents
1
2
3
4
5
6
OBJECTIVES ........................................................................................................ 3
REFERENCES ...................................................................................................... 4
TEST PLAN............................................................................................................ 4
3.1
Testing Approach ....................................................................................... 5
3.2
Identification of Tests ................................................................................ 6
3.3
Test Schedule ............................................................................................. 6
3.4
Fault Reporting and Data Recording ......................................................... 7
3.5
Resource Requirements ............................................................................. 7
3.6
Test Environment ....................................................................................... 8
TEST RESPONSIBILITIES .................................................................................. 9
TEST PROCEDURES ........................................................................................... 9
5.1
Test Case Names and Identifiers ................................................................ 9
TRACEABILITY TO REQUIREMENTS ............................................................ 18
List of Figures
Figure 3-1. AIR Tracker Prototype Major Functional Component Diagram ................ 5
Figure 3-2. E&CS 3316 Conference Room Layout ...................................................... 8
List of Tables
Table 3-1. AIR Tracker prototype test cases .................................................................. 6
Table 3-2. AIR Tracker prototype demonstration schedule............................................ 7
Table 5-1. RuBee Input Processing Functionality Table ................................................ 10
Table 5-2. RuBee Reader Processing Performance Table .............................................. 10
Table 5-3. AIR Tracker and Airport Database Functionality Table .............................. 11
Table 5-4. AIR Tracker and Airport Database Integrity Table ....................................... 11
Table 5-5. MySQL Database Software Performance Table ........................................... 12
Table 5-6. Routing Simulation Creation Functionality Table ........................................ 13
Table 5-7. Routing Simulation Functionality Table ....................................................... 14
Table 5-8. Alert Generator-to-Database Interface Functionality Table ......................... 15
Table 5-9. AIR Tracker Alert Generator Functionality (Internal) Table ....................... 15
Table 5-10. AIR Tracker Alert Generator Functionality (External) Table .................... 16
Table 5-11. Alert Generator-to-Handheld Alert System Interface Functionality Table . 17
Table 5-12. Handheld Alert System GUI Functionality Table ...................................... 17
Table 5-13. Historical Reports of Alerts Functionality Table ....................................... 18
Table 6-1. Traceability matrix for the AIR Tracker prototype ...................................... 19
Lab 3 – AIR Tracker Prototype Test Plan/Procedure – Casper 3
Lab 3 – AIR Tracker Prototype Test Plan/Procedure
1 OBJECTIVES
Automated and Intelligent Reporting (AIR) Tracker, AIR Tracker, Inc.’s proposed product, is
a tool to assist airlines by improving their own baggage-handling process and reducing the total
number of bags that are mishandled at airports. AIR Tracker seeks to integrate into all systems
through a customized installation that will improve baggage handling no matter the size or scope
of the airport or problems within that airport. With an innovative ground-level routing process
(GRP) that tracks the bags from check-in to flight, cart and gate modules that magnify the
attention on the trickiest portion of the process, and a historical data reporting module that alerts
baggage handlers to mishandled bags, AIR Tracker is the solution to the ever-present problem of
mishandled luggage.
The AIR Tracker prototype test plan and procedure document’s purpose is to elaborate on the
overall approach and sequence of testing and the specific tests that will be conducted to prove the
prototype’s success. The tests will essentially analyze the functionality of the many facets of the
AIR Tracker prototype and prove the feasibility of the future real-world product. In order to
demonstrate functionality, the prototype test plan and procedure document will focus on several
obtainable objectives.
The objectives of the AIR Tracker prototype are described by six categories. The first
category is the objective of proving RuBee input processing, which will be the process of
displaying the RuBee hardware’s interaction with the RuBee Finder software, to include the use
of RuBee tags in range of the RuBee scanner. The second objective is summed up in the proving
of the functionality of the AIR Tracker and airport databases. Setting up the databases and
verifying the integrity of pre-populated data or selected data inserted from one database to
Lab 3 – AIR Tracker Prototype Test Plan/Procedure – Casper 4
another is an essential goal of the second objective. The third objective is the confirmation of the
routing simulation’s functionality. The simulation’s creation and functionality as a bag-routing
system will be proven in order to successfully test the AIR Tracker application. The fourth
objective is verification of the alert generator’s functionality. This category includes any and all
testing of the algorithms associated with the AIR Tracker application, ensuring that the fifth
objective, confirming the handheld alert system’s functionality, can be achieved. The graphical
user interfaces (GUIs) are proven to work in this category. Lastly, the sixth objective includes
proving the historical reports of alerts functionality, which will display the archival of alerts
through the AIR Tracker application. More details of these objectives are described in Section
5.1.
2 REFERENCES
Casper, Ashley. (2009). Lab 1 – AIR Tracker Product Description. Virginia Beach, VA:
Author.
Casper, Ashley. (2009). Lab 2 – AIR Tracker Prototype Product Specification. Virginia Beach,
VA: Author.
SITA. (2009). Baggage Report 2008. Retrieved October 25, 2008, from SITA Web site: http://
www.sita.aero/content/baggage-report-2008
U.S. Department of Transportation. (2009, February). Air Travel Consumer Report. Retrieved
February 6, 2009, from U.S. Department of Transportation Web site: http://airconsumer.dot
.gov/reports/2009/ ebruary/200902atcr.pdf
3 TEST PLAN
In order to prove the AIR Tracker prototype’s functionality at all levels, Section 3 will
describe the testing plan that will include test types, methods, and resources that will be required.
Lab 3 – AIR Tracker Prototype Test Plan/Procedure – Casper 5
The requirements set forth for the prototype will need to be proven in full by at least one test. A
schedule for testing and methods for handling data and data faults are also included.
3.1 TESTING APPROACH
The AIR Tracker prototype is comprised of both hardware and software, the major functional
components of which are shown in Figure 3-1. Prototype functionality will be proven by
demonstrating all components successfully pass the test cases described in Section 5.1.
Figure 3-1. AIR Tracker Prototype Major Functional Component Diagram
All testing will be completed at the component level, ensuring that each functional piece of
the AIR Tracker prototype is in working order. Interaction between components may be
necessary to ensure proper function, but the component being tested will always be the
component to complete the test case. The first category and objective is to ensure that the RuBee
hardware will properly function. Through the use of physical tags and a scanner, real data will
be generated through the RuBee Finder software. The second category and objective, to prove
Lab 3 – AIR Tracker Prototype Test Plan/Procedure – Casper 6
database functionality, will utilize a small amount of artificial data to pre-populate the airport
database. Through all other categories and objectives, all AIR Tracker prototype functionality
will be proven through the use of simulated data. Using a controlled testing environment, AIR
Tracker, Inc. will establish a set of feasible airport scenarios that, combined with the test cases
elaborated in Sections 3.2 and 5.1, will satisfactorily prove all functionality of the prototype.
3.2 IDENTIFICATION OF TESTS
Test cases have been placed into one of six categories, which are described in Table 31. These test cases may prove one or more functional requirements specified for the AIR
Tracker prototype. A more detailed description of each test case can be found in Section 5.1.
Category
1
2
3
4
5
6
Description
RuBee Input
Processing
5.2
Description
RuBee Reader Processing Functionality
RuBee Reader Processing Performance
AIR Tracker and Airport Database Functionality
AIR Tracker and Airport Database Integrity
MySQL Database Software Performance
Routing Simulation Creation Functionality
Routing Simulation Functionality
Alert Generator-to-Database Interface Functionality
AIR Tracker Alert Generator Functionality (Internal)
AIR Tracker Alert Generator Functionality
(External)
Alert Generator-to-Handheld Alert System Interface
Functionality
Handheld Alert System GUI Functionality
6.1
Historical Reports of Alerts Functionality
Test Case
1.1
1.2
2.1.1
AIR Tracker and
2.1.2
Airport Database
Functionality
2.2
3.1
Routing Simulation
Functionality
3.2
4.1
Alert Generator
4.2.1
Functionality
4.2.2
Handheld Alert
System Functionality
Historical Reports of
Alerts Functionality
5.1
Table 3-1. AIR Tracker prototype test cases
3.3 TEST SCHEDULE
AIR Tracker, Inc. will have forty-five minutes for the prototype demonstration. After a
fifteen-minute introduction of the AIR Tracker product and prototype concept, all test cases
Lab 3 – AIR Tracker Prototype Test Plan/Procedure – Casper 7
will be tested in accordance with the schedule described in Table 3-2. Minimal set-up and
thorough preparation will save time before the demonstration begins, and efficient testing
will leave enough time for a fifteen-minute question-and-answer session.
Start Time
(hours:min)
0:15
0:18
Duration
(minutes)
3
3
0:21
0:28
7
7
0:35
0:42
7
3
Test Objective
Test Event
RuBee reader input processing
AIR Tracker and airport database
functionality
Routing simulation functionality
AIR Tracker alert generator
functionality
Handheld alert system functionality
Historical reports of alerts functionality
1.1, 1.2
2.1.1, 2.1.2, 2.2
3.1, 3.2
4.1, 4.2.1, 4.2.2
5.1, 5.2
6.1
Table 3-2. AIR Tracker prototype demonstration schedule
3.4 FAULT REPORTING AND DATA RECORDING
All recording of data, faulty or proven to be working correctly, will be visually confirmed.
Hardware elements in the first category of testing will have results recorded into a text file, to
include RuBee tag identification number and a date/time stamp. Fault reporting will include the
lack of data recorded into a text file. In all other instances of testing, visual identification of the
databases, the terminal window, or the GUIs will provide evidence that the AIR Tracker
prototype is working properly. Fault reporting is confirmed through the same; visual
identification through a lack of data where data was originally expected will prove that the
prototype has failed a test case.
3.5 RESOURCE REQUIREMENTS
In order to prove the AIR Tracker prototype’s functionality, both hardware and software
resources will be required. Hardware resources to be utilized include a laptop running Windows
XP or Vista, RuBee tags, and a RuBee scanner. Software resources to be utilized include RuBee
Finder software, two databases created by MySQL database software (v. 5.1), the AIR Tracker
Lab 3 – AIR Tracker Prototype Test Plan/Procedure – Casper 8
application, the airport simulation and test harness, and two GUI applications specified in AIR
Tracker’s requirements. In order to properly execute all tests, two hardware set-up team
members will be required for the RuBee hardware, and one team member will be responsible for
assisting the presenter.
3.6 TESTING ENVIRONMENT
The AIR Tracker prototype demonstration will take place in the E&CS third-floor conference
room on the Old Dominion University campus. The layout of the conference room is shown in
Figure 3-2. The required laptop will be connected to the projector and utilize both projector
screens. RuBee will be easily connected to the laptop just before the presentation begins, and all
required software components will already be installed and ready for use on the laptop.
Figure 3-2. E&CS 3316 Conference Room Layout
The presentation itself will last forty-five minutes and will require a single presenter and an
assistant to ensure that all testing on the laptop is performed properly. The presentation will
Lab 3 – AIR Tracker Prototype Test Plan/Procedure – Casper 9
begin in Powerpoint form, created to show feasibility and AIR Tracker’s overall concept for the
gathered review panel. All remaining team members will ensure RuBee hardware is working
properly and demonstrate any test cases regarding the hardware.
4 TEST RESPONSIBILITIES
AIR Tracker, Inc.’s members will be responsible for different aspects of the prototype
demonstration. Jeremey Sellen will be the lead presenter responsible for introducing the AIR
Tracker product and prototype. Joel Elixson will be assisting by handling all simulation and test
issues on the laptop. Neil Monday and Rahil Patel will be responsible for all hardware
demonstrations. Ashley Casper will be responsible for presentation organization and aesthetics.
5 TEST PROCEDURES
To ensure that all tests are run effectively, Tables 5-1 through 5-13 have been generated.
Each table lists the category, the purpose, the actual activity, the expected results, as well as a
place to annotate whether the test was successful or not. These should be used in verifying the
atomic success of the prototype.
5.1 TEST CASE NAMES AND IDENTIFIERS
Tables 5-1 and 5-2 describe the test cases associated with the first category of testing. All
specifications regarding hardware have been listed. The expected results, when proven, confirm
adherence to the outline specifications and requirements for the AIR Tracker prototype.
[This space is intentionally left blank.]
Lab 3 – AIR Tracker Prototype Test Plan/Procedure – Casper 10
Test Category ID: 1
Test Case: 1.1
Description: RuBee Reader Processing Functionality
Purpose: This test demonstrates correct operability of the RuBee
Reader and Finder software
Specification: 3.1.1.1 Set-Up RuBee Reader Hardware
Specification: 3.1.1.2 Set-Up RuBee Finder Software
Test Level:
Component
Test Type:
Functional
Setup Conditions:
RuBeeTM demo kit required; RuBeeTM Reader components connected
and RuBee Finder software installed
Test Case Activity
Pass/Fail Expected Result
1
Place each of four RuBee tags
Each tag will be seen in the Finder
within range of ranger antenna
software when in range of the
antenna.
2
Remove each of four RuBee
tags from the ranger antenna’s
field
Each tag will not be seen in the
Finder software when not in range of
the antenna.
Table 5-1. RuBee Input Processing Functionality Table
Test Category ID: 1
Test Case: 1.2
Description: RuBee Reader Processing Performance
Purpose: This test demonstrates the performance of the RuBee
Reader and Finder software
Specification: 3.2.1
Evaluate performance of the RuBee reader and Finder Software
Test Level:
Component
Test Type:
Performance
Setup Conditions:
Test 1.1 is completed successfully
Test Case Activity
Pass/Fail Expected Result
1
Insert all four tags into the
The Finder software registers all four
RuBee reader’s field
tags simultaneously
2
Incrementally move each tag
one foot away from the RuBee
reader
The RuBee reader should no longer
register the presence of the tag after
six to twelve feet (depending on
obstructions)
3
Insert a tag into the RuBee
reader’s field and then remove
the tag after the Finder software
has recognized it
The Finder software should show the
absence of the tag within five
seconds of removal
Table 5-2. RuBee Reader Processing Performance Table
Lab 3 – AIR Tracker Prototype Test Plan/Procedure – Casper 11
Tables 5-3 through 5-5 describe the test cases associated with the second category of testing.
All specifications regarding database software have been listed. The expected results, when
proven, confirm adherence to the outline specifications and requirements for the AIR Tracker
prototype.
Test Category ID: 2
Test Case: 2.1.1
Description: AIR Tracker and Airport Database Functionality
Purpose: Ensure that the databases have been properly installed,
created, and populated with test entries.
Specification: 3.1.2.1 Install MySQL database software and create the AIR Tracker and
airport database schemas
Specification: 3.1.2.2 Populate airport and AIR Tracker databases
Test Level:
Component
Test Type:
Functional
Setup Conditions:
MySQL v.5.1 database software installed; phpMyAdmin v.5.2.5
software installed; AIR Tracker and airport schemas created
Test Case Activity
Pass/Fail Expected Result
1
Populate airport database using
Database is populated with a number
a flat file and parametric values
of entries equal to the simulation
from the AIR Tracker simulation
parameters input by the user
2
Utilize the AIR Tracker
application and the airport
database to populate the AIR
Tracker database
Database is populated with a number
of entries equal to the simulation
parameters input by the user
Table 5-3. AIR Tracker and Airport Database Functionality Table
Test Category ID: 2
Test Case: 2.1.2
Description: AIR Tracker and Airport Database Integrity
Purpose: Verify content of the databases is within acceptable ranges
and duplicate entries are not present
Specification: 3.1.2.2 Populate airport and AIR Tracker databases
Test Level:
Component
Test Type:
Functional
Setup Conditions:
MySQL v.5.1 database software installed; phpMyAdmin v.5.2.5
software installed; AIR Tracker and airport schemas created
Test Case Activity
Pass/Fail Expected Result
1
Utilize MySQL constraints and
Attributes are within reasonable
attribute types to constrict the
bounds and duplicate entries are not
types of values accepted by
present
each database table
Table 5-4. AIR Tracker and Airport Database Integrity Table
Lab 3 – AIR Tracker Prototype Test Plan/Procedure – Casper 12
Test Category ID: 2
Test Case: 2.2
Description: MySQL Database Software Performance
Purpose: Verify that the MySQL database software is capable of
performing queries in a time frame that will not perturb any of the
running simulations
Specification: 3.2.2
Evaluate the performance of the MySQL database software
Test Level:
Component
Test Type:
Performance
Setup Conditions:
Tests 2.1.1 and 2.1.2 are successfully completed
Test Case Activity
Pass/Fail Expected Result
1
Send a queue of 10 queries to
Each database should complete all
each database while utilizing the
queries in less than one second or
mysqladmin tool to determine
read 10,000 rows per second
the approximate time for
completion
2
Send a queue of 10 random
insertions and 10 random
updates to each database while
utilizing the mysqladmin tool to
determine the approximate time
for completion
Each database should complete all
insertions and updates in less than
one second
3
Delete the 10 random insertions
from each database while
utilizing the mysqladmin tool to
determine the approximate time
for completion
All entries should be deleted after 30
seconds
Table 5-5. MySQL Database Software Performance Table
Tables 5-6 and 5-7 describe the test cases associated with the third category of testing. All
specifications regarding simulation software have been listed. The expected results, when
proven, confirm adherence to the outline specifications and requirements for the AIR Tracker
prototype.
[This space is intentionally left blank.]
Lab 3 – AIR Tracker Prototype Test Plan/Procedure – Casper 13
Test Category ID: 3
Test Case: 3.1
Description: Routing Simulation Creation Functionality
Purpose: Verify the internal and external routing simulations correctly
generate and load simulation assets
Specification: 3.1.4.1
The routing simulations are generated from the user’s input
Specification: 3.1.4.2
Simulation data structures are easily accessed for verification of asset
creation
Test Level:
Component
Test Type:
Functional
Setup Conditions:
Test 2.2 is completed successfully
Test Case Activity
Pass/Fail Expected Result
1
Initiate the internal routing
The user is prompted for several
simulation
simulation parameters, and each
parameter specifies it’s minimum and
maximum bounds
2
Input parameter values
The program indicates both the
internal and external simulations
have been successfully created
3
Request the program print all
simulated objects and
parameters to a log file
All objects have been successfully
loaded with respect to the user’s
input, and randomly generated
objects are different from previous
simulations
Table 5-6. Routing Simulation Creation Functionality Table
[This space is intentionally left blank.]
Lab 3 – AIR Tracker Prototype Test Plan/Procedure – Casper 14
Test Category ID: 3
Test Case: 3.2
Description: Routing Simulation Functionality
Purpose: Verify the internal and external routing algorithms correctly
route bags through each routing simulation
Specification: 3.1.3.1
Each bag moves through an internal routing simulation in accordance
with its owner’s itinerary
Specification: 3.1.3.2
Each bag moves through an external routing simulation in accordance
with its owner’s itinerary
Test Level:
Component
Test Type:
Functional
Setup Conditions:
Test 3.1 is successfully completed
Test Case Activity
Pass/Fail Expected Result
1
Generate several non-alert
Each bag arrives at its destination
inducing path for a small set of
loading bay in line with its owner’s
bags within the internal routing
itinerary, and the result is visualized
simulation
2
Generate non-alert inducing
states for a small set of bags
within the cart module of the
external routing simulation
Each bag arrives at the correct belt
loader in line with its owner’s
itinerary, and the result is visualized
3
Generate non-alert inducing
states for a small set of bags
within the belt loader module of
the external routing simulation
Each bag arrives at its destination
aircraft in line with its owner’s
itinerary, and the result is visualized
Table 5-7. Routing Simulation Functionality Table
Tables 5-8 through 5-10 describe the test cases associated with the fourth category of testing.
All specifications regarding alert generation have been listed. The expected results, when
proven, confirm adherence to the outline specifications and requirements for the AIR Tracker
prototype.
[This space is intentionally left blank.]
Lab 3 – AIR Tracker Prototype Test Plan/Procedure – Casper 15
Test Category ID: 4
Test Case: 4.1
Description: Alert Generator-to-Database Interface Functionality
Purpose: Verify insertion of alerts into AIR Tracker database is
successful
Specification: 3.1.4.3
Alert information is inserted into the AIR Tracker database
Test Level:
Component
Test Type:
Functional
Setup Conditions:
Connectivity to AIR Tracker database returns ‘open’ status
Test Case Activity
Pass/Fail Expected Result
1
Attempt to insert an entry into
Output to text record indicates alert
the AIR Tracker database and
insertion is successful
output the result to a file
Table 5-8. Alert Generator-to-Database Interface Functionality Table
Test Category ID: 4
Test Case: 4.2.1
Description: AIR Tracker Alert Generator Functionality (Internal)
Purpose: Determine if AIR Tracker’s alert generation algorithm works
correctly with respect to a simulation of internal baggage routing (e.g.
baggage routing along a pusher)
Specification: 3.1.4.3.1 A bag is correctly or incorrectly routed throughout the internal
structure of the simulated airport according to routing simulation
parameters
Test Level:
Component
Test Type:
Functional
Setup Conditions:
Internal routing simulation is running; Test 3.1 is successfully
completed
Test Case Activity
Pass/Fail Expected Result
1
Generate a trajectory in line with
No alert is triggered or inserted into
the bag’s expected path along
the AIR Tracker database and no
the pusher
alert is visualized
2
Generate a trajectory out of line
with the bag’s expected path
along the pusher
An alert is triggered and inserted into
the AIR Tracker database and an
alert is visualized
Table 5-9. AIR Tracker Alert Generator Functionality (Internal) Table
[This space is intentionally left blank.]
Lab 3 – AIR Tracker Prototype Test Plan/Procedure – Casper 16
Test Category ID: 4
Test Case: 4.2.2
Description: AIR Tracker Alert Generator Functionality (External)
Purpose: Determine if AIR Tracker’s alert generation algorithm works
correctly with respect to a simulation of external baggage routing
Specification: 3.1.4.3.2 A bag is correctly or incorrectly routed throughout the external
structure of the simulated airport according to routing simulation
parameters
Test Level:
Component
Test Type:
Functional
Setup Conditions:
External routing simulation is running; Test 3.1 is successfully
completed
Test Case Activity
Pass/Fail Expected Result
1
Instruct the simulation to “stall” a
An alert is generated, stored in the
bag, leaving it in the loading bay
AIR Tracker database, and sent to
the Handheld Alert System GUI
2
Instruct the simulation to place a
bag on a luggage cart
No alert is generated or stored in the
AIR Tracker database
3
Instruct the simulation to remove
or “drops” a bag from a luggage
cart
An alert is generated, stored in the
AIR Tracker database, and sent to
the Handheld Alert System GUI
4
Instruct the simulation to place
the bag onto a belt loader
No alert is generated or stored in the
AIR Tracker database
5
Instruct the simulation to “stall” a
bag, leaving it on the luggage
cart
An alert is generated, stored in the
AIR Tracker database, and sent to
the Handheld Alert System GUI
6
Instruct the simulation to place
the bag onto an incorrect belt
loader
An alert is generated, stored in the
AIR Tracker database, and sent to
the Handheld Alert System GUI
Table 5-10. AIR Tracker Alert Generator Functionality (External) Table
Tables 5-11 and 5-12 describe the test cases associated with the fifth category of testing. All
specifications regarding GUI alert systems have been listed. The expected results, when proven,
confirm adherence to the outline specifications and requirements for the AIR Tracker prototype.
[This space is intentionally left blank.]
Lab 3 – AIR Tracker Prototype Test Plan/Procedure – Casper 17
Test Category ID: 5
Description: Alert Generator-to-Handheld Alert System Interface
Functionality
Test Case: 5.1
Purpose: Verify an alert is capable of being sent by AIR Tracker and
received by the Handheld Alert System GUI
Specification: 3.1.5
AIR Tracker sends information about triggered alerts to the Handheld
Alert System where it is then visualized
Test Level:
Component
Test Type:
Functional
Setup Conditions:
Tests 4.2.1 and 4.2.2 are successfully completed
Test Case Activity
Pass/Fail Expected Result
1
Send a generic alert to the
A generic alert is visualized and the
Handheld Alert System
alert is logged
Table 5-11. Alert Generator-to-Handheld Alert System Interface Functionality Table
Test Category ID: 5
Test Case: 5.2
Description: Handheld Alert System GUI Functionality
Purpose: Verify the Handheld Alert System GUI is capable of
clearing alerts manually and automatically
Specification: 3.1.5.1
The Handheld Alert System GUI displays alerts on a simulated
handheld device and provides alert clearing functionality
Test Level:
Component
Test Type:
Functional
Setup Conditions:
Test 5.1 is successfully completed
Test Case Activity
Pass/Fail Expected Result
1
Select the manual clear option
The alert is no longer active or
visualized
2
Do not select a clear option and
force the simulation to recover
the bag
The alert is automatically cleared
after being recovered and the alert is
no longer visualized
3
Do not select a clear option and
force the simulation to ignore the
alert
The alert is automatically cleared
after several seconds, sent to the
master baggage handler, and no
longer visualized
Table 5-12. Handheld Alert System GUI Functionality Table
Table 5-13 describes the test case associated with the sixth category of testing. All
specifications regarding historical alerts have been listed. The expected results, when proven,
confirm adherence to the outline specifications and requirements for the AIR Tracker prototype.
Lab 3 – AIR Tracker Prototype Test Plan/Procedure – Casper 18
Test Category ID: 6
Test Case: 6.1
Specification: 3.1.5.2
Description: Historical Reports of Alerts Functionality
Purpose: Verify the alert reporting feature is operable
The Master Baggage Handler is able to view a history of alerts and
save selective histories as reports
Test Level:
Component
Test Type:
Functional
Setup Conditions:
Test 5.2 is successfully completed
Test Case Activity
Pass/Fail Expected Result
1
Select a date and time range
A history of alerts using the selected
and alert type
parameters is visualized
Table 5-13. Historical Reports of Alerts Functionality Table
6 TRACEABILITY TO REQUIREMENTS
Each test case has been specifically designed to confirm that one or more prototype
requirements have been met. Four test cases in the AIR Tracker test plan verify two
requirements, but all other test cases verify a single requirement. Specified in Table 6-1 is the
relationship between the requirements and the test cases.
[This space is intentionally left blank.]
Lab 3 – AIR Tracker Prototype Test Plan/Procedure – Casper 19
Requirements
Component
Req ID
RuBee H/W Setup
3.1.1.1
RuBee S/W Setup
3.1.1.2
Rubee Reader
Processing
Performance
3.2.1
3.1.2.1
Database
Functionality
3.1.2.2
MySQL DB
Software
Performance
3.2.2
Routing
3.1.4.1
Simulation
Creation
3.1.4.2
Routing
3.1.3.1
Simulation
Functionality
3.1.3.2
Alert Generator to
DB Interface
3.1.4.3
AIR Tracker Alert
Generator
(Internal)
3.1.4.3.1
AIR Tracker Alert
Generator
(External)
3.1.4.3.2
Alert Generator to
Handheld Alert
System Interface
3.1.5
Handheld Alert
System GUI
3.1.5.1
Historical Reports
of Alerts
3.1.5.2
1.1
X
X
1.2 2.1.1
2.1.2
2.2
Test Cases
3.1 3.2 4.1
4.2.1
4.2.2
5.1
5.2
6.1
X
X
X
X
X
X
X
X
X
X
X
Table 6-1. Traceability matrix for the AIR Tracker prototype
X
X
X
X