Volymtesthandledning: Exempel och volymtestverktyg

volume testing tutorial

Översikt av volymtestning:

Korrelerar bilden nedan med våra appar på något eller annat sätt? Ja, det här är exakt vad som händer när vi överbelastar våra servrar, databaser, webbtjänster etc.

Vi måste alla vara medvetna om funktionell och icke-funktionell testning, men är du uppmärksam på att icke-funktionell testning är lika viktig som funktionstestning? Ibland i kortvariga utgåvor tenderar vi att ignorera denna icke-funktionella testning, som vi helst inte borde göra.

Det borde inte ha någon betydelse för oss om produktägaren har gett detta krav eller inte. Vi bör betrakta denna testning som en del av vår kompletta testprocess även för små utgåvor.

Denna handledning om volymtestning ger dig en fullständig översikt över dess betydelse, behov, betydelse, checklista och några av dess verktyg så att du kan förstå det på ett bättre sätt.

Vad du kommer att lära dig:

• Vad är volymtestning?
• När är detta tvingande viktigt?
• Varför ska jag sikta på volymtestning?
• Vad är min checklista för denna testning?
• Volymtestning mot belastningstestning
• Hur utför jag denna testning?
• Volymtestverktyg
• Slutsats
• Rekommenderad läsning

Vad är volymtestning?

Volymtestning är en typ av icke-funktionell testning. Denna testning görs för att kontrollera datavolymen som hanteras av databasen. Volymtest som också kallas översvämningstestning är icke-funktionell testning som görs för att kontrollera programvaran eller appen för dess prestanda mot enorma data i databasen.

Databasen sträcks till en tröskelpunkt genom att lägga till en stor mängd data till den och sedan testas systemet för sitt svar.

Detta var teoridelen, låt mig förklara dig med några praktiska exempel som hjälper dig att förstå 'när' del av volymtestning.

När är detta tvingande viktigt?

Helst bör varje programvara eller app testas för datavolym men i vissa fall där data inte kommer att vara tunga, tenderar vi att undvika denna testning. Men i vissa fall där data hanteras i MB eller GB dagligen, bör definitivt volymtest utföras.

Nedan följer några exempel på min egen erfarenhet av åtta år som förklarar 'när' -delen:

Exempel 1:

En av mina satsningar var ett stort system som bestod av både webbapp och mobilapp. Men själva webbappen hade tre moduler hanterade av 3 olika team.

Ibland, även hos oss, brukade databasen bli långsam när vi alla 'tillsammans' lade till data för våra tester. Det var irriterande och arbetet brukade hämmas på grund av den enorma datamängden och för att underlätta arbetet var vi tvungna att städa DB ganska ofta.

Uppgifterna som 'live' -systemet hanterade var runt ett GB. Därför testades webbappen mycket ofta med avseende på datamängden jämfört med mobilappen. Webbappens QA-team hade sina egna automatiseringsskript som skulle köras på natten och utföra denna testning.

Exempel 2:

Ett annat exempel på mitt företag var ett ekosystem som inte bara hade en webbapp utan också en SharePoint-app och till och med en installatör. Alla dessa system kommunicerade till samma databas för dataöverföring. Uppgifterna som hanterades av systemet var också väldigt stora och om DB av någon anledning blir långsam skulle även installationsprogrammet sluta fungera.

Följaktligen utfördes volymtest regelbundet och DB-prestanda observerades minutiöst för eventuella problem.

Liknande, vi kan taExempelav få appar som vi använder dagligen för shopping, bokning av biljetter, finansiella transaktioner etc som hanterar tunga datatransaktioner och därmed behöver ett volymtest.

På den andra sidan kan det hända att en perfekt volymtest inte alltid kan uppnås eftersom den har sina egna begränsningar och utmaningar.

Få av dess begränsningar och utmaningar inkluderar:

• Det är svårt att skapa den exakta fragmenteringen av minnet.
• Generering av dynamisk nyckel är knepig.
• Att skapa en idealisk verklig miljö, dvs repliken av live-servern kan vara svårt.
• Automationsverktyg, nätverk etc. påverkar också testresultaten.

Nu har vi förstått det när vi måste göra denna typ av testning. Låt oss också förstå 'Varför' vi bör göra denna testning som i, målet eller syftet med att utföra denna testning.

