daimihenrik bærbak christensen1 mandatory project software reliability and testing

DAIMI Henrik Bærbak Christensen 1

Mandatory Project

Software Reliability and Testing


Aim

To use techniques from the course to– implement a reliable software system– assess system qualities, notably reliability

This entails– test case definition using BB and WB techniques– tactics to make the system testable

– integration testing and test planning

– using review techniques


Context

SRaT World– A simple Role Playing Game (RPG)

• inspired by my kid’s pass time: Diablo II and Titan Quest

– Architectural driver• customizability to support building new RPG’s • modularity to support parallel development


Customizable property

We require that our RPG is highly customizable. For instance it should be able to model both– Diablo II:

• “Barbarian slay beastmen on the cold plains wearing the FrostBite axe and Holy Shield and gain experience points and a level.”

– The EVU Student Trial• “Diploma student solves mandatory exercise 1 in SRaT using

BlackBox testing and gain intelligence. Next he attacks the SRaT oral exam, wins, and has solved the first quest.”


Why?

Why does this make a reasonable project? Because

– Set of relatively isolated modules• all groups do not solve same assignment• thus: realistic integration testing scenario• thus: force you to implement stubs / testability tactics

– Each module/task is relatively small• implementation burden not too big• complexity not overwhelming for using BB and WB

– on the other hand they are larger than System.abs

– Review of other groups’ work that have solved similar modules


What is a RPG?

A Hero– explores worlds– slash enemies– pick up items

• weapons/armour• life potions• gold

– grows stronger• healthier• stronger• more intelligent• learns skills

– trades• gold and items

– solves quests• get rid of “bosses” to go to next quest

Demo: http://www.blizzard.com/diablo2/demo.shtml


Architectural considerations

Our focus will be on the domain production code– we work in parallel with the GUI team but they are

slow

– to develop we aim at two interfaces• a keystroke driven one

– to play around, exploratory testing, debug

• JUnit driven: systematic testing and reliability estimation

– we ignore real-time game play and prototype it using a turn based approach


The worlds (area)

The areas are simply a matrices of tiles (of various types)

Areas are connected by portals – entering a portal and you a instantly teleported to another area...

row = 0

col = 3

item (sword)

portal

hero

nasty enemy


Key-stroke based interface

Vision:– we give commands to our hero using 1-2(-3?)

keystrokes

Use-case 1

– “a9”: attack enemy at NorthEast tile– “p3”: pickup item at SouthEast tile

“m9”: move NorthEast


Inventory and worn items

A hero wears and carries things that he finds– “ic”: display items carried (inventory)

– “iw”: display items worn

– “w1”: wear item #1 from inventory• (items know that they can be worn, and where they are worn)

– “u2”: use item #2 from inventory• (items know they can be used)

1: bronze-sword2: health-potion3: small-shield

head: (none)weapon-hand: heavy-swordshield-hand: (none)torso: small-armourlegs: (none)


Trading

At some tiles (at a trader) you may sell items for gold or buy new items using your gold– “it”: display inventory of trader

– “b1”: buy item #1 from trader inventory (if enough gold)

– “s3”: sell item #3 from my inventory for gold

1: battle-axe2: health-potion3: frostbite-sword


Items and attributes

Our hero has attributes– primary

• health, dexterity (behændighed), strength, ...– health = 0 => you die and game over...

• level and experience points• gold (cash carried)

– items also have attributes• weapons: the damage they can inflict• requirements: what level, strength, dexterity, etc, is required

to wear this weapon/armour?• “+”: wearing/carrying certain items boost your dexterity,

strength, attack ability, etc.• use: using a health-potion increases your health


Complex item attributes

In Diablo II item attributes can be rather complex Deadly sceptre of flame

– damage: 7-13– required strength: 25– required level: 3– +22% enhanced damage– 1-5 fire damage– +2 prayer (paladin only)– +50% damage to undead


The central tale

RPGs are about violently slashing your enemies in an orgy of blood...– (proper entertainment for a 9 year old, sigh...)

Attacking:– chance of hitting (hero)– chance of blocking (enemy)– damage by hit enemy “health” decrease– hero attribute “experience-point” increase

• experience-point > next-level-threshold level++

