Senior Design

Test Plan

Senior Design - Spring/Summer 2000

Modification history:

Team Name: Team 3

Team Members:

• Jeffrey Miller ( j_Miller68@hotmail.com)
• Michael Wales (Mag7Rule@aol.com)
• Jeff Goodman (Jeff2379@aol.com)

Contents of this Document

1. Introduction
2. Overall Objective for Software Test Activity
3. Reference Documents
4. Description of Test Environment
5. Overall Stopping Criteria
6. Description of Individual Test Cases

• Overall Objective for Software Test Activity: Our goal is to create a product that will allow for ONESAF or a human controller to communicate to a robot through the API. The API should be able to communicate remotely to the robot over a network such as wireless ethernet. We want to provide the user with useful feedback so they can determine the results of the command which they input.

Reference Documents:

• Concept of Operations Version 1.0
• Project Plan Version 1.0
• SRS Version 1.0

Most of the testing will be done in the same environment as the code is developed in because it is much easier for us to do. The environments we are using for development are:

• Intel 200 MHz with 64MB of RAM running Red Hat Linux 7.1
• DESCRIPTION OF JEFFS TEST ENVIORNMENT
• DESCRIPTION OF MIKES TEST ENVIORNMENT

The testing will be performed by the developers. Whenever possible, Jeff, Jeff, and Mike will test the modules developed by the other group member to get as great of variety during testing as possible. The testing that is performed during the code's development will be done by the person creating the module. Robustness testing will also be performed by the developer because of their intimate knowledge of the cases when an exception may occur.

Most of our testing will be performed as the code is developed. The developer will create a short section of code, recompile the effected classes, and then perform an exhaustive test on that module to check it for errors. If each method is thoroughly checked as it is created, we should eliminate most bugs that would be found during the final testing phase.

When the final testing is performed, we will focus on correctness and stability. If all testing goes well, I would expect that we would perform testing for about 4 hours. If any minor errors occur, they will be corrected at that time, while larger problems will be documented later fixing. If there are more than 3 or 4 large problems, testing will be suspended till we can fix the problems and start the tests over.

To test for correctness we will attempt to move the robot using the the human interface. If the software passes this test, it will also pass the test where ONESAF is controlling it.

Our product will not be delivered to our customer if we feel that it is not correct. A program is pretty much worthless if it does not do its test correctly. We do not anticipate us giving the product to the customer with any type of bugs or glitches in it, but that has to really be decided after testing and encountering such problems if they exist.

Test Objective
Test Description
Test Conditions
Expected Results

Test Objective
Test Description
Test Conditions
Expected Results

Test Objective
Test Description
Test Conditions
Expected Results

Template created by G. Walton ( GWalton@mail.ucf.edu ) on March 28, 1999 and last modified on August 15, 2000.

This page last modified by Jeffrey Miller ( j_miller68@hotmail.com ) on April 8, 2000.