Wat zijn testgegevens? Test gegevensvoorbereidingstechnieken met voorbeeld

what is test data test data preparation techniques with example

Lees wat testgegevens zijn en hoe u testgegevens voorbereidt voor testen:

In het huidige epos van de revolutionaire groei van informatie en technologie, ervaren de testers vaak een uitgebreide consumptie van testgegevens tijdens de levenscyclus van softwaretests.

De testers verzamelen / onderhouden niet alleen gegevens uit de bestaande bronnen, maar genereren ook enorme hoeveelheden testgegevens om hun kwalitatief hoogstaande bijdrage te leveren aan de levering van het product voor gebruik in de echte wereld.

Daarom moeten wij als testers continu de meest efficiënte benaderingen voor gegevensverzameling, generatie, onderhoud, automatisering en uitgebreid gegevensbeheer verkennen, leren en toepassen voor alle soorten functionele en niet-functionele tests.

In deze tutorial zal ik zorgen tips voor het voorbereiden van testgegevens, zodat belangrijke testgevallen niet worden gemist door onjuiste gegevens en onvolledige testomgeving.

Wat je leert:

• Wat zijn testgegevens en waarom zijn ze belangrijk?
  • Test uitdagingen op het gebied van data-sourcing
  • Strategieën voor het voorbereiden van testgegevens
  • Beschadigde testgegevens
  • Testgegevens voor de prestatietestcase
  • Hoe bereid ik gegevens voor die een maximale testdekking garanderen?
  • Gegevens voor Black Box-tests
  • Voorbeeld van testgegevens voor Open EMR AUT
  • Aanmaken van handmatige gegevens voor het testen van Open EMR-applicatie
• Eigenschappen van goede testgegevens
  • Test gegevenseigenschappen
  • Test gegevensvoorbereidingstechnieken
  • Methoden voor het genereren van gegevens testen:
  • Gevolgtrekking
  • Aanbevolen literatuur

Wat zijn testgegevens en waarom zijn ze belangrijk?

Verwijzend naar een onderzoek dat in 2016 door IBM is uitgevoerd, omvat het zoeken, beheren, onderhouden en genereren van testgegevens 30% -60% van de tijd van de testers. Het is onmiskenbaar bewijs dat datavoorbereiding een tijdrovende fase is bij het testen van software.

Figuur 1: Testers Gemiddelde tijd besteed aan TDM

Niettemin is het in veel verschillende disciplines een feit dat de meeste datawetenschappers 50% -80% van de ontwikkelingstijd van hun model besteden aan het organiseren van gegevens. En nu gezien de wetgeving en evenals de persoonlijk identificeerbare informatie (PII), maakt de betrokkenheid van de testers overweldigend fatsoenlijk tijdens het testen.

Tegenwoordig worden de geloofwaardigheid en betrouwbaarheid van de testgegevens beschouwd als een compromisloos element voor de ondernemers. De producteigenaren zien de spookkopieën van de testgegevens als de grootste uitdaging, die de betrouwbaarheid van een applicatie vermindert op dit unieke moment van de vraag / eisen van klanten aan kwaliteitsborging.

Gezien het belang van testgegevens accepteren de overgrote meerderheid van software-eigenaren de geteste applicaties met nepgegevens of minder in beveiligingsmaatregelen niet.

Waarom herinneren we ons op dit moment niet wat testgegevens zijn? Wanneer we beginnen met het schrijven van onze testcases om de gegeven functies en ontwikkelde scenario's van de applicatie onder de test te verifiëren en valideren, hebben we informatie nodig die wordt gebruikt als input om de tests uit te voeren voor het identificeren en lokaliseren van de defecten.

hoe u elementen van een array toevoegt

En we weten dat deze informatie nauwkeurig en volledig moet zijn om de bugs te verhelpen. Het zijn wat we testdata noemen. Om het nauwkeurig te maken, kunnen het namen, landen enz. Zijn die niet gevoelig zijn, waarbij gegevens met betrekking tot Contactinformatie, SSN, medische geschiedenis en creditcardinformatie gevoelig van aard zijn.

De gegevens kunnen elke vorm hebben, zoals:

• Systeemtestgegevens
• SQL-testgegevens
• Prestatietestgegevens
• XML-testgegevens

Als je testcases schrijft, heb je invoergegevens nodig voor elke soort test. De tester kan deze invoergegevens leveren op het moment dat de testgevallen worden uitgevoerd of de toepassing kan de vereiste invoergegevens kiezen uit de vooraf gedefinieerde gegevenslocaties.

