Meny

Hva er testdata? Testdata Klargjøringsteknikker med eksempel

what is test data test data preparation techniques with example

Prøv Instrumentet Vårt For Å Eliminere Problemer

Lær hva som er testdata og hvordan du klargjør testdata for testing:

I det nåværende eposet med revolusjonerende vekst i informasjon og teknologi, opplever testere ofte omfattende forbruk av testdata i programvaretestets livssyklus.

Testerne samler / vedlikeholder ikke bare data fra eksisterende kilder, men de genererer også store mengder testdata for å sikre et høyt blomstrende bidrag i leveransen av produktet for bruk i den virkelige verden.

Derfor må vi som testere kontinuerlig utforske, lære og bruke de mest effektive tilnærmingene for datainnsamling, generering, vedlikehold, automatisering og omfattende datahåndtering for alle typer funksjonelle og ikke-funksjonelle tester.

Hva er testdata - forberedelse av testdata

I denne opplæringen vil jeg gi tips om hvordan du forbereder testdata slik at enhver viktig testtilfelle ikke blir savnet av feil data og ufullstendig oppsett av testmiljø.

Hva du vil lære:

Hva er testdata og hvorfor det er viktig

Med henvisning til en studie utført av IBM i 2016, omfatter søking, administrering, vedlikehold og generering av testdata 30% -60% av testernes tid. Det er ubestridelig bevis for at utarbeidelse av data er en tidkrevende fase av programvaretesting.

Testernes gjennomsnittlige tid brukt på TDM

Figur 1: Testernes gjennomsnittlige tid brukt på TDM

Likevel er det et faktum på tvers av mange forskjellige fagområder at de fleste dataforskere bruker 50% -80% av modellens utviklingstid på å organisere data. Og nå vurderer lovgivningen og så vel som den personlig identifiserbare informasjonen (PII), gjør testernes engasjement overveldende anstendig i testprosessen.

I dag er troverdigheten og påliteligheten av testdataene ansett som et kompromissløst element for bedriftseiere. Produkteierne ser spøkelseskopiene av testdataene som den største utfordringen, noe som reduserer påliteligheten til enhver applikasjon på dette unike tidspunktet for kundenes krav / krav til kvalitetssikring.

Tatt i betraktning betydningen av testdata, godtar de fleste programvareeiere ikke de testede applikasjonene med falske data eller mindre i sikkerhetstiltak.

På dette tidspunktet, hvorfor husker vi ikke hva testdata er? Når vi begynner å skrive testsakene våre for å verifisere og validere de gitte funksjonene og utviklede scenarier for applikasjonen under testen, trenger vi informasjon som brukes som input for å utføre testene for å identifisere og lokalisere feilene.

hvilken app lar deg laste ned youtube-videoer

Og vi vet at denne informasjonen må være presis og fullstendig for å gjøre feilene. Det er det vi kaller testdata. For å gjøre det nøyaktig, kan det være navn, land osv., Som ikke er sensitive, der data om kontaktinformasjon, SSN, medisinsk historie og kredittkortinformasjon er følsomme.

Dataene kan være i hvilken som helst form som:

  • Systemtestdata
  • SQL-testdata
  • Ytelsestestdata
  • XML-testdata

Hvis du skriver testsaker, trenger du inndata for alle typer test. Testeren kan gi disse inngangsdataene på tidspunktet for utførelsen av testtilfellene, eller applikasjonen kan plukke de nødvendige inngangsdataene fra de forhåndsdefinerte datastasjonene.

Dataene kan være hvilken som helst type inngang til applikasjonen, hvilken som helst fil som lastes inn av applikasjonen eller oppføringer som er lest fra databasetabellene.

Forberedelse av riktige inndata er en del av et testoppsett. Generelt kaller testere det a testbed forberedelse . I testbed er alle programvare- og maskinvarekrav satt ved hjelp av de forhåndsdefinerte dataverdiene.

