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.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related download
- pokemon omega ruby and alpha sapphire extreme
- pokemon white randomizer nuzlocke download rom
- pokemon black randomizer rom android
- bfb oc maker latest update 41 sec ago
- chapter 1 character creation
- music curriculum frameworks ca dept of education
- filename extensions
- final report
- introduction
- appendices for the evogrid an approach to computational
Related searches
- activity 1 3 3 thermodynamics answer key
- activity 1.3.3 thermodynamics answer key
- act 1 3 3 thermodynamics answer key
- 3 3 t score bone density
- 3 by 3 linear system calculator
- 3 by 3 matrix solver
- 3 by 3 system solver
- 3 by 3 system calculator
- 3 equation 3 unknown solver
- 3 x 3 equation solver
- solving 3 x 3 linear systems calculator
- 3 3 repeating as a fraction