3



COMP 3663 X2

S3:

Detailed Design and Test Plan

OutSource Inc. (Group A)

Mallinson, Mike 100071936

Logan, Billy 100059371

Peters, Richard 100071545

Table of Contents

Detailed Design and Test Plan 1

Executive Overview 7

Part I 7

Part II 7

Detailed Design Document 8

1. Introduction 8

1.1 Purpose 8

1.2 Scope 8

1.3 Definitions, Acronyms, and Abbreviations 8

2. References 8

3. Decomposition Description 9

3.1 Module Decomposition 9

Figure 3.1-1 – Module Decomposition 9

3.1.1 User Interface Layer 10

Figure 3.1.1-1 – The User Interface Layer 10

3.1.2 Domain Layer 11

Figure 3.1.2-1 – The Domain Package 11

3.1.3 Data Layer 11

3.2 Concurrent Process Decomposition 11

3.3 Data Decomposition 11

3.4 State Model Decomposition 13

Figure 3.4-1 – State Diagram Decomposition 13

3.5 Use Case Model Decomposition 14

Figure 3.5-1 – Use Case Model Decomposition 14

4. Dependency Description 15

Figure 4-1 – Dependency Description 15

4.1 Intermodule Dependencies 15

4.2 Interprocess Dependencies 15

4.3 State Dependencies 15

4.4 Layer Dependencies 15

5. Interface Description 15

5.1 Intermodule Dependencies 15

5.1.1 Interface of the User Interface Layer 15

6. Detailed Design 16

6.1 Domain Package 16

6.1.1 Character 16

Figure 6.1.1-1 – Character Class 16

6.1.1.1 Attributes 16

6.1.1.2 Methods 17

6.1.1.3 Instance Details 18

6.1.1.4 Pseudo Code for equipping equipment 18

6.1.2 Enemy 19

Figure 6.1.2-1 – Enemy Class 19

6.1.2.1 Attributes 19

6.1.2.2 Methods 19

6.1.2.3 Instance Details 19

6.1.3 Area 20

Figure 6.1.3-1 – Area Class 20

6.1.3.1 Attributes 20

6.1.3.2 Methods 20

6.1.3.3 Instance Details 20

6.1.3.4 Pseudo Code for getting an Item reward 20

6.1.4 Item 21

Figure 6.1.4-1 – Item Class 21

6.1.4.1 Attributes 21

6.1.4.2 Methods 21

6.1.5 Inventory 22

Figure 6.1.5-1 – Inventory Class 22

6.1.5.1 Attributes 22

6.1.5.2 Methods 22

6.1.5.3 Instance Details 23

6.1.6 Game 24

Figure 6.1.6-1 – Game Class 24

6.1.6.1 Attributes 24

6.1.6.2 Methods 24

6.1.6.3 Instance Details 25

6.1.6.4 Pseudo Code for Moving 25

6.1.7 Battle 26

Figure 6.1.7-1 – Battle Class 26

6.1.7.1 Attributes 26

6.1.7.2 Methods 26

6.1.7.3 Instance Details 27

6.1.7.4 Pseudo Code for Battle 27

6.1.8 Entity 28

Figure 6.1.8-1 – Entity Class 28

6.1.8.1 Attributes 28

6.1.8.2 Methods 29

6.1.9 Equipment 30

Figure 6.1.9-1 – Equipment Class 30

6.1.9.1 Attributes 30

6.1.9.2 Methods 30

6.1.10 Consumable 31

6.1.10.1 Attributes 31

6.1.10.2 Methods 31

6.1.11 Princess 31

Figure 6.1.11-1 – Princess Class 31

6.1.11.1 Methods 31

6.2 User Interface Package 32

6.2.1 Title Screen 32

Figure 6.2.1-1 – Title Screen 32

6.2.1.1 Attributes 32

6.2.1.2 Methods 32

6.2.1.3 Instance Details 32

6.2.2 Character Creation 33

Figure 6.2.2-1 – Character Creation 33

6.2.2.1 Attributes 33

6.2.2.2 Methods 34

6.2.2.3 Instance Details 34

6.2.3 Movement Window 35

Figure 6.2.3-1 – Movement Window 35

6.2.3.1 Attributes 35

6.2.3.2 Methods 36

6.2.3.3 Instance Details 37

6.2.4 Battle Window 37

Figure 6.2.4-1 – Battle Window 37

6.2.4.1 Attributes 37

6.2.4.2 Methods 38

6.2.4.3 Instance Details 39

6.3 Class Diagrams 40

Figure 6.3-1 – Module Decomposition 40

Software Test Documentation 41

T1. Introduction 41

T1. Conan Video Game Test Documentation 41

T2.1 Unit Test STD 41

T2.1.1 Introduction 41

T2.1.2 Unit Test Plan 41

T2.1.2.1 Scope 41

T2.1.2.2 Approach 41

T2.1.2.3 Items Under Test 42

T2.1.2.4 Schedule and Personnel 42

T2.1.3 Unit Test Design 42

T2.1.3.1 Items 42

T2.1.3.2 Approach 43

T2.1.3.3 Detailed Plan 43

T2.1.4 Unit Test Cases 43

T2.1.4.1 Procedure C1 – Character Initialization 43

T2.1.4.2 Procedure C2 – Change Strength – Spending Stat Points 44

T2.1.4.3 Procedure C3 – Change Strength – Not Spending Stat Points 44

T2.1.4.4 Procedure C4 – Change Max HP – Spending Stat Points 44

T2.1.4.5 Procedure C5 – Change Max HP – Not Spending Stat Points 44

T2.1.4.6 Procedure C6 – Change Defense – Spending Stat Points 44

T2.1.4.7 Procedure C7 – Change Defense – Not Spending Stat Points 45

T2.1.4.8 Procedure C8 – Change Attack Rating – Spending Stat Points 45

T2.1.4.9 Procedure C9 – Change Attack Rating – Not Spending Stat Points 45