Hvis du ikke har den systematiske tilnærmingen for å bygge data mens skrive og gjennomføre testsaker så er det sjanser for å savne noen viktige testsaker. Testerne kan lage sine egne data i henhold til testbehov.

Ikke stol på dataene som er opprettet av andre testere eller standard produksjonsdata. Lag alltid et nytt datasett i henhold til dine krav.

Noen ganger er det ikke mulig å lage et helt nytt datasett for hver eneste versjon. I slike tilfeller kan du bruke standard produksjonsdata. Men husk å legge til / sette inn dine egne datasett i denne eksisterende databasen. En beste måte å opprette data på er å bruke eksisterende eksempeldata eller testbed og legge til dine nye testcase-data hver gang du får den samme modulen for testing. På denne måten kan du bygge omfattende datasett over perioden.

Test Data sourcing utfordringer

Et av områdene innen generering av testdata, vurderer testerne at det er krav om datasamling for delsett. For eksempel har du over en million kunder, og du trenger tusen av dem for testing. Og disse eksempeldataene skal være konsistente og representere statistisk den riktige fordelingen av målgruppen. Med andre ord skal vi finne den rette personen å teste, noe som er en av de mest nyttige metodene for å teste brukssakene.

Og disse eksempeldataene skal være konsistente og representere statistisk den riktige fordelingen av målgruppen. Med andre ord skal vi finne den rette personen å teste, noe som er en av de mest nyttige metodene for å teste brukssakene.

I tillegg er det noen miljømessige begrensninger i prosessen. En av dem er å kartlegge PII-policyer. Siden personvern er en betydelig hindring, må testerne klassifisere PII-data.

Testdatahåndteringsverktøyene er utformet for å løse det nevnte problemet. Disse verktøyene foreslår retningslinjer basert på standardene / katalogen de har. Skjønt, det er ikke veldig trygg trening. Det gir fremdeles muligheten for revisjon av hva man gjør.

For å holde tritt med dagens og til og med fremtidige utfordringer, bør vi alltid stille spørsmål som når / hvor skal vi starte gjennomføringen av TDM? Hva skal automatiseres? Hvor mye investering skal bedriftene bevilge for testing i områder med kompetanseutvikling og bruk av nyere TDM-verktøy? Bør vi begynne å teste med funksjonell eller ikke-funksjonell testing? Og mye mer sannsynlige spørsmål som dem.

Noen av de vanligste utfordringene ved Test Data Sourcing er nevnt nedenfor:

  • Teamene har kanskje ikke tilstrekkelig kunnskap og ferdigheter med verktøy for testdata-generatorer
  • Testdatadekning er ofte ufullstendig
  • Mindre klarhet i datakrav som dekker volumspesifikasjoner under samlingsfasen
  • Testgrupper har ikke tilgang til datakildene
  • Forsinkelse i å gi produksjonsdata tilgang til testere av utviklere
  • Data om produksjonsmiljø er kanskje ikke fullt brukbare for testing basert på utviklede forretningsscenarier
  • Store datamengder kan trenge i løpet av kort tid
  • Dataavhengighet / kombinasjoner for å teste noen av forretningsscenariene
  • Testerne bruker mer tid enn nødvendig for å kommunisere med arkitekter, databaseadministratorer og BA for å samle inn data
  • For det meste opprettes eller utarbeides dataene under utførelsen av testen
  • Flere applikasjoner og dataversjoner
  • Kontinuerlig frigjøringssyklus på tvers av flere applikasjoner
  • Lovgivning for å ivareta personlig identifikasjonsinformasjon (PII)

På den hvite boksen siden av datatesten, forbereder utviklerne produksjonsdataene. Det er der QAs behov for å samarbeide med utviklerne for å fremme testdekning av AUT. En av de største utfordringene er å innlemme alle mulige scenarier (100% test case) med hver eneste mulige negative sak.

