Vad är testdata? Testdata Beredningstekniker med exempel

what is test data test data preparation techniques with example

Lär dig vad som är testdata och hur man förbereder testdata för testning:

Vid den nuvarande epiken om revolutionerande tillväxt för information och teknik upplever testarna ofta omfattande konsumtion av testdata under programvarutestningens livscykel.

Testerna samlar inte in / underhåller inte bara data från befintliga källor utan de genererar också enorma mängder testdata för att säkerställa deras högkvalitativa bidrag i leveransen av produkten för verklig användning.

Därför måste vi som testare kontinuerligt utforska, lära oss och tillämpa de mest effektiva metoderna för datainsamling, generering, underhåll, automatisering och omfattande datahantering för alla typer av funktionella och icke-funktionella tester.

I denna handledning kommer jag att ge tips om hur du förbereder testdata så att alla viktiga testfall inte kommer att missas av felaktig data och ofullständig installation av testmiljön.

Vad du kommer att lära dig:

• Vad är testdata och varför det är viktigt
  • Testa utmaningar för datakällor
  • Strategier för förberedelse av testdata
  • Skadad testdata
  • Testdata för Performance Test Case
  • Hur förbereder jag data som säkerställer maximal testtäckning?
  • Data för Black Box-testning
  • Testdataexempel för öppen EMR AUT
  • Skapande av manuella data för testning av Open EMR-applikation
• Egenskaper för bra testdata
  • Testdataegenskaper
  • Testdatatillverkningstekniker
  • Metoder för generering av testdata:
  • Slutsats
  • Rekommenderad läsning

Vad är testdata och varför det är viktigt

Med hänvisning till en studie genomförd av IBM 2016, omfattar sökning, hantering, underhåll och generering av testdata 30% -60% av testarens tid. Det är obestridligt bevis för att dataförberedelse är en tidskrävande fas av programvarutestning.

Figur 1: Testarnas genomsnittliga tid på TDM

Ändå är det ett faktum i många olika discipliner att de flesta dataforskare spenderar 50% -80% av sin modells utvecklingstid i att organisera data. Och nu med tanke på lagstiftningen och såväl som personligt identifierbar information (PII) gör testarnas engagemang överväldigande anständigt i testprocessen.

Idag anses testdataens trovärdighet och tillförlitlighet vara ett kompromisslöst element för företagsägarna. Produktägarna ser spökekopiorna av testdata som den största utmaningen, vilket minskar tillförlitligheten hos alla applikationer vid denna unika tidpunkt för kundernas efterfrågan / krav på kvalitetssäkring.

Med tanke på testdataens betydelse accepterar de allra flesta programvaruägare inte de testade applikationerna med falska data eller mindre i säkerhetsåtgärder.

Vid den här tiden, varför kommer vi inte ihåg vad testdata är? När vi börjar skriva våra testfall för att verifiera och validera de angivna funktionerna och utvecklade scenarier för applikationen under testet behöver vi information som används som input för att utföra testerna för att identifiera och lokalisera defekterna.

vilken app låter dig ladda ner youtube-videor

Och vi vet att denna information måste vara exakt och fullständig för att göra fel. Det är vad vi kallar testdata. För att göra det korrekt kan det vara namn, länder, etc ..., som inte är känsliga, där uppgifter om kontaktinformation, SSN, sjukdomshistoria och kreditkortsinformation är känsliga till sin natur.

Uppgifterna kan vara i vilken form som helst:

• Systemtestdata
• SQL-testdata
• Prestandatestdata
• XML-testdata

Om du skriver testfall behöver du inmatningsdata för alla typer av test. Testaren kan tillhandahålla denna ingångsdata vid tidpunkten för utförandet av testfallet eller applikationen kan plocka erforderlig indata från de fördefinierade datalägena.

Uppgifterna kan vara vilken typ av inmatning som helst till applikationen, vilken typ av fil som laddas av applikationen eller poster som läses från databastabellerna.

Att förbereda korrekt inmatad data är en del av en testinställning. I allmänhet kallar testare det a testbäddsberedning . I testbädd ställs alla program- och hårdvarukrav med de fördefinierade datavärdena.

Om du inte har det systematiska tillvägagångssättet för att bygga data samtidigt skriva och genomföra testfall då finns det chanser att missa några viktiga testfall. Testarna kan skapa sina egna data enligt testbehov.

