I dette afsnit lærer vi om præstationstest, hvorfor vi har brug for det, typer af præstationstest og præstationstestprocessen.
Følgende er de emner, som vi vil forstå i dette afsnit:
Hvad er præstationstest?
Det er den vigtigste del af ikke-funktionel test.
Kontrol af en applikations adfærd ved at påføre en vis belastning er kendt som præstationstest.
Generelt definerer denne test, hvor hurtigt serveren reagerer på brugerens anmodning.
Mens vi laver præstationstest på applikationen, vil vi koncentrere os om de forskellige faktorer som f.eks Responstid, belastning og stabilitet af ansøgningen.
Responstid: Svartid er den tid, det tager serveren at svare på klientens anmodning.
Belastning: Her betyder Load, at når N-tal af brugere, der bruger applikationen samtidigt eller sender anmodningen til serveren ad gangen.
Stabilitet: For stabilitetsfaktoren kan vi sige, at når N-antal brugere bruger applikationen samtidigt i et bestemt tidsrum.
Hvornår bruger vi præstationstest?
Vi vil udføre ydelsestest, når softwaren er stabil og flyttet til produktionen, og den kan tilgås af flere brugere samtidigt, af denne grund kan der opstå nogle ydelsesproblemer. For at undgå disse præstationsproblemer udfører testeren én runde præstationstest.
Da det er ikke-funktionel test, hvilket ikke betyder, at vi altid bruger performance test, går vi kun til performance test, når applikationen er funktionelt stabil.
Bemærk: Ydelsestest kan ikke udføres manuelt, da dets dyre og nøjagtige resultat ikke kan opretholdes.
Typer af præstationstest
Følgende er typerne af præstationstest:
java mvc
Lad os diskutere en efter en for at give dig en fuldstændig forståelse af Belastning, stress, skalerbarhed, og Stabilitet præstationstest.
Belastningstest
Belastningstestningen bruges til at kontrollere en applikations ydeevne ved at påføre en belastning, der enten er mindre end eller lig med den ønskede belastning, kaldes belastningstest.
For eksempel: På billedet nedenfor, 1000 brugere er ønsket belastning , som er givet af kunden, og 3/sekund er mål som vi ønsker at opnå, mens vi udfører en belastningstest.
Stresstest
Stresstesten er test, som kontrollerer en applikations opførsel ved at påføre belastning større end den ønskede belastning.
For eksempel: Hvis vi tog ovenstående eksempel og øgede den ønskede belastning 1000 til 1100 brugere, og målet er 4/sekund. Mens stresstesten udføres i dette scenarie, vil den bestå, fordi belastningen er større (100 op) end den faktiske ønskede belastning.
Skalerbarhedstest
Kontrol af en applikations ydeevne ved at øge eller mindske belastningen på bestemte vægte (ingen bruger) er kendt som skalerbarhedstest . Opadgående skalerbarhed og nedadgående skalerbarhedstest kaldes skalerbarhedstest.
Skalerbarhedstest er opdelt i to dele, som er som følger:
Opadgående skalerbarhedstest
Det tester, hvor vi øge antallet af brugere på en bestemt skala indtil vi får et crash point. Vi vil bruge opadgående skalerbarhedstest til at finde den maksimale kapacitet af en applikation.
Nedadgående skalerbarhedstest
Den nedadgående skalerbarhedstest bruges, når belastningstesten ikke er bestået, og start derefter sænkning af nej. af brugere i et bestemt interval indtil målet er nået. Så det er nemt at identificere flaskehalsen (fejlen).
Stabilitetstest
Kontrol af en applikations ydeevne ved påføring af belastningen i et bestemt tidsrum er kendt som Stabilitetstest .
Eksempel på præstationstest
Lad os tage et eksempel, hvor vi vil test adfærden af en applikation, hvor den ønskede belastning enten er mindre end 1000 eller lig med 1000 brugere .
På billedet nedenfor kan vi se, at 100 op brugere øges løbende for at kontrollere maksimal belastning , som også kaldes opadgående skalerbarhedstest .
hvordan man viser en applikation på Android
1200 → 3,5sek.: [det er ikke mindre end eller lig med den ønskede belastning, det er derfor, det vil Svigte ]
1300 → 4sek: [den er ikke mindre end eller lig med den ønskede belastning. dvs. Svigte ]
1400 → Nedstyrtet
Note1: Volumen- og iblødsætningstest er en type test, men ikke præstationstest.
Volumen test
Volumentest er test, som hjælper os med at kontrollere opførselen af en applikation ved at indsætte en massiv mængde af belastningen i form af data er kendt som volumentest, og her vil vi koncentrere os om antallet af datahastigheder end antallet af brugere .
Bemærk 2:
Volumen er en kapacitet, mens Load er en mængde, dvs. belastningstest betyder nej. af brugere, og volumentest betyder mængden af data.
Soak test
I denne type test vil vi kontrollere opførslen af en applikation på miljøet, som ikke er understøttende i lang tid, er kendt som soak test.
Generelt er soak-test en negativ type test, da vi allerede ved, at serveren eller miljøet ikke understøtter.
Præstationstestproces
Ydeevnetestningen kan ikke udføres manuelt, da:
- Vi har brug for mange ressourcer, og det blev en dyrere tilgang.
- Og nøjagtigheden kan ikke opretholdes, når vi sporer responstiden manuelt.
Præstationstestprocessen vil blive gennemført i følgende trin:
- Identificer præstationsscenarier
- Planlæg og design præstationstestscript
- Konfigurer testmiljøet og fordel belastningen
- Udfør testscripts
- Resultat
- Analyse resultat
- Identificer flaskehalsen
- Kør testen igen
Hvis vi udfører en positivt flow af præstationstestprocessen, kan den følge nedenstående proces:
Identificer præstationsscenarier
For det første vil vi identificere ydeevnescenarierne baseret på nedenstående faktorer:
Oftest scenarier: Det betyder, at vi kan finde præstationsscenarierne baseret på scenarierne, som almindeligvis bruges som i Gmail-applikation; vi vil optræde login, indbakke, send varer, og opret en mail og log ud .
Mest kritiske scenarier: Kritiske scenarier betyder regelmæssigt brugt og vigtigt for den forretningsmæssige i Gmail-applikation log ind, skriv, indbakke og log ud .
Kæmpe datatransaktion: Hvis vi har enorme data betyder det, at n-antal af brugerne bruger applikationen på samme tid.
Når vi har identificeret præstationsscenarierne, går vi videre til næste trin.
Planlæg og design præstationstestscript
I dette trin vil vi installere værktøjerne i Test Engineer Machine og få adgang til testserveren, og så skriver vi noget script i henhold til testscenarierne og kører værktøjet.
Når vi er færdige med at skrive manuskriptet, går vi til næste trin.
Konfigurer testmiljøet og fordel belastningen
Efter at have skrevet test scripts, arrangerer vi testmiljøet inden udførelsen. Og administrer også værktøjerne, andre ressourcer og fordel belastningen i henhold til 'Brugsmønsteret' eller nævn varigheden og stabiliteten.
Udfør testscripts
Når vi er færdige med at fordele belastningen, vil vi eksekvere, validere og overvåge testscripts.
Resultat
Efter at have udført testscripts, vil vi få testresultatet. Og kontroller, at resultatet opfylder målet i den givne responstid eller ej, og at responstiden kan være maksimum, gennemsnit og minimum.
Hvis svaret ikke lever op til det krævede tidssvar, går vi efter negativt flow hvor udfører nedenstående trin:
Analyse resultat
Først vil vi analysere testresultatet, om det opfylder responstiden eller ej.
fibonacci-serien i java
Identificer flaskehalsen
Derefter vil vi identificere flaskehals (fejl eller ydeevneproblem ). Og flaskehalsen kan opstå på grund af disse aspekter som problem med kode, hardwareproblem (harddisk, RAM-processor), netværksproblemer, og softwareproblem (operativsystem) . Og efter at have fundet flaskehalsen, vil vi optræde tuning (fix eller justering) at løse denne flaskehals.
Kør testen igen
Når vi har rettet flaskehalsene, skal du køre testscripts igen og kontrollere resultatet, om det opfylder det påkrævede mål eller ej.
Problemet opstår i præstationstest
Mens du udfører ydelsestest på applikationen, kan der opstå nogle problemer, og disse problemer kaldes også præstationsproblem .
Ydeevneproblemerne er som følger:
Svartid spørgsmål
Svartiden betyder, hvor hurtigt serveren reagerer på klientens anmodning. Hvis brugerens anmodning ikke fuldføres inden for den givne svartid, kan det være muligt, at brugeren kan miste sin interesse for den pågældende software eller applikation. Det er derfor, at applikationen eller softwaren skal have en perfekt responstid til hurtigt at besvare brugerens anmodning.
Problem med skalerbarhed
Skalerbarhedsproblemerne opstår, når applikationen ikke kan tage n-tal af brugere og forventede brugeranmodninger på samme tid. Det er derfor, vi vil gøre opadgående skalerbarhedstest (tjek applikationens maksimale kapacitet) og nedadgående skalerbarhedstest (når forventet tid ikke matches med den faktiske tid).
Flaskehals
Flaskehalsen er det uformelle navn på fejlen, som opstår, når applikationen er begrænset af en enkelt komponent og har en dårlig indvirkning på systemets ydeevne.
De vigtigste årsager til flaskehalse er softwareproblemer (problem relateret til operativsystemet), hardwareproblemer (problemer relateret til harddisken, RAM og processoren), og kodningsproblem, etc.
Følgende er de mest almindelige præstationsflaskehalse:
- Hukommelsesudnyttelse
- Diskbrug
- CPU-udnyttelse
- Operativsystems begrænsninger
- Netværksudnyttelse
Hastighedsproblemer
Når vi udfører ydelsestest på applikationen, bør applikationen være hurtigere i hastighed for at få brugerens interesse og opmærksomhed, fordi hvis applikationens hastighed er langsom, kan den miste brugerens interesse for applikationen.
Værktøjer til præstationstest
Vi har forskellige typer af ydelsestestværktøjer tilgængelige på markedet, hvor nogle er kommercielle værktøjer og open source-værktøjer.
Kommercielle værktøjer: LoadRunner[HP], WebLOAD, NeoLoad
Open source-værktøj: JMeter
er lig med streng i java
LoadRunner
Det er et af de mest kraftfulde værktøjer til præstationstestning, som bruges til at understøtte præstationstestning for det omfattende udvalg af protokoller, antallet af teknologier og applikationsmiljøer.
Den identificerer hurtigt de mest almindelige årsager til ydeevneproblemer. Og forudsige også nøjagtigt applikationens skalerbarhed og kapacitet.
JMeter
Apache JMeter-softwaren er et open source-værktøj, som udelukkende er en Java-applikation designet til at indlæse den funktionelle testadfærd og måle ydeevnen.
Generelt var det designet til at teste webapplikationerne, men nu udvidet til andre testfunktioner også.
Apache JMeter bruges til at teste ydeevne for både statiske og dynamiske ressourcer og dynamiske webapplikationer.
Det kan bruges til at gengive den tunge belastning på en server, et netværk eller et objekt, en gruppe af servere for at teste dens styrke eller til at analysere den samlede ydeevne under forskellige belastningstyper.
WebLOAD
WebLOAD-testværktøj, der bruges til at teste belastningstest, ydeevnetest og stresstest webapplikationer.
WebLOAD-værktøjet kombinerer ydeevne, skalerbarhed og integritet som en enkelt proces til verificering af web- og mobilapplikationer.
NeoLoad
Neotys udvikler et testværktøj, som kaldes NeoLoad. NeoLoad bruges til at teste scenarierne for ydeevnetest. Ved hjælp af NeoLoad kan vi finde flaskehalsområderne på nettet og udviklingsprocessen for mobilapps.
NeoLoad-testværktøjet er hurtigere sammenlignet med traditionelle værktøjer.
Udover dem er der nogle andre værktøjer Elektrisk belastning, webstressværktøj, LoadUI Pro, StresStimulus, LoadView, LoadNinja og RedLine13, som hjælper med at teste softwarens eller en applikations ydeevne.