T2.1.4.10 Procedure C10 – Heal 45

T2.1.4.11 Procedure C11 –Experience 45

T2.1.4.12 Procedure C12 – Level Up 46

T2.1.4.13 Procedure C13 – Grid Position 46

T2.1.4.14 Procedure I1 – Inventory Initialization 46

T2.1.4.15 Procedure I2 – Add Item 46

T2.1.4.16 Procedure I3 – Remove Item 46

T2.1.4.17 Procedure I4 – Keys 46

T2.1.4.18 Procedure I5 – Boss Key 47

T2.1.4.19 Procedure I6 – Add Token 47

T2.1.4.20 Procedure I7 – Remove Token 47

T2.1.4.21 Procedure E1 –Equipment Initialization 47

T2.1.5 Unit Test Procedures 47

T2.2 Integration Test STD 48

T2.2.1 Introduction 48

T2.2.2 Build 1 48

T2.2.2.1 Test Plan 48

T2.2.2.1.1 Scope 48

T2.2.2.1.2 Approach 48

T2.2.2.1.3 Items 48

T2.2.2.1.4 Schedule and Personnel 48

T2.2.2.2 Test Design 48

T2.2.2.2.1 Items 48

T2.2.2.3 Test Cases 49

T2.2.2.4 Test Procedures 49

T2.2.3 Build 2 49

T2.2.3.1 Test Plan 49

T2.2.3.1.1 Scope 49

T2.2.3.1.2 Approach 49

T2.2.3.1.3 Items 49

T2.2.3.1.4 Schedule and Personnel 49

T2.2.3.2 Test Design 49

T2.2.3.2.1 Items 49

T2.2.3.2.2 Approach 49

T2.2.3.3 Test Cases 50

T2.2.3.3.1 Case 1 - Usability 50

T2.2.3.3.2 Case 2 – Button Handlers 50

T2.2.3.3.3 Case 3 – Window Switching 50

T2.2.3.4 Test Procedures 50

T2.3 System Test STD 50

T2.3.1 Introduction 50

T2.3.2 Test Plan 50

T2.3.2.1 Scope 50

T2.3.2.2 Approach 51

T2.3.2.3 Items 51

T2.3.2.4 Schedule and Personnel 51

T2.3.3 Test Design 51

T2.3.3.1 Items 51

T2.3.3.2 Approach 51

T2.3.3.3 Detailed Plan 51

T2.3.4 Test Cases 52

T2.3.4.1 Case 1 – Location Changing 52

T2.3.4.2 Case 2 – Clearing Enemies 52

T2.3.4.3 Case 3 – Save/Load Game 52

T2.3.4.4 Case 4 – Changing Map and Battle Windows 52

T2.3.5 Test Procedures 52

T2.4 Conclusion 52

Appendix A: Sample Test Form 53

Executive Overview

Employees at OutSource Inc. proudly present the design for our newly created computer game, Conan: Rescue the Princess for Initech. This document provides the detailed design aspects and test plan of our computer game.

This document is separated into 2 parts and each part is composed of multiple sections.

Part I

Sections 1 & 2 introduce our product and any extra itinerary that will aid in your understanding of this document. The third section is a decomposition of the different components of the game. The fourth section describes the dependency relationship between the different classes that make up our game. The fifth section lists the different interfaces and classes which we will implement to provide a user interface which will allow the game to finally take shape. The sixth section is the final section for part I. It summarizes the attributes and operations for each class in the game.

Part II

We describe the Software Test Documentation (STD). The sections included contain information such as our STD objectives, our testing schedule and our detailed testing procedure which include test cases and examples.

We aim to design a product which in its entirety is more than the basic standard game. Our designers are confident in providing our customer with a successful, tried tested and true product which will be extensible and will keep the user coming back for more!

Sincerely,

OutSource Inc.

Detailed Design Document

1. Introduction

1.1 Purpose

To provide the reader detailed information surrounding our product game

Conan: Rescue the Princess.

1.2 Scope

Providing a detailed design document allows the reader to intimately view comprehensive diagrams, classes, and a test plan OutSource Inc. has created for Initech.

1.3 Definitions, Acronyms, and Abbreviations

• GUI - Graphical User Interface

• IDE - Integrated Development Environment

• IO - Input/Output

• RPG - Role-Playing game

• STD - Software Test Documentation

2. References

Website for COMP 3663 X2 (2006-7) Software Engineering, Computer Science,

Acadia University (Silver, 2006-7)

( )

3. Decomposition Description

3.1 Module Decomposition

Conan will have three layers: the User Interface Layer, the Domain Layer, and the Data Layer. The User Interface Layer will be the GUI. The Domain Layer will contain the game packages. The Data Layer will store the relevant game data for the saving and loading of game data.

[pic]

Figure 3.1-1 – Module Decomposition

3.1.1 User Interface Layer

This layer contains the interface used by the player to interact with the game. Each class is a different window seen within the game. The User Interface Layer will contain classes for the:

1) Title Screen

2) Character Creation

3) Movement Window

4) Battle Window

[pic]

Figure 3.1.1-1 – The User Interface Layer

3.1.2 Domain Layer

This layer contains the classes used by the program to represent the game. The packages

include:

1) Area

2) Item (Broken down into equipment/consumable item packages)

3) Inventory

4) Game

5) Battle

6) Entity (broken down into Enemy/Character/Princess)

[pic]

Figure 3.1.2-1 – The Domain Package

3.1.3 Data Layer

This layer will be responsible for the storing and retrieving of data necessary for the saving and loading of the game.

3.2 Concurrent Process Decomposition

Conan does not implement concurrent processes.

3.3 Data Decomposition

The Game class is the main class used to process the game. This class will create instances of Character, Princess, Area, and Battle.

The Character class will represent the player. It will create an instance of the player's Inventory.

The Area class will represent a room in the game. It will create instances of items which the user can pick up.

