Volumtestopplæring: Eksempler og volumtestverktøy

volume testing tutorial

Oversikt over volumtesting:

Korrelerer bildet nedenfor med appene våre på en eller annen måte? Ja, dette er hva som skjer når vi overbelaster serverne våre, databaser, webtjenester osv.

Alle av oss må være klar over funksjonell og ikke-funksjonell testing, men er du oppmerksom på det faktum at ikke-funksjonell testing er like viktig som funksjonell testing? Noen ganger i kortvarige utgivelser, har vi en tendens til å ignorere denne ikke-funksjonelle testen som ideelt sett ikke burde.

Det skal ikke ha noe for oss om eieren av produktet har gitt dette kravet eller ikke. Vi bør vurdere denne testingen som en del av vår komplette testprosess selv for små utgivelser.

Denne veiledningen om volumtesting gir deg en fullstendig oversikt over dens betydning, behov, betydning, sjekkliste og noen av verktøyene for å gjøre det mulig for deg å forstå det på en bedre måte.

Hva du vil lære:

• Hva er volumtesting?
• Når er denne testen viktig?
• Hvorfor skal jeg sikte på volumtesting?
• Hva er sjekklisten min for denne testen?
• Volumtesting mot belastningstesting
• Hvordan utføre denne testen?
• Volumtestverktøy
• Konklusjon
• Anbefalt lesing

Hva er volumtesting?

Volumtesting er en type ikke-funksjonell testing. Denne testingen er gjort for å kontrollere datavolumet som håndteres av databasen. Volumtesting, også kalt flomtesting, er ikke-funksjonell testing som gjøres for å sjekke programvaren eller appen for ytelse mot enorme data i databasen.

Databasen strekkes til et terskelpunkt ved å legge til en stor mengde data i den, og deretter blir systemet testet for respons.

Dette var teoridelen, la meg forklare deg med noen få praktiske eksempler for å hjelpe deg med å forstå 'når' del av volumtesting.

Når er denne testen viktig?

Ideelt sett bør hver programvare eller app testes for datavolum, men i noen tilfeller der dataene ikke vil være tunge, har vi en tendens til å unngå denne testen. Men i noen tilfeller der data blir behandlet i MB eller GB på daglig basis, bør absolutt volumtest utføres.

Følgende er noen eksempler på min egen erfaring fra 8 år som forklarer 'når' delen:

Eksempel 1:

En av mine satsinger var et stort system som besto av både webapp og mobilapp. Men selve webappen hadde 3 moduler håndtert av 3 forskjellige team.

Noen ganger, selv hos oss, pleide databasen å bli langsom når vi alle 'sammen' la til data for testingen. Det var irriterende, og arbeidet pleide å bli hindret på grunn av det enorme datamengden og for å lette arbeidet vi måtte rydde opp i DB ganske ofte.

Dataene som 'live' -systemet håndterte var rundt GB, og derfor ble webappen veldig ofte testet for datamengden sammenlignet med mobilappen. Nettapp-QA-teamene hadde sine egne automatiseringsskript som skulle kjøre om natten og utføre denne testen.

Eksempel 2:

Et annet eksempel på satsingen min var et økosystem som ikke bare hadde en webapp, men også en SharePoint-app og til og med en installatør. Alle disse systemene kommuniserte til samme database for dataoverføring. Dataene som ble håndtert av systemet var også veldig store, og hvis DB av en eller annen grunn blir treg, ville også installatøren slutte å jobbe.

Derfor ble volumtest utført regelmessig, og DB-ytelsen ble observert nøyaktig for eventuelle problemer.

På samme måte, vi kan taEksemplerav få apper som vi bruker til daglig for shopping, booking av billetter, økonomiske transaksjoner osv. som håndterer tunge datatransaksjoner og derfor trenger en volumtest.

På baksiden kan det hende at en ideell volumtesting ikke alltid kan oppnås, da den har sine egne begrensninger og utfordringer.

Få av begrensningene og utfordringene inkluderer:

• Det er vanskelig å skape den eksakte fragmenteringen av minnet.
• Dynamisk nøkkelgenerering er vanskelig.
• Å skape et ideelt ekte miljø, det vil si at replikken til den live serveren kan være vanskelig.
• Automatiseringsverktøy, nettverk osv. Påvirker også testresultatene.

Nå har vi forstått det når vi trenger å gjøre denne typen testing. La oss også forstå 'Hvorfor' vi bør gjøre denne testingen som i, målet eller målet med å utføre denne testingen.

