Hvad er testdata? Testdata Klargøringsteknikker med eksempel

what is test data test data preparation techniques with example

Lær, hvad der er testdata, og hvordan man forbereder testdata til test:

I det nuværende episke med revolutionerende vækst inden for information og teknologi oplever testere ofte et stort forbrug af testdata i softwaretestens livscyklus.

Testerne indsamler / vedligeholder ikke kun data fra de eksisterende kilder, men de genererer også enorme mængder testdata for at sikre deres højkvalitetsbidrag i leveringen af ​​produktet til brug i den virkelige verden.

Derfor skal vi som testere løbende undersøge, lære og anvende de mest effektive tilgange til dataindsamling, generering, vedligeholdelse, automatisering og omfattende datastyring til enhver form for funktionel og ikke-funktionel test.

I denne vejledning vil jeg give tip til, hvordan man forbereder testdata, så enhver vigtig testtilfælde ikke går glip af forkert data og ufuldstændig opsætning af testmiljø.

Hvad du lærer:

• Hvad er testdata, og hvorfor det er vigtigt
  • Test Data Sourcing Udfordringer
  • Strategier til forberedelse af testdata
  • Korrupte testdata
  • Testdata for Performance Test Case
  • Hvordan forberedes data, der sikrer maksimal testdækning?
  • Data til Black Box-test
  • Eksempel på testdata for åben EMR AUT
  • Oprettelse af manuelle data til test af Open EMR-applikation
• Egenskaber ved gode testdata
  • Test dataegenskaber
  • Test data forberedelse teknikker
  • Metoder til generering af testdata:
  • Konklusion
  • Anbefalet læsning

Hvad er testdata, og hvorfor det er vigtigt

Idet der henvises til en undersøgelse foretaget af IBM i 2016, omfatter søgning, styring, vedligeholdelse og generering af testdata 30% -60% af testernes tid. Det er ubestrideligt bevis for, at dataforberedelse er en tidskrævende fase af softwaretest.

Figur 1: Testernes gennemsnitlige tid brugt på TDM

Ikke desto mindre er det en kendsgerning på tværs af mange forskellige discipliner, at de fleste dataforskere bruger 50% -80% af deres models udviklingstid i at organisere data. Og nu overvejer lovgivningen og såvel som personligt identificerbar information (PII), gør testernes engagement overvældende anstændigt i testprocessen.

I dag betragtes testdataens troværdighed og pålidelighed som et kompromisløst element for virksomhedsejerne. Produktindehaverne ser spøgelseskopierne af testdataene som den største udfordring, hvilket reducerer pålideligheden af ​​enhver applikation på dette unikke tidspunkt af kundernes efterspørgsel / krav til kvalitetssikring.

I betragtning af testdataens betydning accepterer langt de fleste softwareejere ikke de testede applikationer med falske data eller mindre i sikkerhedsforanstaltninger.

På dette tidspunkt, hvorfor husker vi ikke, hvad testdata er? Når vi begynder at skrive vores testsager for at verificere og validere de givne funktioner og udviklede scenarier for applikationen under testen, har vi brug for information, der bruges som input til at udføre testene til identifikation og lokalisering af manglerne.

selen automatiseringstest interview spørgsmål og svar

Og vi ved, at disse oplysninger skal være præcise og komplette for at gøre fejlene ude. Det er det, vi kalder testdata. For at gøre det nøjagtigt kan det være navne, lande osv., Ikke er følsomme, hvor data vedrørende kontaktoplysninger, SSN, sygehistorie og kreditkortoplysninger er følsomme.

Dataene kan være i enhver form som:

• System testdata
• SQL-testdata
• Ydelsestestdata
• XML-testdata

Hvis du skriver testsager, har du brug for inputdata til enhver form for test. Testeren kan tilvejebringe disse inputdata på tidspunktet for udførelsen af ​​testsagerne, eller applikationen kan vælge de krævede inputdata fra de foruddefinerede datalokaliteter.