Lita inte på den data som skapats av andra testare eller standardproduktionsdata. Skapa alltid en ny uppsättning data enligt dina krav.

Ibland är det inte möjligt att skapa en helt ny uppsättning data för varje byggnad. I sådana fall kan du använda standardproduktionsdata. Men kom ihåg att lägga till / infoga dina egna datamängder i denna befintliga databas. Ett bästa sättet att skapa data är att använda befintlig exempeldata eller testbädd och lägga till dina nya testfallsdata varje gång du får samma modul för testning. På så sätt kan du skapa omfattande datamängder under perioden.

Testa utmaningar för datakällor

Ett av områdena i generering av testdata, anser testarna att kravet på datainsamling för underuppsättning är. Till exempel har du över en miljon kunder och du behöver tusen av dem för testning. Och dessa provdata bör vara konsekventa och representera statistiskt den lämpliga fördelningen av den riktade gruppen. Med andra ord ska vi hitta rätt person att testa, vilket är en av de mest användbara metoderna för att testa användningsfall.

Och dessa provdata bör vara konsekventa och representera statistiskt den lämpliga fördelningen av den riktade gruppen. Med andra ord ska vi hitta rätt person att testa, vilket är en av de mest användbara metoderna för att testa användningsfall.

Dessutom finns det några miljömässiga begränsningar i processen. En av dem är att kartlägga PII-policyer. Eftersom integritet är ett viktigt hinder måste testarna klassificera PII-data.

Verktygen för testdatahantering är utformade för att ta itu med nämnda fråga. Dessa verktyg föreslår policyer baserade på de standarder / katalog som de har. Men det är inte särskilt säker träning. Det ger fortfarande möjlighet att granska vad man gör.

För att hålla koll på de nuvarande och till och med framtida utmaningarna bör vi alltid ställa frågor som när / var ska vi börja genomföra TDM? Vad ska automatiseras? Hur mycket investeringar bör företagen avsätta för testning inom kompetensutveckling av mänskliga resurser och användning av nyare TDM-verktyg? Ska vi börja testa med funktionell eller med icke-funktionell testning? Och mycket mer troliga frågor som dem.

Några av de vanligaste utmaningarna med testdatasourcing nämns nedan:

• Lagen kanske inte har tillräcklig kunskap och färdigheter för verktyg för testgenerator
• Testdatatäckningen är ofta ofullständig
• Mindre tydlighet i datakrav som täcker volymspecifikationer under samlingsfasen
• Testteam har inte tillgång till datakällorna
• Försena med att ge produktionsdata tillgång till testarna av utvecklare
• Produktionsmiljödata kanske inte är helt användbara för testning baserat på utvecklade affärsscenarier
• Stora datamängder kan behöva på kort tid
• Databeroenden / kombinationer för att testa några av affärsscenarierna
• Testarna spenderar mer tid än vad som krävs för att kommunicera med arkitekter, databasadministratörer och BA för att samla in data
• För det mesta skapas eller förbereds data under testets genomförande
• Flera applikationer och dataversioner
• Kontinuerlig frigöringscykel över flera applikationer
• Lagstiftning för att ta hand om personlig identifieringsinformation (PII)

På den vita rutans sida av datatestningen förbereder utvecklarna produktionsdata. Det är där QA: s behov av att samarbeta med utvecklarna för att främja testtäckningen av AUT. En av de största utmaningarna är att införliva alla möjliga scenarier (100% testfall) med varje enskilt negativt fall.

I det här avsnittet pratade vi om testdatautmaningar. Du kan lägga till fler utmaningar eftersom du har löst dem i enlighet med detta. Låt oss därefter utforska olika metoder för hantering av testdatadesign och hantering.

Strategier för förberedelse av testdata

Vi vet av daglig praxis att spelarna i testbranschen kontinuerligt upplever olika sätt och sätt att förbättra testinsatserna och framför allt dess kostnadseffektivitet. Under den korta utvecklingen av informations- och teknikutveckling har vi sett när verktyg införlivas i produktions- / testmiljöerna ökade produktionsnivån väsentligt.

När vi pratar om testets fullständighet och fullständiga täckning beror det främst på datakvaliteten. Eftersom testning är ryggraden för att uppnå kvaliteten på programvaran är testdata kärnan i testprocessen.

