Iowa Cycling Project: Testing & Evaluation Plan

Transcription

1 IOWA STATE UNIVERSITY Iowa Cycling Project: Testing & Evaluation Plan [Type the document subtitle] Charles Dunbar, Ben Kallal, Ankit Patel, Peter Purcell, Kody Reynolds [Pick the date] [Type the abstract of the document here. The abstract is typically a short summary of the contents of the document. Type the abstract of the document here. The abstract is typically a short summary of the contents of the document.]

2 Testing & Evaluation In order to test out the functionalities of our design, we will carefully self-test the different modules of our project. This includes testing the: Client Server GIS Client Module The purpose of the client module is to serve as the graphical interface for the user. The UI will also drive the process of finding a route for the user with its UI Elements. The client is meant to be a front end display and interact with the Google Maps API to display a valid route. The client will be displayed and used through a standard html website. All of the interactive UI elements will function using JavaScript. Depending on the task, the JavaScript will make server calls in order to get GIS information or update the web server. These items can post back to the application and change its state by calling specific JavaScript methods. We will test to make sure the application: Will allow full functionality using Firefox, Internet Explorer, and Chrome. Will display warnings for common errors e.g. can t find an address. Will display information to indicate that the application is working on finding a route. Will allow printing of a route. We will also test to make sure the application meets its non-functional requirements, such as: The user interface will look similar in all browsers Will be extensible for the addition of future features. Designed to be useable by people with little computer experience Will allow two users to get the same route with minimal effort Can support many concurrent users Testing the Communication Interface & Other Methods: initialize()

3 getdirections() solveroute(addressresults) showdirections(response, error) addstop(overlay, latlng, overlay_latlng) haserroroccurred(error) clearmap() showbusy(info) hidebusy() createlink() geturlvars() replaceall(source,stringtofind,stringtoreplace) The methods dealing largely with Google Maps and ArcGIS were tested via usability testing as well as some edge case testing, for instance typing in an address outside the scope of our application. The createlink(), geturlvars() and replaceall() where all tested by using some basic unit testing functions and principles. Server Module The server module shall provide the hosting for the client module and also provide the processing of the actual mapping algorithm on this module. This server will run a current version of Red Hat Linux for the operating system and the Apache web server for the purpose of hosting the site. The Java runtime will also need to be installed because that is how one can interface with the ArcGIS server. Services/Tasks/Functions of the Service Module that will need to test: Host the application layer that is handled by the client module Handle main algorithm for user and system requests We will also test the following non-functional requirements for the server module: Usability o Must provide a positive service to the users to help accomplish their goals of finding the least-costly route Reliability

4 o Users must be allowed to access the web service almost always without any downtime and get back the correct least-cost path from origin to destination Speed o The algorithm and user interaction with the application must be reasonably fast and responsive under normal use conditions Scalability o Must be able to handle multiple requests at once up to an upper limit MAX_NUM_USERS that is defined Security o The server module must be immune to attacks from external sources GIS Module The purpose of this module is to store and retrieve the GIS data obtained from the Iowa DOT and our client, INHF. Using ArcGIS Server, getting metadata quickly and easily about each point along the path will allow for the algorithm to ensure the route given to the end user is safe and gets them to their destination with a high degree of precision. We will test the following functional requirements for the GIS Module: Returns metadata about road given specific latitude/longitude Connects client to server data Is able to return proper road information for path creation We will also testing the following non-functional requirements for the GIS Module: Reliable Handle many connections Return results quickly Easy to update Survey In order to test the usability of the web interface, we will conduct a usability test with at least 5 subjects. For our subjects we will use a random sampling that we gather by posting the survey and the URL on

5 various social media web sites. By doing this, all of our friends will be able to utilize our application and give us feedback. It will also show us how the application will respond in real world circumstances. In our survey the users will have the following tasks: 1) Insert a departure and a destination. 2) Select preferences. 3) Observe route given. In our survey we will ask these questions: 1) How easy was the interface to use? (1-easy, 10-hard) 2) What did you like? What did you dislike? 3) On average, how long did it take you to complete the three steps? 4) How satisfied were you with the speed of the application? (1-good, 10-bad) 5) Were the routes given by the application accurate and reasonable? 6) Do you have any suggestions for our application? 7) Were you accessing our application via a desktop or mobile version? 8) How likely are you to use this application? (1-frequently, 10-never) 9) If you answered #8 greater than 5, why did you answer that way? JavaScript Testing We will setup automated testing using JavaScript methods to manipulate the UI elements. The purpose will be to test various possible inputs for precision, accuracy, route timing, and whether the application holds up to safety options selected. Another main function of this testing will be to stress test the system for multiple concurrent users. Requirements Testing As a part of quality control we will also have a phase of testing that compares the application to the design document functional and non-functional requirements. The non-functional requirements will be tested through usability test indicated in the previous section e.g. a post-user experience survey. General Route Testing After general testing has been performed we will create a limited amount of test cases. In these test cases we will create routes that will combine streets and trails. We will then have a test user trace the route on bicycle. The purpose of this will be to get a feeling for accuracy of the route and to assist the group in tweaking the route finding algorithm.