De gegevens kunnen elke soort invoer in de applicatie zijn, elk soort bestand dat door de applicatie wordt geladen of ingangen die uit de databasetabellen worden gelezen.

Het voorbereiden van de juiste invoergegevens maakt deel uit van een testopstelling. Over het algemeen noemen testers het een testbed voorbereiding ​In het testbed worden alle software- en hardwarevereisten ingesteld met behulp van de voorgedefinieerde datawaarden.

Als u niet beschikt over de systematische aanpak voor het opbouwen van gegevens schrijven en uitvoeren van testcases dan zijn er kansen om enkele belangrijke testcases te missen. De testers kunnen hun eigen gegevens creëren op basis van de testbehoeften.

Vertrouw niet op de gegevens die door andere testers zijn gemaakt of op standaardproductiegegevens. Maak altijd een nieuwe set gegevens op basis van uw vereisten.

Soms is het niet mogelijk om voor elke build een volledig nieuwe set gegevens te maken. In dat geval kunt u gebruik maken van standaard productiegegevens. Maar vergeet niet om uw eigen datasets toe te voegen / in te voegen in deze bestaande database. Een beste manier om gegevens te creëren, is door de bestaande voorbeeldgegevens of het testbed te gebruiken en uw nieuwe testgevalgegevens toe te voegen elke keer dat u dezelfde module krijgt om te testen. Op deze manier kunt u gedurende de periode een uitgebreide dataset opbouwen.

Test uitdagingen op het gebied van data-sourcing

Een van de gebieden bij het genereren van testgegevens, beschouwen de testers als de vereiste voor het zoeken naar gegevens voor een subset. Je hebt bijvoorbeeld meer dan een miljoen klanten en je hebt er duizend nodig om te testen. En deze voorbeeldgegevens moeten consistent zijn en statistisch de juiste verdeling van de doelgroep vertegenwoordigen. Met andere woorden, we worden verondersteld de juiste persoon te vinden om te testen, wat een van de meest bruikbare methoden is om de use-cases te testen.

En deze voorbeeldgegevens moeten consistent zijn en statistisch de juiste verdeling van de doelgroep vertegenwoordigen. Met andere woorden, we worden verondersteld de juiste persoon te vinden om te testen, wat een van de meest bruikbare methoden is om de use-cases te testen.

Bovendien zijn er enkele omgevingsbeperkingen in het proces. Een daarvan is het in kaart brengen van PII-beleid. Omdat privacy een aanzienlijk obstakel is, moeten de testers PII-gegevens classificeren.

De tools voor testgegevensbeheer zijn ontworpen om het genoemde probleem aan te pakken. Deze tools suggereren beleid op basis van de standaarden / catalogus die ze hebben. Het is echter niet echt een veilige oefening. Het biedt nog steeds de mogelijkheid om te controleren wat iemand doet.

Om bij te blijven met het aanpakken van de huidige en zelfs de toekomstige uitdagingen, moeten we altijd vragen stellen als wanneer / waar moeten we beginnen met het uitvoeren van TDM? Wat moet er worden geautomatiseerd? Hoeveel investeringen moeten de bedrijven besteden aan testen op het gebied van de voortdurende ontwikkeling van menselijke hulpbronnen en het gebruik van nieuwere TDM-tools? Moeten we testen met functionele of met niet-functionele testen? En veel waarschijnlijkere vragen als deze.

Enkele van de meest voorkomende uitdagingen bij het zoeken naar testgegevens worden hieronder genoemd:

• De teams beschikken mogelijk niet over voldoende kennis en vaardigheden voor het genereren van testgegevens
• De dekking van testgegevens is vaak onvolledig
• Minder duidelijkheid in gegevensvereisten met betrekking tot volumespecificaties tijdens de verzamelingsfase
• Testteams hebben geen toegang tot de databronnen
• Vertraging bij het geven van toegang tot productiegegevens aan de testers door ontwikkelaars
• Gegevens uit de productieomgeving zijn mogelijk niet volledig bruikbaar voor testen op basis van de ontwikkelde bedrijfsscenario's
• Mogelijk zijn er in korte tijd grote hoeveelheden gegevens nodig
• Gegevensafhankelijkheden / -combinaties om enkele van de bedrijfsscenario's te testen
• De testers besteden meer tijd dan nodig is om te communiceren met architecten, databasebeheerders en BA's voor het verzamelen van gegevens
• Meestal worden de gegevens aangemaakt of voorbereid tijdens het uitvoeren van de test
• Meerdere applicaties en gegevensversies
• Continue releasecycli voor verschillende applicaties
• Wetgeving om te zorgen voor persoonlijke identificatie-informatie (PII)

