Een complete gids voor prestatietests met voorbeelden

complete performance testing guide with examples

Wat is prestatietesten?

Performance Testing, ook wel bekend als ‘Perf Testing’, is een soort test die wordt uitgevoerd om te controleren hoe de applicatie of software presteert onder werkbelasting in termen van reactievermogen en stabiliteit. Het doel van de prestatietest is om prestatieknelpunten in een applicatie te identificeren en weg te nemen.

Deze test wordt voornamelijk uitgevoerd om te controleren of de software voldoet aan de verwachte eisen voor applicatiesnelheid, schaalbaarheid en stabiliteit.

hoe je een goed bugrapport schrijft

In deze tutorialserie behandelen we volledige details, zoals: Perf-testtypen, proces en schrijven van prestatieteststrategiedocument vanaf het begin.

Dit is een gedetailleerde tutorialserie die je misschien als bladwijzer wilt gebruiken!

Laten we onderzoeken!

Lijst met ALLE zelfstudies voor prestatietests in deze serie:

Tutorial # 1: Volledige gids voor prestatietests (Deze tutorial)
Tutorial # 2: Verschil tussen prestatie-, belasting- en stresstests
Tutorial # 3: Functioneel testen versus prestatietesten
Tutorial # 4: Prestatietestplan en teststrategie
Tutorial # 5: Manieren om uw prestatietests een boost te geven
Tutorial # 6: Gids voor het testen van cloudprestaties
Tutorial # 7: Gids voor prestatietests voor mobiele apps
Tutorial # 8: Hoe u handmatige prestatietests uitvoert
Tutorial # 9: Zelfstudie over het testen van websiteprestaties
Tutorial # 10: Bedrijven die prestaties testen
Tutorial # 11: Prestatietesten met LoadRunner (Serie)

Gereedschap:

Tutorial # 12: Topprestatietesttools
Tutorial # 13: Neoload Performance Test-zelfstudie
Tutorial # 14: BlazeMeter Mobile Performance Test-zelfstudie
Tutorial # 15: WAPT-zelfstudie over belasting, stress en prestatietests
Tutorial # 16: SmartMeter.io Zelfstudie over prestatietests voor websites

Wat je leert:

• Soorten prestatietests
  • Laadtesten
  • Stress testen
  • Volume testen
  • Capaciteitstesten
  • Betrouwbaarheid / hersteltesten
• Prestatietestproces
• Hoe een prestatieteststrategiedocument schrijven?
  • Voorbeeld van een sjabloon voor een prestatieteststrategie
  • #1. Inleiding
    • Objectief
    • Architectuur
  • # 2) Reikwijdte
    • Binnen bereik
    • Buiten bereik
  • # 3) Aanpak
    • Prestatietestscenario's
    • Typen prestatietests
    • Prestatiestatistieken
    • Prestatietestactiviteiten en -resultaten
  • # 4) Testgegevens
  • # 5) Criteria voor binnenkomst en vertrek
  • # 6) Beheer van defecten
    • Definitie van de ernst van het defect
  • # 7) Testhulpmiddelen en -technieken
  • # 8) Criteria voor opschorting en hervatting
  • # 9) Testresultaten
  • # 10) Rollen en verantwoordelijkheden
  • # 11) Potentiële risico's en mitigatieplan
  • # 12) Veronderstellingen
  • # 13) Afhankelijkheden
  • # 14) Afkortingen
• Best practices voor realistische prestatietests
  • # 1) Planning
  • # 2) Ontwikkeling
  • # 3) Uitvoering
  • # 4) Analyse
  • Gevolgtrekking
  • Aanbevolen literatuur

Soorten prestatietests

Laadtesten

Load Testing is een soort prestatietest waarbij de applicatie wordt getest op zijn prestaties bij normaal en piekgebruik. De prestatie van een applicatie wordt gecontroleerd met betrekking tot zijn reactie op het gebruikersverzoek en zijn vermogen om consistent te reageren binnen een geaccepteerde tolerantie op verschillende gebruikersbelastingen.

De belangrijkste overwegingen zijn:

1. Wat is de maximale belasting die de toepassing kan dragen voordat de toepassing zich onverwachts gaat gedragen?
2. Hoeveel gegevens kan de database verwerken voordat het systeem vertraagt ​​of de crash wordt waargenomen?
3. Zijn er netwerkgerelateerde problemen die moeten worden aangepakt?

