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”.

Bij prestatietesten ligt de focus op het controleren van de volgende aspecten van een softwareprogramma:

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

Waarom zijn prestatietests belangrijk?

De functies en functionaliteit die een softwaresysteem biedt, zijn niet het enige aandachtspunt. De prestaties van een softwareapplicatie, zoals de reactietijd, betrouwbaarheid, resourcegebruik en schaalbaarheid, zijn eveneens van belang. Het doel van prestatietesten is niet om bugs te vinden, maar om prestatieknelpunten te elimineren.

Prestatietesten worden uitgevoerd om belanghebbenden informatie te verschaffen over de snelheid, stabiliteit en schaalbaarheid van hun applicatie. Belangrijker nog, prestatietesten brengen aan het licht wat er verbeterd moet worden voordat het product op de markt komt. Zonder prestatietesten is de kans groot dat de software problemen vertoont, zoals een trage werking bij gelijktijdig gebruik door meerdere gebruikers, inconsistenties tussen verschillende besturingssystemen en een slechte gebruiksvriendelijkheid.

Prestatietests bepalen of software voldoet aan de eisen op het gebied van snelheid, schaalbaarheid en stabiliteit onder de verwachte werkbelasting. Applicaties die op de markt worden gebracht met slechte prestatiecijfers als gevolg van ontbrekende of gebrekkige prestatietests, zullen waarschijnlijk een slechte reputatie krijgen en de verwachte verkoopdoelen niet halen.

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 of GoogleDe overname van .com (19-aug-13) zal de zoekgigant naar schatting evenveel kosten als $ 545,000.

Naar schatting hebben bedrijven omzetverlies geleden ter waarde van... $ 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 langere periode aankan. Het helpt bij het opsporen van problemen zoals geheugenlekken en uitputting van resources die zich pas voordoen tijdens langdurig gebruik.
• Spike-testen – Deze test meet de reactie van de software op plotselinge, grote pieken in de belasting die door gebruikers wordt gegenereerd. In tegenstelling tot stresstesten richt piektesten zich specifiek op hoe het systeem omgaat met en herstelt van scherpe, kortstondige verkeerspieken.
• Volumetesten – Dit houdt in dat een database wordt gevuld met een grote hoeveelheid gegevens en dat het gedrag van het softwaresysteem als geheel wordt gemonitord. Het doel is om de prestaties van de softwareapplicatie te controleren bij wisselende databasevolumes.
• Schaalbaarheidstesten – Het bepaalt de effectiviteit van de softwareapplicatie bij het opschalen om een ​​toename van de gebruikersbelasting op te vangen. Het helpt bij het plannen van capaciteitsuitbreidingen voor uw softwaresysteem.

Veelvoorkomende prestatieproblemen

De meeste prestatieproblemen hebben te maken met snelheid, reactietijd, laadtijd en slechte schaalbaarheid. Snelheid is vaak een van de belangrijkste eigenschappen van een applicatie. Een trage applicatie verliest potentiële gebruikers. Prestatietesten zorgen ervoor dat een applicatie snel genoeg werkt om de aandacht en interesse van de gebruiker vast te houden. De volgende prestatieproblemen komen vaak voor, waarbij snelheid een terugkerende factor is:

• Lange laadtijd – De laadtijd is normaal gesproken de tijd die een applicatie nodig heeft om op te starten. Deze tijd moet over het algemeen tot een minimum beperkt worden. Hoewel sommige applicaties onmogelijk binnen een minuut kunnen laden, moet de laadtijd indien mogelijk onder de paar seconden blijven.
• Slechte responstijd – De responstijd is de tijd die verstrijkt tussen het moment dat een gebruiker gegevens invoert in de applicatie en het moment dat de applicatie een reactie op die invoer geeft. Over het algemeen moet dit zeer snel zijn. Als een gebruiker te lang moet wachten, verliest hij of zij de 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 verminderen. Een knelpunt ontstaat wanneer programmeerfouten of hardwareproblemen een afname van de doorvoer veroorzaken onder bepaalde belasting. Vaak wordt een knelpunt veroorzaakt door één defect stuk code. De sleutel tot het oplossen van een knelpunt is het vinden van het stuk code dat de vertraging veroorzaakt en proberen dit daar te verhelpen. Knelpunten worden over het algemeen verholpen door slecht presterende processen te verbeteren of extra hardware toe te voegen. 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 volgt een algemene procedure voor het uitvoeren van prestatietests.