Dataene kan være enhver form for input til applikationen, enhver form for fil, der indlæses af applikationen, eller poster læst fra databasetabellerne.

Forberedelse af korrekte inputdata er en del af en testopsætning. Generelt kalder testere det testbed forberedelse . I testbed indstilles alle software- og hardwarekrav ved hjælp af de foruddefinerede dataværdier.

Hvis du ikke har den systematiske tilgang til bygning af data mens skrivning og udførelse af testsager så er der chancer for at gå glip af nogle vigtige testsager. Testerne kan oprette deres egne data i henhold til testbehov.

Stol ikke på de data, der er oprettet af andre testere eller standardproduktionsdata. Opret altid et nyt sæt data i henhold til dine krav.

Nogle gange er det ikke muligt at oprette et helt nyt datasæt til hver eneste build. I sådanne tilfælde kan du bruge standardproduktionsdata. Men husk at tilføje / indsætte dine egne datasæt i denne eksisterende database. En bedste måde at oprette data på er at bruge de eksisterende eksempeldata eller testbed og tilføje dine nye testcasesdata hver gang du får det samme modul til test. På denne måde kan du oprette omfattende datasæt over perioden.

Test Data Sourcing Udfordringer

Et af områderne i generering af testdata, som testerne overvejer, er krav til datasourcing til undersæt. For eksempel har du over en million kunder, og du har brug for tusind af dem til test. Og disse stikprøvedata skal være konsistente og repræsentere statistisk den passende fordeling af den målrettede gruppe. Med andre ord skal vi finde den rigtige person til at teste, hvilket er en af ​​de mest nyttige metoder til at teste brugssagerne.

Og disse stikprøvedata skal være konsistente og repræsentere statistisk den passende fordeling af den målrettede gruppe. Med andre ord skal vi finde den rigtige person til at teste, hvilket er en af ​​de mest nyttige metoder til at teste brugssagerne.

Derudover er der nogle miljømæssige begrænsninger i processen. En af dem er kortlægning af PII-politikker. Da privatlivets fred er en væsentlig hindring, skal testerne klassificere PII-data.

Testdatastyringsværktøjerne er designet til at løse det nævnte problem. Disse værktøjer foreslår politikker baseret på de standarder / katalog, de har. Selvom det ikke er særlig sikker træning. Det giver stadig mulighed for at kontrollere, hvad man laver.

For at holde trit med at tackle de nuværende og endda fremtidige udfordringer, bør vi altid stille spørgsmål som Hvornår / hvor skal vi starte udførelsen af ​​TDM? Hvad skal automatiseres? Hvor mange investeringer skal virksomhederne afsætte til afprøvning inden for områder med menneskelig ressource løbende kompetenceudvikling og brug af nyere TDM-værktøjer? Skal vi begynde at teste med funktionel eller ikke-funktionel test? Og meget mere sandsynlige spørgsmål som dem.

Nogle af de mest almindelige udfordringer ved testdatasourcing er nævnt nedenfor:

• Holdene har muligvis ikke tilstrækkelig viden og færdigheder til testdata-generatorværktøjer
• Testdatadækning er ofte ufuldstændig
• Mindre klarhed i datakrav, der dækker volumen specifikationer under indsamlingsfasen
• Testhold har ikke adgang til datakilderne
• Forsinkelse med at give produktionsdata adgang til testere af udviklere
• Data om produktionsmiljø er muligvis ikke fuldt anvendelige til test baseret på de udviklede forretningsscenarier
• Store mængder data kan have brug for inden for en kort periode af en given tid
• Dataafhængighed / kombinationer for at teste nogle af forretningsscenarierne
• Testerne bruger mere tid end nødvendigt til at kommunikere med arkitekter, databaseadministratorer og BA'er til indsamling af data
• For det meste oprettes eller forberedes dataene under udførelsen af ​​testen
• Flere applikationer og dataversioner
• Kontinuerlig frigivelsescyklus på tværs af flere applikationer
• Lovgivning til pasning af personlige identifikationsoplysninger (PII)

