In dit gedeelte leren we over prestatietests, waarom we deze nodig hebben, soorten prestatietests en het prestatietestproces.
Hieronder volgen de onderwerpen die we in deze sectie zullen begrijpen:
Wat is prestatietesten?
Het is het belangrijkste onderdeel van niet-functioneel testen.
Het controleren van het gedrag van een applicatie door enige belasting toe te passen, wordt prestatietesten genoemd.
Over het algemeen bepaalt deze test hoe snel de server reageert op het verzoek van de gebruiker.
Terwijl we prestatietests uitvoeren op de applicatie, zullen we ons concentreren op de verschillende factoren, zoals Reactietijd, belasting en stabiliteit van de applicatie.
Reactietijd: De responstijd is de tijd die de server nodig heeft om op het verzoek van de client te reageren.
Laden: Hier betekent Laden dat wanneer N-nummer aantal gebruikers dat de applicatie tegelijkertijd gebruikt of het verzoek tegelijkertijd naar de server verzendt.
Stabiliteit: Voor de stabiliteitsfactor kunnen we zeggen dat wanneer een N-aantal gebruikers de applicatie tegelijkertijd gedurende een bepaalde tijd gebruiken.
Wanneer gebruiken we prestatietesten?
We zullen prestatietests uitvoeren zodra de software stabiel is en naar productie is verplaatst en deze door meerdere gebruikers tegelijk kan worden gebruikt. Om deze reden kunnen er prestatieproblemen optreden. Om deze prestatieproblemen te voorkomen, voert de tester één ronde prestatietests uit.
Omdat het niet-functioneel testen is, wat niet betekent dat we altijd prestatietesten gebruiken, gaan we alleen over op prestatietesten als de applicatie functioneel stabiel is.
Opmerking: prestatietests kunnen niet handmatig worden uitgevoerd, omdat het kostbare en nauwkeurige resultaat niet kan worden gehandhaafd.
Soorten prestatietests
Hieronder volgen de soorten prestatietests:
Java-array segment
Laten we het één voor één bespreken, zodat u er een volledig inzicht in krijgt Belasting, stress, schaalbaarheid, En Stabiliteit prestatietesten.
Belasting testen
De belastingtest wordt gebruikt om de prestaties van een toepassing te controleren door een belasting toe te passen die kleiner is dan of gelijk is aan de gewenste belasting. Dit wordt belastingtesten genoemd.
Bijvoorbeeld: In de onderstaande afbeelding, 1000 gebruikers zijn de gewenste lading , die door de klant wordt gegeven, en 3/seconde is de doel die we willen bereiken tijdens het uitvoeren van een belastingtest.
Stress testen
De stresstest is een test waarbij het gedrag van een applicatie wordt gecontroleerd door een belasting toe te passen die groter is dan de gewenste belasting.
Bijvoorbeeld: Als we het bovenstaande voorbeeld nemen en de gewenste belasting van 1000 naar 1100 gebruikers verhogen, is het doel 4/seconde. Tijdens het uitvoeren van de stresstests in dit scenario zal deze slagen omdat de belasting groter is (100 hoger) dan de feitelijk gewenste belasting.
Schaalbaarheidstesten
Het controleren van de prestaties van een applicatie door de belasting in bepaalde schalen (nummer van een gebruiker) te verhogen of te verlagen, staat bekend als schaalbaarheid testen . Opwaartse schaalbaarheidstests en neerwaartse schaalbaarheidstests worden schaalbaarheidstests genoemd.
Het testen van de schaalbaarheid is verdeeld in twee delen, die als volgt zijn:
Opwaartse schaalbaarheidstesten
Het is testen waar wij het aantal gebruikers op een bepaalde schaal vergroten totdat we een crashpunt krijgen. We zullen opwaartse schaalbaarheidstests gebruiken om de maximale capaciteit van een applicatie te vinden.
Neerwaartse schaalbaarheidstesten
De neerwaartse schaalbaarheidstest wordt gebruikt wanneer de belastingtest niet is geslaagd en vervolgens wordt gestart het verlagen van nr. van gebruikers in een bepaald interval totdat het doel is bereikt. Zodat het eenvoudig is om de bottleneck (bug) te identificeren.
Stabiliteit testen
Het controleren van de prestaties van een applicatie door het aanbrengen van de belasting gedurende een bepaalde tijdsduur staat bekend als Stabiliteit testen .
Voorbeeld van prestatietests
Laten we een voorbeeld nemen waar we willen test het gedrag van een applicatie waarbij de gewenste belasting minder dan 1000 of gelijk is aan 1000 gebruikers .
In de onderstaande afbeelding kunnen we zien dat de 100 op gebruikers worden voortdurend verhoogd om de maximale lading , ook wel genoemd testen van opwaartse schaalbaarheid .
1200 → 3,5sec: [het is niet minder dan of gelijk aan de gewenste belasting, daarom zal dat wel zo zijn Mislukking ]
1300 → 4sec: [deze is niet kleiner dan of gelijk aan de gewenste belasting. d.w.z., Mislukking ]
1400 → Gecrasht
Opmerking 1: Volume- en soak-tests zijn een soort testen, maar geen prestatietests.
Volumetesten
multiplexer
Volumetesten zijn testen, wat ons helpt het gedrag van een applicatie te controleren door een enorm volume van de belasting in termen van gegevens in te voegen. Dit staat bekend als volumetesten, en hier zullen we ons concentreren op het aantal datasnelheden dan op het aantal gebruikers .
Opmerking 2:
Volume is een capaciteit, terwijl Load een hoeveelheid is, dat wil zeggen dat belastingtesten nee betekenen. van gebruikers, en volumetesten betekent de hoeveelheid gegevens.
Week testen
Bij dit type testen controleren we het gedrag van een applicatie in de omgeving. Dit gedrag wordt gedurende langere tijd niet ondersteund. Dit wordt ook wel soak-testen genoemd.
Over het algemeen zijn soak-tests een negatieve vorm van testen, omdat we al weten dat de server of omgeving niet ondersteunend is.
Prestatietestproces
De prestatietests kunnen niet handmatig worden uitgevoerd, omdat:
- We hebben veel middelen nodig, en het werd een duurdere aanpak.
- En de nauwkeurigheid kan niet worden gehandhaafd als we de responstijd handmatig bijhouden.
Het prestatietestproces wordt in de volgende stappen voltooid:
- Identificeer prestatiescenario's
- Plan en ontwerp prestatietestscript
- Configureer de testomgeving en verdeel de belasting
- Testscripts uitvoeren
- Resultaat
- Analyse resultaat
- Identificeer het knelpunt
- Test opnieuw uitvoeren
Als we een positieve stroom van het prestatietestproces zou het onderstaande proces kunnen volgen:
Identificeer prestatiescenario's
Ten eerste zullen we de prestatiescenario's identificeren op basis van de onderstaande factoren:
Meest voorkomende scenario's: Het betekent dat we de prestatiescenario's kunnen vinden op basis van de scenario's die vaak worden gebruikt, zoals in de Gmail-applicatie; wij zullen optreden inloggen, inbox, items verzenden, een e-mail opstellen en uitloggen .
Meest kritische scenario's: Kritieke scenario's worden regelmatig gebruikt en zijn belangrijk voor het bedrijfsleven, zoals in de Gmail-applicatie inloggen, opstellen, inbox en uitloggen .
Enorme datatransactie: Als we enorme gegevens hebben, betekent dit dat n-aantal gebruikers de applicatie tegelijkertijd gebruiken.
Zodra we de prestatiescenario’s hebben geïdentificeerd, gaan we naar de volgende stap.
sorteer arraylijst
Plan en ontwerp prestatietestscript
In deze stap installeren we de tools in de Test Engineer Machine en krijgen we toegang tot de testserver. Vervolgens schrijven we een script volgens de testscenario's en voeren we de tool uit.
Zodra we klaar zijn met het schrijven van het script, gaan we naar de volgende stap.
Configureer de testomgeving en verdeel de belasting
Na het schrijven van de testscripts regelen wij vóór de uitvoering de testomgeving. En beheer ook de tools en andere bronnen en verdeel de belasting volgens het 'Gebruikspatroon' of vermeld de duur en stabiliteit.
Testscripts uitvoeren
Zodra we klaar zijn met het verdelen van de belasting, zullen we de testscripts uitvoeren, valideren en monitoren.
Resultaat
Na het uitvoeren van de testscripts krijgen we het testresultaat. En controleer of het resultaat binnen de gegeven responstijd aan het doel voldoet of niet, en dat de responstijd maximaal, gemiddeld en minimaal kan zijn.
Als het antwoord niet voldoet aan de vereiste responstijd, gaan we voor de negatieve stroom waar zal de onderstaande stappen worden uitgevoerd:
Analyse resultaat
Eerst analyseren we het testresultaat of het voldoet aan de responstijd of niet.
Identificeer het knelpunt
Daarna zullen we de identiteit identificeren knelpunt (bug of prestatieprobleem ). En het knelpunt kan optreden vanwege deze aspecten, zoals de probleem in code, hardwareprobleem (harde schijf, RAM-processor), netwerkproblemen, en de softwareprobleem (besturingssysteem) . En nadat we het knelpunt hebben gevonden, gaan we optreden afstemmen (fix of aanpassing) om dit knelpunt op te lossen.
Test opnieuw uitvoeren
Zodra we de knelpunten hebben verholpen, voeren we de testscripts opnieuw uit en controleren we of het resultaat aan het vereiste doel voldoet of niet.
Het probleem doet zich voor bij prestatietests
Tijdens het uitvoeren van prestatietests op de applicatie kunnen zich enkele problemen voordoen. Deze problemen worden ook wel de prestatie probleem .
De prestatieproblemen zijn als volgt:
Probleem met responstijd
De responstijd betekent hoe snel de server reageert op het verzoek van de client. Als het verzoek van de gebruiker niet binnen de gegeven responstijd wordt voltooid, is het mogelijk dat de gebruiker zijn/haar interesse in de specifieke software of applicatie verliest. Daarom moet de applicatie of software een perfecte responstijd hebben om snel op het verzoek van de gebruiker te reageren.
Schaalbaarheidsprobleem
De schaalbaarheidsproblemen treden op wanneer de toepassing niet tegelijkertijd het n-aantal gebruikers en de verwachte gebruikersaanvragen kan verwerken. Daarom zullen wij dat doen testen van opwaartse schaalbaarheid (controleer de maximale capaciteit van de toepassing) en neerwaartse schaalbaarheidstesten (wanneer de verwachte tijd niet overeenkomt met de werkelijke tijd).
Knelpunt
De Bottleneck is de informele naam van een bug, die optreedt wanneer de applicatie wordt beperkt door een enkel onderdeel en een slechte impact heeft op de systeemprestaties.
De belangrijkste oorzaken van knelpunten zijn softwareproblemen (probleem gerelateerd aan het besturingssysteem), hardwareproblemen (problemen gerelateerd aan de harde schijf, RAM en de processor), En coderingsprobleem, enz.
Hieronder volgen de meest voorkomende prestatieknelpunten:
- Geheugengebruik
- Schijfgebruik
- CPU-gebruik
- Beperkingen van het besturingssysteem
- Netwerkgebruik
Snelheidsproblemen
Wanneer we prestatietests uitvoeren op de applicatie, moet de applicatie sneller zijn om de interesse en aandacht van de gebruiker te trekken. Als de snelheid van de applicatie laag is, kan de interesse van de gebruiker in de applicatie verloren gaan.
Prestatietesttools
We hebben verschillende soorten prestatietesttools op de markt, waarvan sommige commerciële tools en open-sourcetools zijn.
Commerciële tools: LoadRunner[HP], WebLOAD, NeoLoad
Open source-tool: JMeter
LoadRunner
Het is een van de krachtigste tools voor prestatietests, die wordt gebruikt ter ondersteuning van de prestatietests voor het uitgebreide scala aan protocollen, het aantal technologieën en applicatieomgevingen.
Java-bubbel sorteren
Het identificeert snel de meest voorkomende oorzaken van prestatieproblemen. En voorspel ook nauwkeurig de schaalbaarheid en capaciteit van de applicatie.
JMeter
De Apache JMeter-software is een open-source tool, een volledig Java-applicatie die is ontworpen om het functionele testgedrag te laden en de prestaties te meten.
Over het algemeen was het ontworpen voor het testen van webapplicaties, maar nu is het ook uitgebreid naar andere testfuncties.
Apache JMeter wordt gebruikt om de prestaties van zowel statische als dynamische bronnen en dynamische webapplicaties te testen.
Het kan worden gebruikt om de zware belasting van een server, netwerk of object, een groep servers, te reproduceren, de sterkte ervan te testen of de algehele prestaties onder verschillende soorten belasting te analyseren.
WebLADEN
WebLOAD-testtool die wordt gebruikt om webapplicaties te testen op het gebied van belasting, prestatietests en stresstests.
De WebLOAD-tool combineert prestaties, schaalbaarheid en integriteit als één proces voor de verificatie van web- en mobiele applicaties.
NeoLoad
Neotys ontwikkelt een testtool genaamd NeoLoad. De NeoLoad wordt gebruikt om de prestatietestscenario's te testen. Met behulp van NeoLoad kunnen we de knelpunten in het web en het ontwikkelingsproces van mobiele apps vinden.
De NeoLoad-testtool is sneller in vergelijking met traditionele tools.
Afgezien daarvan zijn er nog enkele andere hulpmiddelen Elektrische belasting, webstresstool, LoadUI Pro, StresStimulus, LoadView, LoadNinja en RedLine13, waarmee u de prestaties van de software of een applicatie kunt testen.