26. November 1999Treffen der GI Fachgruppe 2.1.6 RQ

Zusammenwirken von Anforderungenund Test auf der Basis von Use Cases

1

Zusammenwirken vonAnforderungen und Test auf

der Basis von Use Cases

Johannes RYSER Martin GLINZ

Institut f�r Informatik, Universit�t Z�rich

{ryser, glinz}@ifi.unizh.ch

Die SCENT-Methode: SzenarienbasierteValidierung und Test von Software Systemen

26. November 1999Treffen der GI Fachgruppe 2.1.6 RQ

Zusammenwirken von Anforderungenund Test auf der Basis von Use Cases

2

Übersicht

• Motivation• Anforderungserhebung, … als Problem, Lösungsansätze• Testen, Testen als Problem, Lösungsansätze• Der in SCENT gewählte Ansatz

– Szenarienbasiert– Statecharts, systematische Testfallherleitung

• Die drei Hauptteile der SCENT-Methode– Erstellen von Szenarien– Formalisieren von Szenarien/ Zusätzliche Informationen

festhalten– Testfall-Herleitung

• Schlussbemerkungen

26. Novem

ber 1999

Treffen de

r GI F

achgruppe 2.1.6 R

QZ

usamm

enw

irken von Anfo

rderungenund T

est auf der B

asis von U

se Cases

3

Motivation

•E

ntsprechung von Anforderungsanalyse und

System

test–

Benutzerfokus, B

lack-Box-S

icht–

Analysedokum

ente, Spezifikation als G

rundlage fürS

ystemtest

–F

ehler in der Anforderungsanalyse w

erden oft erst inden S

ystem- und A

bnahmetests gefunden

•P

robleme A

nforderungsanalyse und System

test•

Schere der F

ehlerkostenð

Idee: Synergien zw

ischen den genanntenT

ätigkeiten nutzen!

26. Novem

ber 1999

Treffen de

r GI F

achgruppe 2.1.6 R

QZ

usamm

enw

irken von Anfo

rderungenund T

est auf der B

asis von U

se Cases

4

Anforderungsanalyse als P

roblem

•W

issen/Erkennen, w

as der Benutzer w

ill–

Anforderungen auf-, entdecken, herausholen

–W

eiss der Benutzer, w

as sie/er will

–W

ie vorgehen? System

atik

•W

echsel in, Evolution von A

nforderungen•

Dokum

entieren von Anforderungen

–W

ie? Was? W

ieviel? Quellen, B

egründungen, …–

Traceability, R

eferenzierbarkeit

ðE

xterne Verhaltensspezifikation des S

ystems

26. Novem

ber 1999

Treffen de

r GI F

achgruppe 2.1.6 R

QZ

usamm

enw

irken von Anfo

rderungenund T

est auf der B

asis von U

se Cases

5

Mögliche Lösungsstrategien

•B

enutzermiteinbezug, skandinavische S

chule–

JAD

& P

articipatory Design, user involv. In design

–G

ruppenbasierte Ansätze

•V

erbesserte Kom

munikation

•S

zenarienansätze–

Anw

endungsfälle (Use cases)

–F

ormalere V

orgehen (MS

Cs, F

iresmith)

•Iteratives, zyklisches V

orgehen, Wachstum

s-m

odelle, inkrementelle E

ntwicklungsm

ethoden

26. Novem

ber 1999

Treffen de

r GI F

achgruppe 2.1.6 R

QZ

usamm

enw

irken von Anfo

rderungenund T

est auf der B

asis von U

se Cases

6

Testen als P

roblem

•T

esten ist oft ein ungeplanter ad hoc P

rozess

–K

nappe Ressourcenzuteilung (Z

eit, Mittel)

–K

ein Testplan, keine T

estdokumentation

–U

nstrukturierte, unsystematische T

estfallherleitung

•T

esten ist eine mühsam

e, fehlerträchtige Tätigkeit

•F

ehlende Werkzeugun

terstützung–

Spezielle T

est- oder formale S

prachen, nur auf beschränkteP

robleme oder in spezifischen D

omänen anw

endbar–

Autom

atisierte(s) Testen/T

estfallherleitung nicht allgemein

möglich/einsetzbar

•F

ehlende Methoden

, mangelndes P

roblembe

wusstsein

26. Novem

ber 1999

Treffen de

r GI F

achgruppe 2.1.6 R

QZ

usamm

enw

irken von Anfo

