Fra klassisk til moderne – testteknikker der gør en forskel i 2025 – Del 1
Af: Ole Chr. Hansen, Q Nation A/S
Introduktion
ISTQB Advanced Test Analyst (ATA) version 4.0 introducerer en række testdesignteknikker for at hjælpe testanalytikere med at designe systematiske og effektive tests. Disse teknikker er hovedsageligt black-box teknikker (dvs. baseret på krav og funktionalitet, ikke kode) samt erfaringsbaserede teknikker, da Advanced Test Analyst-rollen fokuserer på forretningsværdi og funktionelle tests frem for kodeorienterede tests. ATA 4.0 inddeler de formelle testteknikker i tre kategorier – databaserede, adfærdsbaserede og regelbaserede – alt efter hvilke aspekter af testgrundlaget der bruges til at designe testtilfælde. Derudover omfatter pensum erfaringsbaserede testmetoder (f.eks. udforskende test). I denne artikel gennemgås alle relevante testteknikker fra ATA v4.0 med beskrivelser, styrker/svagheder, anvendelse og eksempler. Dernæst sammenlignes disse med nyere, moderne testtilgange, herunder modelbaseret test, AI-understøttet risikobaseret test, automatiseret testcase-generering, kontinuerlig test samt test af low-code/no-code applikationer. Undervejs refereres til relevante standarder (f.eks. ISO/IEC) og kilder fra forskning og industri for at underbygge og udvide ATA-pensum, så erfarne testanalytikere får et opdateret helhedsbillede.
Generelt anvendes testteknikker med henblik på at balancere mellem ingen test som det ene yderpunkt og udtømmende test som det andet. Testteknikkerne er med til at sikre en balance mellem disse to yderpunkter, og dermed fokuseres testen samtidig med at omfanget reduceres, således at der testes mindst muligt, men også samtidigt det er er nødvendigt. Testteknikkerne fungerer samtidig som en konkret udmøntning af testtilgangen.
Testteknikker i ISTQB Advanced Test Analyst 4.0
ISTQB ATA 4.0 dækker en række centrale testdesignteknikker. Disse teknikker giver en struktureret måde at udlede testcases fra et givent testgrundlag (krav, usecases, modeller, etc.). I ISO 29119-4-standarden defineres en testteknik som en systematisk tilgang til at udlede testcases ud fra testgrundlaget. Formålet er at sikre, at tests er transparente, reproducerbare og kan måle dækningsgrad af bestemte forhold i software, i stedet for blot at teste arbitrært. ATA 4.0 fokuserer primært på blackbox-teknikker og erfaring, mens white-box teknikker dækkes i den tekniske testanalytiker-certificering. Nedenfor beskrives alle relevante ATA 4.0-teknikker, opdelt i de nævnte kategorier, med deres styrker, svagheder, anvendelsesområder og eksempler.
Databaserede testteknikker
Databaserede teknikker fokuserer på inputdata og værdier. De skal sikre, at systemet håndterer forskellige områder af inputdomænet korrekt. Foundation-niveauet introducerede allerede de grundlæggende teknikker ækvivalenspartitionering (EP) og grænseværdianalyse (BVA), som begge falder i denne kategori. ATA 4.0 udvider med tre yderligere databaserede teknikker: domænetest, kombinatorisk test og random test.
Ækvivalenspartitionering og grænseværdianalyse (EP/BVA)
Beskrivelse: Ækvivalenspartitionering opdeler inputværdier i ækvivalensklasser, hvor alle værdier inden for samme klasse forventes at blive behandlet ens af systemet. Man kan så nøjes med at teste én repræsentant fra hver klasse. Grænseværdianalyse supplerer ved at teste grænserne mellem sådanne klasser, da fejl ofte opstår ved overgangene. For eksempel, hvis et felt accepterer værdier 1-100, testes laveste og højeste tilladte værdier samt værdier lige uden for grænserne.
Styrker: EP/BVA giver bred testdækning med relativt få testtilfælde – man undgår redundant test af mange ens værdier. Teknikkerne er enkle at anvende og effektive til at finde fejl ved manglende eller forkerte valideringer omkring grænser. De er særlig nyttige, hvor input er numeriske områder, kategorier eller intervalskalaer.
Svagheder: EP/BVA adresserer ikke specifikt kombinationer af flere felter eller sekventielle interaktioner. De forudsætter klare krav til værdidomæner; hvis kravene er uklare, kan det være svært at definere ækvivalensklasser præcist. Desuden fanger de ikke fejl der kun opstår ved komplekse kombinationer af inputs (det håndteres bedre af kombinatoriske teknikker).
Anvendelse: EP/BVA er standardvalg ved test af inputfelter, formularer, beregninger osv. F.eks. ved validering af et alder-input (0-120 år) vil testanalytikeren vælge repræsentanter for gyldige intervaller (f.eks. 0, 120) og ugyldige værdier (−1, 121) for at sikre korrekt håndtering af kanterne.
Eksempel: I et webformular skal brugeren indtaste postnummer (forventet 4 cifre). Ækvivalenspartitionering kan dele input i gyldige danske postnumre (0000-9999) vs. ugyldige (ikke-numeriske eller længde ≠ 4). Grænseværdianalyse vil teste f.eks. "0999" (laveste gyldige lige over grænsen), "10000" (lige over højeste gyldige længde) etc., for at afsløre om systemet fejler ved netop grænsen.
Domænetest
Beskrivelse: Domænetest udvider ækvivalenspartitionering og grænseværdianalyse til flerdimensionelle domæner med flere inputparametre. I stedet for at se på ét input ad gangen ser man på en kombination af inputvariable som definerer et domæneområde. Man identificerer ækvivalensområder i et flerparameter-rum og tester ved kanterne af disse. Domænetest indebærer ofte at udtrykke partitionsgrænser som logiske betingelser (f.eks. kombinationer af AND/OR over flere variabler). Et eksempel kunne være et låneansøgningssystem, hvor både alder og indkomst bestemmer udfaldet: Domænet kan opdeles i områder (f.eks. Alder < 18 OG Indkomst < 100k vs. Alder ≥ 18 OG Indkomst < 100k, etc.). Testtilfælde vælges ved at tage værdier på grænserne (ON-punkter) og lige indenfor/udenfor grænserne (OFF-punkter) for hver kombination.
Styrker: Domænetest er grundig til at finde grænsefejl i komplekse inputlogikker. Den kan afsløre defekter hvor implementeringen anvender forkerte operatorer eller konstanter i betingelser (f.eks. < vs ≤). Teknikken sikrer at alle relevante hjørner af et flerdimensionelt inputrum bliver verificeret.
Svagheder: Når antallet af parametre stiger, kan antallet af ækvivalensområder og grænser vokse eksplosivt, hvilket gør teknikken kompleks at anvende manuelt. Det kræver ofte, at testanalytikeren har et godt matematisk/logisk overblik over inputdomænet. Hvis domænet har mange dimensioner eller komplekse regler, kan det være svært at identificere alle relevante kombinationer uden hjælp af værktøjer eller modeller.
Anvendelse: Velegnet når output eller systemets opførsel afhænger af flere input samtidigt. Anvendes tit i finansielle beregninger, forsikrings- eller skattesystemer, hvor regler typisk involverer flere variable. Også relevant i sikkerhedskritiske systemer, hvor standarder (f.eks. ISO 26262 for biler) kræver en dybere test af grænser i kombination. For eksempel i bilindustrien kan valg af testteknik afhænge af risikoniveauet (ASIL – Automotive Security Integrity Level) – ved højere ASIL kræves formelle teknikker som EP/BVA eller domænetest frem for kun erfaring.
Eksempel: Overvej en BMI-beregner, der klassificerer om en person er overvægtig baseret på højdevægt forhold. Reglen kunne være: “Hvis højde > 1,29 m OG BMI ≥ 30 så er personen overvægtig.” Her defineres et domæneområde (to-dimensionelt) med én åben grænse (højde > 1,29) og én lukket grænse (BMI ≥ 30). Domænetest vil udvælge testpersoner med værdier lige omkring disse grænser: f.eks. en person lige under 1,29 m med BMI lidt under 30 (for at teste OUT-punkt), en person lige over 1,29 m og BMI lige på 30 (ON-punkt), osv., for at sikre at klassifikationen skifter korrekt ved grænserne.
Kombinatorisk test (f.eks. Parvis test)
Beskrivelse: Kombinatorisk test (også kaldet kombinationsprøvning) er en teknik hvor testtilfælde designes til at udføre specifikke kombinationer af inputværdier på tværs af flere parametre. I praksis betyder det, at man udvælger en delmængde af alle mulige kombinationer af fx systemets inputfelter eller konfigurationsindstillinger, sådan at man dækker kombinationer op til et vist interaktions-niveau t. En særlig populær variant er Parvis test (2-vis kombinationer), hvor man sørger for at hver mulig kombination af to parameterværdier optræder i mindst ét testtilfælde. Man kan også vælge 3-vis, 4-vis osv. afhængigt af behov og risiko. Ideen bag kombinatorisk test er den empiriske observation, at de fleste softwarefejl udløses af relativt få parametre i samspil. NIST-studier har f.eks. vist, at størstedelen af fejl skyldes sammenhæng mellem højst 2 parametre, og meget færre fejl kræver 3 eller flere parametre i en bestemt kombination. Derfor kan Parvis tests fange mange fejl med væsentligt færre testtilfælde end total test.
Styrker: Effektiv fejlfinding med færre tests er den primære fordel. Parvis test kan dramatisk reducere antallet af nødvendige test kombineret med høj fejlopdagelsesrate, netop fordi mange fejl typisk involverer to-faktor interaktioner. Generelt giver kombinationsmetoder en systematisk dækning af inputkombinationer, hvilket øger tilliden til at de fleste kombinationsfejl opdages. Der findes værktøjer (testdesign-generatorer) til at generere sådanne kombinationer automatisk – f.eks. baseret på algoritmer der opfylder parvis dækning – hvilket gør teknikken praktisk anvendelig selv ved mange parametre. Et anvendeligt værktøj er TestPairs (www.testpairs.dk).
Svagheder: Kombinatorisk test kan stadig resultere i et meget stort antal tests, især hvis man øger t (3-vis, 4-vis etc.) for at afdække mere komplekse interaktioner. Der skal balanceres mellem dækningsgrad og praktikalitet – f.eks. kan 100% 3-vis kombinationsdækning være urealistisk at eksekvere, hvis der er mange parametre. Teknikken forudsætter også, at parametre og deres mulige værdier er identificeret på forhånd; hvis systemets adfærd afhænger af skjulte eller kontinuerlige parametre, kan kombinationerne blive svære at definere. Desuden garanterer Parvis ikke at alle fejl findes – fejl som kræver 3 eller flere samtidige faktorer vil ikke nødvendigvis opdages med kun 2-vis kombinationer.
Anvendelse: Kombinatorisk test er nyttig i konfigurations- eller kompatibilitetstest, hvor man f.eks. vil sikre at software virker på tværs af forskellige browsere, OS, sprog, enheder osv. Her kan Parvis sikre at hver kombination af (browser, OS) eller (enhed, OS) etc. er testet mindst én gang. Også anvendt i domæner som telekom og indlejrede systemer, hvor mange indstillinger kan varieres. Standarder anerkender denne tilgang indirekte; fx refererer ISO/IEC 29119-4 til Parvis (2-way) og n-way kombinationsdækning som et mål for testgrundighed. I safety-critical miljøer (fx bilindustrien) kan man også udnytte kombinationstest baseret på risikovurdering – test med høj interaktionsgrad reserveres til de højeste risici.
Eksempel: Overvej en mobil-app der skal fungere på tværs af 3 operativsystemer (iOS, Android, Windows) og 4 netværkstyper (WiFi, 4G, 5G, offline). Fuld kombinationstest ville kræve 3×4 = 12 tests for at dække alle par. Men en Parvis tilgang kunne nøjes med et mindre sæt, hvis der også var flere faktorer. Her er det overskueligt at teste alle 12, men hvis faktorerne var flere (enhedstyper, browsere, osv.), kunne et værktøj generere fx 2-vis dækkende testdesign. Et genereret Parvis testtilfælde kunne være: (Android, 5G), et andet (iOS, WiFi), osv., så alle OS-netværks par kombineres på tværs af tests. På den måde kan man med rimeligt få tests fange fejl som kun opstår ved specifikke kombinationer (fx et problem der kun viser sig på Android over 5G).
Random testing (tilfældig test)
Beskrivelse: Random testing indebærer at udvælge testtilfælde eller inputværdier tilfældigt fra inputdomænet, ofte ifølge en vis sandsynlighedsfordeling. Det vil sige, at i stedet for at designe hver test case manuelt baseret på analyse, lader man en pseudo-tilfældig mekanisme generere inputs. Idéen er at simulere uforudsete kombinationer og grænsetilfælde, som en struktureret tilgang måske overser, samt at opnå statistisk bred dækning af inputrummet. Random testing bruges typisk med en defineret operational profile, dvs. en fordeling der afspejler realistisk brug (så mere sandsynlige inputs vælges oftere). I ATA 4.0 sammenhæng behandles random testing kun mht. inputdata, ikke tilfældige events eller brugerhandlinger (disse kan dog også randomiseres i andre kontekster).
Styrker: Tilfældig test kan finde uforudsete fejl fordi den ikke er begrænset af testanalytikerens bias eller antagelser. Særligt hvor inputdomænet er meget stort eller komplekst, kan random testing nå bredere omkring end målrettede tests – især hvis man kører mange iterationer. Det er også relativt let at automatisere og skalere; man kan generere tusindvis af tilfældige inputs og lade systemet køre dem igennem hurtigt (hvis automation tillader det), hvilket kan være godt til robustness- eller stress-test. Random testing er desuden brugt til at implementere fuzz testing (f.eks. til sikkerhedstest), hvor vilkårlige eller semi-vilkårlige data indlæses for at se om systemet bryder sammen.
Svagheder: Som testdesignteknik er random mindre målrettet – der er ingen garanti for at specifikke kritiske grænser eller kombinationer bliver ramt, med mindre man kører ekstreme antal iterationer. Man kan komme til at spilde mange testkørsler på at gentage lignende områder af inputdomænet, mens sjældne hjørner måske aldrig rammes. Derfor kombineres random ofte med metamorfiske relationer eller orakler for at vurdere resultater (se senere). Et andet minus er reproducerbarheden: hvis en tilfældig test afslører en fejl, skal man sikre at kunne gengive netop det input (typisk logger man seed/værdi for reproduktion). Random test alene er sjældent tilstrækkelig som teststrategi; den fungerer bedst som supplement til mere systematiske tests.
Anvendelse: Random testing er populært i fx performance- og pålidelighedstest, hvor man vil køre systemet med mange forskellige data for at se om det crasher over tid. Også i sikkerhedstest (fuzzing), hvor tilfældige eller formodet skadelige input genereres (f.eks. tilfældige filer til et filparseringsprogram, random netværkspakker osv.). I AI- og ML-systemer anvendes random input nogle gange pga. svært definerbare korrekte output – her kan metamorf test (nedenfor) hjælpe med at evaluere de random genererede testcases.
Eksempel: Et konkret eksempel er test af en lommeregner-app. En random testtilgang kunne generere 1000 tilfældige regneudtryk (bestående af tal og operatorer) og kontrollere at app’en ikke crasher og giver et numerisk resultat hver gang. Sandsynligvis finder man ingen funktionelle fejl på simple operationer med få tilfældige tests; men hvis app’en fx har en skjult fejl ved meget store tal eller bestemte kombinationer, er der en lille chance for at random test fanger det. I praksis kunne testanalytikeren fordele de tilfældige tests så de dækker forskellige slags operationer (addition, multiplikation osv.) i rimeligt omfang frem for fuldstændig uniform tilfældighed. Random testing bruges ofte sammen med monitorering af output for at opdage anomalier – f.eks. i en grafikmotor kunne man generere random objekter og se efter grafiske fejl eller krasj.
Adfærdsbaserede testteknikker
Adfærdsbaserede teknikker (behavior-based) fokuserer på systemets dynamiske opførsel og brugsscenarier frem for isolerede dataværdier. De modellerer typisk brugerinteraktioner, tilstandsforløb eller forretningsprocesser. ATA 4.0 introducerer her teknikker som CRUD-test, Tilstandsovergangstest og scenariebaseret test. Disse sigter mod at verificere, at systemet korrekt håndterer forskellige tilstande og sekvenser af handlinger over tid.
CRUD-test
Beskrivelse: CRUD står for Create, Read, Update, Delete – det er de fire basale operationer på dataobjekter i et system. CRUD-testing er en teknik hvor man verificerer hele livscyklussen for centrale data-entiteter ved at gennemspille scenarier, der opretter, læser, opdaterer og sletter disse entiteter. Ideen er at teste at hver af CRUD-funktionerne virker individuelt og i sammenhæng: f.eks. at man kan oprette en post, at den korrekte information gemmes (read), at feltændringer slår igennem (update), og at sletning faktisk fjerner data uden bivirkninger. CRUD-tests kan udføres som end-to-end tests hvor en “rejse” for et dataelement følges fra oprettelse til sletning.
Styrker: CRUD-test er meget naturlig for systemer der håndterer vedvarende data, og sikrer fuld dækning af basale usecases for datahåndtering. Den kan afsløre integritetsfejl, f.eks. at updates ikke propaganderer korrekt, at slettede data stadig kan tilgås (ophængende referencer), eller at der opstår fejl ved genbrug af slettede id’er. CRUD-scenarier ligner ofte virkelige brugerflows (oprette en ny kunde, rette kundens info, derefter slette vedkommende), så de har høj forretningsrelevans. Teknikken kan også kombineres med databaseverifikation – f.eks. at data faktisk ændres i DB efter en update.
Svagheder: CRUD-test dækker kun de mest grundlæggende datacyklusser; den siger ikke noget om funktionalitet ud over Create/Read/Update/Delete. Systemer der ikke er centreret om dataobjekter får mindre udbytte af CRUD-tilgangen. Endvidere kan CRUD-scenarier være tidskrævende at køre manuelt, da de involverer flere trin (sammenlignet med enkelte input/output-tests). Hvis dataobjekter har komplekse relationer (f.eks. en ordre med ordrelinjer), kan CRUD-tests for én entitet kræve opsætning af flere associerede entiteter – det skal planlægges nøje.
Anvendelse: CRUD-testing er især relevant i forretningssystemer, CMS’er, CRM/ERP-software osv., hvor kernedriften er at maniplere poster (kunder, ordrer, produkter, etc.). Testanalytikere kan designe CRUD-scenarier for hver større domeneklasse i systemet. Teknikken harmonerer også med regressionstest: hver gang en ny version ruller ud, kan man køre et suite af CRUD-scenarier for at sikre at de basale datamanipulationer stadig fungerer (det fanger mange grove fejl tidligt).
Eksempel: Tænk på en kundedatabase: En CRUD-testcase kunne bestå af disse trin: 1) Opret en ny kunde via GUI’en (Create), 2) Søg eller hent kunden igen for at verificere at data er gemt korrekt (Read), 3) Opdater nogle kundeoplysninger som adresse eller telefon (Update), 4) Hent kunden igen og tjek at ændringen slog igennem (Read igen), 5) Slet kunden (Delete), 6) Forsøg at hente kunden en sidste gang for at sikre at vedkommende virkelig er slettet (forventet “not found”). Dette ene scenarie verificerer samlet set hele livscyklussen for Kunde-entiteten. Hvis fx opdateringen fejler (data ikke ændret) eller sletningen ikke fjerner alt (kunden kan stadig findes), vil CRUD-testen afsløre det.
Tilstandsovergangstest (state transition testing)
Beskrivelse: Tilstandsovergangstest går ud på at modellere systemet som en tilstandsmodel – dvs. identificere de forskellige tilstande systemet eller en komponent kan befinde sig i, og de hændelser (input) der medfører overgang fra én tilstand til en anden. Testtilfældene designes så de udfører gyldige og ugyldige tilstandsændringer for at verificere, at systemet håndterer dem korrekt. Det involverer typisk at tegne en tilstandsdiagram eller tilsvarende tabel (fx en tilstandsmatrix med "current state", "event", "next state" og "udfyld output/aktion"). Testerne fokuserer både på nominale overgange (lovlige sekvenser) og ikke-tilladte overgange(hvor systemet bør afvise handlinger eller håndtere fejl). ATA-pensum adresserer tilstandstest under adfærdsbaserede teknikker – testanalytikeren skal kunne anvende tilstandstabel eller diagram til at generere testcases, som dækker alle væsentlige tilstandsskift.
Styrker: Tilstandsovergangstest er ideel til at finde mangler i workflow-logik: fx om der findes døde tilstande (som aldrig kan nås, måske pga. manglende transitions), uforudsete tilstande (fejl hvis en transition opstår i en forkert kontekst), eller glemte cases (hvis en lovlig kombination af tilstand+event ikke er håndteret i koden). Teknikken sikrer, at man kommer rundt i alle hjørner af en tilstandsbaseret logik, inkl. loops og specielle sekvenser. Den er især stærk til at opdage fejl i sekvensafhængig funktionalitet, som ikke vil fremgå ved kun at teste enkeltstående input.
Svagheder: Hvis systemets tilstandsgraf er meget stor eller kompleks, kan det være vanskeligt at dække alt uden at explosion sker i antallet af testcases. Desuden kræver det at krav eller design specificerer (eller kan udledes til) en tydelig tilstandsmodel; i nogle projekter eksisterer dette måske kun implicit, hvilket gør testdesign krævende. Tilstandstest fokuserer kun på det flowmæssige aspekt – man bør kombinere med databaserede tests for at validere indholdet ved tilstandsændringer. At opsætte starttilstande for visse tests kan kræve lange pre-scripts (sekvenser for at komme i en given tilstand).
Anvendelse: Teknikken er standard ved embedded software, device-styring, spiltilstande, protokoller og generelt hvor "tilstandsautomater" er en passende model. Også i forretningssystemer kan brugerrejser modelleres som tilstande (fx en ordres livscyklus: Ny -> Godkendt -> Forsendt -> Faktureret -> Arkiveret). Testanalytikeren vil ud fra kravspecifikationen udlede en tilstandsgraf og så sikre testcases for hver overgang og for forsøg på ulovlige overgange. I nogle brancher er der standarder/krav: fx i finans kan workflow-tests kræves for at sikre alle faser af en transaktion er testet. ISO 29119-4 nævner Tilstandsovergangstest som en central teknik med dertilhørende coverage-mål (f.eks. at alle overgange er testet mindst én gang).
Eksempel: Tænk på en bruger-konto i et system, der kan være i tilstandene Inaktiv, Aktiv, Spærret. Overgange: Når en ny konto oprettes er den Inaktiv indtil e-mail bekræftes, så går den til Aktiv. Hvis der indtastes forkert kodeord for mange gange, går den til Spærret. En Spærret konto kan evt. genåbnes af support (tilbage til Aktiv). En tilstandstest-case kunne fx verificere: Start i Aktiv, forsøg login med forkert kode 5 gange → forvent at tilstanden skifter til Spærret. Dernæst forsøg login i Spærret tilstand → forvent afslag (ingen overgang). Så anmod om support-unlock → forvent tilstand tilbage til Aktiv. Her har vi testet en gyldig overgangskæde (Aktiv->Spærret->Aktiv) samt en ugyldig transition (login under Spærret). Et andet testtilfælde kunne starte i Inaktiv og teste at login ikke er mulig før aktivering (igen en ugyldig event), derefter simulere e-mail-verificering og tjekke at systemet nu tillader login iAktiv tilstand. Disse scenarier vil afsløre, om systemet fejler i at opdatere eller respektere brugerens status.
Scenarie-baseret test (brugsscenarier)
Beskrivelse: Scenarie-baseret test (også kaldet usecase test eller end-to-end test) indebærer at teste gennem fulde forretningsscenarier fra start til slut, i tråd med hvordan en bruger eller et system anvender funktionaliteten. I stedet for at teste enkeltfunktioner isoleret, kombinerer scenarietest flere trin i en realistisk sekvens. Ofte tager man udgangspunkt i beskrivelser af usecases eller brugerhistorier fra kravspecifikationen. Testanalytikeren udarbejder konkrete testcases, der følger disse historier: fx “kunde køber en vare online” som indeholder trin for søgning af produkt, tilføj til kurv, checkout, betaling, bekræftelse. Scenarie-tests validerer at hele denne kæde fungerer samlet, inkl. integration mellem moduler. ATA pensum kræver at man kan anvende scenarietest i relevante situationer – hvor der lægges vægt på at testanalytikeren kan vælge de vigtigste scenarier og variere dem(f.eks. alternative flows, fejlscenarier).
Styrker: Scenarietests er fremragende til at validere brugerrejser og end-to-end forretningsprocesser, hvilket sikrer, at systemet opfylder kundens forventede anvendelse. De fanger ofte integrationsfejl mellem komponenter (fordi man går på tværs af moduler) samt fejl i state ifm. længere sekvenser af handlinger, som unit-tests ikke opdager. Også brugervenligheds- eller konsistensproblemer kan blive tydelige, når man følger et komplet flow. Fra et stakeholder-perspektiv har scenarietests høj troværdighed – en bestået vigtig usecase giver stor tillid til systemets funktion.
Svagheder: Disse tests kan være tids- og ressourcekrævende, især hvis de køres manuelt. Et enkelt scenarie består af mange trin, så hvis én detalje fejler midtvejs, skal hele scenariet måske gentages efter fejlretning. Det kan være svært at isolere årsagen til en fejl i et langt scenarie (man ser kun at noget gik galt i løbet af flowet). Dækningen med få scenarier kan være begrænset – der er risiko for, at man overser nogle permutationsfejl, fordi man fokuserer på de typiske flows. Derfor bør scenarietests suppleres med mere målrettede teknik-tests (som EP/BVA for at prøve grænser, osv.).
Anvendelse: Næsten alle systemer drager fordel af scenarietest for de væsentligste anvendelsestilfælde. Testanalytikere vælger ofte højrisiko eller hyppigt brugte forretningsflows som scenarier. Eksempler: en kundeordre fra oprettelse til levering, et patientforløb i et hospitalsystem, en kontooprettelse med efterfølgende transaktioner i en banking-app. Scenarietests er også kernen i accepttest, hvor fokus er på at demonstrere at systemet understøtter brugerens arbejde. Ofte laves variationsscenarier: hovedscenarie for et usecase, plus alternative stier (f.eks. hvad hvis betaling fejler?). Som standard kan man sikre mindst ét scenarie pr. usecase i kravene.
Eksempel: Et e-handelswebsite vil have scenarier som “Gennemfør køb som registreret kunde”. Et sådant testforløb kunne bestå af: 1) Login som eksisterende kunde, 2) Søge efter et produkt, 3) Lægge produkt i kurv, 4) Gå til betaling og vælge leveringsadresse, 5) Indtaste betalingsoplysninger og gennemføre, 6) Forvent at få en ordrebekræftelse på skærm og e-mail. Denne end-to-end test sikrer at alle delsystemer (produktkatalog, lager, betalingsgateway, ordresystem, e-mailservice) spiller sammen. Hvis for eksempel betalingssiden ikke overfører det korrekte ordre-id til ordresystemet, vil scenariet fejle (måske ingen bekræftelse sendes) – noget der kunne overses i modulære tests. Man kan udvide med variationer: fx samme scenarie men kunden er ny og skal oprette konto først, eller kunden vælger at annullere ordren efter betaling – for at teste alternative flows.
Regelbaserede testteknikker
Regelbaserede teknikker anvender forretningsregler eller logiske betingelser som grundlag for testdesign. De adresserer primært systemets beslutningslogik – altså hvordan output afhænger af kombinationer af betingelser. I ATA 4.0 dækker regelbaseret test bl.a. beslutningstabeltest og den nyere teknik metamorfisk test. Herunder beskrives disse.
Beslutningstabeltest
Beskrivelse: Beslutningstabeltest er en teknik hvor man opstiller en tabel af betingelser og handlinger (outcomes) for en funktionslogik, og derefter designer testtilfælde til at dække alle reglerne i tabellen. Hver række (eller kolonne, afhængigt af notation) i en beslutningstabel repræsenterer en unik kombination af betingelser (typisk som sand/falsk eller i kategorier) samt den forventede output/aktion. En fuld beslutningstabel for n binære betingelser har 2n regler, men ofte kan nogle kombinationer ikke forekomme eller flere giver samme resultat – tabellen kan simplificeres. Testanalytikeren bruger tabellen til at sikre, at hvert af de mulige udfald er testet mindst én gang. ATA v4.0 forventer at man kan udarbejde og anvende beslutningstabeller i testdesign, hvilket ofte indebærer at identificere regler fra kravspecifikationens “hvis-så”-logikker.
Styrker: Beslutningstabeller er fremragende til at håndtere komplekse kombinationer af forretningsregler på en systematisk måde. De giver et klart overblik over, om der er mangler eller overlap i reglerne – f.eks. kan en tom række indikere en udefineret situation i kravene (som testen så kan afdække). Testmæssigt sikrer tabellen fuld regel-dækning: hver regel bliver til mindst én test. Teknikken kan dermed afsløre logiske fejl som fx: en bestemt kombination af input fejler fordi udvikleren ikke fik implementeret den gren, eller to forskellige kombinationer giver samme output hvor de burde have givet forskelligt (tegn på at en regel er for generel). Beslutningstabeller kan relativt let implementeres i testautomatisering ved at skripte gennem alle regellinjer (hvis input er kvantificerbare).
Svagheder: En komplet beslutningstabel kan vokse eksponentielt med antal betingelser, og hurtigt blive uhåndterlig. Man skal ofte reducere – fx ved at gruppere lignende betingelser eller udelade umulige kombinationer – hvilket kræver omhu; en dårlig forenkling kan give huller i testdækningen. Hvis kravene ikke er formelt specificerede, kan det være tidskrævende at udlede tabellen (testdesigneren skal fortolke tekst og udlede implicitte regler). Desuden fokuserer teknik kun på logik og ignorere sekvens/time-aspekter (her er tilstandstest bedre). Beslutningstabeltest kan overses i agile kontekster med user stories, da reglerne dér kan være spredt i acceptkriterier – det kræver disciplin at samle dem i tabelform.
Anvendelse: Typisk brugt når software har mange kombinerede forretningsregler, fx i beregningsmotorer (skatteberegning, lånegodkendelse), komplekse valideringer (formular med mange afhængige felter), eller konfigurationsvalg (hvor forskellige flag kombineres til visse funktioner). Også populært i test af regelmotorer eller ekspert-systemer. For testanalytikeren er det et værktøj til at arbejde struktureret med krav af typen “Hvis X og Y og Z så…”. Det indgår i mange teststrategier som en måde at sikre at alle væsentlige kombinationer af betingelser er prøvet.
Eksempel: Overvej en regel for forsikringspræmie beregning: Præmien afhænger af alder (under 25 vs 25 og over) samt antal skader sidste år (ingen skader vs mindst 1 skade). Vi kan opstille en beslutningstabel med betingelser: Alder<25? og SkadeHistorik=0? og udfald som fx præmie = høj, medium, lav alt efter kombinationen. En mulig tabel:
Alder < 25
Ingen skader
Forventet præmieklasse
Ja
Ja
Medium (ung men ingen skader)
Ja
Nej
Høj (ung med skader)
Nej
Ja
Lav (ældre, ingen skader)
Nej
Nej
Medium (ældre med skader)
Her er 4 regler. Beslutningstabeltesten kræver mindst én test pr. række. Det kunne være:
Test 1: Kør beregning for 22-årig med 0 skader ⇒ forvent præmie medium.
Test 2: 22-årig med 1 skade ⇒ høj.
Test 3: 30-årig med 0 skader ⇒ lav.
Test 4: 30-årig med 2 skader ⇒ medium.
Disse tests vil bekræfte om systemet implementerer præmie-logikken som specificeret i alle tilfælde. Hvis fx systemet fejlagtigt gav høj præmie til en 30-årig med skader (burde være medium), vil test 4 fange det – muligvis fordi en regel blev kodet forkert. Beslutningstabellen sikrer også, at vi ikke overser kombinationen “ældre med skader”, som måske er mindre oplagt uden tabellen.
Metamorfisk test (MT)
Beskrivelse: Metamorfisk test er en nyere avanceret teknik, der adresserer situationer, hvor det er svært at bestemme det forventede resultat for et givent input (det såkaldte oracle problem). Ideen er at udnytte relationer mellem forskellige kørsler af programmet frem for absolutte orakler. Man starter med en kilde-testcase med kendt (eller godtaget) output, og definerer en metamorf relation (MR) – en regel for hvordan output bør ændre sig hvis input ændres på en bestemt måde. Derefter genereres et eller flere follow-uptestcases ved at modificere input ifølge relationen, og systemets outputs sammenlignes mod den forventede relation. Hvis relationen ikke holder – dvs. programmet opfører sig inkonsistent – indikerer det en fejl. Metamorfiske relationer kan f.eks. være: “Hvis input X giver resultat Y, så bør input X’ (en variant af X) give resultat Y’” hvor Y’ er afledt af Y ud fra kendt egenskab. ATA 4.0 inkluderer metamorfisk test med henblik på test af AI-baserede systemer og andre komplekse domæner.
Styrker: Metamorfisk test er effektiv til at teste “det utestbare” – situationer hvor klassiske assertions er svære at formulere, fx fordi der ikke findes en nem oracle for korrekt output. Ved at kontrollere konsistens på tværs af test udfylder MT det hul. Det har vist sig særligt nyttigt i f.eks. machine learning (hvor vi ikke kan forudsige eksakt hvilket label en ny input bør få, men vi kan formulere metamorfoser, fx “rotation af billedet med 90° bør ikke ændre klassifikationen for symmetriske objekter”). En anden styrke er, at metamorfisk test kan generere nye testcases automatisk fra eksisterende – så man får en form for testforstærkning uden voldsom manuel indsats. Teknikken kan også forbedre testdata-dækning, især når der kombineres med random testing (random input køres, dernæst genereres metamorfiske variationer for at bekræfte resultaterne).
Svagheder: Nøglen ligger i at definere gode metamorfiske relationer – det kræver dyb domæneindsigt og kreativitet. Ikke alle systemer har oplagte metamorfoser. Hvis relationerne er for svage eller trivielle (f.eks. “hvis input er skaleret, output skal også skaleres”), kan et fejlbehæftet program stadig bestå dem uden at være korrekt. Teknikken identificerer, at noget er galt, men ikke nødvendigvis hvilket af testtilfældene der var defekt – der skal debugging til at isolere fejlen. Metamorfisk test er endnu relativt ny i mainstream-test, så værktøjsstøtte og erfaring kan være begrænset udenfor det akademiske område. Endelig, hvis systemet er fuldstændig deterministisk med let beregnelige orakler, er metamorfisk test overkill sammenlignet med bare at tjekke forventede outputs direkte.
Anvendelse: I praksis anvendt til AI/ML-algoritmer, beregningsvidenskab (simuleringer), optimeringsproblemer, søgemaskiner, kompilatorer og andre tilfælde hvor oracle-problemet opstår. F.eks. i en søgemaskine: det er svært at sige præcis hvad rankingen burde være for en given søgning (ingen gylden oracle), men metamorf relationen kan være “hvis jeg tilføjer et ekstra generisk ord til søgestrengen, bør resultaterne indeholde det originale topresultat” – hvis ikke, er der potentielt en defekt. ATA v4.0 pointerer behovet for metamorfisk test i lyset af AI: testanalytikere skal forstå konceptet for at teste f.eks. ML-modeller, hvor traditionelle verifikationsmetoder ikke er nok.
Eksempel: Overvej et matematikprogram der beregner funktioner, hvor vi ikke let kan kende det korrekte output. Et klassisk metamorf eksempel er en funktion f(x) der beregner sinus. Vi ved ikke på forhånd præcist hvad f(13°) er, men vi kender en relation: f(13°) og f(13°+360°) bør give samme resultat (sine med 360° periode). Så vi kan lave: Kilde-testcase: input 13°, få output Y. Follow-up testcase: input 373° (13+360), få output Y’. Forventet relation: Y’ = Y. Hvis programmet giver et andet resultat, er der en bug (f.eks. akkumuleret fejl i beregning). Et andet eksempel: En ML-model klassificerer billeder af håndskrevne tal. Vi tester et billede af tallet "8" og modellen giver output "8". Som metamorf relation kunne vi rotere billedet 180° (et “8” ser stadig ud som et "8"), køre det igennem – modelens output burde fortsat være "8". Hvis den pludselig klassificerer det som "3" efter rotation, er metamorf relation brudt, hvilket afslører et problem i modelens invarians. På denne måde kan vi teste ML-modellen uden at kende det korrekte label i absolut forstand, men ved at vide, at visse transformationer ikke bør ændre label.
Del 2
Hermed afslutter del 1 om ’Fra klassisk til moderne – testteknikker der gør en forskel i 2025’. Del 2 der omfatter erfaringsbaserede testteknikker og nye testteknikker der ikke er omfattet af det nye ATA-pensum. Del 2 forventes offentliggjort inden udgangen af juni 2025.