Stress testen

Stresstesten worden gebruikt om manieren te vinden om het systeem te doorbreken. De test geeft ook het bereik aan van de maximale belasting die het systeem kan dragen.

Over het algemeen heeft stresstesten een incrementele benadering waarbij de belasting geleidelijk wordt verhoogd. De test wordt gestart met een belasting waarvoor de applicatie al is getest. Vervolgens wordt er langzaam meer belasting toegevoegd om het systeem te belasten. Het punt waarop we beginnen te zien dat servers niet reageren op de verzoeken, wordt als het breekpunt beschouwd.

De volgende vragen moeten worden beantwoord:

• Wat is de maximale belasting die een systeem kan dragen voordat het kapot gaat?
• Hoe gaat het systeem kapot?
• Kan het systeem herstellen nadat het is gecrasht?
• Op hoeveel manieren kan een systeem kapot gaan en wat zijn de zwakke punten bij het afhandelen van de onverwachte belasting?

Volume testen

Volume Testing is om te controleren of de prestaties van de applicatie niet worden beïnvloed door de hoeveelheid gegevens die door de applicatie wordt verwerkt. Om een ​​volumetest uit te voeren, wordt er een enorme hoeveelheid gegevens in de database ingevoerd. Deze test kan een incrementele of continue test zijn. Bij de incrementele test wordt het datavolume geleidelijk verhoogd.

Over het algemeen groeit de database met het gebruik van de applicatie en is het noodzakelijk om de applicatie te testen met een zware database. Een goed voorbeeld hiervan kan een website zijn van een nieuwe school of een hogeschool die aanvankelijk kleine hoeveelheden gegevens moet opslaan, maar na 5-10 jaar is de gegevensopslag in de database van de website veel meer.

Capaciteitstesten

=> Is de applicatie in staat om aan het bedrijfsvolume te voldoen onder zowel normale als piekbelasting?

Capaciteitstesten worden over het algemeen gedaan voor toekomstige vooruitzichten. Capaciteitstests behandelen het volgende:

1. Zal de applicatie de toekomstige belasting kunnen ondersteunen?
2. Is de omgeving in staat om de aanstaande verhoogde belasting te weerstaan?
3. Wat zijn de aanvullende middelen die nodig zijn om de omgeving capabel genoeg te maken?

Capaciteitstests worden gebruikt om te bepalen hoeveel gebruikers en / of transacties een bepaalde webtoepassing ondersteunt en nog steeds aan de prestaties voldoet. Tijdens deze tests worden bronnen zoals processorcapaciteit, netwerkbandbreedte, geheugengebruik, schijfcapaciteit, etc. overwogen en aangepast om het doel te bereiken.

Online bankieren is een perfect voorbeeld van waar capaciteitstesten een grote rol kunnen spelen.

Betrouwbaarheid / herstel Testen

Betrouwbaarheidstests of hersteltests - is om te controleren of de toepassing al dan niet in staat is om terug te keren naar de normale toestand na een storing of abnormaal gedrag en hoe lang het duurt om dit te doen (met andere woorden, tijdschatting).

Als een online handelssite een storing ondervindt waarbij de gebruikers op een bepaald moment van de dag (piekuren) geen aandelen kunnen kopen / verkopen, maar dat wel na een uur of twee, kunnen we zeggen dat de applicatie betrouwbaar is of hersteld van het abnormale gedrag.

Prestatietestproces

Hier zijn alle activiteiten die tijdens deze test zijn uitgevoerd:

# 1) Vereiste analyse / verzameling

Het prestatieteam werkt samen met de klant voor het identificeren en verzamelen van vereisten - technisch en zakelijk. Dit omvat het verkrijgen van informatie over de architectuur, technologieën en database van de applicatie, beoogde gebruikers, functionaliteit, applicatiegebruik, testvereiste , hardware- en softwarevereisten, enz.

# 2) POC / Tool-selectie

Zodra de belangrijkste functionaliteit is geïdentificeerd, wordt POC (Proof Of Concept - wat een soort demonstratie is van de realtime activiteit, maar in beperkte zin) gedaan met de beschikbare tools.

De lijst met beschikbare tools is afhankelijk van de kosten van de tool, het protocol dat de applicatie gebruikt, de technologieën die zijn gebruikt om de applicatie te bouwen, het aantal gebruikers dat we simuleren voor de test, etc. Tijdens POC worden scripts gemaakt voor de geïdentificeerde sleutel functionaliteit en uitgevoerd met 10-15 virtuele gebruikers.

