Testdatasæt og referencedata: sådan bygges en test

Forside › Kvalitet og standarder · Gennemgået oktober 2026 · Af John Nielsen

Et testdatasæt er data, hvor du på forhånd ved præcis, hvad der findes: hvilke filer, beskeder, logposter, sletninger og tidsstempler. Kører du et værktøj eller en metode på datasættet og sammenligner med facit, kan du vise, hvad metoden finder, hvad den overser, og hvor den tager fejl. Hvorfor validering er nødvendig, og hvordan den indgår i den samlede kontrol af værktøjer, er beskrevet i verifikation af værktøjer. Denne artikel handler om håndværket: hvordan selve datasættet designes, bygges og dokumenteres, så testen kan gentages og forsvares.

Facit først

Det vigtigste dokument i en test er facitlisten, og den skal skrives, før værktøjet køres. Ellers er der risiko for, at forventningen tilpasses resultatet. Facitlisten beskriver hver forventet observation så konkret, at den kan sammenlignes felt for felt:

Handling · Fil oprettet, omdøbt, slettet; besked sendt; regel oprettet
Tidspunkt · Med tidszone og kilden til uret
Forventet artefakt · Fx post i en database, en logpost eller en filsystempost
Forventet værdi · Filnavn, sti, afsender, indhold, størrelse
Forventet status · Aktiv, slettet, delvist overskrevet

Notér også de ting, der ikke må findes. En negativ kontrol, fx en fil, der aldrig har ligget på mediet, eller en besked i en anden tråd, viser, om værktøjet finder noget, der ikke er der.

Design: hvad skal testen afklare?

Et testdatasæt er ikke en generel samling af data. Det skal svare på et bestemt spørgsmål, typisk et, der har betydning i en konkret type sag:

Viser værktøjet slettede rækker i en SQLite-database, og hvordan markeres de?
Konverteres tidsstempler korrekt omkring skiftet mellem sommer- og vintertid?
Bevares danske tegn i filnavne, emnelinjer og chatbeskeder gennem eksporten?
Fanger en målrettet indsamling alle versioner af et dokument i et cloudlager?
Tolkes et bestemt artefakt ens af to værktøjer?

Start med spørgsmålet, og byg kun de data, der skal til for at besvare det. Et lille, præcist datasæt er lettere at dokumentere og gentage end et stort. Koblingen til kravet om, at metoden skal være egnet til formålet, står i ISO/IEC 27041.

Kanttilfældene er pointen

Værktøjer fejler sjældent på de almindelige data. De fejler på grænserne. Tag bevidst højde for:

Tid: hændelser i overgangsnatten ved sommertid, poster i flere tidszoner, enheder med forkert indstillet ur. → Sommertid og tidszoner i rapporten
Tegn: æ, ø og å, emojis, meget lange filnavne og stier.
Sletning: slettet og tømt papirkurv, slettet og delvist overskrevet, slettet i appen men stadig i en WAL-fil.
Størrelse: tomme filer, meget store filer, filer med forkert endelse.
Versioner: samme app eller samme styresystem i flere versioner, fordi formater ændres.

Byg datasættet kontrolleret

Datasættet skal skabes, så hver handling kan føres tilbage til en registreret aktivitet. Et par grundregler:

Ren start. Brug et nyinstalleret system, en nulstillet testtelefon eller en ny testkonto i en test-tenant. Virtuelle maskiner med snapshots gør det let at vende tilbage til udgangspunktet.
Kendt ur. Synkronisér uret mod en pålidelig kilde, og notér eventuelle afvigelser. Skal uret være forkert som del af testen, så sæt det bevidst og notér det.
Handlingslog. Skriv hver handling ned med tidspunkt, mens den udføres. Handlingsloggen er grundlaget for facitlisten.
Ingen andre brugere. Isolér testmiljøet, så automatiske opdateringer, synkronisering og baggrundstjenester ikke forstyrrer mere end nødvendigt. Det, der ikke kan undgås, skrives ned.
Sikring som i en sag. Sikr testmediet eller testkontoen med samme metode som i en rigtig undersøgelse, og beregn hashværdier af resultatet. → Hashalgoritmer: MD5, SHA-1 og SHA-256

Testmiljøet bør være adskilt fra analysemiljøet for rigtige sager, så testdata og bevisdata aldrig blandes. → Forensic-arbejdsstationen

Særligt for mobil og cloud

Mobiltelefoner og cloudtjenester er de sværeste at teste, fordi formater og tjenester ændres hyppigt, og fordi du ikke selv styrer serversiden.