The Battle class will represent the interaction between the Character and an Enemy. It will create instances of Enemy.

The Inventory class will represent the items held by the character. It will create instances of Item of which the user has obtained.

3.4 State Model Decomposition

Conan has the following states:

1) Initialization – The player is creating the character and initializing the game.

2) Movement – The player is on the movement screen.

3) Battle – The player is engaged in battle.

The following diagram shows the state transitions:

[pic]

Figure 3.4-1 – State Diagram Decomposition

3.5 Use Case Model Decomposition

Conan uses the following 12 use cases:

[pic]

Figure 3.5-1 – Use Case Model Decomposition

4. Dependency Description

This sections deals with the dependencies in section 3.3, which are illustrated below:

[pic]

Figure 4-1 – Dependency Description

4.1 Intermodule Dependencies

The User Interface Layer is dependent on the domain layer.

4.2 Interprocess Dependencies

There is only one process, there can be no dependencies.

4.3 State Dependencies

These are shown in the figure in Section 3.4.

4.4 Layer Dependencies

These are shown in the figure in Section 3.1.

5. Interface Description

5.1 Intermodule Dependencies

This section describes the interfaces of the game Conan. This includes the classes and

modules. Additions or removals may occur during production.

5.1.1 Interface of the User Interface Layer

The User Interface Layer will have the following classes and interfaces:

- public class TitleScreen implements Jframe

- public class CharacterCreation implements Jframe

- public class MovementScreen implements Jframe

- public class BattleScreen implements Jframe

6. Detailed Design

6.1 Domain Package

6.1.1 Character

[pic]

Figure 6.1.1-1 – Character Class

6.1.1.1 Attributes

• int statPoints

o The amount of unspent status points

• int exp

o The amount of experience points the character has

• int level

o The level of the character

• Inventory inv

o The character's inventory

• Item weapon

o The character's weapon

• Item armor

o The character's armor

• Item accessory

o The character’s accessory

• int posx

o The x-coordinate of the character

• int posy

o The y-coordinate of the character

6.1.1.2 Methods

• public Character(String aName, int aHp, int aStr, int aDef, int aAr, int aPic)

o Create a character with given values

• public int getStatPoints()

o get the character's unspent status points value

• public void setStr(int amount, boolean spentPoints)

o set the strength stat to amount, and adjust status points if points were spent

• public void setMaxHp(int amount, boolean spentPoints)

o set the maximum hp stat to amount, and adjust status points if points were spent

• public void setDef(int amount, boolean spentPoints)

o set the defense stat to amount, and adjust status points if points were spent

• public void setAr(int amount, boolean spentPoints)

o set the attack rating stat to amount, and adjust status points if points were spent

• public int getLevel()

o get the character's level

• public void getHealed(int healAmount)

o add hp to the character

• public void addExp(int amount)

o add amount to the character's exp

• private void levelup()

o raise the level

• public Inventory getInv()

o get the character's inventory

• public void equip(Item aEquipment)

o set the character's equipment

• public int getPosx()

o get the character's x position

• public int getPosy()

o get the character's y position

• public void setPosx()

o set the character's x position

• public void setPosy()

o set the character's y position

• private adjustStatPoints(int used)

o adjust the unspent status point amounts upon adding/removing points to a stat

• private void unEquip(Item aEquipment)

o remove equipment from character

6.1.1.3 Instance Details

There will only be a single instance of Character at any given time.

6.1.1.4 Pseudo Code for equipping equipment

unequip current item of the same item type

remove status increases from old item

set equipped item to the new item

add status increases from new item

6.1.2 Enemy

[pic]

Figure 6.1.2-1 – Enemy Class

6.1.2.1 Attributes

• int exp

o Amount of exp earned by defeating enemy

• Item reward

o The item reward for defeating the enemy

• boolean dead

o true if the enemy is dead

6.1.2.2 Methods

• public enemy(String aName, int aHp, int aStr, int aDef, int aAr, int aPic, int exp, Item aItem)

o Create an enemy with given values

• public int getExp()

o get the exp reward amount

• public Item getItem()

o get the item reward

• public boolean isDead()

o determine if the enemy is dead

6.1.2.3 Instance Details

There will only be a single instance of Enemy at any given time.

6.1.3 Area

[pic]

Figure 6.1.3-1 – Area Class

6.1.3.1 Attributes

• int[][] locationGrid