# 3) Prestatietestplan en ontwerp

Afhankelijk van de informatie die in de voorgaande fasen is verzameld, worden testplanning en -ontwerp uitgevoerd.

Testplanning omvat informatie over hoe de prestatietest zal plaatsvinden - testomgeving, werklast, hardware, enz.

Meer over het teststrategiedocument hieronder.

# 4) Ontwikkeling van prestatietests

• Er worden use cases gemaakt voor de functionaliteit die in het testplan is geïdentificeerd als de scope van PT.
• Deze use cases worden ter goedkeuring met de klant gedeeld. Dit is om ervoor te zorgen dat het script wordt opgenomen met de juiste stappen.
• Na goedkeuring begint de scriptontwikkeling met een registratie van de stappen in use cases met de prestatietesttool die is geselecteerd tijdens de POC (Proof of Concepts) en verbeterd door het uitvoeren van correlatie (voor het omgaan met dynamische waarde), parametrisering (waardevervanging) en aangepaste functies zoals per situatie of behoefte. Meer over deze technieken in onze videozelfstudies.
• De scripts worden vervolgens gevalideerd voor verschillende gebruikers.
• Parallel aan het maken van scripts blijft het performanceteam ook werken aan het opzetten van de testomgeving (software en hardware).
• Het prestatieteam zorgt ook voor Metadata (back-end) via scripts als deze activiteit niet door de klant wordt opgepakt.

# 5) Prestatietestmodellering

j2ee interviewvragen en antwoorden pdf

Performance Load Model is gemaakt voor de testuitvoering. Het belangrijkste doel van deze stap is om te valideren of de opgegeven prestatiestatistieken (geleverd door klanten) tijdens de test worden behaald of niet. Er zijn verschillende benaderingen om een ​​laadmodel te maken.​ De wet van Little ”Wordt in de meeste gevallen gebruikt.

# 6) Testuitvoering

Het scenario is ontworpen volgens het Load Model in Controller of Performance Center, maar de eerste tests worden niet uitgevoerd met het maximale aantal gebruikers dat in het Load-model zit.

Testuitvoering wordt stapsgewijs uitgevoerd. Bijvoorbeeld​ Als het maximale aantal gebruikers 100 is, worden de scenario's eerst uitgevoerd met 10, 25, 50 gebruikers enzovoort, en uiteindelijk tot 100 gebruikers.

# 7) Analyse van testresultaten

Testresultaten zijn het belangrijkste resultaat voor de prestatietester. Dit is waar we de ROI (Return on Investment) en productiviteit kunnen bewijzen die prestatietests kunnen opleveren.

Enkele van de best practices die het resultaatanalyseproces helpen:

1. Een unieke en betekenisvolle naam voor elk testresultaat - dit helpt bij het begrijpen van het doel van de test.
2. Neem de volgende informatie op in het overzicht van de testresultaten:

• Reden voor de storing (en)
• Verandering in de prestaties van de applicatie in vergelijking met de vorige testrun
• Wijzigingen die in de test zijn aangebracht vanaf het punt van applicatie-build of testomgeving.
• Het is een goede gewoonte om na elke test een samenvatting van de resultaten te maken, zodat de analyseresultaten niet elke keer dat testresultaten worden doorverwezen, worden samengesteld.
• PT vereist over het algemeen veel testruns om tot de juiste conclusie te komen.
• Het is goed om de volgende punten in het resultaatoverzicht te hebben:
  • Doel van de test
  • Aantal virtuele gebruikers
  • Scenario samenvatting
  • Duur van de test
  • Doorvoer
  • Grafieken
  • Grafieken vergelijking
  • Reactietijd
  • Fout opgetreden
  • Aanbevelingen

# 8) Rapporteren

Testresultaten moeten worden vereenvoudigd, zodat de conclusie duidelijker is en er geen afleiding nodig is. Het ontwikkelteam heeft meer informatie nodig over analyse, vergelijking van resultaten en details over hoe de resultaten werden verkregen.

Het testrapport wordt als goed beschouwd als het kort, beschrijvend en to the point is.

Hoe een prestatieteststrategiedocument schrijven?

In deze tutorial wordt uitgelegd hoe u een voorbeeld van een prestatieteststrategie voor een berichtentoepassing schrijft.