Figur 2: Strategier för testdatahantering (TDM)

Skapande av platta filer baserat på kartläggningsreglerna. Det är alltid praktiskt att skapa en delmängd av de data du behöver från produktionsmiljön där utvecklare designade och kodade applikationen. Faktum är att detta tillvägagångssätt minskar testarnas ansträngningar för dataförberedelse och maximerar användningen av befintliga resurser för att undvika ytterligare utgifter.

Normalt måste vi skapa data eller åtminstone identifiera dem baserat på vilken typ av krav varje projekt har i början.

Vi kan tillämpa följande strategier som hanterar processen för TDM:

1. Data från produktionsmiljön
2. Hämtar SQL-frågor som extraherar data från klientens befintliga databaser
3. Automatiserade datagenereringsverktyg

Testarna ska säkerhetskopiera sina tester med fullständiga data genom att beakta elementen som visas i figur 3 här. Resters i agila utvecklingsteam genererar nödvändig data för att utföra sina testfall. När vi pratar om testfall menar vi fall för olika typer av test som den vita rutan, den svarta rutan, prestanda och säkerhet.

Vid den här tiden vet vi att data för prestandatestning ska kunna avgöra hur snabbt systemet reagerar under en given arbetsbelastning för att vara mycket nära den verkliga eller levande stora datamängden med betydande täckning.

För testning av vitlåda förbereder utvecklarna sina nödvändiga data för att täcka så många grenar som möjligt, alla sökvägar i programmets källkod och det negativa API: et för applikationsprogram.

Figur 3: Testa generering av aktiviteter

Så småningom kan vi säga att alla som arbetar i programvaruutvecklingens livscykel ( SDLC ) som BAs, bör utvecklare och produktägare vara väl engagerade i processen att förbereda testdata. Det kan vara en gemensam insats. Låt oss nu ta dig till frågan om skadade testdata.

Skadad testdata

Innan utförandet av testfall på våra befintliga data bör vi se till att uppgifterna inte är skadade / föråldrade och att applikationen under testet kan läsa datakällan. Vanligtvis, när mer än en testare som arbetar på olika moduler av en AUT i testmiljön samtidigt, är chansen att data blir skadade så höga.

I samma miljö ändrar testarna befintliga data enligt deras behov / krav i testfallet. För det mesta, när testarna är klara med data, lämnar de informationen som den är. Så snart nästa testare hämtar de modifierade uppgifterna och han / hon utför en annan körning av testet, finns det en möjlighet till det specifika testfelet som inte är kodfelet eller defekten.

I de flesta fall är detta hur data skadas och / eller är föråldrade, vilket leder till misslyckande. För att undvika och minimera risken för dataavvikelse kan vi använda lösningarna enligt nedan. Och självklart kan du lägga till fler lösningar i slutet av denna handledning i kommentarfältet.

1. Har säkerhetskopiering av dina data
2. Återställ dina modifierade data till sitt ursprungliga tillstånd
3. Datadelning mellan testarna
4. Håll datalageradministratören uppdaterad för eventuell ändring / modifiering av data

Hur håller jag dina uppgifter intakta i alla testmiljöer?

För det mesta ansvarar många testare för att testa samma byggnad. I det här fallet kommer mer än en testare att ha tillgång till gemensam data och de kommer att försöka manipulera den gemensamma datamängden efter deras behov.

Om du har förberett data för vissa specifika moduler är det bästa sättet att hålla din datauppsättning intakt att behålla säkerhetskopior av samma.

Testdata för Performance Test Case

Prestandatester kräver en mycket stor datamängd. Ibland upptäcker inte manuell skapande av data några subtila buggar som bara kan fångas av faktiska data som skapats av applikationen under test. Om du vill ha realtidsdata, vilket är omöjligt att skapa manuellt, be din lead / chef att göra den tillgänglig från den levande miljön.

Dessa data kommer att vara användbara för att säkerställa att applikationen fungerar smidigt för alla giltiga ingångar.

Vad är den perfekta testdata?

Data kan sägas vara perfekt om alla applikationsfel för att identifieras för den minsta storleken på datauppsättningen. Försök att förbereda data som innehåller alla applikationsfunktioner, men som inte överstiger kostnad och tidsbegränsning för att förbereda data och köra tester.

