Tutorial voor prestatietesten

Wat is prestatietesten?

Performance Testing is een softwaretestproces dat wordt gebruikt voor het testen van de snelheid, responstijd, stabiliteit, betrouwbaarheid, schaalbaarheid en resourcegebruik van een softwareapplicatie onder een bepaalde werklast. Het belangrijkste doel van prestatietests is het identificeren en elimineren van prestatieknelpunten in de softwareapplicatie. Het is een subset van prestatie-engineering en staat ook bekend als “Perf-testen”.

De focus van Performance Testing ligt op het controleren van een softwareprogramma

• Snelheid – Bepaalt of de applicatie snel reageert
• Schaalbaarheid – Bepaalt de maximale gebruikersbelasting die de softwareapplicatie aankan.
• Stabiliteit – Bepaalt of de applicatie stabiel is onder wisselende belastingen

Waarom prestatietesten?

Kenmerken en functionaliteit die door een softwaresysteem worden ondersteund, zijn niet de enige zorg. De prestaties van een softwareapplicatie, zoals de responstijd, betrouwbaarheid, gebruik van bronnen en schaalbaarheid, zijn van belang. Het doel van Performance Testing is niet om bugs te vinden, maar om prestatieknelpunten te elimineren.

Prestatietesten worden uitgevoerd om belanghebbenden informatie te verschaffen over hun applicatie met betrekking tot snelheid, stabiliteit en schaalbaarheid. Nog belangrijker is dat prestatietesten blootlegt wat er verbeterd moet worden voordat het product op de markt komt. Zonder prestatietesten zal de software waarschijnlijk last hebben van problemen zoals: traagheid terwijl meerdere gebruikers het tegelijkertijd gebruiken, inconsistenties tussen verschillende besturingssystemen en slechte bruikbaarheid.

Prestatietests zullen bepalen of hun software voldoet aan de eisen op het gebied van snelheid, schaalbaarheid en stabiliteit onder de verwachte werklast. Applicaties die naar de markt worden gestuurd met slechte prestatiegegevens als gevolg van niet-bestaande of slechte prestatietests, zullen waarschijnlijk een slechte reputatie krijgen en niet aan de verwachte verkoopdoelen voldoen.

Dus, missiekritieke toepassingen zoals ruimtelanceringsprogramma's of levensreddende medische apparatuur moeten op hun prestaties worden getest om ervoor te zorgen dat ze gedurende een lange periode zonder afwijkingen kunnen werken.

Volgens Dunn & Bradstreet ervaart 59% van de Fortune 500-bedrijven naar schatting 1.6 uur downtime per week. Als we bedenken dat het gemiddelde Fortune 500-bedrijf met minimaal 10,000 werknemers $ 56 per uur betaalt, zou het arbeidsdeel van de downtimekosten voor zo'n organisatie $ 896,000 per week bedragen, wat neerkomt op meer dan $ 46 miljoen per jaar.

Slechts 5 minuten stilstand van Google.com (19 augustus 13) zal de zoekgigant naar schatting evenveel kosten $ 545,000.

Er wordt geschat dat bedrijven omzetwaarde verloren $ 1100 per seconde vanwege een recente Amazon Webservicestoring.

Daarom zijn prestatietesten belangrijk. Bekijk deze lijst om u bij dit proces te helpen prestatietestinstrumenten.

Soorten prestatietests

Er zijn voornamelijk zes soorten prestatietesten bij het testen van software. Deze worden hieronder uitgelegd.