I denne delen snakket vi om testdatautfordringer. Du kan legge til flere utfordringer ettersom du har løst dem deretter. La oss deretter utforske ulike tilnærminger til håndtering av testdata og design.

Strategier for utarbeidelse av testdata

Vi vet av hverdagspraksis at aktørene i testindustrien kontinuerlig opplever forskjellige måter og midler for å forbedre testinnsatsen og viktigst av dens kostnadseffektivitet. I løpet av den korte løpet av evolusjon av informasjon og teknologi har vi sett når verktøy blir innlemmet i produksjons- / testmiljøene, økte produksjonsnivået betydelig.

Når vi snakker om fullstendighet og full dekning av testing, avhenger det hovedsakelig av kvaliteten på dataene. Ettersom testing er ryggraden for å oppnå kvaliteten på programvaren, er testdata kjernen i testprosessen.

Strategier for testdataadministrasjon (TDM)

Figur 2: Strategier for testdataadministrasjon (TDM)

Oppretting av flate filer basert på kartleggingsreglene. Det er alltid praktisk å lage et delsett av dataene du trenger fra produksjonsmiljøet der utviklere designet og kodet applikasjonen. Denne tilnærmingen reduserer faktisk testernes innsats for datautarbeidelse, og den maksimerer bruken av de eksisterende ressursene for å unngå ytterligere utgifter.

Vanligvis må vi lage dataene eller i det minste identifisere dem basert på hvilken type krav hvert prosjekt har helt i begynnelsen.

Vi kan bruke følgende strategier som håndterer prosessen med TDM:

  1. Data fra produksjonsmiljøet
  2. Henter SQL-spørringer som trekker ut data fra klientens eksisterende databaser
  3. Automatiserte datagenereringsverktøy

Testerne skal sikkerhetskopiere testingen med fullstendige data ved å vurdere elementene som vist i figur 3 her. Restene i smidige utviklingsteam genererer de nødvendige dataene for å utføre testsakene sine. Når vi snakker om testsaker, mener vi saker for forskjellige typer testing som den hvite boksen, den svarte boksen, ytelse og sikkerhet.

På dette tidspunktet vet vi at data for ytelsestesting skal kunne avgjøre hvor raskt systemet reagerer under en gitt arbeidsmengde for å være veldig nær ekte eller live store datamengder med betydelig dekning.

For testing av hvit boks forbereder utviklerne de nødvendige dataene for å dekke så mange grener som mulig, alle baner i programkildekoden og det negative Application Program Interface (API).

Test datagenereringsaktiviteter

Figur 3: Test datagenereringsaktiviteter

Til slutt kan vi si at alle som jobber i programvarens utvikling livssyklus ( SDLC ) som BA-er, bør utviklere og produkteiere være godt engasjert i prosessen med utarbeidelse av testdata. Det kan være en felles innsats. Og la oss nå ta deg med til problemet med ødelagte testdata.

Korrupte testdata

Før vi utfører testsaker på eksisterende data, bør vi forsikre oss om at dataene ikke er ødelagt / utdatert, og at applikasjonen under testen kan lese datakilden. Vanligvis er sjansen for at data blir ødelagt når det er mer enn en tester som jobber på forskjellige moduler av en AUT i testmiljøet samtidig.

I det samme miljøet endrer testerne eksisterende data i henhold til deres behov / krav til testsakene. For det meste når testerne er ferdige med dataene, lar de dataene være som de er. Så snart neste tester henter de modifiserte dataene, og han / hun utfører en annen utføring av testen, er det en mulighet for den spesifikke testfeilen som ikke er kodefeil eller mangel.

I de fleste tilfeller blir dette ødelagt og / eller utdatert av data, noe som fører til feil. For å unngå og minimere sjansene for dataavvik, kan vi bruke løsningene som nedenfor. Og selvfølgelig kan du legge til flere løsninger på slutten av denne opplæringen i kommentarfeltet.

  1. Å ha sikkerhetskopi av dataene dine
  2. Returner de modifiserte dataene til opprinnelig tilstand
  3. Datadeling mellom testerne
  4. Hold datalageradministratoren oppdatert for endring / modifisering av data

