DAG 3
1
• Testtechnieken deel 1• Algemene informatie• Syntactisch testen• Semantisch testen
Testtechnieken
2
Testtechniek
Beslistabeltest Exploratory testing Real life test
Datacombinatietest
Gegevenscyclustest Semantische test
Elementaire
vergelijkingstestGrenswaardenanaly
seSyntactische
test
Error guessing Procescyclustest Use case test
Testtechnieken (1)
3
Whi
te b
ox
Bla
ck b
ox
Form
eel
Info
rmeel
Pro
gra
mm
aTest
Inte
gra
tieTest
Syst
eem
Inte
gra
tieTes
t
Syst
eem
Test
Geb
ruik
ers
Acc
ep
tati
eTest
Kete
nTest
Pro
du
ctie
Acc
ep
tati
eTest
Pro
gra
mm
ab
esc
hri
jvin
g
Tech
nis
ch O
ntw
erp
Lo
gisc
h D
ata
Mo
de
l
Fu
cntio
nee
l On
twerp
CR
UD
-matr
ix
Geb
ruik
ers
eis
en
&
wen
sen
AO
-pro
ced
ure
s
Beh
eerd
ers
eis
en &
w
en
sen
Beh
eerd
ers
han
dle
idin
g
Pro
du
ctie
han
dle
idin
g
Beveili
gin
g
Bru
ikb
aarh
eid
Con
tin
uït
eit
Con
trole
erb
aarh
eid
Fucn
tion
alit
eit
Geb
ruik
ers
vri
en
delij
kheid
Inp
asb
aarh
eid
Perf
orm
an
ce
Zu
inig
heid
Mu
st
Sh
ou
ld
Cou
ld
Wou
ld
ALG X X X X X X X X X
BTT X X X X X X X X X X X X
DFT X X X X X X X X X
EVT X X X X X X X X X X X X
GCT X X X X X X X X
PCT X X X X X X X X X X X X X
PIT X X X X X X X X X X X
RLT X X X X X X X X X X X X X X X
SEM X X X X X X X X X X X X
SYN X X X X X X X X X X X
ERR X X X X X X X X X X X X X X
TestsoortPrioritering
productrisico’s
< algemene kennis van het systeem >
Testbasis Dynamische kwaliteitsattributen
Doel: afleiden testgevallen
4
InvoerUitgangssituatieTestactiesVeranderingsproces
Verwacht resultaat
Testsituaties
5
Definitie: • Testsituatie is een geïsoleerde omstandigheid waaronder het testobject een specifiek gedrag vertoont en die getest dient te worden.
• Een bestelling van meer dan 1 boek• Gerelateerd hieraan: een bestelling van precies 1 boek
Evt korting die gegeven wordt bij een grens• Orderbedrag boven de drempelwaarde• Orderbedrag beneden de drempelwaarde
Testgevallen:• Met een testgeval wordt onderzocht of het systeem onder bepaalde omstandigheden het gewenste gedrag vertoont.• Input---processing---resultaatvoorspelling(output)
Logische testgevallen
6
Beschrijft in logische termen de omstandigheden waarin het systeemgedrag onderzocht wordt, door aan te geven welke testsituaties door het testgeval gedekt worden
• Bestelling van meer dan 1 boek waarbij het orderbedrag beneden de drempelwaarde blijft• Bestelling van 1 boek met een bedrag dat boven de drempelwaarde ligt.
• Wat de testsituaties zijn• Dat alle gedefinieerde testsituaties afgedekt zijn met testgevallen
Fysieke testgevallen
7
Is de concrete uitwerking van een logisch testgeval, waarbij keuzes gemaakt zijn voor de waarden van alle benodigde invoer en instellingen van de omgevingsfactoren.
Initiële situatie (geldig voor beide testgevallen)Drempelbedrag €50Korting = 10%Prijs boek-01 = €18,50 02 = €25,50 03 = €65,00TG-1:
Actie: bestel boek-01 en boek -02Resultaatvoorspelling = er wordt geen korting verleendOrderbedrag = €44,00
TF-2:ACTIE: BESTEL BOEK-03RESULTAATVOORSPELLING: er wordt korting verleend van 10%Orderbedrag = €58,50 (€65,00 - €6,50)
Dekking, Dekkingsvorm en Dekkingsgraad
8
Dekking is de verhouding tussen datgene wat getest kan worden en datgene wat met de testset getest wordt
Zegt iets over: hoeveel van alle mogelijkheden die getest kunnen worden er ook daadwerkelijk getest wordt.
Dekkingsvorm is de vorm waarin het afdekken van de te testen situaties die afleidbaar zijn uit de testbasis uitgedrukt worden
Geeft aan wat voor soort mogelijkheden beschouwd worden.(mogelijke combinaties van paden)
Dekkingsgraad geeft aan hoeveel percentage er getest gaat worden
Waarom dekking
9
Als het toch onmogelijk is om alles te testen en we dus gedwongen zijn om slechts een subset van alle mogelijkheden te testen, wat is dan de beste subset
Wat is nu eigenlijk precies het verschil tussen iets zwaar testen en iets licht testen? Wat betekent dat concreet voor de testgevallen die we daarvoor nodig hebben.
Dekking heeft alles te maken met de wens om met zo min mogelijk testgevallen zo veel mogelijk fouten te vinden.
Voorbeelden van bruikbare combinaties
10
Paden + equivalentieklassen:Procesverloop van “Orders – Leveren – Betalen” is gespecificeerd in een processchema. Dit wordt getest met paden-dekking testmaat-2. Variaties in soorten orders en in manieren van betalen worden ontworpen met behulp van equivalentieklassen
CRUD + Beslispunten:Van de gegevens order, levering en betaling wordt een CRUD matrix samengesteld. Er zijn integriteitsregels gespecificeerd voor de mogelijke bewerkingen van de gegevens. Deze zijn formeel beschreven, zoals bv:
“Als conditie-A OF (conditie-B EN conditie-C) DAN bewerking niet toegestaan”.
Deze regels worden afgedekt door het toepassen van modified condition / descision coverage.
Belang testontwerptechnieken
11
Geeft een onderbouwde invulling van de teststrategie: afgesproken dekking
op de afgesproken plaats
Tests zijn reproduceerbaar
Gestandaardiseerde werkwijze maakt testproces onafhankelijk van persoon
die de testgevallen specificeert en uitvoert
Gestandaardiseerde werkwijze maakt de specificaties overdraagbaar en
onderhoudbaar
Testproces is beter planbaar en beheersbaar
Syntactische test (1)
12
• Verificatie van user-Interface• Kwaliteitsattributen
• Functionaliteit• Gebruikersvriendelijkheid
• Validatie test waarmee de geldigheid van de invoergegevens getest wordt.
• Vaststellen in hoeverre het systeem bestand is tegen ongeldige of onzinnige invoer.
Syntactische test (2)
13
Doel:Ontdekken van fouten in de lay-out van schermen, overzichten en
in deprimaire invoercontroles met betrekking tot de rubrieken
Als toetscriteria kunnen geldende standaards worden gebruikt en specifiek
beschrijvingen van schermen en overzichten in de functionele specificaties
Syntactische test (3)
14
Stappen:• 1: Identificeren testsituaties / checklisten
• Rubriekcontroles, voor de validatietest• Datatype [numeriek, alfanumeriek,etc]• Veldlengtes [invoervelden, min/max]• Invoer/Uitvoer [geen waarde getoond, waarde niet te
wijzigen, waarde mag gewijzigd worden]• Defaults• Verplicht / niet verplicht• Selectiemechanisme
• Opmaakcontroles, voor de presentatietest.• Kopregels / voetregels
• Schermnaam / lijstnaam• Systeemdatum / afdrukdatum• Versienummer
• Rubrieken• Naamgeving van de rubriek• Plaats van de rubriek op het scherm• Weergave van de rubriek (lettertype, kleur)
Syntactische test (3)
15
Stappen:1. Opstellen logische testgevallen2. De testsituaties uit stap 1 zijn direct de logische testgevallen3. Opstellen fysieke testgevallen (zie volgende sheet voor
voorbeeld)4. Vaststellen uitgangssituatie: meestal zijn er geen speciale
eisen aan de uitgangssituatie
Syntactische test (4)
16
Voorbeeld van fysieke testgevallen bij de SYN-test
Scherm 2.6 Altijd fout
Altijd goede
Waarde Veld
Te vel tekens
Te weinig tekens
Verkeerde Buiten range Min waarde Max waarde
Bankgroep >5 <5 Num Nvt 00001 55555
Vervaldatum >4 <4 Num **01-**02 0001 9912
Postcode >6 <6 Alfanum 9999XX 1000AA 9999ZZ
Pinind >1 <1 alfa {J,N} J N
Syntactische test (5)
17
Opstellen checklist:• Dient gedaan te worden gedurende de testspecificatie fase
(TMap NEXT® fasering)
• Vaststellen welke syntactische controles uitgevoerd dienen te worden
Resultaat:• checklist voor de geselecteerde schermen• checklist voor de geselecteerde overzichten
Semantische test (1)
18
Vooral gebruikt bij online systemen (systeemtest, acceptatietest)
Black Box testtechniek
Testbasis: functionele specificaties, business rules die overkoepelend voor alle functies gelden
Kwaliteitsattributen• Beveiliging• Functionaliteit• Gebruikersvriendelijkheid
Validatietest
Semantische test (2)
19
Doel:• De relaties tussen gegevens bij het invoeren verifiëren• De relaties tussen gegevens binnen een scherm verifiëren• De relaties tussen verschillende schermen verifiëren• De relaties tussen invoer en reeds aanwezige input in database
verifiëren
Semantische test (3)
20
Stappen:• Inventariseren relatiecontroles;• Uitwerken relatiecontroles;• Vaststellen testacties en controles;• Vaststellen initiële gegevensverzameling;• Opstellen testscripts.
Semantische test (4)
21
Inventariseren relatiecontroles:• Doorlezen testbasis• Bepalen relatiecontroles (op scherm niveau)• Controles krijgen een unieke identificatie
Semantische test (5)
22
Uitwerken relatiecontrole:• Gevonden relaties controles uitschrijven in de vorm van enkelvoudige vergelijking• Terminologie die gebruikt wordt: ALS, DAN, ANDERS• Bij samengestelde vergelijking tevens de termen: EN, OF
Semantische test (6)
23
Voorbeeld:A EN B (beiden dienen waar te zijn)
ALS A DAN ALS B • DAN correcte invoer/actie• ANDERS Foutboodschap
A OF B (één hoeft maar waar te zijn)ALS A • DAN correcte invoer/actie• ANDERS ALS B• DAN correcte invoer/actie• ANDERS foutboodschap
Semantische test (7)
24
VoorbeeldALS einddatum oude adres >= ingangsdatum nieuwe adres (a)DAN foutboodschap testpad 1ANDERS correcte invoer testpad 2
Twee testpaden onderkend:Testpad 1: conditie A is waarTestpad 2: bewering is onwaar
Voorbeeld met meerdere paden ALS minimum voorraadcode gelijk is aan S(ignaal) a
DAN ALS aantal minimum voorraad = 0 b DAN foutboodschap 103 testpad 1 ANDERS correcte invoer testpad 2 ANDERS correcte invoer testpad 3
Semantische test (8)
25
Vaststellen testacties en controles• Het testen van de testpaden gebeurt door het uitvoeren van
testacties• In principe genereert ieder testpad en bijbehorende testactie
en eventuele controle
Met betrekking tot het voorraadsysteem:• A01: invoeren min. voorraadcode S en aantal minimum = 0• A02: invoeren min. voorraadcode S en aantal minimum = 200• A03: invoeren min. voorraadcode = B• Bij het uitvoeren van A01: juiste foutboodschap wordt getoond
Semantische test (9)
26
Initiële gegevensverzameling• Controleren of dit noodzakelijk aanwezig dient te zijn voor
het kunnen uitvoeren van de opgestelde testscenario’s
Opstellen testscripts• Acties beschreven die dienen te worden uitgevoerd bij de
daadwerkelijke testuitvoer en op volg tijdelijke wijze
Testuitvoering en beoordeling• Uitvoering middels de opgeleverde scripts• Beoordeling middels verwachte resultaat versus
daadwerkelijke resultaat
Semantische test
27
Uitwerken meegeleverde oefening in cursusmap:
Functioneel Ontwerp: “Opvoeren Klant”
Semantische test
28
Samenvatting:• Validatietesten (Syntactisch)• Geldigheid van de invoer• Testbasis:Semantische regels die specificeren waar een
gegeven aan moet voldoen om als geldige invoer te worden geaccepteerd.
• Relatie tussen gegevens• Functionele specificaties, Business rules• Semantische regels = Beslissingspunten die bestaan uit
samengestelde condities• Default keuze testcoverage: condition / decision coverage
Semantische test
29
Samenvatting:• Varianten
• Condition / decision: lichte variant• Multiple condition coverage: zware variant
• Aandachtspunten:• Identificeren testsituaties• Opstellen logische testgevallen• Opstellen fysieke testgevallen• Vaststellen uitgangssituatie.
Semantische test
30
Voorbeeld:• Semantische controle regel: Als klant in Nederland woont
EN (postcode voldoet niet aan Nederlands formaat OF landcode is niet gelijk aan 31) DAN resulteert dit in een foutmelding
B1A EN (B of C)
1Foutmelding
0nGeldige invoer
A: klant in Nederland 1,1,0 (1) 0,1,0 (3)
B: postcode niet in NL 1,1,0 1,0,0 (4)
C: landcode ongelijk aan 31
1,0,1` (2) 1,0,0
Semantische test
31
Voorbeeld:• Semantische controle regel: Als klant in Nderland woont
EN (postcode voldoet niet aan Nederlands formaat OF landcode is niet gelijk aan 31) DAN resulteert dit in een foutmelding
Testgevallen B1-1 B1-2 B1-3 B1-4
Klant In NL In NL Niet NL In NL
Postcode Niet in NL In NL Niet NL In NL
Landcode 31 Ongelijk 31 31 31
resultaatverwachting
foutmelding
foutmelding OK OK
Testtechnieken EINDE
Testtechnieken deel I
32
Testtechnieken deel II
VERVOLG
Testtechnieken deel IIGrenswaarde analyse
CRUD-MATRIXExploratory Testing
Use case testing
33
Grenswaarde analyse
34
Als het systeemgedrag verandert zodra de waarde van een parameter een bepaalde grens overschrijdt, is er sprake van
eenzogenaamde grenswaarde
Voorbeeld: Voor wat betreft de leeftijd zijn de regels voor het al of niet
Verstrekken van een lening als volgt:• Jonger dan 18: geen lening• Van 18 t/m 55: standaard lening verstrekken• Ouder dan 55: duurdere lening verstrekken
Grenswaarde analyse
35
Techniek:• Bepaal de grenswaarden bij de betreffende
equivalentieklasse of conditie• Definieer de volgende drie testsituaties:
• Precies op de grens• Direct erboven• Direct er onder
Grenswaarde analyse
36
De parameter leeftijd heeft drie equivalentieklassen en twee grenswaarden (18 en 55)
Aantal testsituaties:• Geen grenswaarde: 3 testsituaties (12, 32, 64)• Normale: 6 testsituaties (17, 18, 19 en 54, 55, 56)• Lichte: 4 testsituaties (17, 18, 55, 56)
Grenswaarde analyse
37
Niet alleen van toepassing op de invoerkant van een systeem, maar ook
op de uitvoerkant.
Voorbeeld:Offertepagina mag maximaal 10 regels bevattenGrenswaarde analyse wordt dan:• 9 regels• 10 regels( alle regels op 1 pagina• 11 regels (elfde regel op tweede pagina)
CRUD
38
Gegevens opgeslagen in een systeem kennen een levensloop.• Creëren gegeven (C)• Gegeven wordt geraadpleegd (R)• Gegeven wordt gewijzigd (U)• Gegeven wordt verwijderd (D)
Create, Read, Update, Delete
Samenstellen CRUD-matrix: hiervoor worden alle functies van het systeem doorlopen
• Welke entiteiten door deze functie gebruikt worden• Welke acties ( C, R,U,D) op deze entiteiten worden uitgevoerd.
CRUD
39
Levensloop:• Volledigheidscheck: statische test waarbij in de matrix onderzocht wordt of alle vier mogelijke acties (CRUD) bij iedere entiteit voorkomen• Is voor iedere entiteit de volledige levensloop geïmplementeerd
Consistentietest: dynamische test die zich richt op de integratie van de verschillende functies.• Controle: of de verschillende functies op een consistente manier een gegeven gebruiken
Controleer iedere wijziging van de entiteit middels een R (read)Gegeven correct bewerkt is en bruikbaar is voor andere functies
CRUD-Matrix
40
Factuur Artikel
Beheren artikelen - C,U,D
Aanmaken factuur C R
Balie-betaling C,R,D -
…………. ……… …………
CRUD
41
Een zware dekking van CRUD kan gerealiseerd worden door te eisen dat ook combinaties van acties volledig gedekt zijn. B.v: door te eisen dat na iedere “U” alle functies met een “R” uitgevoerd moeten worden.
Zie uitwerking volgende dia
CRUD
42
Stel dat de entiteit “ORDER”door de volgende functies als volgt bewerkt wordt:Aanmaken order (C); Annuleren order (D); Deellevering (U); Overzicht orders (R); Voorraadplanning (R)De standaard dekking van CRUD wordt dan al bereikt met het volgende testgeval• Aanmaken order (C)• Voorraadplanning (R)• Deellevering (U)• Overzicht orders (R)• Annuleren order (D)• Overzicht orders (R)
Risico: de volgende fout zou niet gevonden worden: Na een deellevering klopt de voorraadplanning niet meer, omdat die (onterecht) de gehele order als geleverd beschouwt. Hoe vinden deze fout wel
CRUD
43
Met zware dekking wordt deze fout wel gevonden:• Aanmaken order (C)• Overzicht orders (R)• Voorraadplanning (R)• Deellevering (U): (veroorzaakt fout in “Voorraadplanning”)• Overzicht orders (R)• Voorraadplanning (R) (fout wordt ontdekt)• Annuleren order (D)• Overzicht orders (R)• Voorraadplanning (R)
Explorarory testingDoor James Bach als begrip en aanpak neergezet en beschreven:
“het simultaan leren, ontwerpen en uitvoeren van tests, met andere woorden elke vorm van testen waarbij de tester zijn testen ontwerpt tijdens de testuitvoering en de informatie die wordt verkregen tijdens het testen wordt gebruikt om nieuwe en betere testgevallen te ontwerpen.”
44
Exploratory testing(2)• Geen pure test specificatietechniek• Tester maakt tijdens de testuitvoering telkens een keuze
over welke test hij wil uitvoeren• Tester ontwerpt ter plekke een test, gebruikmakend van
zijn kennis van test specificatietechnieken, zonder deze te documenteren
• Geen plaats in de fase specificatie
45
Exploratory testing(3)Elementen van Exploratory testing:• Wat ga je testen (binnen de scope, testopdracht)• Wat gaan we niet testen (buiten de scope)• Waarom gaan we dit testen• Hoe gaan we dit testen• Verwachte problemen (waar denk je dat het mis gaat)• Referentie gegevens
46
Exploratory testing(4)• Tester verkent steeds een stukje van het te testen systeem• Tester denkt na over wat er getest moet of kan worden
(testontwerp)• Tester brengt dit ter uitvoering (testuitvoer)• Hierdoor doet de tester gelijk weer nieuwe kennis op over
het systeem, en denkt na over wat er vervolgens getest moet worden
47
Exploratory testing(5)• Ontwerpen en uitvoeren van de tests gebeurt daarmee
zeer dicht op elkaar• Vastleggen van het testgeval is niet nodig• Er vindt dus wel testontwerp plaats in tegenstelling tot ad-
hoc of ongestructureerd testen
48
Exploratory testing(6)• Moeilijk op één lijn te plaatsen met de overige testontwerp
technieken• Niet gebaseerd op een van de basis technieken• Laat keuze te gebruiken techniek vrij aan de tester• Geeft geen gegarandeerde dekking
49
Exploratory testing(7)• Testen zonder formele testbasis zoals een functioneel
ontwerp• Legt minder nadruk op een beschreven testbasis en meer
op andere manieren om te beoordelen of het testobject voldoet
50
Exploratory testing(8)Toe te passen als:• Ervaren testers met materiekennis beschikbaar zijn waarin
men voldoende vertrouwen heeft• Zo goedkoop mogelijk testen verreweg de belangrijkste
overweging is• Er onvoldoende gedocumenteerde testbasis is• Aanvulling op het testen volgens formele technieken met
als doel creatief testen te stimuleren• Er geen tijd beschikbaar is om de tests voor te bereiden
51
Exploratory testing(9)Niet toe te passen als:• Er hogere eisen aan de aantoonbaarheid/verslaglegging
van testen worden gesteld, bijvoorbeeld door opgelegde standaards
• Er sprake is van kritische functionaliteit waarvan het falen grote schade kan veroorzaken
• Het testteam bestaat uit onervaren testers• De testgevallen moeten kunnen worden uitgevoerd door
een andere tester• De testgevallen herbruikbaar moeten zijn
52
Exploratory testing(10)Niet toe te passen als:• Er geen rechtstreekse feedback van testuitvoering is,
zodat de resultaten niet direct beschikbaar zijn• Er sprake is van testen die veel voorbereiding vergen• Testen zo kort mogelijk op het kritieke pad van het project
moeten zitten
53
Exploratory testing(11)Stappen:• Input velden
• Juiste data• Onjuiste data• Veldlengte = max.• Veldlengte = max. +1
• Acties• Toevoegen• Updaten• verwijderen
54
Exploratory testing(12)Benodigde vaardigheden van de tester:• Testontwerp vaardigheden• Observatievermogen• Kritisch kunnen denken• Terug kunnen vallen op ervaringen• Juiste vragen kunnen stellen• Verder kunnen denken dan gewenst• Materiedeskundigheid
55
Exploratory testing(13)
Voordelen Exploratory testing• Snel schakelen• Adequaat reageren• Snel kunnen starten• Teamwork• Bredere kennisontwikkeling tussen ontwikkelaar en tester• Snel resultaat• Geschikt voor kleine projecten
56
Exploratory testing(14)Nadelen Exploratory testing• Gezelligheid binnen team/balans zien te vinden• Veredelde error guessing• Charter moeten opstellen• Kosten aspect• Kritische/risicovolle delen
57
Exploratory testing(15)Status van Exploratory testing:• Er is nog geen eenduidige aanpak• Goeroes:
• James Bach• Cem Kaner• Stale Almland• James Whittaker
58
Exploratory testing(15)
• Verschillen tussen Error guessing en ET
59
Error guessing Exploratory testing
Maakt geen gebruik van de basistechnieken
Maakt afhankelijk van de situatie gebruik van de meest passende basistechniek
Geschikt voor testers, gebruikers, beheerders
Geschikt voor ervaren tester met kennis van de basistechnieken
De testgevallen worden in de fase Specificatie of tijdens testuitvoering ontworpen
De testgevallen worden tijdens fase uitvoering ontworpen
Richt zich op de uitzonderingen en moeilijke situaties
Richt zich op het totaal van een te testen aspect (scherm, functie)
Niet systematisch, geen enkele zekerheid over dekking
Enigszins systematisch
Use Cases(1)
• Bevat een typische interactie tussen een gebruiker en een systeem. De use case beschrijft een compleet stuk functionaliteit dat een systeem aanbiedt aan een gebruiker en dat een voor de gebruiker observeerbaar resultaat oplevert
60
Use Cases(2)
• Definitie volgens Tmap-Next: Een Use case bevat een typische interactie tussen een gebruiker en een systeem. De use case beschrijft een compleet stuk functionaliteit dat een systeem aanbiedt aan een gebruiker en dat een voor de gebruiker observeerbaar resultaat oplevert
61
Use Cases(3)
• Testbasis• Bevat minimaal de use cases en bij voorkeur ook het
bijbehorende use case diagram
• Wordt gebruikt bij het testen van de kwaliteitsattributen• Inpasbaarheid;• Bruikbaarheid;• Gebruikersvriendelijkheid.
62
Use Cases(4)
Use case kan op diverse manieren worden beschreven: controle uit voeren om te onderzoeken of de gehanteerde use case beschrijving voldoende informatie bevat om voor de use case te kunnen worden gebruikt.
Gebruik van een checklist Use case: om te bepalen of een use case bruikbaar is voor het toepassen van de use case test, is afhankelijk van de manier waarop de use case is beschrevenOp de volgende dia staan een aantal controles beschreven
63
Use Cases(5)
• Is de (standaard voor project/organisatie) use case sjabloon volledig ingevuld?• Is de use case diagram aanwezig• Is de use case een op zichzelf staande taak•Is het duidelijk voor welke actor de use case is bedoeld•Heeft de use case betrekking op functionaliteit (dus niet op schermverloop)•Zijn alle bekende uitzonderingen beschreven•Zijn de beschreven stappen uitvoerbaar•Is het resultaat van de stappen controleerbaar
64
Use Cases(6)
Use case diagram: beschrijft een (gedeelte van de) functionaliteit. Een use case diagram geeft de systeemgrenzen aan, geeft mogelijke onderlinge relaties tussen use cases weer, en laat vooral zien welke relaties er zijn tussen de actoren (gebruikers) en de use case.
Bestaat uit de volgende symbolen:• Poppetje om de actor aan te geven• Ovaal om een use case aan tegeven• Lijnverbinding tussen actor en use case, of tussen use cases onderling
65
Use Cases(7)
Use case onderlinge relaties• Extend:
• Wordt gebruikt als een al aanwezige use case overeenkomt met een andere use case, maar iets extra’s doet. Dit extra is uit de use case gehaald en in een aparte use case geplaatst
• Include:• Als een bepaald gedrag in meerdere use cases voorkomt,
wordt dit er meestal uitgemodelleerd in plaats van herhaald
• voorbeeld: use case die de burgerlijke staat van een persoon nagaat. Deze kan gebruikt worden voor; Bepalen belastingtarief Aanpassen burgerlijke staat
66
Use Cases(8)Use case sjabloon:• name = naam use case • actor = naam persoon om wie het gaat• precondities= waar moet aan voldaan zijn alvorens je kunt
starten• primaire scenario = normaal scenario• uitzondering(en) = andere scenario’s die mogelijk zijn• Scope (betreft het een systeem of subsysteem)• Level (betreft het een primaire taak of subtaak)• Stakeholder • Trigger
67
Use Cases(8a)
Voorbeeld Use Case template
68
Name Toets starten
Actor Cursist
Pre conditions Cursist heeft opleiding testtechnieken gevolgd
Primary scenario 1: cursist start het “Testontwerptechniek Toest”programma2: Include <inloggenTot toets>3: maakt keuze uit de technieken4: kiest evt voor de optie “geven van Uitleg”5: kiest evt voor de optie “geven van tussenstanden6: programma staat klaar voor de eerste vraag
Exceptions 1: cursist drukt op vraag knop, terwijl de vorige vraag niet is beantwoord2: tikt iets in het invoerveld terwijl de vraag al is beantwoord3: stopt terwijl er nog geen 10 vragen zijn beantwoord
Post condition Cursist kan beginnen met de uitgekozen test
Use Cases(9)
Stappen:• Identificeren testsituaties
• Zoek variabelen die een reactie van het systeem of omgeving tot gevolg hebben
• Bepaal het domein van de variabelen• Bepaal welke variabelen een relatie met elkaar hebben
• Opstellen logische testgevallen• Opstellen fysieke testgevallen• Vaststellen uitgangssituatie
69
HuiswerkopdrachtTMap Next®, doorlezen:
• Hoofdstuk 14 : Testontwerptechnieken (besproken testontwerptechnieken
• Overige testontwerptechnieken vrijblijvend doorlezen
70
Einde dag 3
Testtechnieken deel II
71
Dag 4
• Testtools• Testorganisatie• Ondersteunende processen• Testomgevingen
72
Testtools (1)
Definitie: Een testtool is en geautomatiseerd hulpmiddel dat ondersteuning biedt aan een of meer testactiviteiten, zoals plannen, beheren, specificeren en uitvoeren.
Voorwaarde voor succesvol gebruik van testtools: aanwezigheid van een gestructureerde testaanpak.
73
Testtools (2)
Soorten testtools:• Tools voor het plannen en beheren van de tests• Tools voor het ontwerpen van de tests• Tools voor het uitvoeren van de tests• Tools voor het debuggen en analyseren van de code
De eerste drie testtools worden voornamelijk gebruikt door de testers in het onafhankelijke testteam
74
Testtools (3)
Plannen en beheren van de test:• Testware beheertool• Bevindingen beheertool: TestDirector/Quality Center• Plannings- en voortgangsbewakingstool: MS-Project• Workflow tool
75
Testtools (4)
Ontwerpen van de test:• Testdatatool• Testontwerptool• “Model based testing”-tool: Dit is een aanpak waarbij op basis van een model van het testobject, testgevallen worden ontworpen.
76
Testtools (5)
Uitvoeren van de test:• Geautomatiseerde testuitvoerings tool: Record & Playback (GUI)• Performance- load- en stresstool• Monitor: Geheugenbeslag, CPU-gebruik, Netwerkbelasting• Code coveragetool: leveren informatie over welke delen van de programmacode tijdens het testen zijn doorlopen• Comparator: Vergelijkingstool, vergelijkt data en rapporteren de verschillen• Databasemanipulatietool: SQL, controles uitvoeren in de database• Simulator: bootst de werking van de omgeving van het te testen testobject na.• Stubs and drivers:
77
Testtools (6)
Uitvoeren van de test:• Stubs and drivers:
78
A A Driver
B Stub B
Testtools (7)
Voordelen gebruik van tools:• Hogere productiviteit;• Hogere kwaliteit testen;• Hogere arbeidsvreugde;• Uitbreiding testmogelijkheden.
79
TestprojectorganisatieVoorbeeld
80
Projectmanager
Testmanager
Testcoördinator TestcoördinatorTestcoördinator
TestersTestanalisten TestautomatiseerdersTesters Testanalisten
Testorganisatie
orbeeld
81
Managertestafdeling
Testmanagers TestanalistenTestcoördinatoren
Project W
Project X
Project Y
Project Z
Ondersteunende processen
Testbeleid: Het testbeleid beschrijft hoe een organisatie omgaat met de mensen, middelen en methoden rondom het testproces in de verschillende situaties.
Dient te gelden voor alle typen systemen, infrastructuren en ontwikkelmethoden.
82
Ondersteunende processen
Strategische ondersteuning: • Voorwaarden stellen aan de interne (IT) organisatie• Kwaliteitsdoelstellingen• Welke mogelijkheden er zijn waarmee die verwezenlijkt moeten worden
Kan gevormd worden door wensen eisen die van binnen de organisatie komenFactoren van buiten af kunnen ook een rol spelen (eisen die gesteld worden vanuit externe toezichthouders, (lokale) wettelijke verplichtingen waaraan voldaan moet worden of brancheafspraken
83
Ondersteunende processen
Tactische ondersteuning: strategisch beleid wordt vertaald naar HOE het in de operatie uitgevoerd gaat worden.Opstellen van voorschriften die aangeven:• binnen welke randvoorwaarden en normen, de middelen en de methoden moeten worden ingezet om de strategische doelstellingen te realiseren.
Beschrijven hoe binnen een organisatie, afdeling, productgroep, programma of project (afhankelijk van de inrichting van de betreffende organisatie), inhoud gegeven moet worden aan een gestructureerde testaanpak
84
Ondersteunende processen
Operationele ondersteuning: • Ondersteuning van het testproces:
• Onderwerpen rond methodisch, technisch en functioneel advies aan de tester(s)
• Ondersteuning werkelijke uitvoering van het testproces• Het testen zelf• Testmanagement
85
Testomgevingen
Voor het dynamisch testen van een testobject (runnen van software) is een passende testomgeving nodig
Inrichting en beheren van de testomgevingen is een expertise waar testers over het algemeen geen kennis van hebben
Definitie: een testomgeving is een samenstel van onderdelen zoals hard- en software, koppelingen, omgevingsdata, beheertools en processen waarin een test wordt uitgevoerd.
86
Testomgevingen
Eisen die aan de inrichting worden gesteld:• Representatief: de testomgeving dient (zoveel mogelijk) de eigenschappen te hebben die nodig zijn voor de beoogde test.• Beheersbaar: noodzakelijk om het testobject steeds onder dezelfde omstandigheden te kunnen testen, duidelijk zijn welke versie er in de omgeving staat (software, besturingssysteem, databasemanagementsysteem, etc)• Flexibel: Moet snel aangepast kunnen worden• Continu: De gevolgen van een storing moten tot een minimum beperkt blijven. Hulpmiddel kan zijn, het maken van back-ups aan het einde van bv iedere testdag.(hierdoor kun je altijd terug naar de beginsituatie van de dag)
87
Testomgevingen
OTAP-model: Ontwikkeling, Test, Acceptatie, Productie.
Het model heeft als uitgangspunt dat iedere gebruiker van de infrastructuur ongestoord zijn werk wil doen en van niemand anders last wil hebben.
Model schrijft niet voor dat er 4 omgevingen zijn, maar dat er 4 typen omgevingen zijn.
Ieder type met zijn eigen kenmerken
88
Testomgevingen
OTAP-model: Ontwikkeling, Test, Acceptatie, Productie.
Het is dus mogelijk dat er 7 omgevingen gebruikt worden volgens het OTAP-model (2 ontwikkelomgevingen, 1 testomgeving, 2 acceptatieomgevingen en 2 productieomgevingen)
89
Testomgevingen
OTAP-model: Ontwikkeling, Test, Acceptatie, Productie.
Mogelijke eigenaren en beheerders van de 4 typen omgevingen:
90
Type omgeving Eigenaar Beheerder
Ontwikkeling Ontwikkelaars Ontwikkelaars
Test Testers Ontwikkelaars, Testers, beheerderorg
Acceptatie Gebruikersorg Ontwikkelaars, Testers, beheerderorg
Productie Gebruikersorg. Beheerorganisatie
Tips
Kijk eens op www.tmap.net. U vindt daar onder andere• downloads (checklists, testontwerptechnieken, woordenlijst)• de TMap Test Topics presentaties• in de pers verschenen Tmap artikelen• Tmap nieuwsbrieven
91
Einde cursus TMap NEXT®