• Belastingtesten – controleert het vermogen van de applicatie om te presteren onder de verwachte gebruikersbelasting. Het doel is om prestatieknelpunten te identificeren voordat de softwareapplicatie live gaat.
• Stress testen - omvat het testen van een applicatie onder extreme werklasten om te zien hoe deze omgaat met veel verkeer of gegevensverwerking. Het doel is om het breekpunt van een applicatie te identificeren.
• Duurtesten – Dit wordt gedaan om ervoor te zorgen dat de software de verwachte belasting gedurende een lange periode aankan.
• Spike-testen – test de reactie van de software op plotselinge grote pieken in de belasting die door gebruikers worden gegenereerd.
• Volume testen – Onder volumetest groot nr. van. Gegevens worden in een database opgeslagen en het gedrag van het algehele softwaresysteem wordt gemonitord. Het doel is om de prestaties van softwareapplicaties onder verschillende databasevolumes te controleren.
• Schaalbaarheidstesten – Het doel van schaalbaarheidstests is het bepalen van de effectiviteit van de softwareapplicatie bij het “opschalen” om een ​​toename van de gebruikersbelasting te ondersteunen. Het helpt bij het plannen van capaciteitsuitbreiding aan uw softwaresysteem.

Veelvoorkomende prestatieproblemen

De meeste prestatieproblemen draaien om snelheid, responstijd, laadtijd en slechte schaalbaarheid. Snelheid is vaak een van de belangrijkste kenmerken van een applicatie. Een traag draaiende applicatie verliest potentiële gebruikers. Prestatietesten zorgen ervoor dat een app snel genoeg draait om de aandacht en interesse van een gebruiker vast te houden. Bekijk de volgende lijst met veelvoorkomende prestatieproblemen en merk op hoe snelheid een gemeenschappelijke factor is in veel van deze problemen:

• Lange laadtijd – De laadtijd is normaal gesproken de initiële tijd die nodig is om een ​​applicatie te starten. Dit moet doorgaans tot een minimum worden beperkt. Hoewel het voor sommige toepassingen onmogelijk is om binnen een minuut te laden, moet de laadtijd indien mogelijk binnen een paar seconden worden gehouden.
• Slechte responstijd – De responstijd is de tijd die verstrijkt vanaf het moment dat een gebruiker gegevens in de applicatie invoert totdat de applicatie een reactie op die invoer geeft. Over het algemeen zou dit zeer snel moeten zijn. Nogmaals, als een gebruiker te lang moet wachten, verliest hij zijn interesse.
• Slechte schaalbaarheid – Een softwareproduct heeft te kampen met een slechte schaalbaarheid als het het verwachte aantal gebruikers niet aankan of als het niet geschikt is voor een voldoende groot aantal gebruikers. load Testen moet worden gedaan om er zeker van te zijn dat de applicatie het verwachte aantal gebruikers aankan.
• Knelpunten – Knelpunten zijn obstakels in een systeem die de algehele systeemprestaties verslechteren. Er is sprake van een knelpunt wanneer coderingsfouten of hardwareproblemen onder bepaalde belastingen een afname van de doorvoer veroorzaken. Knelpunten worden vaak veroorzaakt door een defect codegedeelte. De sleutel tot het oplossen van een knelpuntprobleem is het vinden van het codegedeelte dat de vertraging veroorzaakt, en proberen het daar op te lossen. Knelpunten kunnen over het algemeen worden opgelost door slecht lopende processen te repareren of door extra hardware toe te voegen. Sommige veelvoorkomende prestatieknelpunten zijn
  • CPU-gebruik
  • Geheugengebruik
  • Netwerkgebruik
  • OperaSysteembeperkingen
  • Schijfgebruik

Hoe u prestatietests uitvoert

De methodologie die wordt gehanteerd voor prestatietests kan sterk variëren, maar het doel van prestatietests blijft hetzelfde. Het kan helpen aantonen dat uw softwaresysteem aan bepaalde vooraf gedefinieerde prestatiecriteria voldoet. Of het kan helpen de prestaties van twee softwaresystemen te vergelijken. Het kan ook helpen bij het identificeren van onderdelen van uw softwaresysteem die de prestaties verminderen.

Hieronder vindt u een algemeen proces voor het uitvoeren van prestatietests

Stap 1) Identificeer uw testomgeving

Ken uw fysieke testomgeving, productieomgeving en welke testtools beschikbaar zijn. Begrijp details van de hardware, software en netwerkconfiguraties die tijdens het testen worden gebruikt voordat u met het testproces begint. Het zal testers helpen efficiëntere tests te maken. Het zal ook helpen mogelijke uitdagingen te identificeren die testers kunnen tegenkomen tijdens de prestatietestprocedures.