Aan de witte dooskant van de datatest bereiden de ontwikkelaars de productiedata voor. Dat is waar QA's contact moeten hebben met de ontwikkelaars om de testdekking van AUT te bevorderen. Een van de grootste uitdagingen is om alle mogelijke scenario's (100% testcase) mee te nemen in elk mogelijk negatief geval.

In dit gedeelte hebben we het gehad over uitdagingen op het gebied van testgegevens. U kunt meer uitdagingen toevoegen naarmate u ze dienovereenkomstig hebt opgelost. Laten we vervolgens verschillende benaderingen onderzoeken voor het omgaan met ontwerp en beheer van testgegevens.

Strategieën voor het voorbereiden van testgegevens

We weten door de dagelijkse praktijk dat de spelers in de testindustrie voortdurend verschillende manieren en middelen ervaren om de testinspanningen en vooral de kostenefficiëntie te verbeteren. In het korte verloop van de informatie- en technologie-evolutie hebben we gezien dat wanneer tools werden opgenomen in de productie- / testomgevingen, het outputniveau aanzienlijk toenam.

Als we het hebben over de volledigheid en de volledige dekking van testen, hangt het vooral af van de kwaliteit van de gegevens. Omdat testen de ruggengraat is voor het bereiken van de kwaliteit van de software, vormen testgegevens het kernelement in het testproces.

Figuur 2: Strategieën voor Test Data Management (TDM)

Creëren van platte bestanden op basis van de toewijzingsregels. Het is altijd praktisch om een ​​subset te maken van de gegevens die u nodig hebt vanuit de productieomgeving waarin ontwikkelaars de applicatie hebben ontworpen en gecodeerd. Deze aanpak vermindert inderdaad de inspanningen van de testers om gegevens voor te bereiden, en maximaliseert het gebruik van de bestaande middelen om verdere uitgaven te vermijden.

Meestal moeten we de gegevens creëren of op zijn minst identificeren op basis van het soort vereisten dat elk project in het begin heeft.

We kunnen de volgende strategieën toepassen om het proces van TDM af te handelen:

1. Gegevens uit de productieomgeving
2. SQL-query's ophalen die gegevens uit de bestaande databases van de klant halen
3. Geautomatiseerde tools voor het genereren van gegevens

De testers dienen hun testen te onderbouwen met volledige gegevens door rekening te houden met de elementen zoals weergegeven in figuur 3 hier. De resters in agile ontwikkelteams genereren de benodigde data voor het uitvoeren van hun testcases. Als we het hebben over testcases, bedoelen we cases voor verschillende soorten tests, zoals de witte doos, zwarte doos, prestaties en beveiliging.

Op dit punt weten we dat gegevens voor prestatietests in staat moeten zijn om te bepalen hoe snel het systeem reageert onder een bepaalde werkbelasting, om zo dicht mogelijk bij de echte of live grote hoeveelheid gegevens met een aanzienlijke dekking te liggen.

Voor white box-tests bereiden de ontwikkelaars hun vereiste gegevens voor om zoveel mogelijk branches, alle paden in de programmabroncode en de negatieve Application Program Interface (API) te dekken.

Figuur 3: Test activiteiten voor het genereren van gegevens

Uiteindelijk kunnen we zeggen dat iedereen die in de levenscyclus van softwareontwikkeling werkt ( SDLC ) zoals BA's, ontwikkelaars en producteigenaren moeten goed worden betrokken bij het proces van de voorbereiding van testgegevens. Het kan een gezamenlijke inspanning zijn. En laten we u nu naar de kwestie van beschadigde testgegevens brengen.

Beschadigde testgegevens

Voordat we testcases uitvoeren op onze bestaande gegevens, moeten we ervoor zorgen dat de gegevens niet beschadigd / verouderd zijn en dat de te testen toepassing de gegevensbron kan lezen. Wanneer meer dan een tester tegelijkertijd aan verschillende modules van een AUT in de testomgeving werkt, is de kans dat gegevens beschadigd raken zo groot.

In dezelfde omgeving passen de testers de bestaande gegevens aan volgens hun behoefte / vereisten van de testgevallen. Meestal, wanneer de testers klaar zijn met de gegevens, laten ze de gegevens zoals ze zijn. Zodra de volgende tester de gewijzigde gegevens oppikt en hij / zij de test opnieuw uitvoert, bestaat de mogelijkheid dat die specifieke test mislukt, wat niet de codefout of het defect is.

