CS 411W Lab III Prototype Test Plan/Procedure For Traffic...
Transcript of CS 411W Lab III Prototype Test Plan/Procedure For Traffic...
CS 411W Lab III
Prototype Test Plan/Procedure For
Traffic Wizard
Prepared by: Binh Dong, Blue Team
Date: 11/29/2007
Version 1
Table of Contents
1 Objectives ...................................................................................................................... 3
2 References ..................................................................................................................... 5
3 Test Plan ........................................................................................................................ 5
3.1 Testing Approach ................................................................................................... 6
3.2 Identification of Tests ............................................................................................. 7
3.3 Test Schedule ....................................................................................................... 13
3.4 Fault Reporting and Data Recording .................................................................... 13
3.5 Resource Requirements ........................................................................................ 14
3.6 Test Environment ................................................................................................. 14
4 Test Responsibilities ................................................................................................... 15
5 Test Procedures ........................................................................................................... 15
6 Traceability Requirements .......................................................................................... 15
List of Tables
Table 1: Identification of Test ........................................................................................... 13 Table 2: Test Schedule ...................................................................................................... 13 Table 3: Fault Reporting and Data Recording .................................................................. 14 Table 4: Test Responsibilities ........................................................................................... 15
List of Figures
Figure 1: Prototype Major Functional Components Diagram ............................................. 6
1 Objectives
The Traffic Wizard smartphone application will provide real-time traffic information
to the end user. Traffic Wizard has many key product features and capabilities that make
up the application. It will use a personalized profile system to determine an optimal route
for a driver utilizing the innovative Virtual Checkpoint System, Real-Time Data
Exchange, Traffic Analysis and Driver Profiles. For the prototype, Traffic Wizard will be
tested on iOS.
Traffic Wizard’s target market customer base will be drivers with smartphones in
metropolitan areas and drivers of commercial vendors, such as, buses and shipping
companies. With the rise of smartphone sales, there will be more automobiles with
smartphones on the road. The more vehicles on the roads will lead to higher traffic. The
drivers in metropolitan areas that possess smartphones will be the prime target market
base as there is usually high vehicular traffic in these areas. With many automobiles in
these metropolitan areas, traffic data will be more robust then a rural area with less driver
data. In metropolitan areas, colleges, taxis and buses will be targeted as well. Commercial
shipping companies will be targeted as these companies have many vehicles on the road
at a time. With commercial vendors having Traffic Wizard in their vehicles it will
improve traffic data for metropolitan users. More data equals better accuracy.
Traffic Wizard must provide the end user with reliable and real-time traffic data.
The traffic data will be analyzed by polling global positioning satellite system’s (GPS)
data. The smartphone will pull the GPS data that contains latitude/longitude point and
speed-readings. The GPS data will then be uploaded to the Traffic Wizard’s server to be
analyzed. With Traffic Wizard’s implementation, Virtual Checkpoints shall reduce the
data exchange size while being able to provide the user with on-time, reliable traffic data.
The virtual checkpoint system will enable Traffic Wizard to minimize data
exchange between the smartphone and Traffic Wizard’s servers. The virtual checkpoints
are latitude/longitude specific points along roadways. They identify road segments by the
amount of traffic congestions and can be dynamically re-allocated as roads and traffic
patterns change.
GPS data will be analyzed after the smartphone polls the GPS data and sends the
GPS data up to Traffic Wizard’s Server. The GPS data that is send to the server will
contain latitude, longitude, direction and the speed of a driver. Traffic Wizard’s server
will have algorithms to combine and analyze multiple Traffic Wizard users’ data to
determine traffic conditions. Traffic Analysis will be calculated in real-time on the
Traffic Wizard’s server and not the smartphone.
The graphical user interface shall be very simplistic. Provided for the user will be
the ability to: log in, set and edit their personal driver profile, set and edit their personal
routes, set notifications and trace routes. The login screen will contain a place for the
driver to input their credentials. The driver profile will be a custom profile catered to the
driver. Traffic Wizard will use this profile to set up how a route will be displayed or
calculated. The personal routes will be set by the user or automatically set via a trace
route. The routes’ information will then be used for future traffic condition notifications.
2 Test Plan
Traffic Wizard will be tested in each category. The tests will follow in this order:
databases, algorithms, simulation console, client user interfaces and the simulation
console interface. Each category will have a set of test cases that needs to be fulfilled in
order to prove functionality to the user.
3 References
Dong, Binh. Lab 1 – Traffic Wizard Product Description, CS411, Blue Team, Spring 2012 Dong, Binh. Lab 2 – Traffic Wizard Product Description, CS411, Blue Team, Spring 2012 Brownlow, Mark. "Smartphone Statistics and Market Share." September 2011. Email
Marketing Reports. Retrieved from http://www.emailmarketing-reports.com/wireless-mobile/smartphonestatistics.htm
Dr. M. Weigle, interview, October 19, 2011 Liang, Quincy. "Worldwide PND Shipments to Peak Around 42 M. in 2011-2012: Berg
Insight." October 19, 2011. CENS. Retrieved from http://news.cens.com/cens/html/en/news/news_inner_38131.html
Lomax, Time, David Schrank and Shawn Turner. Texas Transportation Institute. (2011).
Annual Urban Mobility Report. College Station, TX. Retrieved from http://mobility.tamu.edu/ums/
Schroeder, Stan. "Smartphone Sales Up 85% Year-Over-Year." May 19, 2011. Mashable
Tech. Retrieved from http://mashable.com/2011/05/19/smartphone-sales-q1-2011-gartner/
Stiles, Matt. “Census Map Shows Population Growth by County.” June 16, 2010. The
Texas Tribune. http://www.texastribune.org/texas-counties-and-demographics/census/census-map- shows-population-growth-by-county/
U.S. National Highway Traffic Safety Administation, Traffic Safety Facts. Retrieved
from http://www.census.gov/compendia/statab/2012/tables/12s1108.pdf
3.1 Testing Approach
Traffic Wizard’s prototype will be the same as the final product plus multiple
simulation components. For the prototype stage, will be using sample testing smartphone
devices to test data exchange as shown in Figure 1. The server has simulation algorithms,
Traffic Wizard main algorithms and each database. The Traffic Wizard Prototype will
consist of both the server and smartphone.
Figure 1: Prototype Major Functional Components Diagram
Figure 1: Prototype Major Functional Components Diagram
In the Traffic Wizard prototype, there will be three simulation algorithms plus the
main Traffic Wizard algorithms. These algorithms include: simulation data generator,
simulation checkpoint allocator, artificial driver engine, and route evaluation algorithms.
A simulation data generator will create data randomly to simulate traffic conditions. A
simulation checkpoint allocator will define virtual checkpoints in regards to the simulated
traffic conditions. The artificial driver engine will simulate a driver driving a road pre-
defined road course. The route evaluation algorithms will calculate traffic conditions with
simulated traffic data. These algorithms will test how well Traffic Wizard handles input
data.
During the prototype phase, Traffic Wizard will have a working mobile application
written for iOS. The application will be able to collect data as a driver drives a route and
be able to upload to Traffic Wizard’s servers. The prototype mobile application will be
ready to deploy.
For the prototype stage, a virtual machine will be utilized instead of an actual
server to collect data and analyze traffic data. The server will act as if it were a final
product in this prototype stage. The server will be a Linux virtual server hosted by Old
Dominion Computer Science department.
3.2 Identification of Tests
Table 1 shows all the test cases that will test Traffic Wizard.
Category ID Categories Subcategory
ID Subcategory Test Case Description
1.00 Databases 1.10 Virtual
Checkpoint 1.1.1 Database Structure
Test
Verify the structure of all
tables and fields 1.20 Driver Profile
1.30 Speed Limit
2.00 Algorithms
2.10 Speed Aggregator 2.1.x
2.20 VC Reallocator 2.2.1 Source
Code
To check if the code is written in Java or C++.
2.2.2 Open VC Database
To test the ability to open
the Virtual Checkpoint Database.
2.2.3
Open Speed Limit
Database
Test the ability to open the speed limit database.
2.2.4 Add Checkpoint
Test the ability to add a
checkpoint.
2.2.5 Delete Checkpoint
Test the ability to delete a
checkpoint.
2.30 Route Matcher
2.3.1 Source Code
Verify code is written in Java
or C++
2.3.2 VC
Database Connect
Verify Virtual Checkpoint Database is accessible
2.3.3 Input Parameter
Verify parameter
acceptance for input
coordinates
2.3.4 Proximity
Verify ability to return
checkpoint ID's within
vicinity
2.3.5 False Proximity
Verify ability to return no
checkpoint ID
2.40 Route Analyzer
2.4.1
Route Analysis Accuracy
Test
Verify that the Route Analysis
Algorithm properly
validates a route against the Virtual Checkpoint Database.
2.4.2 Route Analysis
To verify the calculation and
Data Test communication of congestion data for a user specified route.
2.50 Blockage Finder 2.5.1
2.60 Next
Checkpoint Estimator
2.6.1
Next Checkpoint Estimator
calculations
Ensure the calculations
performed by the algorithm
are correct
2.6.2
Next Checkpoint Estimator deviation
Test the conditional
branch in the algorithm that
checks whether a user has
deviated from a route
3.00 Simulation Console
3.10 Region Selection
3.1.1 Region Support
Verify region maps available for simulation
3.1.2 Arrival and Destination
Verify regiona maps have
entry and exit points
3.20 Traffic
Scenario Selection
3.2.1 Scenario Support
Verify scenario options defined and available
3.2.2 Scenario Scale
Verify scenarios have
scalability functions
3.30 Driver Generator 3.3.1 Driver
Generator
Ensure that realistic
proportions of drivers and users are
generated, conforming to
variable thresholds
which can be changed by the
user
3.40 Simulation Runtime
Execution
3.4.1
Runtime Defaults
and Selections
Verify simulation
defaults and selectability of
regions and scenarios
3.4.2 Scenario 1 Execution
Verify Scenario 1
(low congestion)
can be executed to
show algorithm
proof
3.4.3 Scenario 8 Execution
Verify Scenario 8
(high congestion)
can be executed to
show algorithm
proof
3.4.4 Virtual Driver Type
Verify generation of two types of
virtual drivers
3.50 Traffic
Activity Display
3.4.1 -
3.4.4 3.4 Tests
Verified through
Simulation Runtime
Execution test cases
4.00 Client User
Interface 4.10 Login 4.1.1 Login
Ensure that only
authorized users are able to access the
main user interface
functionality of the application
4.20 New Trip 4.2.1 New Trip
Ensure the process of New Trip Creation runs correctly
or fails gracefully
4.30 Route Tracer 4.3.1 Route Tracer
Test the functionality of
the Route Tracer screen to ensure that
illegal start/stop
presses are prevented
4.40 Edit Trip 4.4.1 Edit Trip
Ensure the process of
editing a Trip runs correctly
or fails gracefully
4.50 End of Trip 4.5.1 End of Trip
Ensure the End of Trip process
of runs correctly and unobtrusively
to the user
4.60 Delay Notification 4.6.1 Delay
Notification
Ensure the delay
notification process runs correctly and unobtrusively to the driver
5.00 Simulation
Console Interface
5.10 Main Menu 5.1.1 Main Menu Test
Verify interface has
accessible buttons/tabs for features
5.20 Configuration Window X X
*Scrap when the rest are complete
5.30 Driver Profile Demo 5.3.1
Driver Profile
Database
Verify that features of
Driver Profiles have been
implemented correctly
5.3.2 Driver Profile
Screenshots
Verify that features of
Driver Profile Demonstration
utilizes appropriate
GUI screenshots
5.3.3 Driver Profile
Main Menu
Verify that features of
Driver Profile Demonstration allows access to the main
menu
5.40 Route
Creation Demo
5.4.1 Create / Edit
Must describe all fields
required for creating a new route manually as outlined in Requirement
3.1.4.1.3.
5.50 Route Tracer Demo 5.5.1
Route Tracer demo
Show the functionality of
the Route Tracer works as expected and returns
correct results
Must use smartphone
app GUI from Requirement
3.1.4.1 as foundation for
images.
5.60 Traffic
Simulation Window
3.4.1 -
3.4.3 3.4 Tests
Verified through
Simulation Runtime
Execution test cases
5.70 Dashboard
5.7.1 Dashboard Access
Verify accessibility from Traffic Simulation
window
5.7.2 Dashboard Return
Verify that Dashboard
cannot return to Main Menu
during simulation
5.5.3 Anytime Main Menu
Ensure user can return to
the main menu at any time.
Table 1: Identification of Test
3.3 Test Schedule
Table 2 shows the schedule of each test.
Start Time (min)
Duration Description Test Case #
0:10 5 Database (Driver Profile and Virtual Checkpoint) Demo
1.1
0:15 10 Algorithm unit tests (via Simulation Console)
2.1- 2.6
0:25 10 Integration simulation 3.1 – 3.5, 5.1 – 5.7
0:35 10 Smartphone Application Demo
4.1 – 4.6
0:45 15 Questions
Table 2: Test Schedule
3.4 Fault Reporting and Data Recording
Table 3 demonstrates how data recording and error reporting will occur.
Component How/Process of Recording
Hardware − Report failures through visual inspection of Smartphone
device and server stations
− Document through hardcopy forms
GUI − Report failures through visual inspection of GUI
screens in app and simulation console
− Document through hardcopy forms
Database − Report failures through visual inspection of returned
SQL Statements
− Document through hardcopy forms
Algorithms − Report failures through visual inspection of output logs
− Document through hardcopy forms
Table 3: Fault Reporting and Data Recording
3.5 Resource Requirements
The resources for the prototype are minimal. The require resources are Traffic
Wizard’s source code, server, an iPhone and the simulation console.
3.6 Test Environment
The test environment for the prototype, when compared to the final product, will
be reduced in size and scope. The prototype will only be using a portion of interstate 64
around the Hampton Roads Bridge Tunnel to demonstrate Traffic Wizard’s functionality.
The test environment will include a smartphone, server, simulation console and the room
Figure 2: Test Environment
shown in Figure 1.
4 Test Responsibilities
The responsibilities for each team member during the prototype demonstration are
outlined in Table 4. For the most part, team members with a certain realm of expertise
will present the respective component of the prototype. The main presenters will be
Andrew Crossman, Andrew McKnight, and Nick MacLeod, with Sujani Godavarthi,
Binh Dong and Thomas Kennedy adding insight for their developed components.
Team Member Responsibilities Thomas Kennedy Databases Andrew Crossman Presenter/Simulation Console Operator Andrew McKnight Presenter/Smartphone App
Nick MacLeod Presenter/Algorithms Sujani Godavarthi Algorithms
Binh Dong Hardware Table 4: Test Responsibilities
5 Test Procedures
Test procedures for Traffic Wizard have been developed to ensure the
functionality of the prototype is attained and correct. The test procedures are represented
in a format that contains the category, subcategory, purpose, requirements covered, steps
to test, and expected results. Each step in each test may either pass or fail, and a comment
field is provided for tester analysis.
6 Traceability Requirements
The Traceability Matrix shows the relationship between the test cases and the
requirements covered by each. Each requirement has at least one corresponding test case.
The matrix can be found at http://cs.odu.edu/~411blue/?page=collaboration#lab3