Hvordan holder du dataene dine intakte i ethvert testmiljø?

De fleste ganger er mange testere ansvarlige for å teste den samme bygningen. I dette tilfellet vil mer enn en tester ha tilgang til vanlige data, og de vil prøve å manipulere det vanlige datasettet etter deres behov.

Hvis du har utarbeidet data for noen spesifikke moduler, er den beste måten å holde datasettet intakt å beholde sikkerhetskopier av det samme.

Testdata for Performance Test Case

Ytelsestester krever et veldig stort datasett. Noen ganger vil det ikke oppdage noen subtile feil som bare blir fanget av faktiske data opprettet av applikasjonen under test, når du oppretter data manuelt. Hvis du vil ha sanntidsdata, som det er umulig å opprette manuelt, så be lederen / lederen om å gjøre dem tilgjengelige fra live-miljøet.

Disse dataene vil være nyttige for å sikre at applikasjonen fungerer som den skal for alle gyldige innganger.

Hva er de ideelle testdataene?

Data kan sies å være ideelle hvis alle applikasjonsfeilene blir identifisert for den minste størrelsen på datasettet. Prøv å utarbeide data som vil omfatte all applikasjonsfunksjonalitet, men ikke overstiger kostnad og tidsbegrensning for å utarbeide data og kjøre tester.

Hvordan forbereder du data som sikrer maksimal testdekning?

Utform dataene dine med tanke på følgende kategorier:

1) Ingen data: Kjør testsakene dine på blanke eller standarddata. Se om riktige feilmeldinger genereres.

2) Gyldig datasett: Lag den for å sjekke om applikasjonen fungerer i henhold til kravene og gyldige inndata er riktig lagret i database eller filer.

3) Ugyldig datasett: Forbered ugyldige datasett for å sjekke applikasjonsatferd for negative verdier, alfanumeriske strenginnganger.

4) Ulovlig dataformat: Lag ett datasett med ulovlig dataformat. Systemet skal ikke godta data i ugyldig eller ulovlig format. Sjekk også at riktige feilmeldinger genereres.

5) Datasett for grensetilstand: Datasett som inneholder data utenfor området. Identifiser søknadsgrensesaker og utarbeid datasett som vil dekke både nedre og øvre rammebetingelser.

6) Datasettet for ytelse, belastning og stresstesting: Dette datasettet skal ha stort volum.

Denne måten å lage separate datasett for hver testtilstand vil sikre fullstendig testdekning.

Data for Black Box Testing

Kvalitetssikringstesterne utfører integrasjonstesting, systemtesting og akseptantesting, som er kjent som black box testing. I denne testmetoden har ikke testerne noe arbeid med den interne strukturen, utformingen og koden til applikasjonen under testen.

Testernes primære formål er å identifisere og lokalisere feil. Ved å gjøre dette bruker vi enten funksjonell eller ikke-funksjonell testing ved hjelp av forskjellige teknikker for black box testing.

Black Box Data Design Methods

Figur 4: Black Box Data Design Methods

På dette tidspunktet trenger testerne testdataene som input for å utføre og implementere teknikkene for black box testing. Og testerne bør utarbeide dataene som vil undersøke all applikasjonsfunksjonalitet uten å overstige den gitte kostnaden og tiden.

Vi kan designe dataene for testsakene våre med tanke på datasettkategorier som ingen data, gyldige data, ugyldige data, ulovlig dataformat, grensetilstandsdata, ekvivalenspartisjon, beslutningsdatatabell, tilstandsovergangsdata og brukssaksdata. Før de går inn i datasettkategoriene, starter testerne datainnsamling og analyse av de eksisterende ressursene til applikasjonen under tester (AUT).