In de meeste gevallen is dit de manier waarop gegevens beschadigd en / of verouderd raken, wat tot een storing leidt. Om de kans op discrepanties tussen gegevens te vermijden en te minimaliseren, kunnen we de onderstaande oplossingen toepassen. En natuurlijk kunt u aan het einde van deze zelfstudie meer oplossingen toevoegen in het opmerkingengedeelte.

1. De back-up van uw gegevens hebben
2. Zet uw gewijzigde gegevens terug in de oorspronkelijke staat
3. Gegevensverdeling tussen de testers
4. Houd de datawarehouse-beheerder op de hoogte van elke wijziging / wijziging van gegevens

Hoe houdt u uw gegevens intact in elke testomgeving?

Meestal zijn veel testers verantwoordelijk voor het testen van dezelfde build. In dit geval hebben meer dan één tester toegang tot gemeenschappelijke gegevens en zullen ze proberen de gemeenschappelijke gegevensverzameling te manipuleren volgens hun behoeften.

Als u gegevens hebt voorbereid voor een aantal specifieke modules, is de beste manier om uw gegevensset intact te houden, het bewaren van reservekopieën daarvan.

Testgegevens voor de prestatietestcase

Prestatietests vereisen een zeer grote dataset. Soms worden bij het handmatig aanmaken van gegevens geen subtiele bugs gedetecteerd die mogelijk alleen worden opgevangen door feitelijke gegevens die zijn gemaakt door de te testen applicatie. Wil je real-time data, die je niet handmatig kunt aanmaken, vraag dan je lead / manager om deze vanuit de live omgeving beschikbaar te stellen.

Deze gegevens zullen nuttig zijn om de vlotte werking van de applicatie voor alle geldige inputs te garanderen.

Wat zijn de ideale testgegevens?

Gegevens kunnen als ideaal worden beschouwd als voor de minimale omvang van de gegevensverzameling alle toepassingsfouten worden geïdentificeerd. Probeer gegevens voor te bereiden die alle toepassingsfunctionaliteit bevatten, maar waarbij u de kosten en tijd niet overschrijdt voor het voorbereiden van gegevens en het uitvoeren van tests.

Hoe bereid ik gegevens voor die een maximale testdekking garanderen?

Ontwerp uw gegevens met inachtneming van de volgende categorieën:

1) Geen gegevens: Voer uw testcases uit op blanco of standaardgegevens. Kijk of de juiste foutmeldingen worden gegenereerd.

2) Geldige dataset: Maak het om te controleren of de applicatie functioneert volgens de vereisten en of geldige invoergegevens correct zijn opgeslagen in de database of bestanden.

3) Ongeldige dataset: Bereid ongeldige gegevensset voor om het gedrag van de toepassing te controleren op negatieve waarden, alfanumerieke tekenreeksinvoer.

4) Illegaal gegevensformaat: Maak een gegevensset met een illegaal gegevensformaat. Het systeem mag geen gegevens in een ongeldig of illegaal formaat accepteren. Controleer ook of de juiste foutmeldingen worden gegenereerd.

5) Gegevensset grensconditie: Dataset met gegevens buiten het bereik. Identificeer toepassingsgrensgevallen en bereid een dataset voor die zowel onder- als bovengrenscondities omvat.

6) De dataset voor prestatie-, belasting- en stresstests: Deze dataset moet een groot volume hebben.

Op deze manier zorgt het creëren van afzonderlijke datasets voor elke testconditie voor een volledige testdekking.

Gegevens voor Black Box-tests

De Quality Assurance Testers voeren integratietesten, systeemtesten en acceptatietesten uit, ook wel black box testing genoemd. Bij deze testmethode hebben de testers geen werk aan de interne structuur, het ontwerp en de code van de applicatie die wordt getest.

Het primaire doel van de testers is het identificeren en lokaliseren van fouten. Door dit te doen, passen we functionele of niet-functionele testen toe met behulp van verschillende technieken van black box-testen.

Figuur 4: Black Box-gegevensontwerpmethoden

Op dit punt hebben de testers de testgegevens nodig als invoer voor het uitvoeren en implementeren van de technieken van de black box-testen. En de testers moeten de gegevens voorbereiden die alle toepassingsfunctionaliteit zullen onderzoeken zonder de opgegeven kosten en tijd te overschrijden.