Houd er rekening mee dat dit slechts een voorbeeld is en dat de vereisten van de ene klant tot de andere zullen verschillen. In deze tutorial zullen we ook de best practices voor prestatietesten leren kennen.

Voorbeeld van een sjabloon voor een prestatieteststrategie

Over ABC-chattoepassing - Laten we aannemen dat dit een chatwerkbank is die in een bedrijf wordt gebruikt door hun klantenservicemedewerker. Deze chattoepassing gebruikt het XMPP-protocol, d.w.z. Extensible Messaging and Presence Protocol en Open fire-server voor het verzenden en ontvangen van instant messages.

Er zijn enkele verbeteringen aangebracht in deze bestaande chatclient, zoals pc-besturing op afstand, pc-diagnose, reparatiehulpmiddelen, online chat, enz., Dus deze prestatieteststrategie is een voorbeeld van dergelijke toepassingen.

Laten we voor deze applicatie aannemen dat het projectteam heeft besloten om JMeter voor prestatietests en JIRA voor het opsporen van defecten.

De eerste pagina van het prestatieteststrategiedocument moet de titel van het document en de auteursrechten van het bedrijf bevatten.

De tweede pagina moet Documentbeheer bevatten, waaronder de geschiedenis van de documentversies, de lijst met beoordelaars en goedkeurders en de lijst met bijdragers.

De derde pagina moet de inhoudsopgave bevatten, gevolgd door de onderstaande onderwerpen.

#1. Inleiding

Het doel van dit document is om te definiëren / uit te leggen hoe prestatietests worden uitgevoerd op de ABC-chattoepassing voor de huidige en toekomstige staat.

De ABC-chattoepassing is een interne werkbank voor externe ondersteuningsagenten. Deze werkbank zal worden gebruikt om aan verzoeken van klanten te voldoen. Deze workbench heeft mogelijkheden zoals online chat, klantidentificatie, pc-besturing op afstand, pc-diagnose en reparatiehulpmiddelen.

Objectief

De belangrijkste doelstellingen van Performance Testing zijn de volgende:

• Het vertrouwen krijgen dat de wijzigingen aan de bestaande chatapplicatie in lijn zijn met de gedefinieerde Service Level Agreement.
• Om ervoor te zorgen dat de prestaties van de applicatie, de beschikbaarheid van de service en de stabiliteit van de applicatie niet worden beïnvloed als gevolg van de nieuwe verbeteringen.
• De transactiereactietijden blijven binnen de acceptabele tolerantie voor het toenemende belastingsprofiel.
• JVM's vertonen stabiel geheugengebruik over de toenemende belastingsprofielen.

De onderstaande afbeelding legt het prestatietest- en optimalisatieproces duidelijk uit:

Architectuur

In deze sessie moet u het architectuurdiagram van uw project opnemen.

# 2) Reikwijdte

Binnen bereik

Hieronder vindt u de prestatietestscope voor ABC-chatworkbench:

• Kennisverwerving van de belangrijkste zakelijke transacties en opbouw van lastverdeling na een gedetailleerde studie van het systeem.
• Identificeer de kritieke scenario's voor prestatietests met hulp van verschillende projecttrajecten.
• Gebruik de resultaten van de vorige release als basis voor toekomstige releases.
• Verifieer en valideer de prestatietestomgeving en de prestatie- / belastingtesttoolinfrastructuur voor eventuele aanvullende agentmachines.
• Voorbereiding van prestatietestscripts met JMeter voor de geïdentificeerde scenario's die de geïdentificeerde piekbelasting nabootsen.
• Stel prestatiebewaking op de servers in voor het bewaken van de test om de knelpunten tijdens de testuitvoeringsfase te identificeren.
• Publiceer resultaten van prestatietests.
• Coördineer met verschillende belanghebbenden om de geïdentificeerde prestatieproblemen op te lossen.
• Basislijn het prestatieniveau voor toekomstige releases.

Buiten bereik

