Hjem » Siste artikler » Slik lager du trygge testdata uten å lekke ekte informasjon

Slik lager du trygge testdata uten å lekke ekte informasjon

Hovedillustrasjon
Hovedillustrasjon. Foto: Jakub Zerdzicki / Pexels.

Enten du lager en liten nettside eller et større system, kommer du før eller siden til et punkt der du trenger data å teste med. Mange ender opp med å kopiere ekte kundedata eller produksjonsdatabasen, og det kan skape alvorlige personvern- og sikkerhetsproblemer.

I denne artikkelen ser vi på hvordan du kan lage gode testdata som ligner virkeligheten, uten å bruke ekte personopplysninger. Du får konkrete strategier, enkle eksempler og tips til hvordan du kan unngå typiske fallgruver.

Hvorfor testdata er viktigere enn du tror

Testdata er grunnlaget for å oppdage feil før de treffer virkelige brukere. Uten realistiske data kan funksjoner se ut til å virke, men knekke så snart systemet møter virkelige mønstre, rare tegn eller uvanlige kombinasjoner.

Samtidig kan uforsiktig bruk av ekte data gi deg store problemer. Personopplysninger kan havne på utvikler-PC-er, i skylagring eller i logger som ikke er godt nok sikret. Det er blant annet derfor mange virksomheter har strenge regler for håndtering av data fra produksjon.

Tre hovedtyper testdata du bør kjenne til

Det hjelper å tenke på testdata i tre kategorier, fordi de løser ulike behov og har ulike risikoer knyttet til seg.

  • Helt syntetiske data: Alt er generert, ingen kobling til virkelige personer eller hendelser.
  • Anonymiserte data: Basert på ekte data, men skjult eller endret slik at enkeltpersoner ikke kan gjenkjennes.
  • Maskerte data: Ekte struktur beholdes, men felt som navn, epost og telefonnummer erstattes med falske, tilsvarende verdier.

For mange mindre prosjekter holder det ofte å lage helt syntetiske data, mens større systemer noen ganger trenger maskerte eller anonymiserte datasett for å fange kompliserte mønstre.

Grunnprinsipper: hva gode testdata skal dekke

Gode testdata handler ikke bare om mengde, men om variasjon. Du vil at koden skal møte både det normale og det uvanlige, så du slipper overraskelser senere.

Tenk spesielt på disse typene verdier når du lager data:

  • Vanlige tilfeller: Typiske verdier du forventer at systemet skal håndtere daglig.
  • Grenseverdier: For eksempel maks lengde på et felt, minste og største tall, siste dato i en gyldig periode.
  • Sære eller «stygge» data: Spesialtegn, mellomrom i starten eller slutten, tomme felter, veldig store tall, nullverdier.
  • Kombinasjoner: Verdier som hver for seg er «lovlige», men som skaper spesielle regler når de opptrer sammen.

Slik lager du syntetiske data steg for steg

La oss ta utgangspunkt i en typisk situasjon: Du lager et lite system som lagrer kunder med navn, e-post, adresse og dato for registrering. Her er en konkret måte å bygge opp et testdatasett på.

  1. Start med strukturen
    Definer feltene du trenger: fornavn, etternavn, epost, gateadresse, postnummer, land og registreringsdato. Dette gir deg en klar mal.
  2. Lag en liten «ordbank»
    Lag lister med fornavn, etternavn, byer og domener, gjerne i kode. På den måten kan du kombinere dem til mange ulike, men fortsatt realistiske verdier.
  3. Generer variasjon
    Bruk en løkke eller et lite skript som plukker tilfeldig fra listene, setter sammen adressene og velger datoer i et fornuftig intervall, for eksempel de siste to årene.
  4. Legg inn bevisste «feil»
    Legg inn noen få rader med uvanlige verdier: et langt navn, et tomt felt der det skal være valgfritt, et postnummer med bokstav, en registreringsdato i fremtiden.

Eksempel på generering med kode

Under er et kort eksempel i Python som illustrerer prinsippet. Dette er ikke ment som produksjonsklar kode, men som et utgangspunkt du kan tilpasse.