We kunnen de gegevens voor onze testcases ontwerpen, rekening houdend met datasetcategorieën zoals geen gegevens, geldige gegevens, ongeldige gegevens, illegaal gegevensformaat, gegevens over randvoorwaarden, equivalentiepartitie, beslissingsgegevenstabel, gegevens over toestandsovergangen en use case-gegevens. Alvorens in te gaan op de categorieën van datasets, beginnen de testers met het verzamelen en analyseren van de bestaande bronnen van de applicatie onder tester (AUT).

Volgens de eerder genoemde punten over het altijd up-to-date houden van uw datawarehouse, moet u de gegevensvereisten op testcase-niveau documenteren en deze als bruikbaar of niet-herbruikbaar markeren wanneer u uw testcases scriptt. Het helpt u dat de gegevens die nodig zijn voor het testen vanaf het begin goed worden gewist en gedocumenteerd, zodat u er later naar kunt verwijzen voor verder gebruik.

Voorbeeld van testgegevens voor Open EMR AUT

Voor onze huidige tutorial hebben we de Open EMR als de Application Under Test (AUT).

=> Zoek de link voor Open EMR-applicatie hier voor uw referentie / praktijk.

De onderstaande tabel illustreert vrijwel een voorbeeld van het verzamelen van gegevensvereisten die deel kunnen uitmaken van de testcase-documentatie en wordt bijgewerkt wanneer u de testcases voor uw testscenario's schrijft.

​ NOTITIE ​ Klik op een afbeelding voor een vergrote weergave)

Aanmaken van handmatige gegevens voor het testen van Open EMR-applicatie

Laten we een stap vooruit gaan naar het creëren van handmatige gegevens voor het testen van de Open EMR-applicatie voor de gegeven datasetcategorieën.

1) Geen gegevens: De tester valideert de Open EMR-toepassings-URL en de 'Zoek of voeg patiënt toe' -functies zonder gegevens op te geven.

twee) Geldige gegevens: De tester valideert de Open EMR-toepassings-URL en de functie 'Patiënt zoeken of toevoegen' door geldige gegevens op te geven.

3) Ongeldige gegevens: De tester valideert de Open EMR-toepassings-URL en de functie 'Patiënt zoeken of toevoegen' door ongeldige gegevens op te geven.

4) Illegaal gegevensformaat: De tester valideert de Open EMR-toepassings-URL en de functie 'Patiënt zoeken of toevoegen' door ongeldige gegevens op te geven.

Testgegevens voor 1-4 gegevenssetcategorieën:

websites om gratis anime te kijken

5) Gegevensset grensvoorwaarden: Het is bedoeld om invoerwaarden te bepalen voor grenzen die binnen of buiten de opgegeven waarden als gegevens liggen.

6) Equivalentiepartitiegegevensset: Het is de testtechniek die uw invoergegevens verdeelt in de invoerwaarden van geldig en ongeldig.

Testgegevens voor 5^then 6^thdatasetcategorieën, dat is voor Open EMR gebruikersnaam en wachtwoord:

7) Beslissingstabel dataset: Het is de techniek om uw gegevens te kwalificeren met een combinatie van invoer om verschillende resultaten te produceren. Deze methode van black-box-testen helpt u om uw testinspanningen te verminderen bij het verifiëren van elke combinatie van testgegevens. Bovendien kan deze techniek u verzekeren van de volledige testdekking.

Zie hieronder de dataset van de beslissingstabel voor de gebruikersnaam en het wachtwoord van de Open EMR-applicatie.

De berekening van de combinaties in de bovenstaande tabel wordt hieronder beschreven voor uw gedetailleerde informatie. Je hebt het misschien nodig als je meer dan vier combinaties doet.

• Aantal combinaties = Aantal voorwaarden 1 waarden * Aantal voorwaarden 2 waarden
• Aantal combinaties = 2 ^ Aantal waar / niet waar voorwaarden
• Voorbeeld: aantal combinaties - 2 ^ 2 = 4

8) Gegevensset voor statusovergangstest: Het is de testtechniek die u helpt om de statusovergang van de Application Under Test (AUT) te valideren door het systeem te voorzien van de invoercondities.

Bijvoorbeeld, loggen we in op de Open EMR-applicatie door bij de eerste poging de juiste gebruikersnaam en het wachtwoord op te geven. Het systeem geeft ons toegang, maar als we de verkeerde inloggegevens invoeren, weigert het systeem de toegang. Testen van statusovergang valideren hoeveel aanmeldingspogingen u kunt doen voordat Open EMR wordt gesloten.