rderungenund T

est auf der B

asis von U

se Cases

7

Mögliche Lösungen

•V

erbesserte Methode

n und Prozesse

–M

ethoden•

Müssen einfach anw

endbar sein•

Gut integrierbar m

it bestehenden Entw

icklungsmethoden

•D

ürfen / sollen keinen übermässigen A

ufwand / überhöhte

Kosten fordern

–T

estplanung, Testvorbereitung und T

estdokumentation (it

has to be done, just do it)–

System

atische, m

ethodische Testfallherleitung

•V

erbesserte (formale?) S

prachen, W

erkzeugunterstützung

•Integration

von Testaktivitäten, frühzeitige

Testfallher-

leitung und Wiedergebrauch

von SW

-Artefakten

26. Novem

ber 1999

Treffen de

r GI F

achgruppe 2.1.6 R

QZ

usamm

enw

irken von Anfo

rderungenund T

est auf der B

asis von U

se Cases

8

Die S

CE

NT

-Methode: K

onzepte

•S

CE

NT

:A

method for S

CE

Nario-based

validation and Test of softw

are•

Szenarienbasiert

–B

enutzersicht, black-box view–

Miteinbezug des B

enutzers im R

E-P

rozess–

Verbesserte K

omm

unikation zwischen ‚S

takeholders‘–

Keine spezielle S

prache, keine neue Notation

–A

nforderungserhebung, -dokumentation und -bündelung

–H

ilft dem E

ntwickler das V

okabular / die Term

inologieder A

pplikationsdomäne zu erw

erben

26. Novem

ber 1999

Treffen de

r GI F

achgruppe 2.1.6 R

QZ

usamm

enw

irken von Anfo

rderungenund T

est auf der B

asis von U

se Cases

9

Definition des S

zenarienbegriffs

•S

cenario – An ordered set of inte

ractions between

partners, usually betwe

en a system and a set of actors

external to the system. M

ay comprise a concrete

sequence of interaction steps (instance scenario) or a

set of possible interaction steps (type scenario).

•U

se case – A sequence of in

teractions between an

actor (or actors) and a system triggered by a spe

cificactor, w

hich produces a result for an actor. A type

scenario.•

Actor – A

role played by a user or an external systeminter-acting w

ith the system to be specified

26. Novem

ber 1999

Treffen de

r GI F

achgruppe 2.1.6 R

QZ

usamm

enw

irken von Anfo

rderungenund T

est auf der B

asis von U

se Cases

10

Die S

CE

NT

-Methode: K

onzepte

•V

alidierung–

Review

s und Form

alisierung der S

zenarien

•P

raxisorientiert–

Schrittvorgehen

–‚W

iederverwertung‘ von (A

nalyse) S

zenarien–

Keine form

ale Sprache

–V

orteile rechtfertigen zusätzlichen A

ufwand

•S

ystematische T

estfallherleitung•

Einfache Integration m

it bestehenden Softw

are -E

ntwicklungsm

ethoden

26. Novem

ber 1999

Treffen de

r GI F

achgruppe 2.1.6 R

QZ

usamm

enw

irken von Anfo

rderungenund T

est auf der B

asis von U

se Cases

11

Die S

CE

NT

-Methode: U

msetzung

•G

ebrauch von Szenarien in A

nalyse und im T

est–

Natürlichsprachliche S

zenarien um A

nforderungen zuerheben und zu dokum

entieren–

‚formalisierte‘ S

zenarien (= S

tatecharts) um system

atischT

estfälle für den System

test herzuleiten

ðW

iedergebrauch von Artefakten der frühen S

W-

Entw

icklungsphasenð

Integration mit existierenden E

ntwicklungsm

ethodenð

Problem

e natürlichsprachlicher Spezifikation w

erdendurch die S

zenarienformalisierung abgeschw

ächtð

(fortlaufende) Validierung des S

ystems

26. Novem

ber 1999

Treffen de

r GI F

achgruppe 2.1.6 R

QZ

usamm

enw

irken von Anfo

rderungenund T

est auf der B

asis von U

se Cases

12

Die S

CE

NT

-Methode: U

msetzung

•S

tatecharts/Szenarien w

erden mit A

nmerkungen zur

Testfallherleitung versehen

–V

or- und Nachbedingungen (P

re-/Postconditions)

–D

atenbereiche, Datenw

erte, erwartete R

esultate–

Leistungs- und nicht-funktionale Anforderungen

