Lab 4: Software Testing - Software Engineering | CS 451, Lab Reports of Software Engineering

Material Type: Lab; Class: Software Engineering; Subject: Computer Science; University: Drexel University; Term: Unknown 2009;

Typology: Lab Reports

Pre 2010

Uploaded on 08/19/2009

koofers-user-sli
koofers-user-sli 🇺🇸

10 documents

1 / 2

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
CS 451 Software Engineering
Lab 4: Software Testing
Due: 3/13/2009
Goals:
In this lab, you will apply techniques from the previous two lectures for testing a maze
game system. You will practice using the JUnit and EMMA tools to assist you.
Instructions:
The maze game is a small system for building a maze in a computer game; this system uses
the abstract factory pattern, as described by Gamma et al. A maze is defined as a set of
rooms; a room knows its neighbors, such as a wall, or a door to another room. The class
MapSite is the common abstract class for all the components of the maze. There are two
variations of the maze game supported by the abstract factory pattern: a red maze game
and a blue maze game.
The lab has two parts to focus on the two models of testing.
Stage 1: Black Box Testing
Source code for the part of the system that controls moving around the maze has not been
given to you. Design black box tests to ensure that the system functionality is reasonable
(e.g. one cannot move through a wall). Your interface to this functionality is through the
MazeViewer.move(Maze maze, Direction dir) method. This method instructs the person in
the maze to move one location in the specified direction. If the move is valid, the person
will make the move. If the move is invalid, nothing will happen.
It is important to remember that when loading a maze from a file, the person always starts
in room zero. You may find the Maze.getCurrentRoom() method to be helpful; it returns a
reference to the room the person is currently in.
In a text file called blackbox.txt, describe any techniques you used in designing the tests and
why the number of tests you designed is sufficient. Please also record any bugs found in
blackbox.txt.
Stage 2: White Box Testing
For the parts of the system that you have been given source code to, design a set of white
box tests for maximum code coverage. Use JUnit and EMMA to help you. Is it possible for
you to achieve 100% coverage? Explain.
Calculate the cyclomatic complexity for all methods in the SimpleMazeGame class. How did
you come up with these numbers? Please describe in a text file called whitebox.txt
The SimpleMazeGame class constructs a maze based on a description from a file (see
Appendix A for file format). Unit test this method and record any bugs found in writebox.txt
pf2

Partial preview of the text

Download Lab 4: Software Testing - Software Engineering | CS 451 and more Lab Reports Software Engineering in PDF only on Docsity!

CS 451 Software Engineering

Lab 4: Software Testing

Due: 3/13/

Goals:

In this lab, you will apply techniques from the previous two lectures for testing a maze game system. You will practice using the JUnit and EMMA tools to assist you.

Instructions:

The maze game is a small system for building a maze in a computer game; this system uses the abstract factory pattern, as described by Gamma et al. A maze is defined as a set of rooms; a room knows its neighbors, such as a wall, or a door to another room. The class MapSite is the common abstract class for all the components of the maze. There are two variations of the maze game supported by the abstract factory pattern: a red maze game and a blue maze game. The lab has two parts to focus on the two models of testing.

Stage 1: Black Box Testing

Source code for the part of the system that controls moving around the maze has not been given to you. Design black box tests to ensure that the system functionality is reasonable (e.g. one cannot move through a wall). Your interface to this functionality is through the MazeViewer.move(Maze maze, Direction dir) method. This method instructs the person in the maze to move one location in the specified direction. If the move is valid, the person will make the move. If the move is invalid, nothing will happen. It is important to remember that when loading a maze from a file, the person always starts in room zero. You may find the Maze.getCurrentRoom() method to be helpful; it returns a reference to the room the person is currently in. In a text file called blackbox.txt, describe any techniques you used in designing the tests and why the number of tests you designed is sufficient. Please also record any bugs found in blackbox.txt.

Stage 2: White Box Testing

For the parts of the system that you have been given source code to, design a set of white box tests for maximum code coverage. Use JUnit and EMMA to help you. Is it possible for you to achieve 100% coverage? Explain. Calculate the cyclomatic complexity for all methods in the SimpleMazeGame class. How did you come up with these numbers? Please describe in a text file called whitebox.txt The SimpleMazeGame class constructs a maze based on a description from a file (see Appendix A for file format). Unit test this method and record any bugs found in writebox.txt

What to submit

  1. All the Black Box test cases in backbox.zip
  2. All the Write Box test cases in whitebox.zip
  3. Blackbox.txt and writebox.txt

Appendix A: Maze Input File Format

There are two types of lines in the input file: room definitions and door definitions. A room definition consists of the following whitespace delimited tokens: room is the room number (there must be a room number 0 for the display to work). The remaining tokens specify the element on that side of the room. Use the word “wall” (sans quotes) for a wall, or use the name of a door. A door definition consists of the following whitespace delimited tokens: door <room 1> <room 2> is a unique name to identify the door in the room definitions, it may not start with a number. The next two tokens are the numbers of the rooms on either side of the door. The final token can either be “open” or “close” (sans quotes) to specify if the door is open or closed by default. All blank lines in the input file are to be ignored.