De onderstaande tabel geeft aan hoe de juiste of onjuiste inlogpogingen reageren

9) Gebruik Case Test Datum: Het is de testmethode die onze testcases identificeert en het end-to-end testen van een bepaald kenmerk vastlegt.

Voorbeeld, open EMR-login:

Lees ook => Technieken voor gegevensgegevensbeheer

Eigenschappen van goede testgegevens

Als tester moet je de module ‘Examenresultaten’ van de website van een universiteit testen. Bedenk dat de hele applicatie is geïntegreerd en zich in de status ‘Klaar voor testen’ bevindt. ‘Examenmodule’ is gekoppeld aan ‘Registratie’, ‘Cursussen’ en ‘Financiën’ modules.

Stel dat u voldoende informatie heeft over de toepassing en dat u een uitgebreide lijst met testscenario's hebt gemaakt. Nu moet je deze testcases ontwerpen, documenteren en uitvoeren. In ‘Acties / Stappen’ of ‘Testinputs’ van de testcases moet u de acceptabele gegevens vermelden als input voor de test.

De gegevens die in testcases worden genoemd, moeten correct worden geselecteerd. De nauwkeurigheid van de kolom ‘Werkelijke resultaten’ van het testcasedocument is voornamelijk afhankelijk van de testgegevens. De stap om de invoertestgegevens voor te bereiden, is dus aanzienlijk belangrijk. Daarom is hier mijn overzicht van 'DB-testen - Strategieën voor het voorbereiden van testgegevens'.

Test gegevenseigenschappen

De testgegevens moeten nauwkeurig worden gekozen en moeten de volgende vier eigenschappen bezitten:

1) Realistisch:

Realistisch betekent dit dat de gegevens nauwkeurig moeten zijn in de context van real-life scenario's. Als u bijvoorbeeld het veld ‘Leeftijd’ wilt testen, moeten alle waarden positief zijn en 18 of hoger. Het is vrij duidelijk dat de kandidaten voor toelating tot de universiteit meestal 18 jaar oud zijn (dit kan anders worden gedefinieerd in termen van zakelijke vereisten).

Als het testen wordt gedaan met behulp van realistische testgegevens, wordt de app robuuster omdat de meeste mogelijke bugs kunnen worden vastgelegd met behulp van realistische gegevens. Een ander voordeel van realistische gegevens is de herbruikbaarheid ervan, waardoor we tijd en moeite besparen om steeds weer nieuwe gegevens te creëren.

Als we het hebben over realistische data, dan wil ik je laten kennismaken met het concept van de gouden dataset. Een gouden dataset is degene die bijna alle mogelijke scenario's omvat die zich in het echte project voordoen. Door gebruik te maken van de GDS kunnen we een maximale testdekking bieden. Ik gebruik de GDS voor het doen van regressietesten in mijn organisatie en dit helpt me om alle mogelijke scenario's te testen die kunnen optreden als de code in de productiebox terechtkomt.

Er zijn veel tools voor het genereren van testgegevens op de markt die de kolomkenmerken en gebruikersdefinities in de database analyseren en op basis hiervan realistische testgegevens voor u genereren. Er zijn maar weinig goede voorbeelden van de tools die gegevens genereren voor databasetests DTM-gegevensgenerator ​ SQL-gegevensgenerator en Mockaroo ​

2. Praktisch geldig:

Dit is vergelijkbaar met realistisch, maar niet hetzelfde. Deze eigenschap is meer gerelateerd aan de bedrijfslogica van AUT, bijv. waarde 60 is realistisch op het gebied van leeftijd, maar praktisch ongeldig voor een kandidaat van afstudeer- of zelfs masterprogramma's. In dit geval zou een geldig bereik 18-25 jaar zijn (dit kan worden gedefinieerd in vereisten).

3. Veelzijdig om scenario's te dekken:

hoe u .eps-bestanden opent in Windows 10

Er kunnen verschillende opeenvolgende voorwaarden zijn in een enkel scenario, dus kies de gegevens slim om maximale aspecten van een enkel scenario te dekken met de minimale set gegevens, bijv. Denk bij het aanmaken van toetsgegevens voor de resultaatmodule niet alleen aan het geval van reguliere studenten die hun opleiding vlot afronden. Geef aandacht aan de studenten die dezelfde cursus herhalen en tot verschillende semesters of zelfs verschillende opleidingen behoren. De dataset kan er als volgt uitzien:

Er kunnen verschillende andere interessante en lastige subvoorwaarden zijn. Bijv. de beperking van het aantal jaren om een ​​opleiding af te ronden, het behalen van een vereiste cursus voor het inschrijven van een cursus, maximaal aantal. van cursussen die een student kan inschrijven voor een enkel semester enz. enz. Zorg ervoor dat u al deze scenario's verstandig behandelt met de eindige reeks gegevens.

4. Uitzonderlijke gegevens (indien van toepassing / vereist):

Er kunnen bepaalde uitzonderlijke scenario's zijn die minder vaak voorkomen maar veel aandacht vragen wanneer ze zich voordoen, bijv. problemen met gehandicapte studenten.

Een andere goede uitleg en voorbeeld van de uitzonderlijke dataset is te zien in de onderstaande afbeelding:

Afhalen:

Een testdata staat bekend als goede testdata als deze realistisch, valide en veelzijdig is. Het is een bijkomend voordeel als de gegevens ook dekking bieden voor uitzonderlijke scenario's.

Test gegevensvoorbereidingstechnieken

We hebben kort de belangrijke eigenschappen van testdata besproken en er is ook uitgewerkt hoe testdata-selectie belangrijk is tijdens het testen van de database. Laten we nu de ​ technieken om testgegevens voor te bereiden ​ ​

Er zijn slechts twee manieren om testgegevens voor te bereiden:

Methode # 1) Voeg nieuwe gegevens in

Zorg voor een schone database en voer alle gegevens in zoals gespecificeerd in uw testcases. Zodra al uw vereiste en gewenste gegevens zijn ingevoerd, begint u met het uitvoeren van uw testcases en vult u de ‘Pass / Fail’ -kolommen in door de ‘Werkelijke output’ te vergelijken met ‘Verwachte output’. Klinkt simpel toch? Maar wacht, zo eenvoudig is het niet.

Enkele essentiële en kritische zorgen zijn als volgt:

• Een leeg exemplaar van de database is mogelijk niet beschikbaar
• Ingevoegde testgegevens zijn mogelijk onvoldoende voor het testen van bepaalde gevallen, zoals prestatie- en belastingtests.
• Het invoegen van de vereiste testgegevens in een lege DB is geen gemakkelijke taak vanwege de afhankelijkheden van de databasetabel. Vanwege deze onvermijdelijke beperking kan het invoegen van gegevens een moeilijke taak voor de tester worden.
• Het invoegen van beperkte testgegevens (alleen al naargelang de behoeften van de testcase) kan enkele problemen verbergen die alleen met de grote dataset konden worden gevonden.
• Voor het invoegen van gegevens kunnen complexe vragen en / of procedures vereist zijn, en hiervoor is voldoende assistentie of hulp van de DB-ontwikkelaar (s) nodig.

De bovengenoemde vijf problemen zijn de meest kritische en de meest voor de hand liggende nadelen van deze techniek voor het voorbereiden van testgegevens. Maar er zijn ook enkele voordelen:

• De uitvoering van TC's wordt efficiënter omdat de database alleen over de vereiste gegevens beschikt.
• Het isoleren van bugs vereist geen tijd omdat alleen de gegevens die in testgevallen zijn gespecificeerd aanwezig zijn in de database.
• Minder tijd nodig voor testen en vergelijking van resultaten.
• Overzichtelijk testproces

Methode # 2) Kies een voorbeeldgegevenssubset uit de werkelijke DB-gegevens

Dit is een haalbare en meer praktische techniek voor het voorbereiden van testgegevens. Het vereist echter gedegen technische vaardigheden en vereist gedetailleerde kennis van DB Schema en SQL. Bij deze methode moet u productiegegevens kopiëren en gebruiken door enkele veldwaarden te vervangen door dummy-waarden. Dit is de beste gegevenssubset voor uw tests, aangezien deze de productiegegevens vertegenwoordigt. Maar dit is misschien niet altijd haalbaar vanwege problemen met gegevensbeveiliging en privacy.

Afhalen:

In het bovenstaande gedeelte hebben we hierboven de technieken voor het voorbereiden van testgegevens besproken. Kortom, er zijn twee technieken: maak nieuwe gegevens of selecteer een subset uit reeds bestaande gegevens. Beide moeten zo worden uitgevoerd dat de geselecteerde gegevens dekking bieden voor verschillende testscenario's, voornamelijk geldige en ongeldige tests, prestatietests en nultests.

Laten we in de laatste sectie ook een korte rondleiding volgen door de benaderingen voor het genereren van gegevens. Deze benaderingen zijn handig wanneer we nieuwe gegevens moeten genereren.