Quests– Slaying the quest’s “boss” and you go on to the next...


Architecture


Architecture and Design

How do we make such a system?

Well – it seems really object oriented...

We can point on numerous objects with attributes and actions...

However, the challenge was to cover all possible RPGs: “Diablo II” and “EVU Student at Aarhus”


Approach 1

The standard OO modelling paradigm however fails...

class Paladin implements Actor public int dexterity() { return dex; } ... }

Why?


The customizable property

The above model seems awkward at best for modelling the “EVU Student Trial” RPG...

We need an architecture that is much more flexible and define abstractions at a more abstract level.


Buschmann: Reflection pattern

The answer is the Reflection pattern (Posa 1 book): Meta modelling = a model of a model

Architecture consists of two levels: – Base and Meta

Base contains only central abstractions– actor, events, items, game loop (model of model)

Meta contains all specifics– attribute sets– events as attribute manipulations and interpretation– = the model itself


Base level

The base level defines concrete data storage classes with minimal interpretation of variables.

All variables are kept in java.util.Map:– (String, value) pairs like (“health”, 84);

Advantage:– Attribute set is open-ended and can be defined at will

by meta level• actor.getAttributes().putInt(“dexterity”,12);

Disadvantage:– No compile time checking! – ... we have to rely on – well – testing!


Code Example: Base Level


Meta Level

The Meta Level can populate abstractions by reading configuration files.


Base Level

Events express dynamics Define an Event interface whose execute

method takes all possible parameters

Implementing classes can by dynamically loaded by the class loader and identified by their name


Event: Base


Meta

The main game loop receives key-stroke that must be translated into events– “a9” = invoke ‘triggeredExecute’ on instance of

AttackEvent.

Define an “EventBinding” translator– (“a”,AttackEvent.class)

– dynamic class loading

:Game

keyEvent

:EventBinding

getAssociatedEvent

lookup

event

event:Event

triggeredExecute

manipulate actors, areas, items, etc.


Roles: Actor

Actor (animate object)– has attributes

• health, dexterity, skills, experience ...

– has inventory• items picked up but not in use

– wears items• weapons in hands, helmet, armour

– has location in area– may perform events

Example: Hero, all the different types of enemies

Object

Actor


Role: Area

Area– n*m matrix of tiles

Example: “The Wastelands”

Tile– (knows image file)– has attributes: passable/impassable– has 0-1 Object– has 0-1 Event

Example: a wall tile (impassable), a grass tile with a weapon item, a portal with a “portal” event.

Area

Tile

n*m


Role: Item

Item (inanimate object)– has attributes

• semantics is defined by events

Example: – rusty axe with attack strength 2-4

• interpretation defined by attack event

– a shield with defence +10%• interpretation defined by attack event

– life potion with 100% health• interpretation defined by use event

– dexterity charm with +2 dexterity• interpretation defined by attack event (and possibly others)

Object

Item


Role: Event

Event:– defines a state change on actors and/or area

Example:– attack event reduce health of defender and increase experience

of attacker– portal event relocate actor at new position in new area– move event (may) relocate actor at new position in same area

(unless new position is impassable)– use event removes item from inventory and increase actor

attributes (potion -> health)– pick up event removes item from tile and adds it to actor

inventory– wear event removes an item from inventory and adds it to actor

wear list (weapon in hand, etc.)


Event subtypes

TriggeredEvent:– an event triggered by user action

Example: – User presses ‘a9’ -> hero attacks

enemy NorthEast of him

AutomaticEvent:– an event triggered by game loop

Example:– an enemy automatically execute “attack event” when

the hero is-near. “is-near” = within one tile radius.


Status

A draft specification will be prepared for Wednesday 7th and published on the web– Will include partial implementation of base layer

• all interfaces + attribute map code

– Example “game specification files”– Learning tests to kickstart


Status

The spec will be flawed!

Use your testing techniques to discover the ambiguities and defects in the spec !

Report them on the discussion forum (AULA)

Read the forum + web site regularly to adjust to specification revisions.

daimihenrik bærbak christensen1 mandatory project software reliability and testing

Documents

henrik brbak christensenwhy

systematic testing

exploratory testing

blackbox testing

new items

pickup item

wear item

items wornw1