Stap 2) Identificeer de prestatieacceptatiecriteria

Dit omvat doelen en beperkingen voor doorvoer, responstijden en toewijzing van middelen. Het is ook noodzakelijk om succescriteria voor projecten te identificeren die buiten deze doelen en beperkingen vallen. Testers moeten de bevoegdheid krijgen om prestatiecriteria en -doelen vast te stellen, omdat de projectspecificaties vaak niet een voldoende grote verscheidenheid aan prestatiebenchmarks zullen omvatten. Soms is er helemaal geen. Indien mogelijk is het vinden van een vergelijkbare applicatie om mee te vergelijken een goede manier om prestatiedoelen te stellen.

Stap 3) Plan en ontwerp prestatietests

Bepaal hoe het gebruik waarschijnlijk zal variëren tussen eindgebruikers en identificeer belangrijke scenario's om te testen voor alle mogelijke gebruiksscenario's. Het is noodzakelijk om een ​​verscheidenheid aan eindgebruikers te simuleren, prestatietestgegevens te plannen en te schetsen welke statistieken zullen worden verzameld.

Stap 4) Configureren van de testomgeving

Bereid de testomgeving voor vóór uitvoering. Regel ook gereedschap en andere hulpmiddelen.

Stap 5) Implementeer het testontwerp

Creëer de prestatietests volgens uw testontwerp.

Stap 6) Voer de tests uit

Uitvoeren en monitoren van de testen.

Stap 7) Analyseer, stem af en test opnieuw

Consolideer, analyseer en deel testresultaten. Vervolgens fijn afstellen en opnieuw testen om te zien of de prestaties verbeteren of afnemen. Omdat de verbeteringen over het algemeen bij elke nieuwe test kleiner worden, moet u stoppen als er een bottleneck wordt veroorzaakt door de CPU. Dan kunt u overwegen om het CPU-vermogen te vergroten.

Prestatieteststatistieken: bewaakte parameters

De basisparameters die tijdens prestatietests worden gecontroleerd, zijn onder meer:

• Processorgebruik – De hoeveelheid tijd die de processor besteedt aan het uitvoeren van niet-inactieve threads.
• Geheugengebruik – hoeveelheid fysiek geheugen die beschikbaar is voor processen op een computer.
• Schijftijd – hoeveelheid tijd dat de schijf bezig is met het uitvoeren van een lees- of schrijfverzoek.
• Bandbreedte - toont de bits per seconde die door een netwerkinterface worden gebruikt.
• Privébytes – aantal bytes dat een proces heeft toegewezen en dat niet kan worden gedeeld met andere processen. Deze worden gebruikt om geheugenlekken en gebruik te meten.
• Toegewijd geheugen – hoeveelheid virtueel geheugen dat wordt gebruikt.
• Geheugenpagina's/seconde – aantal pagina's dat naar de schijf is geschreven of van de schijf is gelezen om fouten in de harde pagina op te lossen. Harde paginafouten doen zich voor wanneer code die niet uit de huidige werkset komt, van elders wordt opgeroepen en van een schijf wordt opgehaald.
• Paginafouten/seconde – de totale snelheid waarmee foutpagina's door de processor worden verwerkt. Dit gebeurt opnieuw wanneer een proces code van buiten zijn werkset vereist.
• CPU-onderbrekingen per seconde – is het gemiddelde aantal hardware-interrupts dat een processor per seconde ontvangt en verwerkt.
• Lengte schijfwachtrij – is het gemiddelde aantal lees- en schrijfverzoeken dat in de wachtrij staat voor de geselecteerde schijf tijdens een steekproefinterval.
• Lengte netwerkuitvoerwachtrij – lengte van de uitvoerpakketwachtrij in pakketten. Alles meer dan twee betekent dat vertraging en knelpunten moeten worden gestopt.
• Totaal netwerkbytes per seconde – snelheid waarmee bytes worden verzonden en ontvangen op de interface, inclusief frametekens.
• Reactietijd - de tijd vanaf het moment dat een gebruiker een verzoek invoert totdat het eerste teken van het antwoord wordt ontvangen.
• Doorvoer - snelheid waarmee een computer of netwerk verzoeken per seconde ontvangt.
• Hoeveelheid connectiepooling – het aantal gebruikersverzoeken waaraan wordt voldaan door gepoolde verbindingen. Hoe meer verzoeken door verbindingen in de pool worden beantwoord, hoe beter de prestaties zullen zijn.
• Maximale actieve sessies – het maximale aantal sessies dat tegelijk actief kan zijn.
• Hitratio’s – Dit heeft te maken met het aantal SQL statements die worden afgehandeld door gecachte data in plaats van dure I/O-bewerkingen. Dit is een goede plek om te beginnen met het oplossen van knelpuntproblemen.
• Hits per seconde – de nee. aantal hits op een webserver tijdens elke seconde van een belastingstest.
• Terugdraaisegment – de hoeveelheid gegevens die op elk moment kan worden teruggedraaid.
• Databasevergrendelingen – het vergrendelen van tabellen en databases moet worden gecontroleerd en zorgvuldig worden afgestemd.
• Top wacht – worden gemonitord om te bepalen welke wachttijden kunnen worden verkort als het gaat om hoe snel gegevens uit het geheugen worden opgehaald
• Draadaantallen – De gezondheid van een applicatie kan worden gemeten aan de hand van het nee. van threads die actief zijn en momenteel actief zijn.
• Afvalinzameling – Het heeft te maken met het terugsturen van ongebruikt geheugen naar het systeem. Garbage collection moet worden gecontroleerd op efficiëntie.