På den hvide boks side af datatesten forbereder udviklerne produktionsdataene. Det er her, QA's behov for at arbejde sammen med udviklerne for at fremme testdækningen af ​​AUT. En af de største udfordringer er at inkorporere alle mulige scenarier (100% test case) med hver eneste mulige negative sag.

I dette afsnit talte vi om testdataudfordringer. Du kan tilføje flere udfordringer, da du har løst dem i overensstemmelse hermed. Lad os derefter undersøge forskellige tilgange til håndtering af testdatadesign og -administration.

Strategier til forberedelse af testdata

Vi ved ved daglig praksis, at spillerne i testbranchen løbende oplever forskellige måder og midler til at forbedre testindsatsen og vigtigst af dens omkostningseffektivitet. I det korte forløb af udvikling af information og teknologi har vi set, når værktøjer indarbejdes i produktions- / testmiljøerne, at outputniveauet steg væsentligt.

Når vi taler om fuldstændigheden og den fulde dækning af test, afhænger det primært af datakvaliteten. Da test er rygraden for at opnå kvaliteten af ​​softwaren, er testdata det centrale element i testprocessen.

Figur 2: Strategier til testdatastyring (TDM)

Oprettelse af flade filer baseret på kortlægningsreglerne. Det er altid praktisk at oprette en delmængde af de data, du har brug for fra produktionsmiljøet, hvor udviklere designede og kodede applikationen. Faktisk reducerer denne tilgang testernes bestræbelser på at udarbejde data, og den maksimerer brugen af ​​de eksisterende ressourcer til at undgå yderligere udgifter.

Typisk er vi nødt til at oprette dataene eller i det mindste identificere dem ud fra den type krav, hvert projekt har i starten.

Vi kan anvende følgende strategier, der håndterer processen med TDM:

1. Data fra produktionsmiljøet
2. Henter SQL-forespørgsler, der udtrækker data fra klientens eksisterende databaser
3. Automatiske datagenereringsværktøjer

Testerne skal sikkerhedskopiere deres test med komplette data ved at overveje elementerne som vist i figur 3 her. Resters i agile udviklingsteamer genererer de nødvendige data til udførelse af deres testsager. Når vi taler om testsager, mener vi sager til forskellige typer test som den hvide boks, den sorte boks, ydeevne og sikkerhed.

På dette tidspunkt ved vi, at data til præstationstestning skal være i stand til at bestemme, hvor hurtigt systemet reagerer under en given arbejdsbyrde for at være meget tæt på reel eller levende stor datamængde med betydelig dækning.

Til test af hvidboks forbereder udviklerne deres krævede data til at dække så mange grene som muligt, alle stier i programmets kildekode og den negative Application Program Interface (API).

Figur 3: Test Data Generation Aktiviteter

Til sidst kan vi sige, at alle, der arbejder i softwareudviklingens livscyklus ( SDLC ) ligesom BA'er, bør udviklere og produkt ejere være godt engageret i processen med forberedelse af testdata. Det kan være en fælles indsats. Og lad os nu tage dig til spørgsmålet om beskadigede testdata.

Korrupte testdata

Før udførelsen af ​​eventuelle testsager på vores eksisterende data, skal vi sørge for, at dataene ikke er beskadiget / forældet, og applikationen under testen kan læse datakilden. Når mere end en tester, der arbejder på forskellige moduler af en AUT i testmiljøet på samme tid, typisk er chancerne for, at data bliver beskadiget, så høje.

I det samme miljø ændrer testerne de eksisterende data i henhold til deres behov / krav til testsagerne. Når testere er færdige med dataene, efterlader de for det meste dataene, som de er. Så snart den næste tester opfanger de modificerede data, og han / hun udfører en anden udførelse af testen, er der en mulighed for netop denne testfejl, som ikke er kodefejl eller defekt.

