Hvad er testdata i softwaretest?

Som tester kan du måske mene, at det er udfordrende nok at designe testcases – så hvorfor overhovedet besvære sig med noget så rutinepræget som testdata? Denne vejledning introducerer testdata, forklarer, hvorfor de er vigtige, og deler praktiske tips til at generere dem hurtigt.

Hvad er testdata i softwaretest?

Testdata i softwaretest er det input, der gives til et softwareprogram under testudførelse. Det repræsenterer data, der enten påvirker eller påvirkes af softwaren under testning. Testdata bruges i positiv testning - til at verificere, at funktioner producerer forventede resultater for givne input - og i negativ testning til at kontrollere, hvordan softwaren håndterer usædvanlige, exceptionelle eller ugyldige input.

Dårligt designede testdata dækker ikke alle mulige scenarier, hvilket direkte hæmmer softwarekvaliteten.

Hvad er generering af testdata, og hvorfor skal testdata oprettes før testkørsel?

Testning er en proces, der producerer og forbruger store mængder data. De data, der bruges i testning, beskriver de indledende betingelser for en test og er det medie, hvorigennem testeren interagerer med softwaren. Det er derfor en afgørende del af de fleste funktionelle tests.

Afhængigt af dit testmiljø skal du muligvis skabe test data fra bunden, eller i det mindste identificer et passende eksisterende datasæt til din test tilfældeTestdata oprettes typisk synkroniseret med den testcase, de understøtter.

Testdata kan genereres på fire almindelige måder:

• Manuelt af en tester eller forretningsanalytiker.
• Massekopiering af data fra et produktionsmiljø til testmiljøet.
• Massekopiering af testdata fra ældre klientsystemer.
• Automatiserede værktøjer til generering af testdata.

Eksempeldata skal genereres før Testudførelsen begynder, fordi det er vanskeligt at administrere oprettelsen af ​​den senere. Mange testmiljøer kræver flere forudgående trin eller tidskrævende konfiguration, før data kan indlæses. Hvis datagenerering sker under udførelsesfasen, risikerer du at misse testfristen.

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

Testdata for hvid Box Test

In Hvid Box Test, testdatahåndtering er afledt af direkte undersøgelse af den kode, der testes. Udvælgelseskriterierne omfatter typisk:

• Filialdækning: generere data, så hver gren i kildekoden testes mindst én gang.
• Stitestning: håndværksdata, så hver sti udføres mindst én gang.
• Negativ API-test: Brug ugyldige parametertyper eller ugyldige argumentkombinationer til at kalde interne metoder.

Testdata til præstationstestning

Test af ydeevne måler hvor hurtigt et system reagerer under en bestemt arbejdsbyrde. Målet er ikke at finde funktionelle fejl, men at identificere flaskehalse. Eksempeldatasættet skal være meget tæt på virkelig eller levende produktionsdata for at resultaterne er meningsfulde.

Hvordan får man fat i sådanne data? Den mest pålidelige kilde er kunder selv. De kan enten levere et eksisterende datasæt eller beskrive, hvordan data fra den virkelige verden ser ud, så du kan modellere dem. I en vedligeholdelsestest projekt, kan du kopiere data fra produktionen til testmiljøet. Det er god praksis at anonymisere (forvrænge) følsomme felter — CPR-numre, kreditkortnumre, bankoplysninger — før der laves nogen kopi.

Testdata til sikkerhedstest

Sikkerhedstest verificerer, at et informationssystem beskytter data mod ondsindede hensigter. Datasæt skal dække fire søjler:

• Fortrolighed: Oplysninger fra klienter opbevares strengt fortroligt og deles ikke med eksterne parter. Hvis applikationen bruger SSL, skal der designes data, der beviser, at krypteringen er korrekt.
• Integrity: De oplysninger, der returneres af systemet, er korrekte. Opbyg data ved at gennemgå design, kode, databaseskemaer og filstrukturer.
• Godkendelse: processen med at etablere brugeridentitet. Brug forskellige kombinationer af brugernavne og adgangskoder for at bekræfte, at kun autoriserede personer får adgang.
• Bemyndigelse: de rettigheder, der er tildelt en bestemt bruger. Kombinér brugere, roller og handlinger for at bekræfte, at kun brugere med tilstrækkelige rettigheder kan udføre en bestemt handling.

Testdata for sort Box Test

I sort Box Test af koden er ikke synlig for testeren. Funktionelle testcases skal indeholde data, der opfylder følgende kriterier:

• Ingen data: Tjek svaret, når der ikke er indsendt noget.
• Gyldige data: Tjek svaret med korrekte testdata.
• Ugyldige data: Tjek svaret med forkerte testdata.
• Ulovligt dataformat: Tjek svaret, når dataene er i et ikke-understøttet format.
• Datasæt for randbetingelser: data, der ligger på minimums-, maksimums- og lige uden for grænseværdier.
• Ækvivalenspartitiondatasæt: data, der repræsenterer hver ækvivalensklasse.
• Beslutningstabeldatasæt: data, der udøver alle regler i en beslutningstabel.
• Datasæt for tilstandsovergang: data, der driver systemet gennem hver defineret tilstandsovergang.
• Data fra brugsscenarietest: data afstemt med end-to-end use cases.

Bemærk: Afhængigt af den applikation, der testes, kan du bruge nogle eller alle ovenstående kategorier.

Automatiserede testdatagenereringsværktøjer

Automatiserede værktøjer genererer store, varierede datasæt hurtigere end nogen manuel proces. To veletablerede eksempler er:

• DTM-testdata Generator — et brugerdefineret værktøj, der producerer data, tabeller, visninger og procedurer til databasetestscenarier, herunder ydeevne, kvalitetssikring, belastning og brugervenlighed.
• Datatect - en SQL datagenerator fra Banner Software, der skaber realistiske testdata i ASCII-flade filer eller direkte i RDBMS-systemer som f.eks. Oracle, Sybase, SQL Server og Informix.

For en evalueret, opdateret liste over udvalgte, se 10 Bedste Test Data Generator Værktøjer.

Bedste praksis for håndtering af testdata

Pålidelige testdata afhænger af disciplineret husholderskepingFølg disse fremgangsmåder for at holde datasættene sunde på tværs af udgivelser:

• Versionsversion af dine data: Gem datasæt i et repository sammen med de testcases, der bruger dem, så ændringer kan revideres.
• Maskefølsomme felter: anonymiser personlige, økonomiske og sundhedsmæssige data, før de kopieres fra produktionssystemet.
• Opdater regelmæssigt: Genopbyg datasæt ved hver udgivelse for at holde trit med ændringer i skemaer og forretningsregler.
• Dokumentér forventede resultater: Par hvert datasæt med det forventede resultat, så fejl er nemme at sortere fra hinanden.
• Automatiser såning: Brug scripts eller fixtures til at indlæse data i starten af ​​hver testkørsel, hvilket sikrer repeterbarhed.

Ofte Stillede Spørgsmål