I henhold til de tidligere nevnte punktene om å holde datalageret ditt alltid oppdatert, bør du dokumentere datakravene på test-case-nivå og merke dem som brukbare eller ikke-gjenbrukbare når du skripter testsakene dine. Det hjelper deg dataene som kreves for testing er godt ryddet og dokumentert helt fra begynnelsen som du kan referere til for videre bruk senere.

Testdataeksempel for åpen EMR AUT

For vår nåværende opplæring har vi Open EMR som Application Under Test (AUT).

=> Finn lenke for Open EMR-applikasjon her for din referanse / praksis.

Tabellen nedenfor illustrerer stort sett et utvalg av datakravsinnsamlingen som kan være en del av testdokumentasjonen og oppdateres når du skriver testsakene for testscenariene.

( MERK : Klikk på et hvilket som helst bilde for en forstørret visning)

innsamling av testdata krav 1

Oppretting av manuelle data for testing av Open EMR-applikasjon

La oss gå fremover til å lage manuelle data for testing av Open EMR-applikasjonen for de gitte datasettkategoriene.

1) Ingen data: Testeren validerer Open EMR-applikasjons-URL og “Søk eller legg til pasient” -funksjonene uten å gi noen data.

to) Gyldige data: Testeren validerer Open EMR-applikasjons-URL og 'Søk eller legg til pasient' -funksjonen med gyldige data.

3) Ugyldige data: Testeren validerer Open EMR-applikasjons-URL og “Søk eller legg til pasient” -funksjonen med ugyldige data.

4) Ulovlig dataformat: Testeren validerer Open EMR-applikasjons-URL og “Søk eller legg til pasient” -funksjonen med ugyldige data.

Testdata for 1-4 datasettkategorier:

Testdataprøver 2

5) Datasett for grensetilstand: Det er å bestemme inngangsverdier for grenser som enten er innenfor eller utenfor de gitte verdiene som data.

6) Datasett for ekvivalenspartisjon: Det er testteknikken som deler inndataene dine i inngangsverdiene til gyldig og ugyldig.

Testdata for 5thog 6thdatasettkategorier, som er for Open EMR brukernavn og passord:

Åpne EMT-testdata 3

c ++ tilfeldig mellom 0 og 1

7) Beslutningstabell datasett: Det er teknikken for å kvalifisere dataene dine med en kombinasjon av innganger for å gi forskjellige resultater. Denne metoden for black box testing hjelper deg med å redusere testinnsatsen din ved å verifisere hver kombinasjon av testdata. I tillegg kan denne teknikken sikre deg fullstendig testdekning.

Vennligst se under beslutningstabellens datasett for Open EMR-applikasjonens brukernavn og passord.

Beslutningstabelldata 4

Beregningen av kombinasjonene i tabellen ovenfor er beskrevet for detaljert informasjon som nedenfor. Du trenger det kanskje når du gjør mer enn fire kombinasjoner.

  • Antall kombinasjoner = Antall betingelser 1 Verdier * Antall betingelser 2 verdier
  • Antall kombinasjoner = 2 ^ Antall sanne / falske forhold
  • Eksempel: Antall kombinasjoner - 2 ^ 2 = 4

8) Datasett for tilstandstransisjonstest: Det er testteknikken som hjelper deg med å validere tilstandsovergangen til Application Under Test (AUT) ved å gi systemet inngangsbetingelsene.

For eksempellogger vi på Open EMR-applikasjonen ved å oppgi riktig brukernavn og passord ved første forsøk. Systemet gir oss tilgang, men hvis vi skriver inn feil innloggingsdata, nekter systemet tilgang. Statlig overgangstesting validerer at hvor mange påloggingsforsøk du kan gjøre før Open EMR lukkes.

Tabellen nedenfor viser hvordan enten det riktige eller feil forsøk på å logge inn reagerer

Pålogging Forsøk på testdata 5

9) Bruk saksprøvedato: Det er testmetoden som identifiserer testtilfellene våre som tar slutt til slutt-testing av en bestemt funksjon.