I de fleste tilfælde er det sådan, at data bliver beskadiget og / eller forældet, hvilket fører til fiasko. For at undgå og minimere chancerne for dataoverensstemmelse kan vi anvende løsningerne som nedenfor. Og selvfølgelig kan du tilføje flere løsninger i slutningen af ​​denne vejledning i kommentarfeltet.

1. At have sikkerhedskopi af dine data
2. Sæt dine ændrede data tilbage til deres oprindelige tilstand
3. Datadeling mellem testere
4. Hold datalageradministratoren opdateret for enhver ændring / ændring af data

Hvordan holder du dine data intakte i ethvert testmiljø?

For det meste er mange testere ansvarlige for at teste den samme build. I dette tilfælde vil mere end en tester have adgang til fælles data, og de vil forsøge at manipulere det fælles datasæt efter deres behov.

Hvis du har forberedt data til nogle specifikke moduler, er den bedste måde at holde dit datasæt intakt ved at opbevare sikkerhedskopier af det samme.

Testdata for Performance Test Case

Ydelsestest kræver et meget stort datasæt. Nogle gange kan oprettelse af data manuelt ikke registrere nogle subtile fejl, der muligvis kun fanges af faktiske data oprettet af applikation under test. Hvis du vil have data i realtid, som det er umuligt at oprette manuelt, så bed din lead / manager om at gøre dem tilgængelige fra det levende miljø.

Disse data vil være nyttige for at sikre, at applikationen fungerer gnidningsløst for alle gyldige input.

Hvad er de ideelle testdata?

Data kan siges at være ideelle, hvis alle applikationsfejl for at blive identificeret for minimumsstørrelsen på datasættet. Prøv at forberede data, der vil omfatte al applikationsfunktionalitet, men ikke overstiger omkostnings- og tidsbegrænsning til at forberede data og køre tests.

bedste spilvirksomheder at arbejde for

Hvordan forberedes data, der sikrer maksimal testdækning?

Design dine data under hensyntagen til følgende kategorier:

1) Ingen data: Kør dine testcases på blanke eller standarddata. Se om der genereres korrekte fejlmeddelelser.

2) Gyldigt datasæt: Opret det for at kontrollere, om applikationen fungerer i henhold til kravene, og gyldige inputdata gemmes korrekt i database eller filer.

3) Ugyldigt datasæt: Forbered ugyldigt datasæt for at kontrollere applikationsadfærd for negative værdier, alfanumeriske strenginput.

4) Ulovligt dataformat: Lav et datasæt med ulovligt dataformat. Systemet bør ikke acceptere data i et ugyldigt eller ulovligt format. Kontroller også, at der oprettes korrekte fejlmeddelelser.

5) Datasæt for grænseoverskridende betingelser: Datasæt, der indeholder data uden for området. Identificer applikationsgrænsesager, og forbered datasæt, der dækker nedre såvel som øvre grænseforhold.

6) Datasættet til ydelse, belastning og stresstest: Dette datasæt skal have et stort volumen.

På denne måde oprettes separate datasæt for hver testtilstand, der sikrer fuldstændig testdækning.

Data til Black Box-test

Kvalitetssikringstestere udfører integrationstest, systemtest og acceptstest, der er kendt som black box-test. I denne testmetode har testerne ikke noget arbejde med den interne struktur, design og koden for applikationen under testen.

Testernes primære formål er at identificere og lokalisere fejl. Ved at gøre dette anvender vi enten funktionel eller ikke-funktionel test ved hjælp af forskellige teknikker til test af sort boks.

Figur 4: Black Box Data Design Metoder

På dette tidspunkt har testerne brug for testdataene som input til udførelse og implementering af teknikkerne til test af sort boks. Og testerne skal forberede de data, der undersøger al applikationsfunktionalitet uden at overstige de givne omkostninger og tiden.