• Functioneel testen , UAT, systeemtesten en beveiligingstests.
• Prestatietests / monitoring van interfaces van derden.
• Prestaties afstemmen. (Meestal wordt het afstemmen door een ander team gedaan, als je prestatie-ingenieurs hebt om het systeem af te stemmen, kun je dit toevoegen in de Inscope).
• Codeprofilering / Hardware-dimensionering / Capaciteitsplanning.
• Beveiliging / Kwetsbaarheidstesten / UAT / White box testen ​
• Gegevensgeneratie voor prestatietests.
• Niet-functionele tests ( Bijvoorbeeld, failover, disaster recovery, back-up, bruikbaarheid) anders dan de prestatietests.
• Testen van elke mobiele oplossing.
• Prestatietesten en afstemmen van applicaties van derden.
• Realisatie van prestatieaanbevelingen, wijzigingen in applicatiecode en wijzigingen in de door de leverancier ondersteunde producten / serverconfiguratie vallen buiten het bereik vanuit het perspectief van het Performance Team.
• Infrastructuurondersteuning / build-implementatie / omgevingsgereedheid / databaseherstel / netwerkondersteuning enz.

# 3) Aanpak

Prestatietests voor ABC-chat worden uitgevoerd met Jmeter door aangepaste XMPP-plug-ins te schrijven die een smack-bibliotheek gebruiken voor XMPP-verbindingen. Deze bibliotheken worden gebruikt om verbindingen tot stand te brengen, in te loggen en chatberichten naar de XMPP-server te sturen.

Deze bibliotheken zijn gebundeld in een jar-bestand dat wordt geïmplementeerd in de Jmeter en is ontworpen op basis van de te testen scenario's. De Jmeter Work Bench is geïnstalleerd in de lokale machine die verbinding maakt met de JMeter-server die de Load Generators heeft om de vereiste belasting op het Chat-serversysteem te genereren om het systeemgedrag te bewaken.

Het testscenario wordt gescript met behulp van de JMeter-tool. De scripts zouden naar wens worden aangepast. Het schema wordt gemaakt met de vereiste opstarttijd om de real-world scenario's te simuleren.

Het testscenario zou worden opgesplitst en gemeten in de onderstaande aspecten:

a) Basislijntest: Elk scenario uitvoeren met 1 Vuser en meerdere iteraties om te bepalen of de applicatieprestaties voldoen aan de zakelijke Service Level Agreement of niet.

b) Basisbelastingtest: Om te voldoen aan de Business Benchmark onder belastingtest, zal het Performance Testing-team een ​​basislasttest uitvoeren die zal helpen om eventuele systeemprestatieproblemen met toenemende belasting te identificeren en de basislijn creëert voor het volgende niveau van prestatietests.

c) Piekbelasting / schaalbaarheidstest: Het prestatietestteam zal meerdere tests uitvoeren met toenemende Vusers om aan de verwachte belasting te voldoen en ook om de applicatieprestaties te meten om de prestatiecurve vast te stellen en te bepalen of de implementatie de serviceniveau-overeenkomsten kan ondersteunen onder de piekgebruikersbelasting.

Het helpt bij het afstemmen of capaciteitsplanning van de individuele Java virtual machines (JVM), het totale aantal vereiste JVM's en de processors. Dit wordt bereikt door het aantal Vusers te verhogen naar 50%, 75%, 100% en 125% van de piekcapaciteit.

d) Uithoudingstest: Het prestatietestteam voert deze test uit voor een periode van 8 uur / 16 uur / 24 uur om geheugenlekken, prestatieproblemen in de loop van de tijd en algehele systeemstabiliteit te identificeren. Tijdens duurtests bewaakt het Performance Testing-team de belangrijkste prestatie-indicatoren, zoals transactieresponstijden en de stabiliteit van het geheugengebruik.

hoe json-bestand op Windows te openen

Systeembronnen zoals CPU, geheugen en IO moeten worden bewaakt met de hulp van het projectteam.

Aangenomen wordt dat de Performance-testomgeving een replica is van de productieomgeving. De tests worden uitgevoerd met een incrementele belasting om vast te stellen waar de applicatie faalt.

Prestatietestscenario's

Voeg het Excel toe aan de set scenario's.

Bijvoorbeeld,

Scenario 1: Om de chat tussen agent en klant te valideren voor X no. van gelijktijdige sessies.

Typen prestatietests

In de onderstaande tabel worden de verschillende soorten prestatietests en hun doelstellingen toegelicht.

Prestatiestatistieken

• Metrische gegevens aan de clientzijde

• Systeem- en netwerkprestatiemetingen

Prestatietestactiviteiten en -resultaten

# 4) Testgegevens

Aangenomen wordt dat de Performance omgevingsdata een kopie is van de productiedata en de benodigde testdata wordt aangeleverd door het projectteam.

# 5) Criteria voor binnenkomst en vertrek