•K

onkrete Testfälle w

erden bestimm

t, indem P

fade(K

riterium!) in den S

tatecharts durchschritten werden

ðV

erbesserte Verhalten

sspezifikation des Syste

ms

ðS

ystematisches V

orgehen um

Testfälle herzuleite

n

ðD

okumentation der T

estfälle

26. Novem

ber 1999

Treffen de

r GI F

achgruppe 2.1.6 R

QZ

usamm

enw

irken von Anfo

rderungenund T

est auf der B

asis von U

se Cases

13

Der S

zenarienerstellungsprozess

•S

chrittvorgehen zur Szenarienerzeugung

–A

kteure identifizieren, (äussere) Ereignisse, E

in- & A

us-gabe und R

esultate–

System

grenzen festlegen–

Grobe S

zenarien auf Geschäftsprozess-E

bene erstellen–

Szenarienpriorisierung, -verfeinerung, Ü

bersichtsdiagramm

und Dependency C

harts, Modellieren von A

lternativen undB

ehandlung von Ausnahm

en–

Ausfaktorisieren abstrakter S

zenarien, Miteinbeziehen von

nicht-funktionalen und Leistungsanforderungen–

Benutzer review

en und validieren Szenarien

•S

zenarienvorlage (Layout, Struktur, F

ormate)

26. Novem

ber 1999

Treffen de

r GI F

achgruppe 2.1.6 R

QZ

usamm

enw

irken von Anfo

rderungenund T

est auf der B

asis von U

se Cases

14

Beispiel zur S

zenarienerstellungB

eschreibung:A

n einem G

eldautomaten kann der B

enutzer den Kontostand abfragen oder

Geld bis zu einer bestim

mten B

ezugsgrenze/Limite und in gegebener S

tücke-lung beziehen. D

er Benutzer braucht eine K

arte und eine persönliche Identifi-ka

tion

snu

mm

er (P

IN), u

m Z

ug

riff zum

Syste

m zu

erh

alte

n u

nd

die

erw

äh

nte

nT

ransaktionen durchführen zu können. Das S

ystem kom

muniziert m

it einemzentralen B

anksystem, um

benötigte Benutzer- und K

ontoinformationen zu

erhalten und um den K

ontostand zu erfragen und zu verändern.

Akteure: ”K

un

de”,”S

ervice

pe

rson

al”,”O

pe

rate

ur”, ”B

an

ksystem”

Ereignisse: K

un

de

gib

t Ka

rte e

in, gib

t PIN

ein, w

äh

lt ein

e A

ktion, g

ibt B

etra

g e

in,n

imm

t die

Ka

rte zu

rück, n

imm

t da

s Ba

rge

ld; Op

era

teu

r füllt No

ten

na

ch; Service

-p

erso

na

l wa

rtet d

en

Ge

lda

uto

ma

ten

Systemeingaben: K

arte

n, PIN

s, Au

swa

hl (d

er T

A), B

eträ

ge, N

ote

n

System

ausgaben/Resultate:

Ka

rten, K

on

tosta

nd

info

rma

tion

en, G

eld

Szenarios: (1)K

on

tosta

nd

, (2)Ba

rge

ld b

ezie

he

n, (3)A

TM

wa

rten

, (4)No

ten

na

chfü

llen

26. Novem

ber 1999

Treffen de

r GI F

achgruppe 2.1.6 R

QZ

usamm

enw

irken von Anfo

rderungenund T

est auf der B

asis von U

se Cases

15

Auszüge aus einem

Szenario

Szenario 2: Bargeld beziehen (A

kteur: Kunde)

Der K

unde (mit K

arte & PIN

) bezieht Geld am

Autom

aten

Ablauf:

1.Der K

unde gibt die Karte ein

2.Das System

pr�ft die G�ltigkeit der K

arte3.D

as System zeigt den ãB

itte PIN eingebenÒ D

ialog4.D

er Kunde gibt die pers�nliche Identifikationsnum

mer ein

5.Das System

pr�ft die pers�nliche Identifikationsnumm

er6.D

as System zeigt ...

Alternative A

bl�ufe:1a. D

er Kartenschacht ist verstopft

1a.1 Der K

unde informiert ...

1a.2 ...

26. Novem

ber 1999

Treffen de

r GI F

achgruppe 2.1.6 R

QZ

usamm

enw

irken von Anfo

rderungenund T

est auf der B

asis von U

