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 Pentium 200 MHz with 64MB of RAM running Red Hat Linux 7
• Intel Pentium 100 MHz with 32MB of RAM running Red Hat Linux 7 (and Windows 95)

The developers will peform the testing. 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 if the system does actually control a robot.
Test Description	Start the programs, on their respective machines. Attempt to move the robot using the two interfaces.
Test Conditions	We will perform this test preferably twice, the first time will be on a regular Ethernet network using two Linux machines. The second test will be performed on wireless Ethernet using two Linux machines.
Expected Results	The system will control the robot in either of the two given tests.

Test Objective	Test surrogate to see if it responds like an actual robot
Test Description	Start the programs, on their respective machines. Attempt to control the robot using one of the two interfaces (probably the human control), and compare results of the surrogate to that of an actual robot.
Test Conditions	We will perform this test on an Ethernet network using two Linux machines.
Expected Results	We expect that the surrogate will perform its actions exactly as a real robot would.

Test Objective	Test communication between API and surrogate.
Test Description	Monitor where there is two way communications between the surrogate and API.
Test Conditions	We will perform this test on an Ethernet network using two Linux machines.
Expected Results	Two way communications will take place.

Test Objective	Test the GUI to see if it properly displays the motion of the robot.
Test Description	Move the robot using the human interface, and monitor the motion of the robot, and compare this with the on screen value.
Test Conditions	We will perform this test on an Ethernet network using two Linux machines.
Expected Results	The GUI will properly display the motion of the robot.

Test Objective	Test the commands of the system (forward, backward, turn left, turn right, increase speed, decrease speed, stop).
Test Description	Using the human interface test each of the commands given.
Test Conditions	We will perform this test on an Ethernet network using two Linux machines.
Expected Results	The surrogate or actual robot will respond to the commands and take the appropriate actions to carry them out.

Test Objective	Test to see if the API has a standard interface that both the human interface and OTB are communicating with.
Test Description	We will review our code and test it against our detailed design to make sure we are following our design.
Test Conditions	Code review meeting.
Expected Results	Our design will match our planned design.

Test Objective	Test that only the API is controlling the robot through its common interface.
Test Description	Start the programs on their respective machines. Input no commands to the API, and make sure the robot does nothing except send regular status reports.
Test Conditions	We will perform this test on an Ethernet network using two Linux machines.
Expected Results	The robot will not move, but send regular status updates.

Test Objective	Test to see if our human interface is acceptable (comfortable to use and understand what is going on with the robot).
Test Description	Show our interface to our client and get it approved.
Test Conditions	We will perform this test on an Ethernet network using two Linux machines.
Expected Results	Our client will approve of the interface, which we have constructed.

Test Objective	Test documentation is meeting our set coding standards.
Test Description	Code Review, we will have a meeting and examine each others code to make sure we coding to the standards we have established.
Test Conditions	Meeting
Expected Results	Our code will meet our standards.

Test Objective	Test responsiveness of the system.
Test Description	We will issues commands to the robot rapidly.
Test Conditions	We will perform this test on an Ethernet network using two Linux machines.
Expected Results	The system should respond rapidly to the input commands.

Test Objective	Test for robustness.
Test Description	Each programmer will test their code for exceptional circumstances. After the program is completely integrated we will also test for robustness
Test Conditions	While coding, or shortly after completion. Also we will test for robustness when the entire system is built.
Expected Results	Our program should be stable and handle all exceptional events.

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