Konseptet er enkelt:definer noen lister, trekk tilfeldige kombinasjoner, og skriv til en fil eller direkte til databasen din.

Viktige poenger når du bruker slike skript:

  • Ikke bland inn ekte data i listene dine.
  • Hold selve genereringsskriptet i versjonskontroll, så du kan gjenskape datasettet senere.
  • Dokumenter kort hva slags «rare» verdier du har lagt inn, slik at du forstår feilene når de dukker opp.

Fordeler og fallgruver med anonymiserte og maskerte data

Tematisk illustrasjon
Tematisk illustrasjon. Foto: Juanjo Jaramillo / Unsplash.

Noen ganger trenger du strukturen og kompleksiteten fra produksjon, for eksempel når du tester rapporter, ytelse eller kompliserte sammenhenger. Da kan anonymisering eller maskering være aktuelt.

Fordeler:Du får realistiske fordelinger, sammenhenger og datamengder. Spesielt nyttig når mange tabeller henger sammen, og det er vanskelig å lage syntetiske data manuelt.

Fallgruver:Anonymisering kan være vanskelig å gjøre riktig. Det kan være mulig å gjenskape identiteter hvis du ikke ødelegger nok detaljer, særlig i små datasett eller nisjesystemer.

Hvis du vurderer denne typen data i en arbeidssammenheng, bør du sjekke interne retningslinjer, snakke med ansvarlig for informasjonssikkerhet og eventuelt involvere noen som har erfaring med personvernregler.

Slik organiserer du testdata for mindre prosjekter

For små egne prosjekter og læringsprosjekter trenger du ikke avanserte verktøy. Det viktigste er at du er bevisst, og at du kan gjenskape dataene når du trenger det på nytt.

En praktisk måte å gjøre det på kan være:

  • Ha et eget skript i prosjektet som genererer testdata.
  • La skriptet kjøre mot en lokal database, for eksempel en egen utviklingsdatabase.
  • Rydd alt og regenerer når du har gjort strukturelle endringer.
  • Lag noen få, godt navngitte testkontoer du bruker under manuell testing.

Gode vaner som gjør testdata tryggere

Noen få vaner gir stor gevinst på sikt, enten du jobber alene eller i et team. Dette handler både om sikkerhet og om å gjøre livet lettere når du feilsøker.

  • Bland aldri test og produksjon: Ha tydelig adskilte databaser og miljøer. Ikke koble testmiljøer mot betalingsløsninger eller eksterne systemer som gjør reelle operasjoner.
  • Merk testdata tydelig: Bruk for eksempel egne domener for test-eposter, som ikke kan nå ekte mottakere.
  • Loggfør genereringen: Skriv til logg når du genererer testdata, så du vet hvilken versjon du tester mot.
  • Slett når du er ferdig: Testdata kan også inneholde sensitiv logikk, som interne ID-strukturer. Slett ubrukte testmiljøer og backup-kopier.

Når bør du bruke dedikerte verktøy

Etter hvert som prosjektene blir større, kan manuelle skript bli vanskelig å holde styr på. Da kan det være aktuelt å se på verktøy som er laget for datagenerering eller maskering.

Slike verktøy kan typisk:

  • Generere store mengder data ut fra en databasestruktur.
  • Maskere felter i en kopi av produksjonsdata etter en definert regel.
  • Lage scenarier for ytelsestesting og lasttesting.

Før du tar slike verktøy i bruk på ekte data, bør du likevel stoppe opp og vurdere risiko, og sjekke om det finnes retningslinjer i organisasjonen din for hvordan dette skal gjøres.

Oppsummert: bygg gode vaner tidlig

Det er fristende å «bare ta en dump» av produksjonsbasen for å få noe å teste på. Men hvis du venner deg til å tenke strukturert og bevisst rundt testdata allerede i små prosjekter, står du mye sterkere når du senere skal jobbe med større og mer følsomme systemer.

Start med syntetiske data, legg inn litt variasjon og bevisste grenseverdier, og hold testmiljøene dine tydelig adskilt fra alt som har ekte brukere. Da får du både bedre kodekvalitet og mindre hodebry rundt sikkerhet og personvern.

0 kommentarer