Testtelefoner: Brug en telefon, der kun bruges til test, og notér styresystemets og de relevante apps’ versioner, før data skabes. Opdateres en app, er det i praksis et nyt testsæt.
Testkonti og test-tenants: Brug konti og tenants oprettet til formålet, aldrig en rigtig brugers konto. Registrér licensniveau og relevante indstillinger, fordi de afgør, hvad der logges.
Forsinkelse: Mange cloudlogs bliver først tilgængelige et stykke tid efter handlingen. Vent, og notér, hvornår posterne dukkede op.
Gentagelse: En eksport fra en cloudtjeneste kan ikke altid gentages med samme hashværdi. Sammenlign derfor indholdet post for post frem for kun hashværdien.

Offentlige testsæt som supplement

Der findes offentligt tilgængelige referencedatasæt og testbilleder, blandt andet NIST’s portal CFReDS (Computer Forensic Reference Data Sets) og forskningssamlingen Digital Corpora, der stiller diskimages, mobiludtræk og netværksoptagelser til rådighed med beskrivelser. NIST’s NSRL er en anden type reference: en samling hashværdier for kendt software, som bruges til at sortere kendte filer fra. De er nyttige, fordi andre har brugt dem, så resultater kan sammenlignes. NIST’s værktøjstest og datasæt er gennemgået i NIST CFTT og CFReDS, og vejledningerne om validering i SWGDE-vejledninger.

Begrænsningerne skal dog med:

De er sjældent bygget til danske forhold, fx danske tegn, dansk tidszone og danske apps.
Facit kan være mindre detaljeret end det, din test kræver.
De ældes. Et testbillede fra en ældre styresystemversion siger lidt om den aktuelle.

Brug dem som supplement og til sammenligning, og byg egne datasæt til de spørgsmål, der er afgørende i dine sager.

Sammenligning og vurdering

Når værktøjet er kørt, sammenlignes resultatet med facitlisten post for post. Registrér fire kategorier:

Fundet og korrekt · Værktøjet viser observationen med rigtige værdier
Fundet, men forkert · Fx forkert tidszone, afkortet tekst, forkert status
Ikke fundet · Observationen findes, men vises ikke
Fundet, men ikke i facit · Mulig fejltolkning, eller noget testen ikke kendte til

Den sidste kategori kræver omtanke. Det kan være værktøjet, der tager fejl, men det kan også være systemet, der har skabt et artefakt, du ikke forudså. Undersøg det, før det kaldes en fejl.

Er resultatet uventet, så gentag testen, før det kaldes en fejl. En forkert handling under opbygningen af datasættet, et ur, der ikke var synkroniseret, eller en baggrundstjeneste, der skrev til de samme filer, kan give afvigelser, der skyldes testen og ikke værktøjet. Notér både første og anden kørsel, også når de giver forskellige resultater.

Dokumentation og genbrug

En test, der ikke kan gentages, har begrænset værdi. Gem derfor:

formålet med testen og det spørgsmål, den besvarer,
handlingsloggen og facitlisten,
sikringen af testdata med hashværdier,
værktøj, version og indstillinger,
resultatet og sammenligningen,
konklusionen, herunder kendte begrænsninger.

Navngiv og versionér datasættene, så det er entydigt, hvilken test der er kørt mod hvilken værktøjsversion. Når et værktøj opdateres, kan testen så køres igen, og forskelle bliver synlige. Testarkivet er en naturlig del af en praksis’ kvalitetsstyring. → Kvalitetsstyring i en lille forensic-praksis

Hvad en test kan og ikke kan vise

En bestået test viser, at værktøjet håndterede netop disse data korrekt under netop disse betingelser. Den viser ikke, at værktøjet altid har ret. Data i en rigtig sag kan have en anden version, en anden opsætning eller en tilstand, testen ikke dækkede. I rapporten bør henvisningen til en test derfor være præcis: hvilken test, hvilken version og hvilke typer data. Er et fund afgørende og afviger fra det, testen dækker, er en målrettet test på et tilsvarende system ofte den bedste måde at underbygge fortolkningen på.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Kvalitet og standarder

Læs også: Afvigelser og fejl undervejs: sådan dokumenteres de · Kvalitetsstyring i en lille forensic-praksis

→ Second opinion på en IR- eller forensic-rapport · For sagkyndige · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT

Skrevet af John Nielsen, IT‑sagkyndig og indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Har været IT‑sagkyndig i danske retskredse og ved Den Fælles Europæiske Patentdomstol (UPC). Om John Nielsen · LinkedIn · Redaktionel politik