Hur förbereder jag data som säkerställer maximal testtäckning?

Utforma dina data med beaktande av följande kategorier:

1) Inga data: Kör dina testfall på tomma eller standarddata. Se om korrekta felmeddelanden genereras.

2) Giltig datamängd: Skapa den för att kontrollera om applikationen fungerar enligt kraven och giltiga indata sparas korrekt i databas eller filer.

3) Ogiltig datamängd: Förbered ogiltig datamängd för att kontrollera applikationsbeteende för negativa värden, alfanumeriska strängingångar.

4) Olagligt dataformat: Skapa en datamängd med olagligt dataformat. Systemet bör inte acceptera data i ogiltigt eller olagligt format. Kontrollera också att korrekta felmeddelanden genereras.

5) Uppsättning av gränsvillkor: Dataset som innehåller data utanför området. Identifiera applikationsgränsfall och förbered datamängder som täcker både lägre och övre gränsvillkor.

6) Datauppsättningen för prestanda, belastning och stresstestning: Denna datamängd bör vara stor i volym.

På så sätt skapas separata datamängder för varje testvillkor kommer att säkerställa fullständig testtäckning.

Data för Black Box-testning

Kvalitetssäkringstestarna utför integreringstest, systemtestning och godkännandestestning, som kallas black box-testning. I denna testmetod har testarna inget arbete med den interna strukturen, designen och koden för applikationen under testet.

Testarnas främsta syfte är att identifiera och lokalisera fel. Genom att göra detta tillämpar vi antingen funktionell eller icke-funktionell testning med olika tekniker för black box-testning.

Figur 4: Black Box Data Design Methods

Vid denna tidpunkt behöver testarna testdata som input för att utföra och implementera teknikerna för black box-testningen. Och testarna bör förbereda data som kommer att undersöka all applikationsfunktionalitet utan att överstiga den angivna kostnaden och tiden.

Vi kan designa data för våra testfall med beaktande av datauppsättningskategorier som inga data, giltiga data, ogiltiga data, olagligt dataformat, gränsvillkor, ekvivalenspartition, beslutsdatatabell, tillståndsövergångsdata och användningsfallsdata. Innan de går in i datauppsättningskategorierna initierar testarna datainsamling och analys av de befintliga resurserna i applikationen under testaren (AUT).

Enligt de tidigare nämnda punkterna om att hålla ditt datalager alltid uppdaterad, bör du dokumentera datakraven på testfallet och markera dem som användbara eller återanvändbara när du skriptar dina testfall. Det hjälper dig att de data som krävs för testning är väl rensade och dokumenterade från början som du kan referera till för vidare användning senare.

Testdataexempel för öppen EMR AUT

För vår nuvarande handledning har vi Open EMR som Application Under Test (AUT).

=> Hitta länk för Open EMR-applikation här för din referens / praxis.

Tabellen nedan illustrerar i stort sett ett exempel på insamlingen av datakrav som kan vara en del av testfallsdokumentationen och uppdateras när du skriver testfall för dina testscenarier.

( NOTERA : Klick på valfri bild för en förstorad vy)

Skapande av manuella data för testning av Open EMR-applikation

Låt oss gå framåt för att skapa manuella data för att testa Open EMR-applikationen för de angivna datamängderna.

1) Inga data: Testaren validerar Open EMR-applikations-URL och ”Sök eller lägg till patient” -funktionerna utan att ge någon data.

två) Giltiga data: Testaren validerar Open EMR-applikations-URL och funktionen 'Sök eller lägg till patient' med giltiga data.

3) Ogiltiga data: Testaren validerar Open EMR-applikations-URL och “Sök eller lägg till patient” -funktionen med att ge ogiltiga data.

4) Olagligt dataformat: Testaren validerar Open EMR-applikations-URL och “Sök eller lägg till patient” -funktionen med att ge ogiltiga data.

Testdata för 1-4 datauppsättningskategorier:

5) Uppsättning för gränsvillkor: Det är att bestämma ingångsvärden för gränser som ligger inom eller utanför de givna värdena som data.

6) Datapaket för ekvivalenspartition: Det är testtekniken som delar dina inmatade data i inmatningsvärdena giltiga och ogiltiga.