o what the location contains (0 = illegal location, 1 = legal location, 2 = item, 3+ linked area's identification number(exit), negative = fog of war covered)

• Arraylist items

o possible items for this area

• Random rand

o randomizer to decide the item at the area

6.1.3.2 Methods

• public Area(int aMap)

o Create the area, reading locationgrid data from file specified by amap

• public int locationStatus(int x, int y)

o return the status of the location (0 = illegal location, 1 = legal location, 2 = item, 3+ next area's identification number)

• public Item getItem()

o returns a random item possible for this area

6.1.3.3 Instance Details

There will only be a single instance of Area at any given time.

6.1.3.4 Pseudo Code for getting an Item reward

generate random number up to the size of the ArrayList

find the item at that index in the ArrayList

return that item

6.1.4 Item

[pic]

Figure 6.1.4-1 – Item Class

6.1.4.1 Attributes

• String name

o The name of the item

• int pic

o The number representing the visual representation of the item

• int type

o The type of item (0 = consumable, 1 = weapon, 2 = armor, 3 = accessory)

6.1.4.2 Methods

• public item(String aName, int aType, int aPic)

o Create an item with given values

• public String getName()

o get the name of the item

• public int getPic()

o get the item’s picture

• public int getType()

o get the item’s type

6.1.5 Inventory

[pic]

Figure 6.1.5-1 – Inventory Class

6.1.5.1 Attributes

• Arraylist items

o The items in the inventory

• boolean key

o If the player has the room key

• boolean bossKey

o If the player has the boss key

• int tokens

o The number of life tokens held by the player

6.1.5.2 Methods

• public Inventory()

o Create an empty inventory

• public void addItem(Item aItem)

o Add an item to the inventory

• public boolean removeItem(Item aItem)

o Remove an item from the inventory (return 0 if failed)

• public void addKey()

o Add a key to the inventory

• public boolean useKey()

o Use the key in the inventory

• public void addBossKey()

o Add the boss key to the inventory

• public boolean useBossKey()

o Use the boss key in the inventory

• public void addToken()

o Add a life token to the inventory

• public void removeToken()

o remove a token from the inventory

• public int getTokens()

o get the number of tokens

• public int numItems()

o get the number of items held

• public Item getItem(int type)

o gets the item of a specific type

• public void save()

o Saves the current game to file

• public void load()

o Load a game from file

6.1.5.3 Instance Details

There will only be a single instance of Inventory at any given time.

6.1.6 Game

[pic]

Figure 6.1.6-1 – Game Class

6.1.6.1 Attributes

• Character char

o The player's character

• Area area

o The current area

• Random rand

o Random number generator (for encounter rate, etc)

• int encounter

o Used to determine if an encounter occurs upon movement

6.1.6.2 Methods

• public Game(Character aChar, Area aArea)

o Initialize the game

• public boolean move(int aDirection)

o Move in the direction (2 = down, 4 = left, 6 = right, 8 = up)

• public void useItem(Item aItem)

o Use the item

• public void addStat(int stat)

o Add 1 to the stat, if feasible (0 = maxhp, 1 = str, 2 = def, 3 = ar)

• public void remStat(int stat)

o Remove 1 from the stat, if feasible (0 = maxhp, 1 = str, 2 = def, 3 = ar)

• private void moveArea()

o Move to the next area

• public void save()

o Saves the current game to file

• public void load()

o Load a game from file

6.1.6.3 Instance Details

There will only be a single instance of Game at any given time.

6.1.6.4 Pseudo Code for Moving

Get the status of the destination location from area

if status is a legal area

move the character

decrement the encounter variable

if random number between 0 and encounter == 0

begin battle

reset encounter to initial value

if status is item location

add item to inventory

if status is a linked area identification number AND has a key

go to linked area

else

alert user they have no key

update fog of war status to surrounding squares

else

do nothing

6.1.7 Battle

[pic]

Figure 6.1.7-1 – Battle Class

6.1.7.1 Attributes

• Character char

o The character

• Enemy enemy

o The enemy

• int bg

o The numerical value of the background image

6.1.7.2 Methods

• public Battle(Character aChar, Enemy aEnemy, int aBG)

o Create a battle with the given values

• public void attack()

o attack the enemy

• public void berserk()

o berserk attack the enemy

• public void useItem(Item aItem)

o Use the item

• public boolean flee()

o flee from battle

• public void defendSelf()

o defend yourself

• public void defendPrincess()

o defend the princess

6.1.7.3 Instance Details

There will only be a single instance of Battle at any given time.

6.1.7.4 Pseudo Code for Battle

Calculate random number between 0 and 100

if random number < character attack rating

Calculate character's raw attack damage based on strength

Send raw damage to enemy

Calculate the inflicted damage based on defense

Remove that much hp from the enemy

if the enemy is not dead

Calculate random number between 0 and 100

if random number < enemy attack rating

Calculate enemy's raw attack damage based on strength

Send raw damage to character or princess (random choice)

Calculate the inflicted damage based on defense

Remove that much hp from the character

6.1.8 Entity

[pic]

Figure 6.1.8-1 – Entity Class

6.1.8.1 Attributes

• String name

o Name of character

• int pic

o chosen visual representation of entity

• int hp

o Remaining health points

• int maxHp

o Maximum amount of health points

• int str

o Influences damage done by entity

• int def

o Influences damage received by entity

• int ar

o Influences accuracy of attacks by entity

6.1.8.2 Methods

• public Entity(String aName, int aHp, int aStr, int aDef, int aAr, int aPic)

o Create an Entity with given values

• public String getName()

o get the name

• public int getPic()

o get the picture number

• public int getHp()

o get the remaining hp

• public int getMaxHp()

o get the maximum hp

• public int getStr()

o get the strength value

• public int getDef()

o get the defense value

• public int getAr()

o get the attack rating value

• public void getAttacked(int rawDamage)

o Remove hp from the entity

6.1.9 Equipment

[pic]

Figure 6.1.9-1 – Equipment Class

6.1.9.1 Attributes

• int strValue

o The attack value of the equipment

• int defValue

o The defense value of the equipment

• int arValue

o The attack rating value of the equipment

• int maxHpValue

o The maximum hp bonus value of the equipment

6.1.9.2 Methods

• public equipment(String aName, int aType, int aPic, int str, int def, int ar, int maxHp)

o Create a piece of equipment with the given values

• public int getStrValue()

o get the attack value of the equipment

• public int getDefValue()

o get the defense value of the equipment

• public int getArValue()

o get the attack rating value of the equipment

• public int getMaxHpValue()

o get the maximum hp bonus value of the equipment

6.1.10 Consumable

[pic]

Figure 6.1.10-1 – Consumable Class

6.1.10.1 Attributes

• int value

o The healing value of the item

6.1.10.2 Methods

• public Consumable(String aName, int aType, int aPic, int value)

o Create a consumable item with the given values

• public int getValue()

o get the value of the consumable

6.1.11 Princess

[pic]

Figure 6.1.11-1 – Princess Class

6.1.11.1 Methods

• public Princess(String aName, int aHp, int aStr, int aDef, int aAr, int aPic)

o Creates a princess with the given stats

• public void save()

o Saves the current game to file

• public void load()

o Load a game from file

6.2 User Interface Package

6.2.1 Title Screen

[pic]

Figure 6.2.1-1 – Title Screen

6.2.1.1 Attributes

• private JPanel mainPanel

o The main panel of the window

• private JButton newButton

o The new game button

• private JButton loadButton

o The load game button

• private JButton exitButton

o The quit game button

• private buttonListener listen

o The button listener for all buttons

6.2.1.2 Methods

• public void actionPerformed(ActionEvent e)

o Handles the actions caused by clicking a button

6.2.1.3 Instance Details

There will only be a single instance of Title Screen at any given time.

6.2.2 Character Creation

[pic]

Figure 6.2.2-1 – Character Creation

6.2.2.1 Attributes

• private JPanel mainPanel

o The main panel of the window

• private JTextField name

o The text field in which to enter the character's name

• private ButtonGroup difficult

o The group of buttons to select difficulty

• private JRadioButton easy

o The easy difficulty radio button

• private JRadioButton medium

o The medium difficulty radio button

• private JRadioButton hard

o The hard difficulty radio button

• private ButtonGroup picture

o The group of buttons to choose the character picture

• private JRadioButton pic1…x

o The radio button to choose the character picture

• private ImageIcon pic1…x

o The image icons to show the possible character pictures

• private JTextField strength

o The text field in which to enter the character's strength

• private JTextField defense

o The text field in which to enter the character's defense

• private JTextField attackRating

o The text field in which to enter the character's attack rating

• private JButton startGame

o The button to begin the game

• private JButton cancel

o The button to return to the title screen

6.2.2.2 Methods

• public void actionPerformed(ActionEvent e)

o Handles the actions caused by clicking a button

6.2.2.3 Instance Details

There will only be a single instance of Character Creation at any given time.

6.2.3 Movement Window

[pic]

Figure 6.2.3-1 – Movement Window

6.2.3.1 Attributes

• private JPanel containerPanel

o Holds the various panels that make up the window

• private JPanel mapPanel

o The panel that displays the map on which the character moves

• private JPanel statusPanel

o The panel that displays attributes, and allows the distribution of status points

• private JButton increaseStr

o Button that increases character's strength

• private JButton increaseDef

o Button that increases character's defence

• private JButton increaseAr

o Button that increases character's attack rating

• private JButton decreaseStr

o Button that decreases character's strength

• private JButton decreaseDef

o Button that decreases character's defence

• private JButton decreaseAr

o Button that decreases character's attack rating

• private JPanel inventoryPanel

o The panel that displays the contents of the inventory, and allows the usage of items

• private JButton halfPotion

o Button that uses a half potion (50% healed)

• private JButton fullPotion

o Button that uses a full potion (100% healed)

• private JPanel messagePanel

o The panel that displays messages to the user

• private JTextField messageField

o The text field in which to display messages to the user

6.2.3.2 Methods

• private JPanel createMapPanel()

o Create and return the map panel

• private JPanel createStatusPanel()

o Create and return the status panel

• private JPanel createInventoryPanel()

o Create and return the inventory panel

• private JPanel createMessageaPanel()

o Create and return the message panel

• private void keyTyped(KeyEvent e)

o Handles the actions caused by pressing a key

• public void actionPerformed(ActionEvent e)

o Handles the actions caused by clicking a button

6.2.3.3 Instance Details

There will only be a single instance of Movement Window at any given time.

6.2.4 Battle Window

[pic]

Figure 6.2.4-1 – Battle Window

6.2.4.1 Attributes

• private JPanel containerPanel

o Holds the various panels that make up the window

• private JPanel battlePanel

o The panel that shows the character and enemy engaged in battle

• private JPanel enemyPanel

o The panel to show the stats of the enemy

• private JPanel characterPanel

o The panel to show the stats of the character

• private JPanel princessPanel

o The panel to show the stats of the princess

• private JPanel messagePanel

o The panel to show the messages to the player

• privare JTextField messageField

o The text field in which to show messages to the player

• private JPanel commandPanel

o The panel with the command buttons to control the character

• private JButton attackButton

o The button to give the attack command

• private JButton berserkButton

o The button to give the berserk command

• private JButton halfPotionButton

o The button to give the use half potion command

• private JButton fullPotionButton

o The button to give the use full potion command

• private JButton defendButton

o The button to give the defend command

• private JButton fleeButton

o The button to give the flee command

• private JButton princessHalfPotionButton

o The button to have the princess use a half potion

• private JButton princessFullPotionButton

o The button to have the princess use a full potion

6.2.4.2 Methods

• private JPanel createBattlePanel()

o Create and return the battle panel

• private JPanel createEnemyPanel()

o Create and return the enemy panel

• private JPanel createCharacterPanel()

o Create and return the character panel

• private JPanel createPrincessPanel()

o Create and return the princess panel

• private JPanel createMessagePanel()

o Create and return the message panel

• private JPanel createCommandPanel()

o Create and return the command panel

• public void actionPerformed(ActionEvent e)

o Handles the actions caused by clicking a button

6.2.4.3 Instance Details

There will only be a single instance of Battle Window at any given time.

6.3 Class Diagrams

[pic]

Figure 6.3-1 – Module Decomposition

Software Test Documentation

T1. Introduction

This document describes the STD for Conan: Rescue the Princess. The categories of testing addressed in this document include unit, integration and system testing. This document lists the testing that will take place before the game is turned over to the customer to ensure that meets the customer’s requirements. IEEE standard 829-1983 will be used at each level of testing.

The objective of the STD is to detect bugs in the system and ensure they are corrected before turning the system over to the customer. It is essential to state that it is impossible for every bug to be found, as there are infinitely many possible combinations of input and actions that may result in an unwanted action by the system. This test documentation is intended to find bugs that based off a series of test cases. The allotted resources to the testing portion of this project govern the number of test cases and depth to which they are covered. Each phase of testing will be complete when all test cases described in this document are satisfied and result in no errors.

T1. Conan Video Game Test Documentation

This section describes the test planning, specification and reporting for the Conan game. There are separate plans for unit, integration, and system testing. Each test plan references its test design, test case and test procedure specifications.

T2.1 Unit Test STD

T2.1.1 Introduction

Conan is broken down into classes, which encapsulate common methods and attributes. These classes can be tested individually by using “Unit Tests” which tests the methods of each class. A unit test forces a set of actions on a class then tests that the output of a method matches the predetermined output value for that method.

T2.1.2 Unit Test Plan

T2.1.2.1 Scope

Each class in the domain layer of Conan will have an associated unit test class. These unit test classes will ensure that the domain classes are functioning properly and outputting the correct values. The classes in the user interface and data layer will not be tested using unit tests.

T2.1.2.2 Approach

The unit tests will be implemented in Java using the JUnit library. Each class will have an associated JUnit class that will test its methods. Multiple test cases will exist for the methods of domain classes. These different test cases will be used to test boundary cases which are the most likely to fail.

Each project build will be submitted to the quality assurance leader, Mike Mallinson, for the running of the unit tests. After the tests are complete the results will be returned to the lead developer, Richard Peters. The lead developer will be required to fix any problems encountered in the unit tests and continue development. Upon the next build, any failed unit tests will be retested along with the tests associated with the new build.

T2.1.2.3 Items Under Test

All classes in the domain layer will be tested. This document will only list the test cases for the Character, Equipment and Inventory however all classes will be tested. The methods of these classes will be tested using JUnit tests.

T2.1.2.4 Schedule and Personnel

|Personnel |Class |Build |Date |

|Mike Mallinson |Character |1.0 |March 20, 2007 |

|Mike Mallinson |Inventory |1.0 |March 20, 2007 |

|Mike Mallinson |Equipment |1.0 |March 20, 2007 |

T2.1.3 Unit Test Design

T2.1.3.1 Items

Items to be tested are listed below:

Procedure C1 – Character Initialization

Procedure C2 – Change Strength – Spending Stat Points

Procedure C3 – Change Strength – Not Spending Stat Points

Procedure C4 – Change Max HP – Spending Stat Points

Procedure C5 – Change Max HP – Not Spending Stat Points

Procedure C6 – Change Defense – Spending Stat Points

Procedure C7 – Change Defense – Not Spending Stat Points

Procedure C8 – Change Attack Rating – Spending Stat Points

Procedure C9 – Change Attack Rating – Not Spending Stat Points

Procedure C10 – Heal

Procedure C11 –Experience

Procedure C12 – Level Up

Procedure C13 – Grid Position

Procedure I1 – Inventory Initialization

Procedure I2 – Add Item

Procedure I3 – Remove Item

Procedure I4 – Keys

Procedure I5 – Boss Key

Procedure I6 – Add Token

Procedure I7 – Remove Token

Procedure E1 –Equipment Initialization

T2.1.3.2 Approach

The unit tests will be implemented in Java using the JUnit library. Each class will have an associated JUnit class that will test its methods. Multiple test cases will exist for the methods of domain classes. These different test cases will be used to test boundary cases which are the most likely to fail.

Each project build will be submitted to the quality assurance leader, Mike Mallinson, for the running of the unit tests. After the tests are complete the results will be returned to the lead developer, Richard Peters. The lead developer will be required to fix any problems encountered in the unit tests and continue development. Upon the next build, any failed unit tests will be retested along with the tests associated with the new build.

T2.1.3.3 Detailed Plan

The unit test cases have been chosen in order to test the system for defects. These cases are designed to find errors that a tester with no inside knowledge of the system might not consider. The official term for this is “White Box Testing” which is when the developers of the system generate tests that will catch the bugs with values near the extremes.

T2.1.4 Unit Test Cases

T2.1.4.1 Procedure C1 – Character Initialization

Class: Character

Purpose: Ensure that the character class is initialized properly as a subclass of Entity.

Preconditions: None

Input:

aName = “TestChar”

aHp = 100

aStr = 3

aDef = 3

aAr = 1

aPic = 1

Post-Conditions: Check that the character attributes match input parameters in the constructor. Also check that getinv() returns an inventory instance which contains zero items.

T2.1.4.2 Procedure C2 – Change Strength – Spending Stat Points

Class: Character

Purpose: Ensure that the strength is adjusted and stat points are used.

Preconditions: Character is initialized and has 5 unused stat points and 2 strength

Input: Call setstr(3, true)

Post-Conditions: Run the method getstatpoints() which should return 2. Run the method getstr() which should return 5.

T2.1.4.3 Procedure C3 – Change Strength – Not Spending Stat Points

Class: Character

Purpose: Ensure that the strength is adjusted and stat points are used.

Preconditions: Character is initialized and has 5 unused stat points and 2 strength

Input: Call setstr(3, false)

Post-Conditions: Run the method getstatpoints() which should return 5. Run the method getstr() which should return 5.

T2.1.4.4 Procedure C4 – Change Max HP – Spending Stat Points

Class: Character

Purpose: Ensure that the max HP is adjusted and stat points are used.

Preconditions: Character is initialized and has 5 unused stat points and 100 max HP.

Input: Call setmaxhp(105, true)

Post-Conditions: Run the method getstatpoints() which should return 0. Run the method getmaxhp() which should return 105.

T2.1.4.5 Procedure C5 – Change Max HP – Not Spending Stat Points

Class: Character

Purpose: Ensure that the max HP is adjusted and stat points are not used.

Preconditions: Character is initialized and has 5 unused stat points and 100 max HP.

Input: Call setmaxhp(105, false)

Post-Conditions: Run the method getstatpoints() which should return 5. Run the method getmaxhp() which should return 105.

T2.1.4.6 Procedure C6 – Change Defense – Spending Stat Points

Class: Character

Purpose: Ensure that the defense is adjusted and stat points are used.

Preconditions: Character is initialized and has 5 unused stat points and 10 defense.

Input: Call setdef(15, true)

Post-Conditions: Run the method getstatpoints() which should return 0. Run the method getdef() which should return 15.

T2.1.4.7 Procedure C7 – Change Defense – Not Spending Stat Points

Class: Character

Purpose: Ensure that the defense is adjusted and stat points are not used.

Preconditions: Character is initialized and has 5 unused stat points and 10 defense.

Input: Call setdef(15, false)

Post-Conditions: Run the method getstatpoints() which should return 5. Run the method getdef() which should return 15.

T2.1.4.8 Procedure C8 – Change Attack Rating – Spending Stat Points

Class: Character

Purpose: Ensure that the attack rating is adjusted and stat points are used.

Preconditions: Character is initialized and has 5 unused stat points and 10 attack rating.

Input: Call setar(15, true)

Post-Conditions: Run the method getstatpoints() which should return 0. Run the method getar() which should return 15.

T2.1.4.9 Procedure C9 – Change Attack Rating – Not Spending Stat Points

Class: Character

Purpose: Ensure that the attack rating is adjusted and stat points are not used.

Preconditions: Character is initialized and has 5 unused stat points and 10 attack rating.

Input: Call setar(15, false)

Post-Conditions: Run the method getstatpoints() which should return 5. Run the method getar() which should return 15.

T2.1.4.10 Procedure C10 – Heal

Class: Character

Purpose: Ensure that the attack rating is adjusted and stat points are not used.

Preconditions: Character is initialized and has 10 HP out of 100

Input: Call gethealed(15)

Post-Conditions: Run the method gethp() which should return 25.

T2.1.4.11 Procedure C11 –Experience

Class: Character

Purpose: Ensure that the experience is adjusted properly.

Preconditions: Character is initialized and has 135 experience points.

Input: Call addexp(11)

Post-Conditions: Run the method getexp() which should return 146.

T2.1.4.12 Procedure C12 – Level Up

Class: Character

Purpose: Ensure that the attack rating is adjusted and stat points are not used.

Preconditions: Character is initialized and has 10 status points and is level 1.

Input: Call levelup()

Post-Conditions: Run the method getstatpoints() which should return a number larger than 10. Call getlevel which should return 2.

T2.1.4.13 Procedure C13 – Grid Position

Class: Character

Purpose: Ensure that the position of the character in the map is updated.

Preconditions: Character is initialized and is location (2,5)

Input: Call setX(3) and setY(6)

Post-Conditions: Run the method getX() which should return 3 and getY() which should return 6.

T2.1.4.14 Procedure I1 – Inventory Initialization

Class: Inventory

Purpose: Ensure that the inventory class is initialized properly.

Preconditions: None

Input: None

Post-Conditions: Run the method numitems() which should return zero

T2.1.4.15 Procedure I2 – Add Item

Class: Inventory

Purpose: Ensure that items are added to the inventory properly

Preconditions: Inventory has been initialized and contains no items. An item

aItem has been created of the type 2 and is ready to be added to the inventory.

Input: Call method additem() with the input parameter aItem.

Post-Conditions: Run the method numitems() which should return 1. Call method getitem with a parameter of 2 which should return the added item.

T2.1.4.16 Procedure I3 – Remove Item

Class: Inventory

Purpose: Ensure that items are removed from the inventory properly

Preconditions: Inventory has been initialized and contains one item aItem.

Input: Call method removeitem() with the input parameter aItem.

Post-Conditions: Run the method numitems() which should return 0.

T2.1.4.17 Procedure I4 – Keys

Class: Inventory

Purpose: Ensure that keys are added and used properly

Preconditions: Inventory has been initialized.

Input: Call method addkey().

Post-Conditions: Run the method usekey() which should return true.

T2.1.4.18 Procedure I5 – Boss Key

Class: Inventory

Purpose: Ensure that the boss key is used properly

Preconditions: Inventory has been initialized.

Input: Call method addbosskey().

Post-Conditions: Run the method usebosskey() which should return true.

T2.1.4.19 Procedure I6 – Add Token

Class: Inventory

Purpose: Ensure that items life tokens are added properly.

Preconditions: Inventory has been initialized.

Input: Call method addtoken().

Post-Conditions: Run the method gettokens() which should return 1.

T2.1.4.20 Procedure I7 – Remove Token

Class: Inventory

Purpose: Ensure that items life tokens are removed properly.

Preconditions: Inventory has been initialized.

Input: Call method addtoken() then removetoken().

Post-Conditions: Run the method gettokens() which should return 0.

T2.1.4.21 Procedure E1 –Equipment Initialization

Class: Equipment

Purpose: Ensure that equipment items are being created properly as a subclass of item. The attributes of the equipment class should be initialized to the values of the constructor. This will also test the “getter” methods for the class. The equipment class doesn’t have any special methods which do any calculations so this will be the only test for this class.

Preconditions: None

Input:

aName = “Starter Sword”

aType = 1

aPic = 1

str = 1

def = 0

ar = 1

maxhp = 0

Post-Conditions: The class attributes should match the input values.

T2.1.5 Unit Test Procedures

The current build should be imported into Eclipse, the IDE we’ll be using to implement the project, to run the test cases. The tester should select the associated JUnit test class and click run. The results of the tests will be shown on the left portion of the screen. The tester should note the results of the test in the proper test results form.

T2.2 Integration Test STD

T2.2.1 Introduction

During the process of developing Conan, the game will go through a series of builds. Progressively with each build more classes will be complete and integrated into the game. The test plan for the initial two builds have been described.

T2.2.2 Build 1

T2.2.2.1 Test Plan

T2.2.2.1.1 Scope

This build will consist of the domain layer of Conan. The tests will be used to verify that subclasses are created successfully and are interacting properly.

T2.2.2.1.2 Approach

This build should be tested using the unit tests described in the Unit Test section.

T2.2.2.1.3 Items

The methods for each class of the domain layer should be tested.

T2.2.2.1.4 Schedule and Personnel

This testing for this build should be completed by Mike Mallinson after March 20th when this build is completed.

T2.2.2.2 Test Design

T2.2.2.2.1 Items

The items to be tested in this section include all classes from the domain layer.

T2.2.2.2.2 Approach

The tests in this section are designed to test the interaction between classes and their inner workings. The domain layer should be thoroughly tested before proceeding to develop the other layers so a sound foundation has been established.

T2.2.2.3 Test Cases

See Section 2.1.4, Unit Test Cases, for the test cases to be executed.

T2.2.2.4 Test Procedures

The test results from this section should be executed and returned to the lead developer for review.

T2.2.3 Build 2

T2.2.3.1 Test Plan

T2.2.3.1.1 Scope

The scope of this build will include the user interface layer and the domain layer. Any problems encountered in the previous build will be retested in this build.

T2.2.3.1.2 Approach

The importance of this build focuses on the user interface layer so the different windows will be tested.

T2.2.3.1.3 Items

The items to be tested should include each window that is displayed to the user.

T2.2.3.1.4 Schedule and Personnel

The tests for build 2 will be completed by Mike Mallinson after March 22, 2007 when this build is scheduled for completion.

T2.2.3.2 Test Design

T2.2.3.2.1 Items

This build will test that the user interfaces are working properly and updating the domain classes when necessary.

T2.2.3.2.2 Approach

The tests for this section will be carried out by running the application and using the user interface.

T2.2.3.3 Test Cases

T2.2.3.3.1 Case 1 - Usability

Ensure that the buttons are easily accessible and are grouped in a logical order. These should be easy for the user to distinguish which buttons belong to each panel and what these buttons will do. Usability tests are difficult to specify how the results should be specified. With this in mind, the test should be performed from a users point of view or have someone with no prior knowledge of the interface test it.

T2.2.3.3.2 Case 2 – Button Handlers

Ensure that all button perform the expected action associated. This should be conducted by attempting to play the game and verifying that the action after pressing a button has occurred.

T2.2.3.3.3 Case 3 – Window Switching

Verify that the windows are switching properly. This includes switching to the map view after creating a character and switching to and from battle mode. These should flow smoothly and not have any “hiccups”.

T2.2.3.4 Test Procedures

These tests should be performed as if it was a user playing the game. Inside knowledge of the system should be put aside so that the user interface is viewed from a newcomer to the game.

T2.3 System Test STD

T2.3.1 Introduction

The system tests are designed to verify that the system architecture has been implemented correctly. This should validate that the user interface layer is properly interacting with the domain layer and that the domain layer is properly interacting with the data layer. The completion of these tests will ensure that the system is functioning properly as described in the model decomposition of the design document.

T2.3.2 Test Plan

T2.3.2.1 Scope

The scope of this test plan covers the interaction between the layers of the model decomposition.

T2.3.2.2 Approach

Upon completion of implementing the requirements these tests will be performed to determine problems within the module layers. If problems are found they will be sent to development for correction. After correction these tests will be performed again to ensure that the problem was indeed corrected and that no additional problems were introduced.

T2.3.2.3 Items

The items to be tested should show that the system is functioning properly. This should include cases that involve multiple windows, interaction from the user layer progressing down to the data layer through the domain layer and other cases which may produce problems.

T2.3.2.4 Schedule and Personnel

These tests will be performed at the end of the development cycle to find problems within the module layers. Mike Mallinson, the quality assurance lead, will perform these tests are report them to Richard Peters, the development lead.

T2.3.3 Test Design

T2.3.3.1 Items

Items to be tested include:

• Game saving

• Game loading

• Character creation

• Movement of character between rooms.

• The changing between the map and the battle windows.

T2.3.3.2 Approach

Upon completion of implementing the requirements these tests will be performed to determine problems within the module layers. If problems are found they will be sent to development for correction. After correction these tests will be performed again to ensure that the problem was indeed corrected and that no additional problems were introduced.

T2.3.3.3 Detailed Plan

The system test cases have been chosen in order to test the system for defects. These cases are designed to find errors in the system from a user perspective. These include performing tasks that a user would encounter while playing the game.

T2.3.4 Test Cases

T2.3.4.1 Case 1 – Location Changing

Step 1 – Move character from Room A to Room B.

Step 2 – Move character from Room B to Room A.

Step 3 – Move character from Room A to Room B.

T2.3.4.2 Case 2 – Clearing Enemies

Step 1 – Kill all enemies in Room A.

Step 2 – Move character to Room B.

Step 3 – Return to Room A.

Step 4 – Move around Room A. No battles should be encountered.

T2.3.4.3 Case 3 – Save/Load Game

Step 1 – Start a new game.

Step 2 – Create character.

Step 3 – Save the current game.

Step 4 – Close game.

Step 5 – Open game.

Step 6 – Load the saved game.

Step 7 – Verify that attributes and character location has been maintained.

T2.3.4.4 Case 4 – Changing Map and Battle Windows

Step 1 – Move around a room until a battle is started.

Step 2 – Defeat the enemy.

Step 3 – Experience and item may be gained.

Step 4 – The map window should be shown.

Step 5 – Repeat steps 1-4 once more.

T2.3.5 Test Procedures

Tests should be systematically performed according to the specifications of the test cases. The results noted without prejudice exactly as they occur. If a problem exists or something unexpected occurs during the test it should be written down and returned to the development team.

T2.4 Conclusion

All tests are to be completed fully and the results documented. The code will be at a standstill while testing is being completed. While a lot of testing will be done for this project there is no guarantee that it will be bug free. In conjunction with the tests described, we will be taking a walk through of the code in attempts to find bugs that may not show in our tests.

Appendix A: Sample Test Form

|Test Number: | |

|Class: | |

|Tester Name: | |

|Test Date: | |

|Build Number: | |

|Purpose: | |

| | |

|Preconditions: | |

| | |

|Input: | |

| | |

|Post-Conditions: | |

| | |

|Successful? | |

|Comments: | |

| | |

| | |

|Signature: | |

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download