Stap 1) Identificeer uw testomgeving

Zorg dat je je fysieke testomgeving, productieomgeving en beschikbare testtools goed kent. Begrijp de details van de hardware-, software- en netwerkconfiguraties die tijdens het testen worden gebruikt voordat je met het testproces begint. Dit helpt testers efficiëntere tests te ontwikkelen. Het helpt ook bij het identificeren van mogelijke problemen die testers tijdens de prestatietests kunnen tegenkomen.

Stap 2) Identificeer de prestatieacceptatiecriteria

Dit omvat doelen en beperkingen voor doorvoer, responstijden en toewijzing van middelen. Het is ook nodig om succescriteria voor het project 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 geen voldoende breed scala aan prestatiebenchmarks bevatten. Soms zijn er zelfs helemaal geen. Waar mogelijk is het vinden van een vergelijkbare applicatie om mee te vergelijken een goede manier om prestatiedoelen te bepalen.

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 gebruikssituaties. Het is noodzakelijk om een ​​verscheidenheid aan eindgebruikers te simuleren, prestatietestgegevens te plannen en te beschrijven welke meetwaarden zullen worden verzameld.

Stap 4) De testomgeving configureren

Bereid de testomgeving voor voordat u begint met testen. Zorg ook voor de benodigde tools en andere resources. Probeer de testomgeving zo goed mogelijk na te bootsen, zodat de testresultaten realistisch en bruikbaar zijn.

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) Analyseren, afstellen en opnieuw testen

Verzamel, analyseer en deel de testresultaten. Verfijn vervolgens de instellingen en test opnieuw om te zien of de prestaties verbeteren of verslechteren. Omdat de verbeteringen over het algemeen kleiner worden bij elke hertest, moet u stoppen wanneer de CPU de bottleneck vormt. In dat geval moet u mogelijk overwegen om de CPU-kracht te verhogen.

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 – De hoeveelheid fysiek geheugen die beschikbaar is voor processen op een computer.
• Schijftijd – De 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 – Het aantal bytes dat een proces heeft toegewezen en dat niet gedeeld kan worden met andere processen. Deze worden gebruikt om geheugenlekken en -gebruik te meten.
• Toegewijd geheugen – de hoeveelheid gebruikt virtueel geheugen.
• Geheugenpagina's/seconde – Het aantal pagina's dat naar de schijf is geschreven of ervan is gelezen om harde paginafouten op te lossen. Harde paginafouten treden op wanneer code die niet tot de huidige werkset behoort, van elders wordt aangeroepen en van de schijf wordt opgehaald.
• Paginafouten/seconde – De algehele snelheid waarmee foutpagina's door de processor worden verwerkt. Dit gebeurt wanneer een proces code nodig heeft die buiten de eigen werkset valt.
• CPU-onderbrekingen per seconde – Het gemiddelde aantal hardware-onderbrekingen dat een processor per seconde ontvangt en verwerkt.
• Lengte schijfwachtrij – Het gemiddelde aantal lees- en schrijfverzoeken dat in de wachtrij staat voor de geselecteerde schijf gedurende een bepaald meetinterval.
• Lengte netwerkuitvoerwachtrij – De lengte van de uitvoerpakketwachtrij in pakketten. Alles meer dan twee betekent een vertraging en knelpunten moeten worden verholpen.
• Totaal netwerkbytes per seconde – De snelheid waarmee bytes via de interface worden verzonden en ontvangen, inclusief framingtekens.
• Reactietijd - De tijd die verstrijkt tussen het moment dat een gebruiker een verzoek invoert en het moment dat het eerste teken van het antwoord wordt ontvangen.
• Doorvoer - De 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 betrekking op 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 – Het aantal hits op een webserver per seconde tijdens 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 – Er wordt gemonitord om te bepalen welke wachttijden kunnen worden verkort bij het optimaliseren van de snelheid waarmee gegevens uit het geheugen worden opgehaald.
• Draadaantallen – De gezondheid van een applicatie kan worden gemeten aan de hand van het aantal threads dat actief is.
• Afvalinzameling – Dit houdt in dat ongebruikt geheugen wordt teruggegeven aan het systeem. De efficiëntie van de garbage collection moet worden gecontroleerd.