Varför ska jag sikta på volymtestning?

Volymtestning kan hjälpa dig att förstå hur passande ditt system är för den verkliga världen och det hjälper också till att spara dina pengar som senare kommer att spenderas på underhåll.

Följande är några möjliga skäl för att utföra denna testning:

• Det mest grundläggande behovet är att analysera systemets prestanda mot ökad data. Att skapa en enorm datamängd hjälper dig att förstå systemets prestanda när det gäller svarstid, dataförlust etc.
• Identifiera de problem som kommer att uppstå med enorma data och tröskelvärdet.
• Utöver hållbarhetsgränsen eller tröskelvärdet blir systembeteendet, dvs om DB-kraschen inte svarar eller tar slut.
• Implementera lösningar för DB-överbelastning och till och med verifiera dem.
• Ta reda på den extrema punkten i din DB (som inte kan fixas) utöver vilken systemet kommer att misslyckas och därför måste försiktighetsåtgärder vidtas.
• Vid fler än en DB-server, ta reda på problemen med DB-kommunikation, dvs den som är mest benägna att misslyckas med dem etc.

Nu vet vi vikten och anledningen till att utföra denna testning.

ELLER ne erfarenhet som jag vill dela här är att när det gäller mobilappar kanske volymtestning inte behövs eftersom bara en person använder appen åt gången och mobilappar är utformade för att vara enkla .

Så om du inte har en mycket komplex app med mycket datainvolvering kan volymtest hoppas över.

När du väl vet vad som måste verifieras för ditt system eller din app är nästa sak att göra en checklista för din app att definiera 'Vad' måste testas.

Vad är min checklista för denna testning?

Innan vi går in på några exempel för att skapa en checklista för din app eller ett system, låt oss först förstå några tips som vi måste tänka på när vi skapar en checklista för volymtestning eller metoden innan vi startar testningen.

Poäng att komma ihåg:

• Håll utvecklarna i ögonen om din testplan eftersom de vet mycket om systemet och kan ge dig ingångar och till och med flaskhalsar.
• Förstå den fysiska aspekten som i serverkonfigurationer, RAM, processor osv innan du testar strategin.
• Förstå komplexiteten i DB, procedurer, DB-skript etc. i möjlig utsträckning så att du kan beskriva systemets komplexitet överlag.
• Förbered informatik, dvs grafer, datablad etc., om möjligt för den normala datamängden och hur bra systemet är, kommer detta att hjälpa dig att se till att prestandan är bra för normal datalast innan du stressar DB. Detta hjälper dig också att se till att det inte finns några problem som kräver en fix för ditt volymtest innan du går vidare till den stressande delen.

Nedan följer några exempel som du kan lägga till eller använda i din checklista:

• Kontrollera om datalagringsmetoderna är korrekta.
• Kontrollera om systemet har nödvändiga minnesresurser eller inte.
• Kontrollera om det finns någon risk för datavolym som är större än en viss gräns.
• Kontrollera och observera systemets svar på datavolymen.
• Kontrollera om data går vilse under volymtestningen.
• Kontrollera att om data skrivs över görs det med tidigare information.
• Identifiera områdena som sträcker sig utanför det normala intervallet som många attribut (sökbara), stort nej. av uppslagstabeller, många platsmappningar etc.
• Som tidigare nämnts skapar du först en baslinje genom att få resultat för normal volym och sedan gå vidare med stress.

Innan vi går vidare till de andra exemplen, testfall och verktyg, låt oss först förstå hur denna testning skiljer sig från belastningstestning.

Volymtestning mot belastningstestning

Nedan följer några av de främsta skillnaderna mellan volym- och belastningstest:

Hur utför jag denna testning?

Denna testning kan göras både manuellt eller med valfritt verktyg. I allmänhet sparar vi tid och ansträngningar med hjälp av verktyg, men i fall av volymtest, enligt min erfarenhet med hjälp av verktyg kan du få mer exakta resultat jämfört med manuell testning.

Innan du utför ditt testfall, se till att:

• Teamet har godkänt testplanen för denna testning.
• Andra team i ditt projekt är väl informerade om databasändringarna och dess inverkan på deras arbete.
• Testbäddarna är inställda för de angivna konfigurationerna.
• Baslinjen för testning förbereds.
• De specifika datavolymerna för testning (dataskript eller procedurer etc) är klara. Du kan läsa om verktyg för att skapa data på vår datagenereringssida.

Låt oss se några exempel på testfall som du kan använda vid utförande:

Verifiera detta för alla valda datavolymer för volymtest:

1. Kontrollera om att lägga till data kan göras framgångsrikt och om det återspeglas i appen eller webbplatsen.
2. Kontrollera om det går att radera data och om det återspeglas i appen eller webbplatsen.
3. Kontrollera om uppdatering av data kan göras framgångsrikt och om det återspeglas i appen eller webbplatsen.
4. Verifiera att det inte finns någon dataförlust och all information visas som förväntat i appen eller webbplatsen.
5. Kontrollera att appen eller webbsidorna inte tar slut på grund av hög datavolym.
6. Kontrollera att kraschfel inte visas på grund av hög datavolym.
7. Kontrollera att data inte skrivs över och korrekta varningar visas.
8. Kontrollera att andra moduler på din webbplats eller app inte kraschar eller tar slut med hög datavolym.
9. Kontrollera att svarstiden för DB ligger inom det acceptabla intervallet.

Volymtestverktyg

Som tidigare diskuterats sparar automatiseringstest tid och ger till och med korrekta resultat jämfört med manuell testning. En annan fördel med att använda verktyg för volymtestning är att vi kan köra testerna på natten och på så sätt påverkas inte de andra lagens eller gruppmedlemmarnas arbete av databandets volym.

Vi kan schemalägga testerna på morgonen och resultaten blir klara.

Nedan följer en lista över få volymtestverktyg med öppen källkod:

# 1) DbFit:

Detta är ett verktyg med öppen källkod som stöder testdriven utveckling.

DbFit testramverk skrivs ovanpå Fitness, testen skrivs med hjälp av tabeller och kan köras med valfritt Java IDE- eller CI-verktyg.

# 2) HammerDb:

HammerDb är också ett öppen källkodsverktyg som kan vara automatiserat, flertrådat och till och med möjliggör körtidsskript. Det kan fungera med SQL, Oracle, MYSQL etc.

# 3) JdbcSlim:

JdbcSlim kommandon kan enkelt integreras i Slim Fitness och den stöder alla databaser som har en JDBC-drivrutin. Fokus ligger på att hålla konfigurationen, testdata och SQL-frågor separat.

# 4) NoSQLMap:

Detta är ett Python-verktyg med öppen källkod som är utformat för att automatiskt injicera attacker och störa DB-konfigurationerna för att analysera hotet. Det fungerar bara för MongoDB.

# 5) Ruby-PLSQL-spec:

PLSQL kan enhetstestas med Ruby eftersom Oracle finns som ett öppen källkodsverktyg. Detta använder i princip två bibliotek: Ruby-PLSQL och Rspec.

Slutsats

Volymtestning är icke-funktionell testning som görs för att analysera databasens prestanda. Det kan göras manuellt såväl som med hjälp av vissa verktyg.

Om du är en kvalitetsbedömare som är ny i denna testning föreslår jag att du spelar med verktyget eller utför några testfall först. Detta hjälper dig att förstå begreppet volymtest innan du hoppar in i testningen.

vilket är inte ett exempel på datautvinning?

Denna testning är ganska knepig och har sina egna utmaningar, därför är det mycket viktigt att ha en grundlig kunskap om konceptet, skapandet av testbädden och DB-språket innan du utför det.

Hoppas att denna handledning skulle ha ökat din kunskapsvolym om detta ämne :)

Rekommenderad läsning

• Bästa verktyg för testning av programvara 2021 (QA Test Automation Tools)
• Parvis testning eller testning i alla par med hjälp av verktyg och exempel
• Funktionell testning mot icke-funktionell testning
• Konfigurationstesthandledning med exempel
• Testing Primer eBook Download
• Handledning för destruktiv testning och icke-destruktiv testning
• 11 bästa automatiseringsverktyg för testning av Android-applikationer (Android-apptestverktyg)
• Bästa IVR-testverktyg: CYARA och HAMMER-testhandledning