Eksempel, åpen EMR-pålogging:

Testdata for suksessfeil 6

Les også => Data data management teknikker

Egenskaper for gode testdata

Som tester må du teste modulen ‘Examination Results’ på nettstedet til et universitet. Tenk på at hele applikasjonen er integrert, og at den er i 'Ready for Testing' -tilstand. 'Examination Module' er knyttet til 'Registration', 'Courses' og 'Finance' moduler.

Anta at du har tilstrekkelig informasjon om applikasjonen, og at du opprettet en omfattende liste over testscenarier. Nå må du designe, dokumentere og utføre disse testtilfellene. I delen “Handlinger / trinn” eller “Testinnganger” i testsakene, må du nevne akseptable data som input for testen.

Dataene som er nevnt i testsaker, må velges riktig. Nøyaktigheten til kolonnen 'Faktiske resultater' i testdokumentet er hovedsakelig avhengig av testdataene. Så trinn for å forberede inngangstestdataene er viktig. Dermed er her min oversikt over 'DB Testing - Test Data Preparation Strategies'.

Test dataegenskaper

Testdataene bør velges nøyaktig og de må ha følgende fire kvaliteter:

1) Realistisk:

Med realistisk betyr det at dataene skal være nøyaktige i sammenheng med virkelige scenarier. For eksempel, for å teste feltet 'Alder', bør alle verdiene være positive og 18 eller høyere. Det er helt åpenbart at kandidatene for opptak til universitetet vanligvis er 18 år (dette kan defineres annerledes når det gjelder forretningskrav).

Hvis testingen gjøres ved hjelp av realistiske testdata, vil det gjøre appen mer robust ettersom de fleste av de mulige feilene kan fanges opp ved hjelp av realistiske data. En annen fordel med realistiske data er dets gjenbrukbarhet, noe som sparer tid og krefter på å lage nye data igjen og igjen.

Når vi snakker om realistiske data, vil jeg introdusere deg for konseptet med det gyldne datasettet. Et gyldent datasett er det som dekker nesten alle mulige scenarier som oppstår i det virkelige prosjektet. Ved å bruke GDS kan vi tilby maksimal testdekning. Jeg bruker GDS for å gjøre regresjonstesting i organisasjonen min, og dette hjelper meg å teste alle mulige scenarier som kan oppstå hvis koden går i produksjonsboksen.

Det er mange testdata generatorverktøy tilgjengelig i markedet som analyserer kolonneegenskapene og brukerdefinisjonene i databasen, og basert på disse genererer de realistiske testdata for deg. Få av de gode eksemplene på verktøyene som genererer data for databasetesting er DTM Data Generator , SQL Data Generator og Mockaroo .

2. Praktisk gyldig:

Dette ligner på realistisk, men ikke det samme. Denne egenskapen er mer relatert til forretningslogikken til AUT, f.eks. verdi 60 er realistisk i aldersfeltet, men praktisk talt ugyldig for en kandidat for eksamen eller til og med masterprogrammer. I dette tilfellet vil et gyldig område være 18-25 år (dette kan defineres i kravene).

3. Allsidig for å dekke scenarier:

c ++ tegn til int

Det kan være flere påfølgende forhold i et enkelt scenario, så velg dataene på en nøyaktig måte for å dekke maksimale aspekter av et enkelt scenario med minimum datasett, f.eks. mens du oppretter testdata for resultatmodul, bør du ikke bare vurdere tilfellet med vanlige studenter som fullfører programmet. Vær oppmerksom på studentene som gjentar det samme kurset og tilhører forskjellige semestre eller til og med forskjellige programmer. Datasettet kan se slik ut:

MR# Student ID Program_ID Kurs_ID Karakter
1 BCS-høst2011-morgen-01 BCS-F11 CS-401 TIL
to BCS-Våren 2011-Kveld-14 BCS-S11 CS-401 B +
3 MIT-høst2010-ettermiddag-09 MIT-F10 CS-401 TIL-
... ... ... ... ...

