1. No category

Nye testteknikker fra ISTQB
- direkte fra hylderne
Ole Chr. Hansen
TestExpo
29. Januar 2015
Præsentation
Ole Chr. Hansen
•
•
Managing Consultant
Fellow – SogetiLabs – Global Innovation Team
•
•
•
Blog - http://ochansen.blogspot.com
LinkedIn: www.linkedin.com/in/ochansen
Twitter: www.twitter.com/Ole_Chr_Hansen
•
•
•
•
•
•
•
•
ISTQB Accredited Trainer in Software Testing
ISEB Practitioner Certificate in Software Testing
ISTQB Foundation Certificate in Software Testing
TMap NEXT® Test Engineer Certificate
TPI NEXT® Foundation Certificate
PRINCE2 Foundation Certificate
Certified Scrum Master
Certified Lead Assessor (ISO 9000)
•
•
Sogeti, ATP, Nordea, BRFkredit, WM-data, CRI, LEC
15+ år inden for softwaretest, 10+ år inden for it-udvikling/projektledelse
© Capgemini Sogeti
2
Test teknikker – Testanalytikerens værktøjskasse
© Capgemini Sogeti
3
Hvad er nyt
Testteknik
ISTQB ATA Pensum
2007
2012
Ækvivalenspartitionering
X
X
Grænseværdianalyse
X
X
Beslutningstabeller
X
X
Årsags-virkningstest
X
X
Tilstandsovergangstest
X
X
Klassifikationstræmetode
X
X
Parvis test
X
X
Ortogonale arrays (del af parvis test)
X
X
Usecase test
X
X
Userstory test
X
Domæneanalyse
X
© Capgemini Sogeti
4
Domæneanalyse
Domæneanalyse – Introduktion
Et domæne er et defineret sæt af værdier.
Lige som ækvivalenspartition – alle værdierne i en partition forventes at blive
håndteret på samme måde af systemet:
• Hvis en værdi fungerer – så fungerer alle
• Hvis en værdi fejler – så fejler alle
Præmis for at det er
en partition
Endimensionelt domæne – en variabel.
Multidimensionelt domæne – to eller flere variable som interagerer.
Eksempel:
Mænd over 24 år og under 66 år, og med vægt over 69 kg og under 90 kg.
© Capgemini Sogeti
6
Domæneanalyse – Fordele
Brug af ækvivalenspartitionering og grænseværdianalyse vil få antallet af testcases til
at stige eksponentielt.
Domæneanalyse:
• Har den fordel, at den kun vil give en liniær stigning i antal testcases.
• Vil kunne finde defekter i multidimensionelle domæner, som de større testsæt ikke vil
finde.
• Det kræver it-understøttelse at bestemme værdierne til testcases ved 3 eller flere
dimensioner.
© Capgemini Sogeti
7
Domæneanalyse – Anvendelighed
Anvendelighed:
• Kombinerer de teknikker, der anvendes for beslutningstabeller,
ækvivalenspartitionering og grænseværdianalyse.
• Identificerer et mindre antal testcases
• Dækker de vigtigste områder
• Sandsynlige fejlområder.
• Anvendes ofte, hvor beslutningstabeller bliver for store grundet et stort
antal variable/betingelser.
• Kan anvendes på alle testniveauer – mest integrations- og systemtest.
© Capgemini Sogeti
8
Domæneanalyse – Begrænsninger
Begrænsninger:
• Kræver en stærk forståelse af softwaren for at identificere
domænerne og den eventuelle interaktion mellem dissse.
• Hvis et domæne er uidentificeret kan testen blive
mangelfuld – men vil sandsynligvis blive fundet for nogle af
værdierne vil lande der.
• Mest anvendelig til partitioner der består af kontinuerte
værdier.
© Capgemini Sogeti
9
Domæneanalyse – Definition
Domæneanalyse – En black-box testdesignteknik, der bruges til at identificere
effektive og egnede testcases, når flere variabler kan eller bør testes sammen. Den
bygger på og generaliserer ækvivalenspartitionering og grænseværdianalyse. Se også
grænseværdianalyse, ækvivalenspartitionering.
Grænseværdianalyse - En black-box testdesignteknik, hvor testcases designes
baseret på grænseværdier.
Ækvivalenspartitionering - En black-box testdesignteknik, hvor testcases er designet til
at eksekvere repræsentanter fra ækvivalenspartitioner. I princippet designes testcases
til at dække hver partition mindst en gang.
Kilde: ISTQB Terminologiliste, version 2.2
© Capgemini Sogeti
10
Domæneanalyse – Typiske defekter
• Defekter omfatter
• funktionelle problemer inden for domænet
• grænseværdihåndtering
• problemer med interaktion mellem variable
• fejlhåndtering
• specielt for de værdier, der ikke er i et gyldigt domæne
© Capgemini Sogeti
11
Domæneanalyse - Værdier
INDE: Repræsenterer en værdi, der er i partitionen/domænet.
UDE: Repræsenterer en værdi, der er uden for
partitionen/domænet/grænsen.
PÅ: Repræsenterer en værdi på grænsen af partitionen/domænet.
UDENFOR: Repræsenterer en værdi lige uden for partitionens/domænets
grænse – mindst mulige nominelle værdi.
Ved bestemmelse af disse værdier testes hver partition sammen med
dens grænsebetingelser.
Vær opmærksom på:
•
LUKKEDE grænser (>=, <=, =)  PÅ er i domænet
•
ÅBNE grænser (<, >)  PÅ er ikke i domænet
© Capgemini Sogeti
12
Domæneanalyse – Værdier / Optimere testen
Optimering af testen – ingen
gentagelse af en test.
Y
En INDE værdi for et domæne
er en UDE værdi for andet.
200
150
100
D1
INDE – D2
UDE – D1
D2
UDENFOR
50
PÅ
50
© Capgemini Sogeti
100
150
200
X
13
Domæneanalyse – Dækningskriterier
Dækning: Graden, udtrykt som en procentdel, af aktivering af et specificeret
dækningselement ud fra en sekvens af testcases.
Dækningselement: En enhed eller egenskab, der anvendes som grundlag for
testdækning.
Dækningskriterier for domæneanalyse:
Minimumsdækning for domæneanalyse vil være at have en test for hver
INDE, UDE, PÅ og UDENFOR-værdi for hvert domæne.
Hvor der er overlap mellem værdierne, er der ingen grund til at gentage testen. Derfor
er der ofte færre end fire tests pr. domæne.
© Capgemini Sogeti
14
Domæneanalysematrix
Variabel
Betingelse
Type
V1
B1
PÅ
1
2
3
4
5
N
UDENFOR
B2
PÅ
UDENFOR
Bn
PÅ
UDENFOR
Typisk
INDE
Forventet resultat
En værdi er i PÅ
eller UDE – alle
andre i INDE
© Capgemini Sogeti
Hver kolonne har
præcis en værdi
pr. variabel
15
Domæneanalysematrix
Domæneanalysematricen udfyldes som følger:
1. Udfyld variabelnavne
2. Udfyld betingelser
3. Tilføj TYPISK for hver variabel
4. Tilføj PÅ og UDE
5. Tilføj værdier til alle variable
6. Udfyld INDE værdien
7. Udfyldt næste kolonne – ved brug af PÅ og UDE rækkerne
© Capgemini Sogeti
16
Domæneanalyse - Eksempel
• Entre-billet til et arrangement koster 200 DKK.
• Kun hele DKK.
• Der kan betales kontant og/eller med kreditkort
• Kun kontant
• Kun kreditkort
• Kombination af kontant og kreditkort (summerer til
200 DKK)
© Capgemini Sogeti
17
Domæneanalyse - Eksempel
Domænet: Kontant
Grænse
Alle værdier
mindre end 0
Alle
værdier
større end
0
Kontantbetingelse:
X >= 0
-155
-1 0
UDE UDENFOR PÅ
© Capgemini Sogeti
45
INDE
18
Domæneanalyse - Eksempel
Domænet: Kreditkort
Grænse
Alle værdier
mindre end 0
Alle
værdier
større end
0
Kreditkortbetingelse:
X >= 0
-12
-1
0
UDE UDENFOR PÅ
© Capgemini Sogeti
155
INDE
19
Domæneanalyse - Eksempel
Domænet: Kombination af Kontant og Kreditkort
Alle
værdier
større end
200
Grænse
Alle værdier
mindre end
200
Betingelse:
199 200
UDENFOR
© Capgemini Sogeti
PÅ
201
UDE
Kontant + Kreditkort = 200 DKK
Domæneanalyse - Eksempel
Kontant
200
150
100
50
50
© Capgemini Sogeti
100
150
200
Kreditkort
Domæneanalyse - Eksempel
Variabel
Betingelse
Type
Kontant
X >= 0
PÅ
1
2
Kreditkort
INDE
X >= 0
PÅ
4
Kombineret K&KK
INDE
X + Y = 200
PÅ
6
7
-1
45
45
0
UDENFOR
Typisk
5
0
UDENFOR
Typisk
3
-1
155
155
45/15
5
159/4
0
UDENFOR
121/8
0
UDENFOR
INDE
Forventet resultat
© Capgemini Sogeti
Ej
OK
Ej
OK
Ej
OK
Ej
OK
OK
Ej
OK
Ej
OK
Domæneanalyse - Multidimensionelt
Viste eksempel – to-dimensioner.
Kunne være multi-dimensionelt: Anvendelse af flere kreditkort.
© Capgemini Sogeti
23
User story test
Agile…….
Agile metoder – f.eks. Scrum forberedes kravene i form af
user stories, som beskriver små funktionelle enheder, der kan designes,
udvikles, testes og demonstreres i en enkelt iteration.
© Capgemini Sogeti
25
User story test
• User story:
–
–
–
–
Titel og nummer
Som________
Vil jeg____________
Med det formål at_____________
– Værdi, Risiko, Estimat, Acceptkriterier
© Capgemini Sogeti
26
User story test – Definition
User story test – En black-box testdesignteknik hvor testcases designes med
udgangspunkt i user stories for at kontrollere at disse er korrekt implementeret. Se også user story.
User story - Et høj-niveau bruger- eller forretningskrav, almindeligvis anvendt i agil softwareudvikling, typisk
bestående af en eller flere sætninger i hverdags- eller forretningssprog, og som beskriver hvilken funktionalitet en
bruger behøver, eventuelle ikke-funktionelle kriterier, samt godkendelseskriterier. Se også agil softwareudvikling,
krav.
Agil softwareudvikling - En gruppe af softwareudviklingsmetodikker baseret på iterativ inkrementel udvikling, hvor
krav og løsninger udvikles gennem et samarbejde mellem selvorganiserende tværfunktionelle teams.
Krav - En betingelse eller evne, som en bruger behøver for at løse et problem eller opnå et mål, der skal opfyldes
af - eller være indeholdt i - systemet eller systemkomponenten for at opfylde en kontrakt, standard, specifikation
eller andet formelt indført dokument. [Efter IEEE 610]
Kilde: ISTQB Terminologiliste, version 2.2
© Capgemini Sogeti
27
User story test – Typiske defekter
• Defekter er normalt funktionelle
• der leveres ikke den specificerede funktionalitet
• integrationsproblemer med funktionaliteten der allerede er
implementeret ses også
• Stories udvikles uafhængigt
• der kan forekomme performance-, interface- og
fejlhåndteringsproblemer
• Vigtigt at teste både den leverede funktionalitet og
integrationen ved frigivelse af en ny story.
© Capgemini Sogeti
28
User story test – Dækningskriterier
Dækning: Graden, udtrykt som en procentdel, af aktivering af et specificeret
dækningselement ud fra en sekvens af testcases.
Dækningselement: En enhed eller egenskab, der anvendes som grundlag for
testdækning.
Dækningskriterier for user story test:
Minimum dækning af en user story er at verificere, at hvert af de
specificerede acceptkriterier er blevet opfyldt.
© Capgemini Sogeti
29
User story test – Anvendelse
Anvendelse
• Anvendes primært i agile og tilsvarende iterative og inkrementelle
miljøer
• Både funktionel og ikke-funktionel test
• Test på alle niveauer
• Udvikleren demonstrerer user storyens implementerede
funktionalitet for teamet.
© Capgemini Sogeti
30
User story test – Begrænsninger
Begrænsninger
• Små forøgelser af funktionalitet
• Udvikle og bruge stubbe og drivere
• Bruge API-værktøjer
• Normalt udviklerens opgave og ansvar
• Kontinuert integrationsmodel – ses ofte i agile projekter
• Behovet for stubbe og drivere minimaliseret
• F.eks. Først laves en succes-scenarie  denne kode kan dermed
anvendes af andre udviklere i stedet for stubbe/drivere.
• Der mangler fortsat fejlhåndtering, afvisning af ugyldige værdier m.m.,
hvilket leveres senere.
• HUSK: Behovet for regressionstest vil øges for alle iterationer efter den
første.
© Capgemini Sogeti
31
User story test – Eksempel
–
User story: 1 – Køb med kreditkort
–
–
–
Som KUNDE
Vil jeg KUNNE BETALE MED KREDITKORT
Med det formål at KØBE PRODUKTER
–
Acceptkriterier:
– Alle gængse kreditkort
– Kreditmax tjek
– ……
Testcases gængse kreditkort: Dankort, VISA, Mastercard, Diners, Amex…..
Kreditmax tjek: Inden for kreditmax, på kreditmax, overskreden kreditmax
……..
© Capgemini Sogeti
32
Afslutning
Hvad er nyt
Testteknik
ISTQB ATA Pensum
2007
2012
Ækvivalenspartitionering
X
X
Grænseværdianalyse
X
X
Beslutningstabeller
X
X
Årsags-virkningstest
X
X
Tilstandsovergangstest
X
X
Klassifikationstræmetode
X
X
Parvis test
X
X
Ortogonale arrays (del af parvis test)
X
X
Usecase test
X
X
Userstory test
X
Domæneanalyse
X
© Capgemini Sogeti
34
Spørgsmål
© Capgemini Sogeti
35