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