Vi kan designe dataene til vores testsager i betragtning af datasættkategorier som ingen data, gyldige data, ugyldige data, ulovligt dataformat, randbetingelsesdata, ækvivalenspartition, beslutningsdatatabel, tilstandsovergangsdata og brugssagsdata. Før testere går ind i datasættkategorierne, initierer de dataindsamling og analyse af de eksisterende ressourcer i applikationen under testeren (AUT).

I henhold til de tidligere nævnte punkter om at holde dit datalager altid opdateret, skal du dokumentere datakravene på test-case niveau og markere dem anvendelige eller ikke-genanvendelige, når du script dine testcases. Det hjælper dig med at de data, der kræves til testning, er godt ryddet og dokumenteret lige fra starten, som du kan henvise til til senere brug senere.

Eksempel på testdata for åben EMR AUT

Til vores nuværende tutorial har vi Open EMR som Application Under Test (AUT).

=> Find venligst link til Open EMR-applikation her til din reference / praksis.

Tabellen nedenfor illustrerer stort set et eksempel på indsamling af datakrav, der kan være en del af testdokumentationen og opdateres, når du skriver testcases til dine testscenarier.

( BEMÆRK : Klik på på ethvert billede for en forstørret visning)

Oprettelse af manuelle data til test af Open EMR-applikation

Lad os gå videre til oprettelsen af ​​manuelle data til test af Open EMR-applikationen for de givne datasættkategorier.

1) Ingen data: Testeren validerer Open EMR-applikations-URL og “Søg eller tilføj patient” -funktionerne uden at give nogen data.

to) Gyldige data: Testeren validerer Open EMR-applikations-URL og funktionen 'Søg eller tilføj patient' med angivelse af gyldige data.

3) Ugyldige data: Testeren validerer Open EMR-applikations-URL og funktionen 'Søg eller tilføj patient' med angivelse af ugyldige data.

4) Ulovligt dataformat: Testeren validerer Open EMR-applikations-URL og funktionen 'Søg eller tilføj patient' med angivelse af ugyldige data.

Testdata for 1-4 datasættkategorier:

5) Datasæt for grænsetilstand: Det er at bestemme inputværdier for grænser, der enten er inden for eller uden for de givne værdier som data.

6) Datasæt for ækvivalenspartition: Det er testteknikken, der opdeler dine inputdata i inputværdierne gyldig og ugyldig.

Testdata for 5^thog 6^thdatasætkategorier, som er til Open EMR-brugernavn og adgangskode:

7) Beslutningstabel datasæt: Det er teknikken til at kvalificere dine data med en kombination af input for at producere forskellige resultater. Denne metode til test af black box hjælper dig med at reducere din testindsats med at verificere hver kombination af testdata. Derudover kan denne teknik sikre dig den fulde testdækning.

Se nedenstående beslutningstabellsæt for Open EMR-applikations brugernavn og adgangskode.

Beregningen af ​​kombinationerne udført i tabellen ovenfor er beskrevet for din detaljerede information som nedenfor. Du har muligvis brug for det, når du gør mere end fire kombinationer.

• Antal kombinationer = Antal betingelser 1 Værdier * Antal betingelser 2 værdier
• Antal kombinationer = 2 ^ Antal sande / falske forhold
• Eksempel: Antal kombinationer - 2 ^ 2 = 4

8) datasæt for tilstandstransitionstest: Det er testteknikken, der hjælper dig med at validere tilstandsovergangen for Application Under Test (AUT) ved at give systemet inputbetingelserne.

For eksempel, logger vi på Open EMR-applikationen ved at angive det korrekte brugernavn og adgangskoden ved første forsøg. Systemet giver os adgang, men hvis vi indtaster de forkerte login-data, nægter systemet adgang. State overgangstest validerer, hvor mange loginforsøg du kan gøre, før Open EMR lukkes.

Nedenstående tabel viser, hvordan enten det korrekte eller det forkerte loginforsøg reagerer