Methoden voor het genereren van gegevens testen:

• Handmatige generatie van testgegevens: Bij deze benadering worden de testgegevens handmatig ingevoerd door testers volgens de vereisten van de testcase. Het is een tijd die het proces in beslag neemt en ook vatbaar voor fouten.
• Geautomatiseerde generatie van testgegevens: Dit wordt gedaan met behulp van tools voor het genereren van gegevens. Het belangrijkste voordeel van deze aanpak is de snelheid en nauwkeurigheid. Het kost echter meer dan het handmatig genereren van testgegevens.
• Back-end data-injectie : Dit wordt gedaan door middel van SQL-query's. Deze aanpak kan ook de bestaande gegevens in de database bijwerken. Het is snel en efficiënt, maar moet zeer zorgvuldig worden geïmplementeerd, zodat de bestaande database niet beschadigd raakt.
• Gebruik van tools van derden : Er zijn tools beschikbaar op de markt die eerst uw testscenario's begrijpen en vervolgens gegevens genereren of injecteren om een ​​brede testdekking te bieden. Deze tools zijn nauwkeurig omdat ze zijn aangepast aan de zakelijke behoeften. Maar ze zijn behoorlijk duur.

Afhalen:

Er zijn 4 manieren om het genereren van gegevens te testen:

1. Handboek,
2. automatisering,
3. back-end data-injectie,
4. en tools van derden.

Elke benadering heeft zijn eigen voor- en nadelen. U moet de aanpak selecteren die voldoet aan uw zakelijke en testbehoeften.

Gevolgtrekking

Het creëren van complete softwaretestgegevens in overeenstemming met de industrienormen, wetgeving en de basisdocumenten van het uitgevoerde project behoort tot de kernverantwoordelijkheden van de testers. Hoe efficiënter we de testgegevens beheren, hoe meer we redelijk foutloze producten kunnen inzetten voor gebruikers in de echte wereld.

Testgegevensbeheer (TDM) is het proces dat is gebaseerd op de analyse van uitdagingen en het introduceren en toepassen van de beste tools en methoden om de geïdentificeerde problemen goed aan te pakken zonder de betrouwbaarheid en de volledige dekking van de eindoutput (product) in gevaar te brengen.

We moeten altijd vragen bedenken om te zoeken naar innovatieve en meer kosteneffectieve methoden voor het analyseren en selecteren van testmethoden, inclusief het gebruik van tools voor het genereren van de gegevens. Het is algemeen bewezen dat goed ontworpen gegevens ons in staat stellen defecten van de te testen applicatie in elke fase van een meerfasige SDLC te identificeren.

We moeten creatief zijn en meedoen met alle leden binnen en buiten ons agile team. Deel alstublieft uw feedback, ervaring, vragen en opmerkingen, zodat we onze technische discussies kunnen voortzetten om onze positieve impact op AUT te maximaliseren door gegevens te beheren.

Het voorbereiden van de juiste testgegevens is een kernonderdeel van de “opzet van de projecttestomgeving”. We kunnen de testcase niet missen door te zeggen dat er niet volledige gegevens beschikbaar waren om te testen. De tester moet zijn / haar eigen testgegevens creëren naast de bestaande standaardproductiegegevens. Uw dataset moet qua kosten en tijd ideaal zijn.

Wees creatief, gebruik uw eigen vaardigheden en oordelen om verschillende datasets te maken in plaats van te vertrouwen op standaard productiegegevens.

Deel II - Het tweede deel van deze tutorial is op de ​ Testgegevensgeneratie met GEDIS Studio Online Tool ​

Heeft u te maken gehad met het probleem van onvolledige testgegevens om te testen? Hoe is het gelukt? Deel uw tips, ervaringen, opmerkingen en vragen om dit gespreksonderwerp verder te verrijken.

Aanbevolen literatuur

• ETL-testen Tutorial datawarehouse-testen (een complete gids)
• Wat is mutatietesten: zelfstudie met voorbeelden
• Gegevensgestuurde tests uitvoeren met de TestComplete Tool
• Datagestuurd of geparametriseerd testen met Spock Framework
• De 4 stappen naar Business Intelligence (BI) -testen: hoe u bedrijfsgegevens test
• Zelfstudie voor het testen van volumes: voorbeelden en tools voor het testen van volumes
• Een uitstekende manier om gegevens te testen met behulp van XML-technologieën (witboek)
• Top 10 gestructureerde gegevenstest- en validatietools voor SEO