I det här avsnittet kommer vi att lära oss om prestandatester, varför vi behöver det, typer av prestandatester och prestandatestningsprocessen.
Följande är ämnen som vi kommer att förstå i det här avsnittet:
Vad är prestandatestning?
Det är den viktigaste delen av icke-funktionell testning.
Att kontrollera beteendet hos en applikation genom att applicera en viss belastning kallas prestandatestning.
I allmänhet definierar denna testning hur snabbt servern svarar på användarens begäran.
När vi gör prestandatestning av applikationen kommer vi att koncentrera oss på de olika faktorerna som Svarstid, belastning och stabilitet av ansökan.
Respons tid: Svarstid är den tid det tar för servern att svara på klientens begäran.
Ladda: Här betyder Load att när N-nummer användare som använder applikationen samtidigt eller skickar begäran till servern åt gången.
Stabilitet: För stabilitetsfaktorn kan vi säga att när N-antal användare använder applikationen samtidigt under en viss tid.
När använder vi prestandatester?
Vi kommer att göra prestandatester när programvaran är stabil och flyttad till produktionen, och den kan nås av flera användare samtidigt, på grund av detta kan vissa prestandaproblem uppstå. För att undvika dessa prestandaproblem utför testaren en omgång prestandatester.
Eftersom det är icke-funktionell testning vilket inte betyder att vi alltid använder prestandatestning, går vi bara till prestandatest när applikationen är funktionellt stabil.
Obs: Prestandatestning kan inte göras manuellt eftersom dess kostsamma och exakta resultat inte kan upprätthållas.
Typer av prestandatester
Följande är typerna av prestandatester:
java tolka sträng till int
Låt oss diskutera en efter en för att ge dig en fullständig förståelse för Belastning, stress, skalbarhet, och Stabilitet prestandatester.
Belastningstestning
Belastningstestningen används för att kontrollera en applikations prestanda genom att applicera en belastning som antingen är mindre än eller lika med den önskade belastningen kallas belastningstestning.
Till exempel: På bilden nedan, 1000 användare är de önskad belastning , som ges av kunden, och 3/sekund är mål vilket vi vill uppnå när vi utför en lasttestning.
Stresstestning
Stresstestningen är testning, som kontrollerar beteendet hos en applikation genom att applicera en belastning som är större än den önskade belastningen.
Till exempel: Om vi tog exemplet ovan och ökade den önskade belastningen 1000 till 1100 användare, och målet är 4/sekund. När stresstestningen utförs i detta scenario kommer den att passera eftersom belastningen är större (100 upp) än den faktiska önskade belastningen.
Skalbarhetstestning
Att kontrollera prestandan för en applikation genom att öka eller minska belastningen på vissa vågar (ingen användare) kallas skalbarhetstestning . Skalbarhetstestning uppåt och nedåt kallas skalbarhetstestning.
Skalbarhetstestning är uppdelad i två delar som är följande:
Skalbarhetstestning uppåt
Det testar var vi öka antalet användare i en viss skala tills vi får en kraschpunkt. Vi kommer att använda skalbarhetstestning uppåt för att hitta den maximala kapaciteten för en applikation.
Skalbarhetstestning nedåt
Skalbarhetstestet nedåt används när belastningstestet inte är godkänt, starta sedan minskar antalet. användare i ett visst intervall tills målet är uppnått. Så att det är lätt att identifiera flaskhalsen (bugg).
Stabilitetstestning
Kontrollera prestandan för en applikation genom applicering av belastningen under en viss tidsperiod är känd som Stabilitetstestning .
Exempel på prestandatestning
Låt oss ta ett exempel där vi ska testa beteendet för en applikation där den önskade belastningen antingen är mindre än 1000 eller lika med 1000 användare .
På bilden nedan kan vi se att 100 upp användare ökas kontinuerligt för att kontrollera maximal belastning , som också kallas skalbarhetstestning uppåt .
1200 → 3,5sek: [det är inte mindre än eller lika med den önskade belastningen, det är därför det kommer Misslyckas ]
1300 → 4sek: [den är inte mindre än eller lika med den önskade belastningen. dvs. Misslyckas ]
1400 → Kraschade
Note1: Volym- och blötläggningstestning är en typ av testning men inte prestandatestning.
Volymtestning
Volymtestning är testning, vilket hjälper oss att kontrollera beteendet hos en applikation genom att infoga en massiv volym av belastningen i termer av data kallas volymtestning, och här kommer vi att koncentrera oss på antalet datahastigheter än antalet användare .
Anteckning 2:
Volym är en kapacitet medan belastning är en kvantitet, dvs. lasttestning betyder nej. antal användare, och volymtestning betyder mängd data.
Blötläggningstestning
I denna typ av testning kommer vi att kontrollera beteendet hos en applikation på miljön, som inte stöder under lång tid kallas blötläggningstestning.
I allmänhet är soak-testning en negativ typ av testning eftersom vi redan vet att servern eller miljön inte stödjer.
Prestandatestprocess
Prestandatestningen kan inte göras manuellt eftersom:
- Vi behöver mycket resurser och det blev ett dyrare tillvägagångssätt.
- Och noggrannheten kan inte bibehållas när vi spårar svarstiden manuellt.
Prestandatestningsprocessen kommer att slutföras i följande steg:
konvertera sträng till char
- Identifiera prestationsscenarier
- Planera och designa prestandatestskript
- Konfigurera testmiljön och fördela belastningen
- Utför testskript
- Resultat
- Analysresultat
- Identifiera flaskhalsen
- Kör testet igen
Om vi utför a positivt flöde av prestandatestningsprocessen kan den följa följande process:
Identifiera prestationsscenarier
Först kommer vi att identifiera prestationsscenarierna baserat på följande faktorer:
De vanligaste scenarierna: Det betyder att vi kan hitta prestationsscenarierna baserat på scenarierna, som vanligtvis används som i Gmail-applikation; vi kommer att uppträda logga in, inkorg, skicka objekt och skriv ett mail och logga ut .
De mest kritiska scenarierna: Kritiska scenarier innebär regelbundet använda och viktiga för den affärsmässiga i Gmail-applikationen logga in, skriv, inkorga och logga ut .
Enorma datatransaktioner: Om vi har enorma data betyder det att n-antal användare använder applikationen samtidigt.
När vi har identifierat prestationsscenarierna går vi vidare till nästa steg.
Planera och designa prestandatestskript
I det här steget kommer vi att installera verktygen i Test Engineer Machine och komma åt testservern och sedan skriver vi något skript enligt testscenarierna och kör verktyget.
När vi är klara med att skriva manuset går vi till nästa steg.
Konfigurera testmiljön och fördela belastningen
Efter att ha skrivit testskripten kommer vi att ordna testmiljön innan utförandet. Hantera även verktygen, andra resurser och fördela belastningen enligt 'Användningsmönster' eller nämn varaktigheten och stabiliteten.
Utför testskript
När vi är klara med att distribuera belastningen kommer vi att exekvera, validera och övervaka testskripten.
Resultat
Efter att ha kört testskripten får vi testresultatet. Och kontrollera att resultatet når målet inom den givna svarstiden eller inte, och att svarstiden kan vara maximal, genomsnittlig och minimum.
Om svaret inte motsvarar den tid som krävs, kommer vi att gå för negativt flöde var kommer att utföra följande steg:
Analysresultat
Först kommer vi att analysera testresultatet om det överensstämmer med svarstiden eller inte.
Identifiera flaskhalsen
Efter det kommer vi att identifiera flaskhals (bugg eller prestandaproblem ). Och flaskhalsen kan uppstå på grund av dessa aspekter som problem med kod, hårdvaruproblem (hårddisk, RAM-processor), nätverksproblem, och den mjukvaruproblem (operativsystem) . Och efter att ha hittat flaskhalsen kommer vi att prestera inställning (fix eller justering) för att lösa denna flaskhals.
Kör testet igen
När vi har åtgärdat flaskhalsarna, kör testskripten igen och kontrollerar resultatet om det uppfyller det önskade målet eller inte.
undantag kasta java
Problemet uppstår vid prestandatestning
När du utför prestandatestning av applikationen kan vissa problem uppstå, och dessa problem kallas också prestationsproblem .
Prestandaproblemen är följande:
Svarstidsfråga
Svarstiden betyder hur snabbt servern svarar på kundens begäran. Om användarens begäran inte slutförs inom den angivna svarstiden, kan det ha varit möjligt att användaren förlorar sitt intresse för den specifika programvaran eller applikationen. Det är därför applikationen eller programvaran bör ha en perfekt svarstid för att snabbt svara på användarens begäran.
Skalbarhetsproblem
Skalbarhetsproblemen uppstår när applikationen inte kan ta n-antal användare och förväntade användarförfrågningar samtidigt. Det är därför vi kommer att göra skalbarhetstestning uppåt (kontrollera applikationens maximala kapacitet) och skalbarhetstestning nedåt (när förväntad tid inte matchas med den faktiska tiden).
Flaskhals
Flaskhalsen är det informella namnet på buggen, som uppstår när applikationen begränsas av en enda komponent och skapar en dålig inverkan på systemets prestanda.
De främsta orsakerna till flaskhalsar är mjukvaruproblem (problem relaterat till operativsystemet), hårdvaruproblem (problem relaterade till hårddisken, RAM-minnet och processorn), och kodningsproblem, etc.
Följande är de vanligaste prestandaflaskhalsarna:
- Minnesanvändning
- Diskanvändning
- CPU-användning
- Operativsystems begränsningar
- Nätverksanvändning
Hastighetsproblem
När vi utför prestandatester på applikationen bör applikationen vara snabbare i hastighet för att få användarens intresse och uppmärksamhet eftersom om applikationens hastighet är långsam kan den tappa användarens intresse för applikationen.
Verktyg för prestandatest
Vi har olika typer av prestandatestverktyg tillgängliga på marknaden, där några är kommersiella verktyg och open source-verktyg.
Kommersiella verktyg: LoadRunner[HP], WebLOAD, NeoLoad
Verktyg med öppen källkod: JMeter
LoadRunner
Det är ett av de mest kraftfulla verktygen för prestandatestning, som används för att stödja prestandatestning för det omfattande utbudet av protokoll, antal tekniker och applikationsmiljöer.
Den identifierar snabbt de vanligaste orsakerna till prestandaproblem. Och även exakt förutsäga applikationens skalbarhet och kapacitet.
JMeter
Apache JMeter-mjukvaran är ett verktyg med öppen källkod, som helt och hållet är en Java-applikation designad för att ladda det funktionella testbeteendet och mäta prestandan.
I allmänhet var det designat för att testa webbapplikationerna men nu utökat till andra testfunktioner också.
Apache JMeter används för att testa prestanda för både statiska och dynamiska resurser och dynamiska webbapplikationer.
Den kan användas för att reproducera den tunga belastningen på en server, nätverk eller objekt, grupp av servrar för att testa dess styrka eller för att analysera övergripande prestanda under olika belastningstyper.
WebLOAD
WebLOAD-testverktyg som används för att testa belastningstestning, prestandatestning och stresstestwebbapplikationer.
WebLOAD-verktyget kombinerar prestanda, skalbarhet och integritet som en enda process för verifiering av webb- och mobilapplikationer.
int parseint
NeoLoad
Neotys utvecklar ett testverktyg som kallas NeoLoad. NeoLoad används för att testa scenarierna för prestandatest. Med hjälp av NeoLoad kan vi hitta flaskhalsområdena i webben och utvecklingsprocessen för mobilappar.
NeoLoad-testverktyget är snabbare jämfört med traditionella verktyg.
Förutom dem finns det några andra verktyg Elektrisk last, webbstressverktyg, LoadUI Pro, StresStimulus, LoadView, LoadNinja och RedLine13, som hjälper till att testa programvarans eller en applikations prestanda.