9) Brugsdato testdato: Det er testmetoden, der identificerer vores testtilfælde, der registrerer slutningen til slut-testen af ​​en bestemt funktion.

Eksempel, Åbn EMR-login:

Læs også => Teknikker til styring af datadata

Egenskaber ved gode testdata

Som tester skal du teste modulet 'Undersøgelsesresultater' på universitetets hjemmeside. Overvej, at hele applikationen er integreret, og at den er i tilstanden 'Klar til test'. 'Eksamensmodul' er knyttet til 'Registrering', 'Kurser' og 'Finans' moduler.

Antag, at du har tilstrækkelig information om applikationen, og at du har oprettet en omfattende liste over testscenarier. Nu skal du designe, dokumentere og udføre disse testsager. I afsnittet 'Handlinger / trin' eller 'Testindgange' i testsagerne bliver du nødt til at nævne de acceptable data som input til testen.

De data, der er nævnt i testtilfælde, skal vælges korrekt. Nøjagtigheden af ​​kolonnen 'Faktiske resultater' i testdokumentet afhænger primært af testdataene. Så trin for at forberede input-testdata er meget vigtigt. Således er her min oversigt over 'DB Testing - Test Data Preparation Strategies'.

Test dataegenskaber

Testdataene skal vælges nøjagtigt, og de skal have følgende fire kvaliteter:

1) Realistisk:

Ved realistisk betyder det, at dataene skal være nøjagtige i sammenhæng med virkelige scenarier. For eksempel skal alle værdierne være positive og 18 eller derover for at teste feltet 'Alder'. Det er helt indlysende, at kandidaterne til optagelse på universitetet normalt er 18 år (dette kan defineres forskelligt med hensyn til forretningskrav).

Hvis test udføres ved hjælp af realistiske testdata, vil det gøre appen mere robust, da de fleste af de mulige fejl kan fanges ved hjælp af realistiske data. En anden fordel ved realistiske data er genanvendelighed, hvilket sparer vores tid og kræfter på at skabe nye data igen og igen.

Når vi taler om realistiske data, vil jeg gerne introducere dig til konceptet med det gyldne datasæt. Et gyldent datasæt er det, der dækker næsten alle mulige scenarier, der opstår i det virkelige projekt. Ved at bruge GDS kan vi give maksimal testdækning. Jeg bruger GDS til at udføre regressionstest i min organisation, og dette hjælper mig med at teste alle mulige scenarier, der kan opstå, hvis koden går i produktionsboksen.

Der er mange testdata-generatorværktøjer til rådighed på markedet, der analyserer søjlekarakteristika og brugerdefinitioner i databasen, og på baggrund af disse genererer de realistiske testdata til dig. Få af de gode eksempler på de værktøjer, der genererer data til databasetest, er DTM Data Generator , SQL Data Generator og Mockaroo .

2. Praktisk gyldig:

Dette ligner realistisk, men ikke det samme. Denne ejendom er mere relateret til AUT's forretningslogik, f.eks. værdi 60 er realistisk i aldersfeltet, men praktisk talt ugyldig for en kandidat til eksamen eller endda kandidatuddannelser. I dette tilfælde vil et gyldigt interval være 18-25 år (dette kan defineres i kravene).

3. Alsidig til at dække scenarier:

hvad er en bin-fil?

Der kan være flere efterfølgende betingelser i et enkelt scenario, så vælg dataene klogt for at dække maksimale aspekter af et enkelt scenario med det minimale datasæt, f.eks. mens du opretter testdata til resultatmodul, skal du ikke kun overveje tilfældet med almindelige studerende, der afslutter deres program glat. Vær opmærksom på de studerende, der gentager det samme kursus og tilhører forskellige semestre eller endda forskellige programmer. Datasættet kan se sådan ud:

Der kan være flere andre interessante og vanskelige underbetingelser. For eksempel. begrænsningen af ​​år til at gennemføre en uddannelse, bestå en forudsætning for at tilmelde et kursus, maksimalt nr. af kurser, som en studerende kan tilmelde sig et enkelt semester osv. osv. Sørg for at dække alle disse scenarier klogt med det endelige datasæt.

