Hva er testdata i programvaretesting?

Som tester kan du tenke at det å designe testtilfeller er utfordrende nok – så hvorfor bry seg med noe så rutinepreget som testdata? Denne veiledningen introduserer testdata, forklarer hvorfor de er viktige og deler praktiske tips for å generere dem raskt.

Hva er testdata i programvaretesting?

Testdata i programvaretesting er inputen som gis til et program under testkjøring. Den representerer data som enten påvirker eller påvirkes av programvaren under testing. Testdata brukes i positiv testing – for å bekrefte at funksjoner gir forventede resultater for gitte input – og i negativ testing for å sjekke hvordan programvaren håndterer uvanlige, eksepsjonelle eller ugyldige input.

Dårlig utformede testdata dekker ikke alle mulige scenarier, noe som direkte hemmer programvarekvaliteten.

Hva er generering av testdata, og hvorfor bør testdata opprettes før testkjøring?

Testing er en prosess som produserer og forbruker store mengder data. Dataene som brukes i testing beskriver startbetingelsene for en test og er mediet som testeren samhandler med programvaren gjennom. Det er derfor en avgjørende del av de fleste funksjonelle tester.

Avhengig av testmiljøet ditt, kan det hende du må skape test data fra bunnen av, eller i det minste identifiser et passende eksisterende datasett for din test tilfellerTestdata opprettes vanligvis synkronisert med testtilfellet den støtter.

Testdata kan genereres på fire vanlige måter:

• Manuelt, av en tester eller forretningsanalytiker.
• Massekopiering av data fra et produksjonsmiljø til testmiljøet.
• Massekopiering av testdata fra eldre klientsystemer.
• Automatiserte verktøy for generering av testdata.

Eksempeldata bør genereres før du Testkjøringen starter, fordi det er vanskelig å administrere å opprette den senere. Mange testmiljøer krever flere forhåndstrinn eller tidkrevende konfigurasjon før data kan lastes inn. Hvis datagenerering skjer i løpet av utførelsesfasen, risikerer du å gå glipp av testfristen.

Avsnittene nedenfor beskriver flere testtyper sammen med forslag til deres testdatabehov.

Testdata for hvit Box Testing

In Hvit Box Testing, testdatahåndtering er avledet fra direkte undersøkelse av koden som testes. Utvalgskriteriene inkluderer vanligvis:

• Dekning av filialer: generere data slik at hver gren i kildekoden testes minst én gang.
• Stitesting: håndverksdata slik at hver bane utøves minst én gang.
• Negativ API-testing: bruk ugyldige parametertyper eller ugyldige argumentkombinasjoner til å kalle interne metoder.

Testdata for ytelsestesting

Ytelsestesting måler hvor raskt et system reagerer under en bestemt arbeidsbelastning. Målet er ikke å finne funksjonelle feil, men å identifisere flaskehalser. Eksempeldatasettet må være svært nær ekte eller levende produksjonsdata for at resultatene skal være meningsfulle.

Hvordan får du tak i slike data? Den mest pålitelige kilden er kunder seg selv. De kan enten tilby et eksisterende datasett eller beskrive hvordan data fra den virkelige verden ser ut, slik at du kan modellere det. I en vedlikeholdstesting prosjektet, kan du kopiere data fra produksjonen til testområdet. Det er god praksis å anonym (forvrenge) sensitive felt – personnummer, kredittkortnummer, bankopplysninger – før det lages noen kopi.

Testdata for sikkerhetstesting

Sikkerhetstesting bekrefter at et informasjonssystem beskytter data mot ondsinnede hensikter. Datasett må dekke fire søyler:

• Konfidensialitet: Informasjon fra klienter behandles strengt konfidensielt og deles ikke med eksterne parter. Hvis applikasjonen bruker SSL, må du designe data som beviser at krypteringen er korrekt.
• Integrity: informasjonen som returneres av systemet er korrekt. Bygg data ved å gjennomgå design, kode, databaseskjemaer og filstrukturer.
• Autentisering: prosessen med å etablere brukeridentitet. Bruk forskjellige kombinasjoner av brukernavn og passord for å bekrefte at bare autoriserte personer får tilgang.
• Autorisasjon: rettighetene som er gitt til en bestemt bruker. Kombiner brukere, roller og operasjoner for å bekrefte at bare brukere med tilstrekkelige rettigheter kan utføre en bestemt operasjon.

Testdata for svart Box Testing

I svart Box Testing av koden er ikke synlig for testeren. Funksjonelle testtilfeller bør inneholde data som oppfyller følgende kriterier:

• Ingen data: sjekk svaret når ingenting er sendt inn.
• Gyldige data: sjekk svaret med korrekte testdata.
• Ugyldige data: sjekk svaret med feil testdata.
• Ulovlig dataformat: Sjekk svaret når dataene er i et format som ikke støttes.
• Datasett for grensebetingelser: data som sitter på minimums-, maksimums- og like utenfor grenseverdier.
• Ekvivalenspartisjonsdatasett: data som representerer hver ekvivalensklasse.
• Datasett for beslutningstabell: data som utøver alle regler i en beslutningstabell.
• Datasett for tilstandsovergang: data som driver systemet gjennom hver definerte tilstandsovergang.
• Brukstilfelle-testdata: data samkjørt med ende-til-ende-brukstilfeller.

OBS: Avhengig av applikasjonen som testes, kan du bruke noen eller alle kategoriene ovenfor.

Automatiserte verktøy for generering av testdata

Automatiserte verktøy genererer store, varierte datasett raskere enn noen manuell prosess. To etablerte eksempler er:

• DTM-testdata Generator – et tilpassbart verktøy som produserer data, tabeller, visninger og prosedyrer for databasetestingsscenarier, inkludert ytelse, kvalitetssikring, last og brukervennlighet.
• Datatect - en SQL datagenerator fra Banner Software som lager realistiske testdata i ASCII flatfiler eller direkte inn i RDBMS-systemer som Oracle, Sybase, SQL Server og Informix.

For en evaluert, oppdatert kortliste, se 10 beste testdata Generator verktøy.

Beste praksis for håndtering av testdata

Pålitelige testdata avhenger av disiplinert hushjelppingFølg disse fremgangsmåtene for å holde datasettene i god stand på tvers av utgivelser:

• Versjon av dataene dine: lagre datasett i et repositorium sammen med testtilfellene som bruker dem, slik at endringer kan revideres.
• Maskefølsomme felt: anonymiser personlige, økonomiske og helsemessige data før kopiering fra produksjon.
• Oppdater regelmessig: gjenoppbygge datasett ved hver utgivelse for å holde tritt med endringer i skjemaer og forretningsregler.
• Dokumenter forventede resultater: Koble hvert datasett med det forventede resultatet, slik at feil blir enkle å sortere.
• Automatiser såing: Bruk skript eller fixturer til å laste inn data i starten av hver testkjøring, noe som sikrer repeterbarhet.

Spørsmål og svar