Det kan være flere andre interessante og vanskelige underforhold. F.eks. begrensningen av år for å fullføre et studieprogram, bestått et forutsetningskurs for å registrere et kurs, maksimumsnr. av kurs en student kan melde seg på i et enkelt semester osv. etc. Sørg for å dekke alle disse scenariene med omhu med det endelige datasettet.

gode testdata

4. Eksepsjonelle data (hvis aktuelt / påkrevd):

Det kan være visse eksepsjonelle scenarier som forekommer sjeldnere, men som krever stor oppmerksomhet når det skjedde, f.eks. funksjonshemmede studenter relaterte problemer.

En annen god forklaring og et eksempel på det eksepsjonelle datasettet ses i bildet nedenfor:

Eksepsjonelle data

Ta bort:

Testdata er kjent som gode testdata hvis de er realistiske, gyldige og allsidige. Det er en ekstra fordel hvis dataene også gir dekning for eksepsjonelle scenarier.

Test teknikker for forberedelse av data

Vi har kort diskutert de viktige egenskapene til testdata, og det har også utdypet hvordan valg av testdata er viktig mens du gjør databasetestingen. La oss nå diskutere ' teknikker for å utarbeide testdata ' .

Det er bare to måter å forberede testdata på:

Metode nr. 1) Sett inn nye data

Skaff deg en ren DB og sett inn alle dataene som spesifisert i testsakene dine. Når alle nødvendige og ønskede data er lagt inn, begynner du å utføre testsakene og fyller 'Bestått / ikke bestått' -kolonnene ved å sammenligne 'Faktisk utdata' med 'Forventet utdata'. Høres enkelt ut, ikke sant? Men vent, det er ikke så enkelt.

Få viktige og kritiske bekymringer er som følger:

  • En tom forekomst av databasen er kanskje ikke tilgjengelig
  • Innsatte testdata kan være utilstrekkelig for å teste noen tilfeller som ytelse og belastningstesting.
  • Å sette inn de nødvendige testdataene i tom DB er ikke en enkel jobb på grunn av databasetabellavhengighet. På grunn av denne uunngåelige begrensningen kan datainnsetting bli en vanskelig oppgave for testeren.
  • Innsetting av begrensede testdata (bare i henhold til testsakens behov) kan skjule noen problemer som bare kan bli funnet med det store datasettet.
  • For innsetting av data kan det være nødvendig med komplekse spørsmål og / eller prosedyrer, og for dette vil tilstrekkelig hjelp eller hjelp fra DB-utvikleren (e) være nødvendig.

Ovennevnte fem saker er de mest kritiske og de mest åpenbare ulempene med denne teknikken for utarbeidelse av testdata. Men det er også noen fordeler:

  • Utførelse av TC-er blir mer effektiv ettersom DB bare har de nødvendige dataene.
  • Feilisolering krever ikke tid ettersom bare dataene som er spesifisert i testtilfeller er til stede i DB.
  • Mindre tid som kreves for testing og sammenligning av resultater.
  • Rotfri testprosess

Metode 2) Velg eksempeldatasett fra faktiske DB-data

Dette er en gjennomførbar og mer praktisk teknikk for utarbeidelse av testdata. Det krever imidlertid gode tekniske ferdigheter og krever detaljert kunnskap om DB Schema og SQL. I denne metoden må du kopiere og bruke produksjonsdata ved å erstatte noen feltverdier med dummyverdier. Dette er det beste datasettet for testingen, da det representerer produksjonsdataene. Men dette er kanskje ikke gjennomførbart hele tiden på grunn av datasikkerhets- og personvernproblemer.

Ta bort:

I avsnittet ovenfor har vi diskutert teknikkene for forberedelse av testdata. Kort sagt, det er to teknikker - enten lag nye data eller velg et delsett fra allerede eksisterende data. Begge må gjøres slik at de valgte dataene gir dekning for forskjellige testscenarier, hovedsakelig gyldig og ugyldig test, ytelsestest og nulltest.

I den siste delen, la oss også ta en rask omvisning av datagenereringsmetoder. Disse tilnærmingene er nyttige når vi trenger å generere nye data.

Tilnærminger til generering av testdata:

  • Manuell generering av testdata: I denne tilnærmingen blir testdataene skrevet inn manuelt av testere i henhold til testtilfellekravene. Det er en tid å ta prosessen og også utsatt for feil.
  • Automatisk generering av testdata: Dette gjøres ved hjelp av datagenereringsverktøy. Den største fordelen med denne tilnærmingen er dens hastighet og nøyaktighet. Det kommer imidlertid til en høyere pris enn manuell generering av testdata.
  • Back-end datainjeksjon : Dette gjøres gjennom SQL-spørsmål. Denne tilnærmingen kan også oppdatere eksisterende data i databasen. Det er raskt og effektivt, men bør implementeres veldig nøye slik at den eksisterende databasen ikke blir ødelagt.
  • Bruke tredjepartsverktøy : Det finnes verktøy tilgjengelig i markedet som først forstår testscenariene dine, og deretter genererer eller injiserer data tilsvarende for å gi bred testdekning. Disse verktøyene er nøyaktige ettersom de er tilpasset i henhold til bedriftens behov. Men de er ganske kostbare.

Ta bort:

Det er fire tilnærminger for å teste datagenerering:

  1. Håndbok,
  2. automasjon,
  3. back-end datainjeksjon,
  4. og tredjepartsverktøy.

Hver tilnærming har sine egne fordeler og ulemper. Du bør velge tilnærmingen som tilfredsstiller din virksomhets og testbehov.

Konklusjon

Å lage komplette programvaretestdata i samsvar med bransjestandardene, lovgivningen og grunnlagsdokumentene til det gjennomførte prosjektet er et av hovedansvarene til testerne. Jo mer vi effektivt administrerer testdataene, jo mer kan vi distribuere rimelige feilfrie produkter for brukere i den virkelige verden.

Testdataadministrasjon (TDM) er prosessen som er basert på analysen av utfordringer og introduserer pluss å bruke de beste verktøyene og metodene for å håndtere de identifiserte problemene uten å gå på kompromiss med påliteligheten og full dekning av sluttproduktet (produktet).

Vi må alltid komme med spørsmål for å søke på innovative og mer kostnadseffektive metoder for å analysere og velge testmetoder, inkludert bruk av verktøy for å generere data. Det er allment bevist at veldesignede data lar oss identifisere mangler ved applikasjonen under testen i hver fase av en flerfaset SDLC.

Vi må være kreative og delta med alle medlemmene i og utenfor vårt smidige team. Vennligst del din tilbakemelding, erfaring, spørsmål og kommentarer slik at vi kan fortsette de tekniske diskusjonene våre for å maksimere vår positive innvirkning på AUT ved å administrere data.

Forberedelse av riktige testdata er en sentral del av 'oppsett av prosjekttestmiljø'. Vi kan ikke bare gå glipp av testsaken og si at fullstendige data ikke var tilgjengelige for testing. Testeren skal lage sine egne testdata i tillegg til eksisterende standard produksjonsdata. Datasettet ditt bør være ideelt når det gjelder kostnad og tid.

Vær kreativ, bruk dine egne ferdigheter og vurderinger til å lage forskjellige datasett i stedet for å stole på standard produksjonsdata.

Del II - Den andre delen av denne veiledningen er på ' Test generering av data med GEDIS Studio Online Tool ”.

Har du møtt problemet med ufullstendige testdata for testing? Hvordan du klarte det? Del dine tips, erfaringer, kommentarer og spørsmål for å berike dette diskusjonstemnet ytterligere.

Anbefalt lesing

^