4. Ekstraordinære data (hvis relevant / påkrævet):

Der kan være visse ekstraordinære scenarier, der forekommer sjældnere, men som kræver stor opmærksomhed, når de opstod, f.eks. handicappede studerendes relaterede spørgsmål.

En anden god forklaring og et eksempel på det ekstraordinære datasæt ses i billedet nedenfor:

Tag væk:

Testdata kaldes gode testdata, hvis de er realistiske, gyldige og alsidige. Det er en ekstra fordel, hvis dataene også giver dækning for ekstraordinære scenarier.

Test data forberedelse teknikker

Vi har kort diskuteret de vigtige egenskaber ved testdata, og det har også uddybet, hvordan valg af testdata er vigtigt, mens du udfører databasetest. Lad os nu diskutere '' teknikker til at forberede testdata '' .

Der er kun to måder at forberede testdata på:

Metode nr. 1) Indsæt nye data

Få en ren DB, og indsæt alle data som angivet i dine testsager. Når alle dine krævede og ønskede data er indtastet, skal du starte udførelsen af ​​dine testsager og udfylde 'Pass / Fail' -kolonnerne ved at sammenligne 'Faktisk output' med 'Forventet output'. Det lyder simpelt, ikke? Men vent, det er ikke så simpelt.

Få væsentlige og kritiske bekymringer er som følger:

• En tom forekomst af databasen er muligvis ikke tilgængelig
• Indsatte testdata kan være utilstrækkelige til at teste nogle tilfælde som ydeevne og belastningstest.
• Indsættelse af de krævede testdata i tom DB er ikke et let job på grund af databasetabellens afhængighed. På grund af denne uundgåelige begrænsning kan dataindsættelse blive en vanskelig opgave for testeren.
• Indsættelse af begrænsede testdata (kun i henhold til testsagens behov) kan skjule nogle problemer, der kun kan findes med det store datasæt.
• Til dataindsættelse kan der kræves komplekse forespørgsler og / eller procedurer, og til dette er tilstrækkelig hjælp eller hjælp fra DB-udvikleren (e) nødvendig.

Ovenstående er fem spørgsmål de mest kritiske og de mest åbenlyse ulemper ved denne teknik til forberedelse af testdata. Men der er også nogle fordele:

• Udførelse af TC'er bliver mere effektiv, da DB kun har de nødvendige data.
• Fejlisolering kræver ingen tid, da kun de data, der er specificeret i testsager, er til stede i DB.
• Mindre tid krævet til test og sammenligning af resultater.
• Rodfri testproces

Metode nr. 2) Vælg eksempeldatasæt fra faktiske DB-data

Dette er en praktisk og mere praktisk teknik til forberedelse af testdata. Det kræver dog gode tekniske færdigheder og kræver detaljeret viden om DB Schema og SQL. I denne metode skal du kopiere og bruge produktionsdata ved at erstatte nogle feltværdier med dummy-værdier. Dette er det bedste datasæt til din test, da det repræsenterer produktionsdataene. Men dette er muligvis ikke muligt hele tiden på grund af datasikkerhed og privatlivets fred.

Tag væk:

I ovenstående afsnit har vi diskuteret ovenfor teknikkerne til forberedelse af testdata. Kort sagt er der to teknikker - enten opret nye data eller vælg et undersæt fra allerede eksisterende data. Begge skal gøres på en måde, så de valgte data dækker forskellige testscenarier, hovedsagelig gyldig og ugyldig test, præstationstest og null test.

I det sidste afsnit, lad os også tage en hurtig rundtur i datagenereringsmetoder. Disse tilgange er nyttige, når vi har brug for at generere nye data.

Metoder til generering af testdata:

• Manuel generering af testdata: I denne tilgang indtastes testdata manuelt af testere i henhold til testcases krav. Det er tid til at tage processen og også udsat for fejl.
• Automatisk generering af testdata: Dette gøres ved hjælp af datagenereringsværktøjer. Den største fordel ved denne tilgang er dens hastighed og nøjagtighed. Det kommer dog til en højere pris end manuel testdata generering.
• Back-end dataindsprøjtning : Dette gøres gennem SQL-forespørgsler. Denne tilgang kan også opdatere de eksisterende data i databasen. Det er hurtigt og effektivt, men bør implementeres meget omhyggeligt, så den eksisterende database ikke bliver ødelagt.
• Brug af tredjepartsværktøjer : Der findes værktøjer på markedet, der først forstår dine testscenarier og derefter genererer eller indsprøjter data i overensstemmelse hermed for at give bred testdækning. Disse værktøjer er nøjagtige, da de er tilpasset efter virksomhedens behov. Men de er ret dyre.

Tag væk:

Der er 4 tilgange til test af generering af data:

1. Håndbog,
2. automatisering,
3. back-end dataindsprøjtning,
4. og tredjepartsværktøjer.

Hver tilgang har sine egne fordele og ulemper. Du skal vælge den tilgang, der opfylder din virksomheds og testbehov.

Konklusion

Oprettelse af komplette softwaretestdata i overensstemmelse med branchestandarderne, lovgivningen og basisdokumenterne for det gennemførte projekt er blandt testernes kerneansvar. Jo mere vi effektivt administrerer testdata, jo mere kan vi implementere rimeligt fejlfrie produkter til brugere i den virkelige verden.

Testdatastyring (TDM) er den proces, der er baseret på analyse af udfordringer og introduktion samt anvendelse af de bedste værktøjer og metoder til godt at løse de identificerede problemer uden at gå på kompromis med pålideligheden og den fulde dækning af slutproduktet (produktet).

Vi er altid nødt til at komme med spørgsmål til søgning efter innovative og mere omkostningseffektive metoder til analyse og valg af testmetoder, herunder brug af værktøjer til generering af data. Det er bredt bevist, at veldesignede data giver os mulighed for at identificere mangler ved applikationen under testen i hver fase af en flerfaset SDLC.

Vi er nødt til at være kreative og deltage med alle medlemmer inden for og uden for vores agile team. Del din feedback, erfaring, spørgsmål og kommentarer, så vi kan fortsætte vores tekniske diskussioner for at maksimere vores positive indvirkning på AUT ved at administrere data.

Forberedelse af korrekte testdata er en central del af “opsætningen af ​​projekttestmiljøet”. Vi kan ikke bare gå glip af testsagen og sige, at komplette data ikke var tilgængelige til test. Testeren skal oprette sine egne testdata ud over de eksisterende standardproduktionsdata. Dit datasæt skal være ideelt med hensyn til omkostninger og tid.

Vær kreativ, brug din egen færdighed og vurderinger til at oprette forskellige datasæt i stedet for at stole på standard produktionsdata.

Del II - Den anden del af denne tutorial handler om ' Test datagenerering med GEDIS Studio Online Tool ”.

Har du stået over for problemet med ufuldstændige testdata til test? Hvordan du klarede det? Del dine tip, erfaring, kommentarer og spørgsmål til yderligere berigelse af dette diskussionsemne.

Anbefalet læsning

• ETL Testing Tutorial Data Warehouse Testing Tutorial (En komplet guide)
• Hvad er mutationstest: Vejledning med eksempler
• Sådan udføres datadrevet test ved hjælp af TestComplete-værktøjet
• Datadrevet eller parametreret test med Spock Framework
• De 4 trin til Business Intelligence (BI) -test: Sådan testes forretningsdata
• Volume Testing Tutorial: Eksempler og Volume Testing Tools
• En fremragende måde at datatest på ved hjælp af XML-teknologier (hvidbog)
• Top 10 strukturerede datatest- og valideringsværktøjer til SEO