Hvorfor skal jeg sikte på volumtesting?

Volumtesting kan hjelpe deg med å forstå hvor passende systemet ditt er for den virkelige verden, og det hjelper også å spare penger som senere blir brukt på til vedlikeholdsformål.

Følgende er noen mulige årsaker til å utføre denne testen:

• Det mest grunnleggende behovet er å analysere systemets ytelse mot økte data. Å lage et stort datamengde vil hjelpe deg å forstå ytelsen til systemet ditt når det gjelder responstid, tap av data, etc.
• Identifiser problemene som vil oppstå med enorme data og terskelpunktet.
• Utover det bærekraftige eller terskelpunktet, blir systematferden, dvs. hvis DB krasjer, ikke svarer eller tidsavbrudd.
• Implementere løsninger for DB overbelastning og til og med verifisere dem.
• Finne det ekstreme punktet i DB-en din (som ikke kan løses) utover som systemet vil mislykkes, og det må derfor tas forholdsregler.
• Ved mer enn én DB-server, å finne ut av problemene med DB-kommunikasjon, dvs. den som er mest utsatt for feil ut av dem, etc.

Nå vet vi viktigheten og årsaken til å utføre denne testen.

ELLER ne erfaring som jeg vil dele her er at når det gjelder mobilapper, kan det hende at volumtesting ikke er nødvendig fordi bare en person bruker appen om gangen, og mobilapper er designet for å være enkle .

Så med mindre du har en veldig kompleks app med mye datainnblanding, kan volumtesting hoppes over.

Når du vet hva som må verifiseres for systemet eller appen din, er den neste tingen å gjøre å lage en sjekkliste som appen din kan definere 'hva' må testes.

Hva er sjekklisten min for denne testen?

Før vi går inn i noen eksempler for å lage en sjekkliste for appen din eller et system, la oss først forstå noen tips som vi må huske på mens vi lager en sjekkliste for volumtesting eller tilnærmingen før vi starter testingen.

Poeng å huske:

• Hold utviklerne løpende om testplanen din fordi de vet mye om systemet og kan gi deg innspill og til og med flaskehalser.
• Forstå det fysiske aspektet som i serverkonfigurasjonene, RAM, prosessor osv. Godt før du strategiserer testingen.
• Forstå kompleksiteten i DB, prosedyrer, DB-skript osv. I den grad det er mulig, slik at du kan skissere systemets kompleksitet i det hele tatt.
• Forbered informatikk, dvs. grafer, datablad osv., Hvis mulig for det normale datavolumet og hvor godt systemet er, vil dette hjelpe deg med å sørge for at ytelsen er god for normal datalast før du stresser DB. Dette vil også hjelpe deg med å sikre før du går videre til den stressende delen, at det ikke er noen problemer som krever en løsning for volumtesten.

Følgende er noen eksempler som du kan legge til eller bruke i sjekklisten din:

• Kontroller om datalagringsmetodene er riktige.
• Sjekk om systemet har de nødvendige minnesressursene eller ikke.
• Sjekk om det er noen risiko for datavolum som er større enn en spesifisert grense.
• Sjekk og observer systemets respons på datavolumet.
• Sjekk om dataene går tapt under volumtesting.
• Sjekk at hvis data blir overskrevet, gjøres det med forhåndsinformasjon.
• Identifiser områdene som strekker seg utenfor normalområdet som mange attributter (søkbare), stort nei. av oppslagstabeller, mange plasseringskartlegginger osv.
• Som nevnt tidligere, opprett en grunnlinje først ved å få resultater for det normale volumet, og fortsett deretter med stress.

Før vi går videre til de andre eksemplene, testtilfellene og verktøyene, la oss først forstå hvordan denne testen skiller seg fra belastningstesting.

Volumtesting mot belastningstesting

Nedenfor er noen av de viktigste forskjellene mellom volum- og lasttesting:

Hvordan utføre denne testen?

Denne testingen kan gjøres både manuelt eller ved hjelp av hvilket som helst verktøy. Generelt vil bruk av verktøy spare tid og krefter, men i tilfelle volumtest, i henhold til min erfaring ved hjelp av verktøy kan du gi mer nøyaktige resultater sammenlignet med manuell testing.

Før du starter testutførelsen, må du forsikre deg om at:

• Teamet har godtatt testplanen for denne testingen.
• Andre team i prosjektet ditt er godt informert om databaseendringene og dens innvirkning på arbeidet deres.
• Testsengene er angitt for de spesifiserte konfigurasjonene.
• Basislinjen for testing er utarbeidet.
• De spesifikke datavolumene for testing (dataskripter eller prosedyrer osv.) Er klare. Du kan lese om dataopprettingsverktøy på siden for generering av data.

La oss se noen eksempler på testtilfeller som du kan bruke til utførelse:

Bekreft dette for alle de valgte datavolumene for volumtesting:

1. Bekreft om du kan legge til data, og om det gjenspeiles i appen eller nettstedet.
2. Bekreft om sletting av data kan gjøres og om det gjenspeiles i appen eller nettstedet.
3. Bekreft om oppdatering av data kan gjøres, og om det gjenspeiles i appen eller nettstedet.
4. Bekreft at det ikke er tap av data, og at all informasjon vises som forventet i appen eller nettstedet.
5. Bekreft at appen eller nettsidene ikke går ut på grunn av høyt datavolum.
6. Kontroller at krasjfeil ikke vises på grunn av høyt datavolum.
7. Kontroller at dataene ikke blir overskrevet, og at riktige advarsler vises.
8. Bekreft at andre moduler på nettstedet ditt eller appen din ikke krasjer eller tidsavbrutt med høyt datavolum.
9. Kontroller at responstiden til DB er innenfor akseptabelt område.

Volumtestverktøy

Som diskutert tidligere sparer automatiseringstesting tid og gir til og med nøyaktige resultater sammenlignet med manuell testing. En annen fordel ved å bruke verktøy for volumtesting er at vi kan kjøre testene om natten, og at arbeidet til de andre lagene eller teammedlemmene ikke vil bli påvirket av DB-datavolumet.

Vi kan planlegge testene om morgenen, og resultatene vil være klare.

Følgende er en liste over få volumtestverktøy med åpen kildekode:

# 1) DbFit:

Dette er et åpen kildekodeverktøy som støtter testdrevet utvikling.

DbFit testrammeverket er skrevet på toppen av Fitness, testene er skrevet ved hjelp av tabeller og kan utføres ved hjelp av hvilket som helst Java IDE- eller CI-verktøy.

# 2) HammerDb:

HammerDb er også et åpen kildekodeverktøy som kan automatiseres, flertrådes og til og med tillater runtime-skripting. Det kan fungere med SQL, Oracle, MYSQL etc.

# 3) JdbcSlim:

JdbcSlim kommandoer kan enkelt integreres i Slim Fitness, og den støtter alle databasene som har en JDBC-driver. Fokuset er å holde konfigurasjonen, testdata og SQL-spørsmål separat.

# 4) NoSQLMap:

Dette er et åpen kildekode-Python-verktøy som er designet for automatisk å injisere angrep og forstyrre DB-konfigurasjonene for å analysere trusselen. Det fungerer bare for MongoDB.

# 5) Ruby-PLSQL-spesifikasjon:

PLSQL kan enhetstestes ved hjelp av Ruby, da Oracle er tilgjengelig som et åpen kildekodeverktøy. Dette bruker i utgangspunktet to biblioteker: Ruby-PLSQL og Rspec.

Konklusjon

Volumtesting er ikke-funksjonell testing som gjøres for å analysere ytelsen til databasen. Det kan gjøres manuelt så vel som ved hjelp av noen verktøy.

Hvis du er en kvalitetssikring som er ny i denne testen, vil jeg foreslå at du leker med verktøyet eller utfører noen testsaker først. Dette vil hjelpe deg å forstå konseptet med volumtesting før du hopper ut i testing.

stemmeskiftere som jobber med uenighet

Denne testingen er ganske vanskelig, og den har sine egne utfordringer, og det er derfor veldig viktig å ha grundig kunnskap om konseptet, oppretting av testbed og DB-språket før du utfører det.

Håper denne opplæringen ville ha økt kunnskapsvolumet ditt om dette emnet :)

Anbefalt lesing

• Beste verktøy for testing av programvare 2021 (QA Test Automation Tools)
• Pairwise Testing eller All-Pair Testing Tutorial med verktøy og eksempler
• Funksjonstesting mot ikke-funksjonell testing
• Konfigurasjonstestveiledning med eksempler
• Testing Primer eBook Download
• Destruktiv testing og ikke-destruktiv testing
• 11 beste automatiseringsverktøy for testing av Android-applikasjoner (Android-app-testverktøy)
• Beste IVR testverktøy: CYARA og HAMMER testopplæring