Testdata för 5^thoch 6^thdatauppsättningskategorier, som är för Open EMR-användarnamn och lösenord:

7) Uppsättning av beslutstabell: Det är tekniken för att kvalificera dina data med en kombination av ingångar för att ge olika resultat. Denna metod för black box-test hjälper dig att minska dina testansträngningar för att verifiera varje kombination av testdata. Dessutom kan denna teknik säkerställa dig för fullständig testtäckning.

Se nedan beslutsuppgiftsuppsättningen för Open EMR-applikations användarnamn och lösenord.

Beräkningen av kombinationerna i tabellen ovan beskrivs för detaljerad information nedan. Du kan behöva det när du gör mer än fyra kombinationer.

• Antal kombinationer = Antal villkor 1 Värden * Antal villkor 2 Värden
• Antal kombinationer = 2 ^ Antal sanna / falska förhållanden
• Exempel: Antal kombinationer - 2 ^ 2 = 4

8) Uppsättning av testdata för tillståndsövergång: Det är testtekniken som hjälper dig att validera tillståndsövergången för Application Under Test (AUT) genom att tillhandahålla systemet ingångsförhållandena.

Till exempelloggar vi in ​​Open EMR-applikationen genom att ange rätt användarnamn och lösenord vid första försöket. Systemet ger oss åtkomst, men om vi anger felaktiga inloggningsuppgifter nekar systemet åtkomst. Statlig övergångstest validerar att hur många inloggningsförsök du kan göra innan Open EMR stängs.

c ++ slumpmässigt mellan 0 och 1

Tabellen nedan visar hur rätt eller felaktiga inloggningsförsök svarar

9) Användningsfallstestdatum: Det är testmetoden som identifierar våra testfall som tar hänsyn till testning av en viss funktion från slut till slut.

Exempel, öppna EMR-inloggning:

Läs också => Tekniker för datahantering

Egenskaper för bra testdata

Som testare måste du testa modulen 'Examination Results' på universitetets webbplats. Tänk på att hela applikationen har integrerats och att den är i 'Ready for Testing' -tillstånd. 'Examination Module' är kopplad till modulerna 'Registration', 'Courses' och 'Finance'.

Antag att du har tillräcklig information om applikationen och att du har skapat en omfattande lista med testscenarier. Nu måste du designa, dokumentera och utföra dessa testfall. I avsnittet 'Åtgärder / steg' eller 'Testingångar' i testfallet måste du nämna acceptabla data som input för testet.

De uppgifter som nämns i testfall måste väljas korrekt. Noggrannheten i kolumnen 'Faktiska resultat' i testfallsdokumentet beror främst på testdata. Så steg för att förbereda ingångstestdata är väsentligt viktigt. Således är här min översikt över 'DB Testing - Test Data Preparation Strategies'.

Testdataegenskaper

Testdata bör väljas exakt och de måste ha följande fyra kvaliteter:

1) Realistisk:

Med realistisk betyder det att uppgifterna ska vara korrekta i samband med verkliga scenarier. För att till exempel testa fältet 'Ålder' bör alla värden vara positiva och 18 eller högre. Det är helt uppenbart att kandidaterna för antagning till universitetet vanligtvis är 18 år (detta kan definieras annorlunda när det gäller affärsbehov).

Om testning görs med hjälp av realistiska testdata kommer det att göra appen mer robust eftersom de flesta möjliga buggar kan fångas med realistiska data. En annan fördel med realistiska data är dess återanvändbarhet vilket sparar tid och ansträngning för att skapa nya data om och om igen.

När vi pratar om realistiska data vill jag presentera konceptet för den gyllene datamängden. En gyllene datamängd är den som täcker nästan alla möjliga scenarier som uppstår i det verkliga projektet. Genom att använda GDS kan vi ge maximal testtäckning. Jag använder GDS för att göra regressionstester i min organisation och detta hjälper mig att testa alla möjliga scenarier som kan uppstå om koden går i produktionsrutan.

Det finns många testdata generatorverktyg tillgängliga på marknaden som analyserar kolumnegenskaper och användardefinitioner i databasen och baserat på dessa genererar de realistiska testdata åt dig. Få av de goda exemplen på verktygen som genererar data för databastester är DTM Data Generator , SQL Data Generator och Mockaroo .

2. Praktiskt giltigt:

Detta liknar realistiskt men inte detsamma. Den här egenskapen är mer relaterad till affärslogiken för AUT, t.ex. värde 60 är realistiskt i åldersfältet men praktiskt taget ogiltigt för en kandidat till examen eller till och med magisterprogram. I detta fall skulle ett giltigt intervall vara 18-25 år (detta kan definieras i krav).

3. Mångsidig för att täcka scenarier:

gratis mp3 nedladdningsapp för android

Det kan finnas flera efterföljande villkor i ett enda scenario, så välj data på ett smart sätt för att täcka maximala aspekter av ett enda scenario med den minsta uppsättningen data, t.ex. medan du skapar testdata för resultatmodulen, överväga inte bara fallet med vanliga studenter som smidigt slutför sitt program. Var uppmärksam på de studenter som upprepar samma kurs och tillhör olika terminer eller till och med olika program. Datauppsättningen kan se ut så här:

Det kan finnas flera andra intressanta och knepiga undervillkor. T.ex. begränsningen av år för att genomföra ett utbildningsprogram, genomgå en förutsättningskurs för att registrera en kurs, max. av kurser kan en student anmäla sig till en termin etc. etc. Se till att du täcker alla dessa scenarier klokt med den ändliga uppsättningen data.

4. Exceptionella uppgifter (om tillämpligt / krävs):

Det kan finnas vissa exceptionella scenarier som förekommer mindre ofta men kräver stor uppmärksamhet när de inträffade, t.ex. funktionshindrade elever relaterade frågor.

En annan bra förklaring och exempel på den exceptionella datamängden visas i bilden nedan:

Hämtmat:

Testdata kallas bra testdata om de är realistiska, giltiga och mångsidiga. Det är en extra fördel om data också ger täckning för exceptionella scenarier.

Testdatatillverkningstekniker

Vi har kort diskuterat de viktiga egenskaperna hos testdata och det har också utarbetat hur val av testdata är viktigt när vi gör databasprovningen. Låt oss nu diskutera '' tekniker för att förbereda testdata '' .

Det finns bara två sätt att förbereda testdata:

Metod nr 1) Infoga nya data

Skaffa en ren databas och sätt in all information enligt dina testfall. När alla dina önskade och önskade data har matats in, börja köra dina testfall och fylla i 'Godkänn / misslyckas' -kolumnerna genom att jämföra 'Faktisk utdata' med 'Förväntad utdata'. Låter enkelt, eller hur? Men vänta, det är inte så enkelt.

Få väsentliga och kritiska problem är följande:

• En tom instans av databasen kanske inte är tillgänglig
• Insatta testdata kan vara otillräckliga för att testa vissa fall som prestanda och belastningstest.
• Att infoga nödvändiga testdata i tom DB är inte ett enkelt jobb på grund av databastabellberoenden. På grund av denna oundvikliga begränsning kan datainsättning bli en svår uppgift för testaren.
• Infogning av begränsade testdata (helt enligt testfallets behov) kan dölja vissa problem som bara kan hittas med den stora datamängden.
• För datainförande kan komplexa frågor och / eller procedurer krävas, och för detta krävs tillräcklig hjälp eller hjälp från DB-utvecklaren.

Ovan nämnda fem frågor är de mest kritiska och de mest uppenbara nackdelarna med denna teknik för förberedelse av testdata. Men det finns också några fördelar:

• Utförande av TC: er blir effektivare eftersom DB endast har nödvändiga data.
• Insektsisolering kräver ingen tid eftersom endast de data som anges i testfall finns i DB.
• Mindre tid krävs för testning och resultatjämförelse.
• Störningsfri testprocess

Metod nr 2) Välj exempeluppdelning från faktiska DB-data

Detta är en genomförbar och mer praktisk teknik för testdataförberedelse. Det kräver dock goda tekniska färdigheter och kräver detaljerad kunskap om DB Schema och SQL. I den här metoden måste du kopiera och använda produktionsdata genom att ersätta vissa fältvärden med dummyvärden. Detta är den bästa datamängden för din testning eftersom den representerar produktionsdata. Men det här kanske inte är genomförbart hela tiden på grund av datasäkerhets- och sekretessproblem.

Hämtmat:

I avsnittet ovan har vi diskuterat ovan teknikerna för förberedelse av testdata. Kort sagt, det finns två tekniker - antingen skapa nya data eller välj en delmängd från redan existerande data. Båda måste göras på ett sätt så att de valda uppgifterna ger täckning för olika testscenarier, främst giltiga och ogiltiga test, prestandatest och null-test.

I det sista avsnittet, låt oss också ta en snabb rundtur i datagenereringsmetoder. Dessa tillvägagångssätt är användbara när vi behöver generera nya data.

Metoder för generering av testdata:

• Manuell generering av testdata: I detta tillvägagångssätt matas testdata manuellt in av testare enligt testfallskraven. Det är en tid att ta processen och också utsatt för fel.
• Automatiserad generering av testdata: Detta görs med hjälp av verktyg för datagenerering. Den största fördelen med detta tillvägagångssätt är dess hastighet och noggrannhet. Det kostar dock en högre kostnad än manuell generering av testdata.
• Back-end datainjektion : Detta görs genom SQL-frågor. Detta tillvägagångssätt kan också uppdatera befintlig data i databasen. Det är snabbt och effektivt men bör implementeras mycket noggrant så att den befintliga databasen inte skadas.
• Använda verktyg från tredje part : Det finns verktyg tillgängliga på marknaden som först förstår dina testscenarier och sedan genererar eller injicerar data därefter för att ge bred testtäckning. Dessa verktyg är korrekta eftersom de anpassas enligt företagets behov. Men de är ganska dyra.

Hämtmat:

Det finns fyra metoder för att testa datagenerering:

1. Handbok,
2. automatisering,
3. back-end datainjektion,
4. och verktyg från tredje part.

Varje tillvägagångssätt har sina egna fördelar och nackdelar. Du bör välja det tillvägagångssätt som uppfyller ditt företags och testbehov.

Slutsats

Att skapa fullständiga programvarutestdata i enlighet med branschstandarderna, lagstiftningen och grunddokumenten för det genomförda projektet är bland testarnas kärnansvar. Ju mer vi effektivt hanterar testdata, desto mer kan vi distribuera rimligt felfria produkter för verkliga användare.

Testdatahantering (TDM) är den process som bygger på analys av utmaningar och införande samt att använda de bästa verktygen och metoderna för att på ett bra sätt ta itu med de identifierade problemen utan att kompromissa med tillförlitligheten och hela täckningen av slutprodukten (produkten).

Vi behöver alltid komma med frågor för att söka på innovativa och mer kostnadseffektiva metoder för att analysera och välja testmetoder, inklusive användning av verktyg för att generera data. Det är allmänt bevisat att väldesignade data tillåter oss att identifiera defekter i applikationen under testet i varje fas i en flerfas SDLC.

Vi måste vara kreativa och delta med alla medlemmar inom och utanför vårt agila team. Dela din feedback, erfarenhet, frågor och kommentarer så att vi kan fortsätta med våra tekniska diskussioner för att maximera vår positiva inverkan på AUT genom att hantera data.

Att förbereda korrekta testdata är en viktig del av ”installationen av projekttestmiljön”. Vi kan inte bara missa testfallet och säga att fullständig information inte var tillgänglig för testning. Testaren bör skapa sina egna testdata utöver befintlig standardproduktionsdata. Din datamängd bör vara perfekt när det gäller kostnad och tid.

Var kreativ, använd din egen skicklighet och bedömningar för att skapa olika datamängder istället för att förlita dig på standardproduktionsdata.

Del II - Den andra delen av denna handledning handlar om ' Testa generering av data med GEDIS Studio Online Tool ”.

Har du mött problemet med ofullständiga testdata för testning? Hur du lyckades med det? Dela dina tips, erfarenheter, kommentarer och frågor för att ytterligare berika detta diskussionsämne.

Rekommenderad läsning

• ETL Testing Data Warehouse Testing Tutorial (En komplett guide)
• Vad är mutationstest: handledning med exempel
• Hur man utför datadriven testning med TestComplete-verktyget
• Datadriven eller parametrerad testning med Spock Framework
• De fyra stegen till BI-testning: Hur man testar affärsdata
• Volymtesthandledning: Exempel och volymtestverktyg
• Ett utmärkt sätt att datatestas med XML-teknik (vitbok)
• Topp 10 test- och valideringsverktyg för strukturerad data för SEO