se Cases

16

Problem

e mit natürlichsprachlichen S

zenarien

•W

ie kann auf–

Unstim

migkeiten, Inconsistencies

–U

nvollständigkeit, Auslassungen

–M

ehrdeutigkeit, Missverständlichkeit

geprüft werden?

ðR

eviews, W

alkthroughsð

Form

alisieren der Szenarien

In SC

EN

T nehm

en wir einen M

ittelweg: N

icht vollständigeF

ormalisierung, sondern T

ransformation von natürlich-

sprachlichen Szenarien in eine teilform

ale graphischeR

epräsentation ð S

tatecharts

26. Novem

ber 1999

Treffen de

r GI F

achgruppe 2.1.6 R

QZ

usamm

enw

irken von Anfo

rderungenund T

est auf der B

asis von U

se Cases

17

Form

alisierung von Szenarien

•T

ransformation natürlichsprachlicher S

zenarien inS

tatecharts

•D

ie Transform

ation selbst ist nicht formalisiert, w

irdaber durch H

euristiken unterstützt–

Ein S

zenario plus alle seine Alternativabläufe =

ein Statechart

–S

tatecharts werden m

it den Szenarien erstellt und verfeinert

–Z

uerst den Norm

alablauf modellieren, später A

lternativabläufeintegrieren. P

rüfen, ob Alternativen fehlen

–E

reignisse auf Transitionen, einzelne A

rbeitsschritte inS

zenarien entsprechen Zuständen in S

tatecharts–

Überprüfe die S

tatecharts auf Vollständigkeit und K

onsistenz–

Überprüfe die S

tatecharts wechselseitig

26. Novem

ber 1999

Treffen de

r GI F

achgruppe 2.1.6 R

QZ

usamm

enw

irken von Anfo

rderungenund T

est auf der B

asis von U

se Cases

18

Form

alisierung von Szenarien

•D

ie Form

alisierung erleichtert das Validieren und

Verifizieren

–Inconsistencies, M

ehrdeutigkeiten undA

uslassungen werden aufgedeckt

–V

erbesserte Validierung w

ird ermöglicht (durch

Anim

ation/Sim

ulation, ‘form

ales’ Schliessen, ...)

•S

tatecharts können nach Bedarf zu einem

Gesam

tsystem-M

odell integriert werden

•D

ie Validierung der S

tatecharts geht Hand in

Hand m

it der Herleitung von T

estfällen

26. Novem

ber 1999

Treffen de

r GI F

achgruppe 2.1.6 R

QZ

usamm

enw

irken von Anfo

rderungenund T

est auf der B

asis von U

se Cases

19

Statechart A

nnotation

•In S

tatecharts wird das S

ystemverhalten m

odelliert;

Daten, Leistungsanforderungen und and

ere (Qualitäts-)

Attribute w

erden nicht erfasstð

Diese Inform

ationen fehlen in der Testfallherleitung

ðD

eshalb: Statecharts m

it Anm

erkungen versehen

–V

or- und Nachbedingungen

•Legen die A

usgangslage für die T

estfälle fest, die aus demS

tatechart hergeleitet we

rden

–D

atenbereiche und Datenw

erte, erwartete R

esultate•

Erm

öglichen Dom

änentests, Grenzw

ertanalyse

•E

rwartete R

esultate (dienen als T

estorakel)

–Leistungs- und nicht-funktionale A

nforderungen

26. Novem

ber 1999

Treffen de

r GI F

achgruppe 2.1.6 R

QZ

usamm

enw

irken von Anfo

rderungenund T

est auf der B

asis von U

se Cases

20

Beispiel zur S

zenarientransformation

UC

002: Authentication v0.1

Custom

erinserts card

System

checks PIN

System

checksthe card’s validity

Custom

erenters P

IN

Card

entered

PIN

entered

PIN

validD

isplay main m

enu

Card valid

Display ‘E

nter PIN

’ Dialog

UC

002: Authentication v0.4

Eject card

Custom

erinserts card

System

checksthe card’s validity

Retain card

Custom

erenters P

INS

ystemchecks P

IN

Card valid

Display ‘E

nterP

IN’ D

ialogInvalid P

IND

isplayretry m

sg

PIN

entered

Card

retained

Displaym

sg

Card

ejectedR

esetC

ardinserted

PIN

validD

isplay main m

enu

Third

invalid PIN

Tim

eoutD

isplay w

elcome

screen

Display

