Version 0 Revision History
Download 191.43 Kb.
|
- Navigate this page:
- 1.Introduction 1.1Purpose of this document
- 1.4Definitions and acronyms
- 1.4.2Acronyms and abbreviations
- 2.Test-plan introduction
- 5.Features not to be tested
- 7.Item pass/fail criteria
- 7.1Installation and Configuration
- 8.Suspension criteria and resumption requirements
- 11.Risks and contingencies
  
Version Revision History
Table of Contents 1. Introduction 5 1.1 Purpose of this document 5 1.2 Intended Audience 5 1.3 Scope 5 1.4 Definitions and acronyms 5 1.4.1 Definitions 5 1.4.2 Acronyms and abbreviations 5 1.5 References 5 2. Test-plan introduction 6 3. Test items 6 4. Features to be tested 6 5. Features not to be tested 8 6. Approach 8 7. Item pass/fail criteria 8 7.1 Installation and Configuration 12 7.2 Documentation problems 12 8. Suspension criteria and resumption requirements 12 9. Environmental needs 12 10. Test procedure 13 11. Risks and contingencies 20 12. Approvals 21
1.Introduction1.1Purpose of this documentThe purpose of this document is to determine if the requirements specification is met by the developed product, through a set of test cases described in the next sections. This document is defined at the end of the implementation work and would be revised in case new functionalities were added before the final release. Its contents will be then made final when the product is delivered.
1.2Intended AudienceThe intended audience is:
1.3ScopeThis document describes the set of test cases for the Car Gossip Android application, web application and traffic simulator. Moreover, it contains the results coming from the execution of the test cases together with the steps needed to perform it. 1.4Definitions and acronyms1.4.1Definitions
1.4.2Acronyms and abbreviations
1.5ReferencesThis document is based on the previously developed deliverables available at http://www.fer.unizg.hr/rasip/dsd/projects/taraxacum/documents
2.Test-plan introductionThe Car Gossip product will be tested at different levels by means of acceptance and unit testing. The requirement document will serve as a reference to individuate what to be verified, especially at acceptance testing level, on which this document focuses. The final product is composed by three parts that have to be tested:
3.Test items3.1: Desktop Application In the Traffic Simulator we will go to test Parser, Scenario Creation, Simulator, DSRC messages and Bluetooth connection In the Parser, we will test the connection with database and the importing of the data from database; Scenario Creation, we will test if the user can choose for the simulator a number of the cars present on the map; Simulator, we will test if the movement of the cars involved in the simulation is presented on the map, DSRC messages are being sent and the Bluetooth connection is established.
In Android Application we will go to test the Bluetooth connection, alert buttons, user interface. In the Bluetooth connection we will test if when the driver presses the alert button a picture appears on the map and an alert message is sent to other cars via Bluethoot; User Interface, we will test if the map appears on the Android Application and with right coordinates and if the alert buttons appear on the layout. 3.3: Web application In Web application we will test if the map appears, the web application receives message from Android application and stores the message in the database. 4.Features to be tested4.1: Desktop Application
4.2: Android Application
4.3: Web application
5.Features not to be testedThe following features will not be tested:
6.ApproachThe system will be tested manually through a series of detailed test cases. The tests will be described in detail in order to enable the interested reader to recreate and execute them. The tests will be carried out by the project team by dividing the tests into three categories; one for the Desktop Application, one for the Android Application and finally one for the Web Application. 7.Item pass/fail criteria7.1: Desktop Application AD01: Database connection to MongoDB Pass:
Fail: Desktop Application cannot connect to the MongoDB database server. Case 1: MongoDB database is not available. AD01: Import of data from ns-2 movement format file Pass: Traffic simulator successfully parses the data and stores the data in the MongoDB . Fail: Case 1: Application cannot parse the input data. Case 2: Application cannot store parsed data in the database. 4.1.2: Import of data from ns-2 movement format file Pass:
Fail: Appears the message the file is corrapted Case 1: Application cannot parse the input data. Case 2: Application cannot store parsed data in the database.
Pass: Application selects cars from the map and marks them as selected. Fail: Case 1: Application throws an unhandled exception. 4.1.4: Select time frame for the scenario Pass: Application selects time frame on the double slider and stores the time frame. Fail: Case 1: Application throws an unhandled exception. 4.1.5: Create the scenario Pass:
Fail: Application cannot store data in the database. Case 1: The users have selected too cars : Create the scenario Pass:
Fail: Application throws an unhandled exception and the Application cannot store data in the databse Case 1: The users have selected too cars and slide time selected is too big : Create the scenario Pass:
Fail: The users have selected too cars Case 1: Application cannot store data in the database. 4.1.5: Create the scenario Pass: Application uses selected cars, creates the scenario and stores it in the database. Fail: Case 1: No cars are selected. Case 2: Application cannot store data in the database. 4.1.6: Scenario loading from the database Pass: Application loads lists of scenarios from the database. Fail: Case 1: No cars are selected. Case 2: Application cannot store data in the database. 4.1.7: Scenario saving to the database Pass: Application stores scenario to the database. Fail: Case 1: Application cannot store data in the database. 4.1.8: ICD Selection in the simulation window Pass: Application reacts to the user input, selects the selected ICD and starts to follow it on the map. Fail: Case 1: Application doesn’t follow the ICD. 4.1.9: Start Simulation Pass: Application starts the simulation. Fail: Case 1: Application throws an unhandled exception. 4.1.10: Stop Simulation Pass: Application stops the simulation. Fail: Case 1: Application throws an unhandled exception. 4.1.11: Forward / Rewind simulation Pass: Application reacts to user input and forwards / rewinds the simulation by setting the new simulation time. Fail: Case 1: Application doesn’t set the right time. 4.1.12: Visualize selected ICD Pass: Application uses the selected ICD and visualizes it on the map. Fail: Case 1: ICD doesn’t appear on the map. 4.1.13: Visualize surrounding cars Pass: Application shows ICDs on the map with selected ICD in the center. Fail: Case 1: ICDs don’t appear on the map. 4.1.14: Establish Bluetooth connection with phone that runs the Android application Pass: Application connect to Android application via the Bluetooth device and displays it in the status bar. Fail: Case 1: Bluetooth device isn’t available. Case 2: Bluetooth connection cannot be established. 4.1.15: Receive alert messages from the Android application via BT Pass: Application is connected to Android application via the Bluetooth device and receives alert messages. Fail: Case 1: Bluetooth connection isn’t established. Case 2: Alert messages aren’t received. 4.1.16: Visualize alert message and spreading to surrounding cars Pass: Application draws the followed car on the map and draws all the surrounding cars. Cars to which the messages are spread are drawn differently. Fail: Case 1 The cars are not shown on the map. Case 2 The spreading of the messages is not shown. 4.1.17: Distribute messages through a simulated DSRC device Pass: Application simulates the ICDs and DSRC message spread via the DSRC cloud. The DSRC cloud should accept and distribute messages to surrounding ICDs. Fail: Case 1: The messages are not spread. 4.2: Android Application 4.2.1: Set up Bluetooth connection Pass: Bluetooth connection is set up. Fail: Case 1: Bluetooth device isn’t available. Case 2: Bluetooth connection cannot be established. 4.2.2: Initialize a Map with a view of Switzerland Pass: Shows the map of Switzerland. Fail: Case 1: Map of Switzerland is not shown. 4.2.3: Receive position data from the selected ICD in the simulator Pass: ICD data is received from the simulator via Bluetooth. Fail: Case 1: Bluetooth connection isn’t established. Case 2: ICD data isn’t received. 4.2.4: Visualize and update map view with the position data Pass: Center the map to the current ICD data. Fail: Case 1: The map isn’t updated. 4.2.5: Receive gossip messages from surrounding cars Pass: Receives gossip messages from the simulator. Fail: Case 1: Gossip messages are not received. 4.2.6: Visualize surrounding cars on the map Pass: Application visualizes the received data from the cars on the map. Fail: Case 1: Surrounding cars on the map are not shown. 4.2.7: Select an alert message Pass: Application reacts on user input and selects alert from the alert overlay. Fail: Case 1: Application doesn’t react on user input. 4.2.8: Visualize alert message Pass: Alert messages icons appear on the map. Fail: Case 1: Alert messages are not shown on the map. 4.2.9: Send alert message via Bluetooth Pass: Alert messages are sent to the simulator application. Fail: Case 1: Alert messages are not received by the simulator application. 4.2.10: Send alert message via REST-interface Pass: Alert messages are sent via REST-interface to the server. Fail: Case 1: Internet connection isn’t available Case 2: Messages cannot be sent. 4.2.11: Send gossip message via REST-interface Pass: Gossip messages are sent via REST-interface to the server. Fail: Case 1: Internet connection isn’t available Case 2: Messages cannot be sent. 4.2.12: Receive confirmation via REST-interface Pass: Confirmation messages are received by the application. Fail: Case 1: Internet connection isn’t available Case 2: Messages cannot be received. 4.3: Web application 4.3.1: Receive gossip message Pass: Receives gossip messages from the Android device. Fail: Case 1: Internet connection isn’t available Case 2: Messages cannot be received. 4.3.2: Store gossip message in a database Pass: Messages are successfully stored in the database. Fail:
Case 1: Cannot store the messages in the database. 4.3.3: Receive alert message Pass: Receives alert messages from the Android device. Fail: Case 1: Internet connection isn’t available Case 2: Messages cannot be received. 4.3.4: Store alert message in a database Pass: Messages are successfully stored in the database. Fail: Case 1: Cannot store the messages in the database. 4.3.5: Verify alert message Pass: Alert messages are reported as spam or not spam by the application. Fail: Case 1: Application misreports message as spam. 7.1Installation and ConfigurationNo configuration is needed for application deployment. Application is installed as java jars and as the Android package. This doesn’t affect testing. 7.2Documentation problemsSince the features that are planned for the web application are still not in a determined state, it is not clear what to test in these cases. 8.Suspension criteria and resumption requirementsWe test the code development and if a bug is being found, we stop the testing and fix it then we restart the testing from the beginning. Instead, when we test the connection between Android and Desktop Application the Bluetooth device could give some problem of connection, then we should change Bluetooth device and restart to test from the beginning.
9.Environmental needsIn this chapter we list which hardware and software we need to test the Android, Desktop and Web Application. 9.1. Hardware This is the list of the hardware that we need to test each part of the project, so to test:
9.2. Software This is the list of the software that we need to test each part of the project, so to test:
10.Test procedure8.1. Desktop Application 8.1.1. Database connection to MongoDB - DESKTOP-001 Description: Testing database connection. Test type: Positive Preconditions:
Input definition:
Output definition:
8.1.2. Import of data from ns-2 movement format file – 002 Description: Testing importing data to database. Test type: Positive Preconditions:
Input definition:
Output definition:
Description: Testing importing data to database. Test type: Negative Preconditions:
Input definition: 1. User clicks on the import mov file button in the database tab, and selects a file different from mov file. Output definition: 1. Old database is dropped. 2. The database is empty.
Input definition:
Output definition:
8.1.4: Select time frame for the scenario - DESKTOP-004 Description: Testing time frame selection for the scenario setup. Test type: Positive Preconditions:
Input definition:
Output definition:
8.1.5: Create the scenario - DESKTOP-005 Description: Testing creating scenarios. Test type: Positive Preconditions:
Input definition:
Output definition:
Description: Testing creating scenarios. Test type: Negative Preconditions:
Input definition: 1. User selects car region or selects a high number of cars from the table . 2. User selects time frame or leaves the default one. 3. User clicks on the create scenario button. Output definition: 1. Exception not unhandle. 8.1.6: Scenario loading from the database - DESKTOP-006 Description: Testing loading scenarios from the database. Test type: Positive Preconditions:
Input definition:
Output definition:
8.1.7: Scenario saving to the database - DESKTOP-007 Description: Testing saving scenarios to the database. Test type: Positive Preconditions:
Input definition:
Output definition:
8.1.8: ICD Selection in the simulation window - DESKTOP-008 Description: Testing selecting ICDs in the simulation. Test type: Positive Preconditions:
Input definition:
Output definition:
8.1.9: Start Simulation - DESKTOP-009 Description: Testing simulation starting. Test type: Positive Preconditions:
Input definition:
Output definition:
8.1.10: Stop Simulation DESKTOP-010 Description: Testing stopping the simulation. Test type: Positive Preconditions:
Input definition:
Output definition:
8.1.11: Forward / Rewind simulation - DESKTOP-011 Description: Testing simulation time manipulation. Test type: Positive Preconditions:
Input definition:
Output definition:
8.1.12: Visualize selected ICD - DESKTOP-012 Description: Testing ICD visualization. Test type: Positive Preconditions:
Input definition:
Output definition:
8.1.13: Visualize surrounding cars - DESKTOP-013 Description: Testing visualizing traffic on the map. Test type: Positive Preconditions:
Input definition: Output definition:
8.1.14: Establish Bluetooth connection with phone that runs the Android application - DESKTOP-014 Description: Testing Bluetooth connectivity. Test type: Positive Preconditions:
Input definition:
Output definition:
8.1.15: Receive alert messages from the Android application via BT - DESKTOP-015 Description: Testing Bluetooth communication. Test type: Positive Preconditions:
Input definition:
Output definition:
8.1.16: Visualize alert message and spreading to surrounding cars - DESKTOP-016 Description: Testing visualizing the alerts. Test type: Positive Preconditions:
Input definition:
Output definition:
8.1.17: Distribute messages through a simulated DSRC device DESKTOP-017 Description: Testing gossip algorithm. Test type: Positive Preconditions:
Input definition:
Output definition:
8.2: Android application - ANDROID 8.2.1: Set up Bluetooth connection - ANDROID-001 Description: The test to verify that a Bluetooth connection between Simulator and Android application can be established. Test type: Positive Preconditions:
Input definition: 1. User selects “Connect to device on Android application. 2. User selects the corresponding system there the simulator is run on.
1. The video component has loaded the video. 2. Navigation controls are enabled.
Input definition: 1. The GSP coordinates Output definition: 1. The map is loaded on the Android Application. 8.2.3 Alert Button - ANDROID-003 Description: When the user clicks on the buttons the alert icon appears on the map. Test type: Positive Preconditions:
Input definition: 1. User clicks on an Alert button. Output definition: 1. The alert icons appears on the map 8.2. 4 Alert Button - ANDROID-004 Description: When the user clicks on the buttons the message is sent to Simulator Test type: Positive Preconditions:
Input definition: 1. User clicks on an Alert button. Output definition: 1. The simulator receives the message and an alert icon appears on the map of the simulator. 8.2. 4 Alert Icon - ANDROID-005 Description: When the user clicks on the alert icon the popup appears Test type: Positive Preconditions:
Input definition: 1. User clicks on an alert icon. Output definition: 1. The popup appears on the screen with message:”Are you sure to remove the icon message?” and the buttons “Yes” and “No”
Input definition: 1. User clicks on ”Yes” button. Output definition:
Description: When the user clicks "Yes" button to remove the second alert icon Test type: Negative Preconditions:
Input definition: 1. User clicks on ”Yes” button. Output definition:
Description: When the user clicks "No” button Test type: Negative Preconditions:
Input definition: 1. User clicks on ”No” button. Output definition:
8.3: Web application - WEB 8.3.1: Receive gossip message - WEB-001
Input definition:
Output definition:
8.3.2: Store gossip message in a database - WEB-002 Description: Test if the gossip message is stored in a database. Test type: Positive Preconditions:
Input definition:
Output definition:
8.3.3: Receive alert message - WEB-003 Description: Test if the Web application receives alert messages. Test type: Positive Preconditions:
Input definition:
Output definition:
8.3.4: Store alert message in a database - WEB-004 Description: Test if the alert message is stored in a database. Test type: Positive Preconditions:
Input definition:
Output definition:
8.3.5: Verify alert message - WEB-005 Description: Test if the alert message is valid Test type: Positive Preconditions:
Input definition: Output definition: 11.Risks and contingenciesAll developers have to be ready to make quick fixes if a bug is caught in their responsible parts of the development. During the testing process the developers need to document what they used as input and what came out as output. If an error occurred this should be documented as well so the responsible developer has all information needed to fix the issue. The developer has to make sure that every requirement is fulfilled for the test procedure for the test to be positive. When one test is done the developer has to put in the result in the test report. 12.Approvals
Directory: download -> repository repository -> Escaping the trap: the simplified application of eu law repository -> Project (Project name) Date repository -> Mass Observation (MOb) Acceptance Test Plan repository -> Livetv for Mobile Applications repository -> Summary Week Report Project repository -> Mass Observation (MOb) Acceptance Test Plan repository -> BuySafe Acceptance Test Plan Version 0 Revision History repository -> Summary Week Report Project repository -> Search4Yummy Final Project Report Version 0 repository -> Design Description Version 0 Revision History Download 191.43 Kb. Share with your friends:
|