Prestatietesten Voorbeeld van testgevallen

• Testgeval 01: Controleer of de responstijd niet langer is dan 4 seconden wanneer 1000 gebruikers tegelijkertijd de website bezoeken.
• Testgeval 02: Controleer of de responstijd van de applicatie onder belasting binnen een acceptabel bereik ligt als de netwerkverbinding traag is
• Testgeval 03: Controleer het maximale aantal gebruikers dat de applicatie aankan voordat deze crasht.
• Testgeval 04: Controleer de uitvoeringstijd van de database wanneer 500 records tegelijkertijd worden gelezen/geschreven.
• Testgeval 05: Controleer het CPU- en geheugengebruik van de applicatie en de databaseserver onder piekbelasting
• Testgeval 06: Controleer de responstijd van de toepassing onder lage, normale, matige en zware belasting.

Tijdens de daadwerkelijke uitvoering van de prestatietest worden vage termen als acceptabel bereik, zware belasting, etc. vervangen door concrete getallen. Prestatie-engineers stellen deze getallen in op basis van de bedrijfsvereisten en het technische landschap van de applicatie.

Prestatietesthulpmiddelen

Er is een grote verscheidenheid aan prestatietesttools op de markt beschikbaar. Welke tool u kiest om te testen, hangt af van vele factoren, zoals de typen ondersteunde protocollen, licentiekosten, hardwarevereisten, platformondersteuning, enz. Hieronder vindt u een lijst met veelgebruikte testtools.

• HP LoadRunner - is de meest populaire prestatietesttool die momenteel op de markt is. Deze tool is in staat honderdduizenden gebruikers te simuleren, waardoor applicaties onder reële belasting worden geplaatst om hun gedrag onder verwachte belasting te bepalen. Laadloper beschikt over een virtuele gebruikersgenerator die de handelingen van echte menselijke gebruikers simuleert.
• Jmeter – een van de toonaangevende tools die worden gebruikt voor het testen van de belasting van web- en applicatieservers.

FAQ

Conclusie

In Software EngineeringPrestatietests zijn noodzakelijk voordat een softwareproduct op de markt wordt gebracht. Het zorgt voor klanttevredenheid en beschermt de investering van een investeerder tegen productfalen. De kosten van prestatietests worden doorgaans ruimschoots gecompenseerd door een grotere klanttevredenheid, loyaliteit en retentie.