error msg

Card invalid

Card can’tbe read

Display

error msg

Card can’t fullybe inserted

Display

error message

Precondition: A

TM

is operational, card is being inserted

Annotations

PIN

consists of more than 3 and less than 7 num

eralsT

he color to be used for error messages only

red

[<2s]

[<0.05s]

{PIN

-> [0..9] }

64

26. Novem

ber 1999

Treffen de

r GI F

achgruppe 2.1.6 R

QZ

usamm

enw

irken von Anfo

rderungenund T

est auf der B

asis von U

se Cases

21

Testfallherleitung

•D

ie Testfallherleitung geschieht in drei

Schritten:

–T

estfallherleitung aus Statecharts

–T

estfallherleitung aus Dependency C

harts–

Zusätzliche T

estfallherleitung (unterstützt durchS

zenenarien)•

Tests zur Ü

berprüfung bestimm

ter Qualitäten,

Leistungstests•

Intuitives Testen (F

ehlererwartungen, E

rfahrung)unterstützt durch N

otizen in den Szenarien

26. Novem

ber 1999

Treffen de

r GI F

achgruppe 2.1.6 R

QZ

usamm

enw

irken von Anfo

rderungenund T

est auf der B

asis von U

se Cases

22

Testfallherleitung

•T

estfälle werden durch P

faddurchschreitung inden S

tatecharts bestimm

t–

Knoten-K

anten Überdeckung (oder beliebige andere

Pfadüberdeckungsm

asse, z.B. sw

itch / n-switch

Überdeckungen)

–N

ormalablauf zuerst, alternative A

bläufe, Ausnahm

en

•G

ebrauch von Anm

erkungen um die

Testentw

icklung zu verbessern–

Datenbereiche und D

atenwerte für D

omänentests

–Z

eit- und Leistungsanforderungen

26. Novem

ber 1999

Treffen de

r GI F

achgruppe 2.1.6 R

QZ

usamm

enw

irken von Anfo

rderungenund T

est auf der B

asis von U

se Cases

23

Erw

eiterte Testfallherleitung

•D

ependency Charts halten A

bhängigkeitenzw

ischen Szenarien fest

–logische, kausale und zeitliche A

bhängigkeiten

•D

iese Abhängigkeiten m

üssen geprüftw

erden (Pfade)

Application

refusedA

pply for card

Inquire balance

Issue card

0..3 in five years

Withdraw

cash

26. Novem

ber 1999

Treffen de

r GI F

achgruppe 2.1.6 R

QZ

usamm

enw

irken von Anfo

rderungenund T

est auf der B

asis von U

se Cases

24

Beispiel zur T

estfallherleitung

1.1 Z

uerst wird der N

ormalablauf getestet

1.2-1.4 Alle A

lternativabläufe und alle Ausnahm

en testen1.3-1.4 B

enutze die Anm

erkungen und Notizen um

weitere

Testfälle zu entw

ickeln

Test p

rep

ara

tion

:A

TM

operational, card and P

IN (1234) have b

een issued, card is being in

serted

IDS

tate

Inp

ut/U

ser a

ction

s/ Co

nd

ition

sE

xpe

cted

ou

tpu

t

1.1

Ca

rd sensed

Card ca

n be read, card valid

, valid PIN

(1234)ente

red in time

Ma

in menu d

isplayed

1.2

Ca

rd sensed

Card ca

n be read, card valid

, invalid

PIN

(1245)ente

red in time (first try)

Retry m

essage displayed

1.3

Retry m

sgInvalid

PIN

(123) entered in time, se

cond tryR

etry message displayed

1.4

Retry m

sgInvalid

PIN

(1234567) entered in time, third try

Card reta

ined, user inform

ed

……

……

26. Novem

ber 1999

Treffen de

r GI F

achgruppe 2.1.6 R

QZ

usamm

enw

irken von Anfo

rderungenund T

est auf der B

asis von U

se Cases

25

Schlussbem

erkungen

•S

CE

NT

ist in zwei industriellen P

rojekteneingesetzt w

orden–

Applikationen zum

entfernten Überw

achen voneingebetteten S

ystemen

•G

emachte E

rfahrungen–

Szenariengebrauch sehr w

ertvoll–

Iterativ verfeinerndes Vorgehen bew

ährt–

Szenarien w

eniger geeignet um S

ysteminternas zu

modellieren

–S

zenarienmanagem

ent war D

AS

Problem