• Toegang tot alle applicaties in de omgeving.
• Milieubereidheid voltooid.
• Gereedheid van prestatietestgegevens.

# 6) Beheer van defecten

• De module Defect Management in JIRA zal in het project worden gebruikt voor het vastleggen van defecten en voor het traceren tot sluiting.
• Identificatie van defecten die tijdens de testuitvoeringsfase worden gevonden, wordt vastgelegd in JIRA en deze defecten worden door het ontwikkelteam opgelost volgens de onderstaande ernst.
• Bijeenkomsten voor de beoordeling van defecten zouden dagelijks worden gehouden met deelname van de test-, ontwikkelings-, kwaliteitsanalisten en zakelijke teams.
• De criteria om defecten op te lossen zouden stringenter worden naarmate het project de Go Live-datum nadert. Richtlijnen voor defectherstelcriteria die tijdens defectbeoordelingsbijeenkomsten moeten worden gepubliceerd.

Definitie van de ernst van het defect

De definities van ernstcodes zijn als volgt:

# 7) Testhulpmiddelen en -technieken

# 8) Criteria voor opschorting en hervatting

Hieronder staan ​​de kritieke opschortings- en hervattingscriteria die van invloed zijn op de testactiviteiten:

# 9) Testresultaten

De resultaten van de prestatietest omvatten:

• Strategie voor prestatietests
• Document met prestatie-eisen
• Scenariodocument voor prestatietest
• Scripts voor prestatietests
• Resultaten van prestatietests

# 10) Rollen en verantwoordelijkheden

Rollen en verantwoordelijkheden worden duidelijk uitgelegd in de onderstaande tabel.

# 11) Potentiële risico's en mitigatieplan

# 12) Veronderstellingen

• Performance Test Environment zal een replica zijn van het landschap van de productarchitectuur. (d.w.z. correcte hardware, software, interfaces, integratielagen, enz.).
• Prestatiescripts worden ontworpen op basis van de kritische stromen waarvoor het gebruik hoog is.
• Alle infrastructuurproblemen moeten worden opgelost voordat u met prestatietests begint. Eventuele wijzigingen in de systeemconfiguratie die later worden aangebracht, maken de testresultaten ongeldig.
• Een applicatie is stabiel en klaar voor gebruik in de Performance testomgeving.
• De benodigde hardware- en softwarebronnen (zoals load generator machines / software, controller / agent machines) worden ter beschikking gesteld.
• Alle wijzigingen in de scope zullen door een change control-proces gaan en het prestatietestteam zal de impact van tijdlijnen en middelen beoordelen.
• Van respectieve servers wordt verwacht dat ze de belasting afhandelen.
• Traceerlogboeken van toepassingen moeten worden ingeschakeld voor de ondersteunende systemen voor bewakingsdoeleinden.

# 13) Afhankelijkheden

• Beschikbaarheid van de Performance-testomgeving die een replica is van het productarchitectuurlandschap.
• Ondersteuning vereist van verschillende Functional, Development, Database en Infrastructure teams tijdens de testvoorbereiding en uitvoeringsfase.
• Er worden geen codewijzigingen doorgevoerd tijdens de volledige prestatietestfase, aangezien de tijd zeer beperkt is.
• In het geval van onvoorziene problemen die leiden tot beperkingen binnen de tijdlijnen, als tijdlijnen het niet mogelijk maken om aan alle testscopes te voldoen binnen de oorspronkelijke mijlpaaldata, is ondersteuning beschikbaar bij de Release Managers om een ​​scoping- en prioriteitsbeslissing te nemen.
• Applicatie Zakelijke gebruikers / Subject Matter Experts zullen beschikbaar worden gesteld voor functionele verduidelijkingen en ondertekening van zakelijke transacties.
• ABC Chat Program Manager zal beoordelen en afmelden.

# 14) Afkortingen

U moet nu duidelijk hebben begrepen hoe u een effectieve prestatieteststrategie voor een berichtentoepassing schrijft.

Best practices voor realistische prestatietests

Om een ​​Performance Test-project met succes af te ronden, moeten we ervoor zorgen dat we het op de juiste manier doen vanaf de planningsfase, dwz planning, ontwikkeling, uitvoering en analyse.

Laten we elke fase in detail bekijken om prestatietests effectief uit te voeren.

# 1) Planning