Prestatietesten Voorbeeld van testgevallen

Hieronder volgen voorbeelden van testcases voor prestatietests:

• Testgeval 01: Controleer of de reactietijd niet langer is dan 4 seconden wanneer 1000 gebruikers tegelijkertijd de website bezoeken.
• Testgeval 02: Controleer of de reactietijd van de applicatie onder belasting binnen een acceptabel bereik ligt wanneer 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.

Best practices voor prestatietesten

Door de vastgestelde beste werkwijzen te volgen, wordt ervoor gezorgd dat prestatietests betrouwbare resultaten opleveren. Deze richtlijnen helpen teams veelvoorkomende valkuilen te vermijden.

• De productieomgeving nabootsen – Configureer uw testopstelling zo dat deze de productieomgeving zo goed mogelijk nabootst. Verschillen in hardware- of softwareversies kunnen namelijk tot misleidende resultaten leiden.
• Ontwerp realistische testscenario's – Ontwikkel testgevallen die het daadwerkelijke gebruikersgedrag simuleren, inclusief denktijden en gelijktijdige transactiemixen.
• Gebruik op percentielen gebaseerde meetwaarden – Gebruik de responstijden van het 90e en 95e percentiel in plaats van alleen gemiddelden. Percentielen brengen vertragingen aan het licht die gemiddelden kunnen verbergen.
• Test vroeg en continu – Integreer prestatietests in de CI/CD-pipeline in plaats van ze als een activiteit in de laatste fase te beschouwen.
• Documenteer en bepaal de basisresultaten – Leg de resultaten van elke testrun vast. Door nieuwe resultaten te vergelijken met de basislijn, kunnen regressies tussen releases eenvoudig worden opgespoord.

Hoe AI prestatietesten transformeert

Kunstmatige intelligentie is reshaping Prestatietesten door complexe analysetaken te automatiseren en voorspellende mogelijkheden te bieden. AI-gestuurde tools analyseren historische gegevens, detecteren patronen en geven bruikbare aanbevelingen zonder dat menselijke tussenkomst bij elke stap nodig is.

• Voorspellende anomaliedetectie – AI-algoritmen analyseren realtime prestatiegegevens tijdens belastingstests en signaleren afwijkingen voordat deze escaleren tot kritieke storingen.
• Geautomatiseerde oorzaakanalyse – AI-gestuurde tools correleren gegevens uit gedistribueerde systemen om de exacte componenten te identificeren die prestatievermindering veroorzaken.
• Intelligente testoptimalisatie – Machine learning-modellen identificeren redundante testscenario's en stellen optimale configuraties voor, waardoor de uitvoeringstijd wordt verkort en de testdekking behouden blijft.
• Zelfherstellende testscripts – AI past testscripts aan wanneer applicatie-interfaces veranderen, waardoor de onderhoudskosten voor prestatietestsuites worden verlaagd.

Tools voor het testen van prestaties

Er is een breed scala aan tools voor prestatietesten beschikbaar. De tool die u kiest voor het testen, hangt af van vele factoren, zoals de ondersteunde protocoltypen, licentiekosten, hardwarevereisten en platformondersteuning. Hieronder vindt u een lijst met veelgebruikte testtools.

• HP LoadRunner - is een van de populairste tools voor prestatietesten op de markt. Deze tool kan honderdduizenden gebruikers simuleren, waardoor applicaties onder realistische belasting worden geplaatst om hun gedrag onder verwachte omstandigheden te bepalen. LoadRunner beschikt over een virtuele gebruikersgenerator die de handelingen van echte menselijke gebruikers simuleert.
• JMeter - Een van de meest gebruikte open-source tools voor het uitvoeren van belastingstests op web- en applicatieservers. Het ondersteunt meerdere protocollen en biedt uitgebreide rapportagemogelijkheden.

Veelgestelde vragen