volume testing tutorial
Overzicht van volumetests:
Komt de onderstaande afbeelding op de een of andere manier overeen met onze apps? Ja, dit is wat er precies gebeurt als we onze servers, databases, webservices, enz. Overbelasten.
We moeten allemaal op de hoogte zijn van functionele en niet-functionele tests, maar weet u ook dat niet-functionele tests net zo belangrijk zijn als functionele tests? Soms negeren we in releases met een korte duur deze niet-functionele tests, wat idealiter niet zou moeten.
Het maakt voor ons niet uit of de producteigenaar aan deze eis heeft voldaan of niet. We moeten dit testen beschouwen als een onderdeel van ons complete testproces, zelfs voor kleine releases.
Deze tutorial over volumetesten geeft u een compleet overzicht van de betekenis, de noodzaak, het belang, de checklist en enkele van de tools om u in staat te stellen het op een betere manier te begrijpen.
Wat je leert:
- Wat is volumetesten?
- Wanneer is deze toetsing noodzakelijk?
- Waarom zou ik streven naar volumetests?
- Wat is mijn checklist voor deze tests?
- Volume testen versus belasting testen
- Hoe voer je deze test uit?
- Hulpmiddelen voor het testen van volumes
- Gevolgtrekking
- Aanbevolen literatuur
Wat is volumetesten?
Volumetesten is een soort niet-functionele test. Deze test wordt gedaan om het datavolume te controleren dat door de database wordt verwerkt. Volumetests, ook wel overstromingstests genoemd, zijn niet-functionele tests die worden uitgevoerd om de prestaties van de software of app te vergelijken met enorme gegevens van de database.
De database wordt uitgerekt tot een drempelpunt door er een grote hoeveelheid gegevens aan toe te voegen en vervolgens wordt het systeem getest op zijn respons.
Dit was het theoriegedeelte, laat me je uitleggen met een paar praktische voorbeelden om je te helpen het te begrijpen 'wanneer' onderdeel van volume testen.
Wanneer is deze toetsing noodzakelijk?
Idealiter zou elke software of app moeten worden getest op datavolume, maar in sommige gevallen waarin de gegevens niet zwaar zullen zijn, hebben we de neiging om deze tests te vermijden. Maar in sommige gevallen waarin gegevens dagelijks in MB's of GB's worden verwerkt, moet beslist een volumetest worden uitgevoerd.
Hieronder volgen enkele voorbeelden uit mijn eigen ervaring van 8 jaar die het 'wanneer'-gedeelte verklaren:
Voorbeeld 1:
Een van mijn ondernemingen was een groot systeem dat zowel uit een webapp als een mobiele app bestond. Maar de web-app zelf had 3 modules die door 3 verschillende teams werden afgehandeld.
Soms, zelfs bij ons, werd de database traag als we allemaal ‘samen’ gegevens toevoegden voor onze tests. Het was vervelend en het werk werd vroeger belemmerd door de enorme hoeveelheid gegevens en om het werk te vergemakkelijken moesten we de DB vrij vaak opschonen.
De gegevens die het 'live'-systeem verwerkte, waren ongeveer een GB, dus in vergelijking met de mobiele app werd de web-app zeer vaak getest op het datavolume. De QA-teams van de webapp hadden hun eigen automatiseringsscripts die 's nachts zouden worden uitgevoerd en deze tests zouden uitvoeren.
Voorbeeld 2:
Een ander voorbeeld van mijn onderneming was een ecosysteem dat niet alleen een webapp had, maar ook een SharePoint-app en zelfs een installatieprogramma. Al deze systemen communiceerden met dezelfde database voor gegevensoverdrachten. De gegevens die door dat systeem werden verwerkt, waren ook erg groot en als de DB om welke reden dan ook traag wordt, stopt zelfs het installatieprogramma met werken.
Daarom werd er regelmatig een volumetest uitgevoerd en werden de DB-prestaties minutieus geobserveerd op eventuele problemen.
Evenzo we kunnen nemenVoorbeeldenvan de weinige apps die we dagelijks gebruiken om te winkelen, tickets te boeken, financiële transacties enz. die te maken hebben met zware datatransacties en daarom een volumetest nodig hebben.
Aan de andere kant is het testen van een ideaal volume misschien niet altijd haalbaar, omdat het zijn eigen beperkingen en uitdagingen heeft.
Enkele van de beperkingen en uitdagingen zijn:
- Het is moeilijk om de exacte fragmentatie van het geheugen te creëren.
- Dynamische sleutelgeneratie is lastig.
- Het creëren van een ideale echte omgeving, d.w.z. de replica van de live server, kan lastig zijn.
- Automatiseringstools, netwerk etc. hebben ook invloed op de testresultaten.
Nu hebben we het begrepen wanneer we moeten dit soort testen doen. Laten we het ook begrijpen 'waarom' we moeten dit testen doen zoals in het doel of doel van het uitvoeren van deze testen.
Waarom zou ik streven naar volumetests?
Volumetests kunnen u helpen te begrijpen hoe geschikt uw systeem is voor de echte wereld en het helpt ook om uw geld te besparen dat later zal worden besteed aan onderhoudsdoeleinden.
Hieronder volgen enkele mogelijke redenen om deze test uit te voeren:
- De meest elementaire behoefte is om de prestaties van uw systeem te vergelijken met meer gegevens. Door een enorme hoeveelheid gegevens te creëren, krijgt u inzicht in de prestaties van uw systeem in termen van reactietijd, gegevensverlies, enz.
- Identificeer de problemen die zich voordoen met enorme gegevens en het drempelpunt.
- Buiten het duurzame of drempelpunt, het systeemgedrag, d.w.z. als de DB-crash onverwacht wordt of een time-out optreedt.
- Oplossingen implementeren voor DB-overbelasting en deze zelfs verifiëren.
- Het uiterste punt van uw DB achterhalen (dat niet kan worden opgelost) waarboven het systeem zal falen en daarom moeten voorzorgsmaatregelen worden genomen.
- In het geval van meer dan één DB-servers, het achterhalen van de problemen met DB-communicatie, d.w.z. de meest kans op storingen, enz.
Nu kennen we het belang en de reden voor het uitvoeren van deze tests.
OF Een ervaring die ik hier graag wil delen, is dat in termen van mobiele apps volumetests misschien niet nodig zijn omdat slechts één persoon de app tegelijk gebruikt en mobiele apps zijn ontworpen om eenvoudig te zijn
Dus tenzij u een zeer complexe app heeft met veel gegevens, kunnen volumetests worden overgeslagen.
Als u eenmaal weet wat er moet worden geverifieerd voor uw systeem of app, is het volgende dat u moet doen een checklist maken voor uw app om te definiëren 'wat' moet worden getest.
Wat is mijn checklist voor deze tests?
Voordat we ingaan op enkele voorbeelden voor het maken van een checklist voor uw app of een systeem, moeten we eerst enkele punten begrijpen waarmee we rekening moeten houden bij het maken van een checklist voor het testen van volumes of de aanpak voordat we met het testen beginnen.
Punten om te onthouden:
- Houd de ontwikkelaars op de hoogte van uw testplan, want ze weten veel van het systeem en kunnen u input en zelfs bottlenecks geven.
- Begrijp het fysieke aspect, zoals in de serverconfiguraties, RAM, processor enz., Goed voordat u de teststrategie opstelt.
- Begrijp de complexiteit van de database, de procedures, databasescripts enz. Voor zover mogelijk, zodat u de complexiteit van uw systeem in zijn geheel kunt schetsen.
- Bereid informatica voor, d.w.z. grafieken, gegevensblad, enz., Indien mogelijk voor de normale hoeveelheid gegevens en hoe goed het systeem is, dit zal u helpen ervoor te zorgen dat voordat u de DB beklemtoont, de prestaties goed zijn voor normale gegevensbelasting. Dit helpt u er ook voor te zorgen, voordat u verder gaat met het stressgedeelte, dat er geen problemen zijn die een oplossing vereisen voor uw volumetest.
Hieronder volgen enkele voorbeelden die u kunt toevoegen aan of gebruiken in uw checklist:
- Controleer de juistheid van de methoden voor gegevensopslag.
- Controleer of het systeem over de benodigde geheugenbronnen beschikt of niet.
- Controleer of er een risico bestaat dat het datavolume groter is dan een opgegeven limiet.
- Controleer en observeer de reactie van het systeem op het datavolume.
- Controleer of de gegevens verloren gaan tijdens het testen van het volume.
- Controleer of als gegevens worden overschreven, dit gebeurt met voorafgaande informatie.
- Identificeer de gebieden die buiten het normale bereik vallen, zoals veel attributen (doorzoekbaar), enorm nee. van opzoektabellen, veel locatietoewijzingen, enz.
- Zoals eerder vermeld, maakt u eerst een basislijn door resultaten voor het normale volume te krijgen en vervolgens verder te gaan met stress.
Voordat we verder gaan met de andere voorbeelden, testcases en tools, moeten we eerst begrijpen hoe dit testen verschilt van load testen.
Volume testen versus belasting testen
Hieronder staan enkele van de belangrijkste verschillen tussen volume- en belastingtests:
| S.No. | Volume testen | Laadtesten |
|---|---|---|
| 1 | De volumetests worden uitgevoerd om de databaseprestaties te vergelijken met een grote hoeveelheid gegevens in de database. | De belastingstest wordt gedaan door de gebruikersbelastingen voor de bronnen te wijzigen en de prestaties van de bronnen te verifiëren. |
| twee | De primaire focus van deze tests ligt op ‘data’. | De primaire focus van deze test is op ‘gebruikers’. |
| 3 | De database wordt tot het uiterste belast. | De server wordt tot het uiterste belast. |
| 4 | Een eenvoudig voorbeeld kan het maken van een enorm groot bestand zijn. | Een eenvoudig voorbeeld kan het maken van een groot aantal bestanden zijn. |
Hoe voer je deze test uit?
Deze tests kunnen zowel handmatig als met een willekeurig hulpmiddel worden uitgevoerd. Over het algemeen zal het gebruik van tools onze tijd en moeite besparen, maar in het geval van een volumetest, zoals ik heb ervaren het gebruik van tools kan u nauwkeurigere resultaten opleveren in vergelijking met handmatige tests.
Voordat u met de uitvoering van uw testcase begint, moet u ervoor zorgen dat:
- Het team heeft ingestemd met het testplan voor deze testen.
- Andere teams van uw project zijn goed geïnformeerd over de wijzigingen in de database en de impact ervan op hun werk.
- De testopstellingen zijn ingesteld voor de opgegeven configuraties.
- De basislijn voor testen wordt voorbereid.
- De specifieke datavolumes voor testen (datascripts of procedures etc) zijn klaar. U kunt meer lezen over tools voor het maken van gegevens op onze gegevensgeneratiepagina.
Laten we enkele voorbeeldtestcases bekijken die u bij de uitvoering kunt gebruiken:
Controleer dit voor alle geselecteerde datavolumes voor volumetests:
- Controleer of het toevoegen van gegevens met succes kan worden gedaan en of dit wordt weerspiegeld in de app of website.
- Controleer of het verwijderen van gegevens met succes kan worden uitgevoerd en of dit wordt weerspiegeld in de app of website.
- Controleer of het bijwerken van gegevens met succes kan worden uitgevoerd en of dit wordt weerspiegeld in de app of website.
- Controleer of er geen gegevensverlies is en of alle informatie wordt weergegeven zoals verwacht in de app of website.
- Controleer of de app of webpagina's geen time-out krijgen vanwege een hoog datavolume.
- Controleer of crashfouten niet worden weergegeven vanwege een hoog datavolume.
- Controleer of de gegevens niet worden overschreven en dat de juiste waarschuwingen worden weergegeven.
- Controleer of andere modules van uw website of app niet crashen of een time-out krijgen met een hoog datavolume.
- Controleer of de responstijd van de DB binnen het acceptabele bereik ligt.
Hulpmiddelen voor het testen van volumes
Zoals eerder besproken, bespaart automatiseringstesten tijd en geeft het zelfs nauwkeurige resultaten in vergelijking met handmatig testen. Een ander voordeel van het gebruik van tools voor volumetests is dat we de tests 's nachts kunnen uitvoeren en op die manier wordt het werk van de andere teams of teamleden niet beïnvloed door het datavolume van de database.
We kunnen de tests in de ochtend plannen en de resultaten zijn klaar.
Hieronder volgt een lijst met enkele open-source volumetesttools:
# 1) DbFit:
Dit is een open-source tool die testgestuurde ontwikkeling ondersteunt.
DbFit Testraamwerk is bovenop Fitness geschreven, de tests zijn geschreven met tabellen en kunnen worden uitgevoerd met elke Java IDE- of CI-tool.
# 2) HammerDb:
HammerDb is ook een open-source tool die kan worden geautomatiseerd, multi-threaded en zelfs run-time scripting mogelijk maakt. Het kan werken met SQL, Oracle, MYSQL etc.
# 3) JdbcSlim:
JdbcSlim commando's kunnen eenvoudig in Slim Fitness worden geïntegreerd en het ondersteunt alle databases die een JDBC-stuurprogramma hebben. De focus ligt op het gescheiden houden van de configuratie, testdata en SQL-queries.
# 4) NoSQLMap:
Dit is een open-source Python-tool die is ontworpen om automatisch aanvallen te injecteren en de DB-configuraties te verstoren om de dreiging te analyseren. Het werkt alleen voor MongoDB.
# 5) Ruby-PLSQL-spec
De PLSQL kan worden getest met behulp van Ruby, aangezien Oracle beschikbaar is als open-source tool. Dit gebruikt in principe twee bibliotheken: Ruby-PLSQL en Rspec.
Gevolgtrekking
Volumetests zijn niet-functionele tests die worden uitgevoerd om de prestaties van de database te analyseren. Het kan zowel handmatig als met behulp van enkele tools worden gedaan.
Als u een QA bent die nieuw is bij deze test, raad ik u aan om met de tool te spelen of eerst enkele testcases uit te voeren. Dit zal u helpen het concept van volumetesten te begrijpen voordat u met testen begint.
prestatietests interviewvragen voor ervaren
Dit testen is behoorlijk lastig en het heeft zijn eigen uitdagingen, daarom is het erg belangrijk om een grondige kennis te hebben van het concept, de testbedcreatie en de DB-taal voordat je het uitvoert.
Ik hoop dat deze tutorial je kennisvolume over dit onderwerp zou hebben vergroot :)
Aanbevolen literatuur
- Beste softwaretesttools 2021 (QA Test Automation Tools)
- Zelfstudie over paarsgewijs testen of testen in alle paren met tools en voorbeelden
- Functioneel testen versus niet-functioneel testen
- Tutorial voor configuratietesten met voorbeelden
- Primer eBook downloaden testen
- Tutorial over destructief testen en niet-destructief testen
- 11 beste automatiseringstools voor het testen van Android-applicaties (Android App Testing Tools)
- Beste IVR-testtools: CYARA en HAMMER-testhandleiding