• Probeer de meest voorkomende workflows te identificeren, d.w.z. de bedrijfsscenario's die moeten worden getest. Als de toepassing al bestaat, controleer dan de serverlogboeken om de meest gebruikte scenario's te begrijpen. Als de applicatie nieuw is, overleg dan met het projectmanagementteam om de belangrijkste bedrijfsstroom te begrijpen.
• Plan de belastingtest zodanig dat u een breed scala aan workflows bestrijkt, zoals licht gebruik, gemiddeld gebruik en piekbelastingen.
• U moet veel cycli van de Load Test uitvoeren, dus probeer een raamwerk te maken zodat u dezelfde scripts keer op keer kunt gebruiken. Probeer ook een back-up van de scripts te maken.
• Probeer te analyseren hoe lang een test moet duren, is het een uur? 8 uur? Een dag of een week? Meestal zullen langdurige tests veel belangrijke defecten aan het licht brengen, zoals OS-bugs, geheugenlekken, enz.
• Als uw organisatie een APM (Application Monitoring Tool) gebruikt, kunt u deze opnemen tijdens de testruns, zodat u de prestatieproblemen gemakkelijk kunt identificeren en de hoofdoorzaak gemakkelijker kunt identificeren.

# 2) Ontwikkeling

• Probeer tijdens het ontwikkelen van de scripts, d.w.z. opname, een meer betekenisvolle transactienaam te geven op basis van de bedrijfsstroomnamen die in het plan worden vermeld.
• Neem geen applicaties van derden op en als het wordt opgenomen, probeer het dan te filteren terwijl u de scripts verbetert.
• Niet alle dynamische waarden kunnen worden gecorreleerd met de autocorrelatiefunctie in de tool, dus probeer een handmatige correlatie uit te voeren om fouten te voorkomen.
• Probeer uw prestatietests zo te ontwerpen dat u de backend van de applicatie raakt en niet alleen de cacheserver.

# 3) Uitvoering

• Zorg ervoor dat u de tests uitvoert in een productieachtige omgeving, inclusief factoren als SSL, Load Balancer en Firewalls. Dit is nodig om een ​​realistische belasting van het systeem te simuleren.
• Probeer een workload te creëren die erg realistisch is, u kunt dit verkrijgen door de serverlogboeken te controleren of het een bestaande applicatie is en als het een nieuwe applicatie is, moet u deze informatie van het zakelijke team krijgen. Onthoud dat werkdruk erg belangrijk is voor het uitvoeren van succesvolle prestatietests.
• Kom nooit tot een conclusie door tests uit te voeren met de helft van de productiegrootte omgeving, het is altijd aan te raden om tests uit te voeren in een omgeving die gelijk is aan productie.
• Probeer tijdens het uitvoeren van langlopende tests de run met regelmatige tussenpozen te bekijken om er zeker van te zijn dat de test soepel verloopt.

# 4) Analyse

• Probeer de applicatie te analyseren door eerst enkele belangrijke tellers toe te voegen, als er een bottleneck wordt gevonden, probeer dan extra tellers toe te voegen met betrekking tot de bottleneck. Dit zal op zijn beurt helpen om het probleem gemakkelijker te vinden.
• Een toepassing kan om vele redenen mislukken, zoals het niet reageren op een verzoek, reageren met een foutcode, uw validatielogica niet halen of te traag reageren. Dus probeer al deze dingen te onderzoeken voordat u tot een conclusie komt.

Gevolgtrekking

Ik ben er zeker van dat deze tutorial je een enorme kennis zou hebben gegeven over prestatietests en hoe je een prestatieteststrategiedocument met gedetailleerde voorbeelden kunt schrijven.

In onze aanstaande tutorial zullen we de verschillen tussen prestatie-, belasting- en stresstests in detail leren.

Controleer ook => Gratis LoadRunner diepgaande trainingsserie

VOLGENDE zelfstudie

Aanbevolen literatuur

• Prestatietests versus belastingtests versus stresstests (verschil)
• Laadtests met HP LoadRunner-zelfstudies
• Cloud-prestatietests: cloudgebaseerde serviceproviders voor belastingtests
• Webapplicatie laden, stress en prestatie testen met behulp van WAPT
• Tools en services voor het testen van websiteprestaties
• Hoe voer ik handmatige prestatietests uit?
• Prestatietests van mobiele applicaties met BlazeMeter
• Prestatietests van webservices met behulp van LoadRunner VuGen-scripts