Zelfstudie over prestatietests: wat is, typen, metrische gegevens & Voorbeeld

Prestatietests

Prestatietesten is een softwaretestproces dat wordt gebruikt voor het testen van de snelheid, responstijd, stabiliteit, betrouwbaarheid, schaalbaarheid en resourcegebruik van een softwareapplicatie onder een bepaalde werkbelasting. 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 Testing".

De focus van Performance Testing is het controleren van softwareprogramma's

• 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

In deze tutorial leer je-

• Wat is prestatietesten?
• Waarom prestatietests uitvoeren?
• Soorten prestatietests
• Veelvoorkomende prestatieproblemen
• Prestatietestproces
• Prestatieteststatistieken: bewaakte parameters
• Voorbeeld van prestatietestgevallen
• Tools voor prestatietests
• FAQ

Waarom prestatietests uitvoeren?

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

Prestatietests worden uitgevoerd om belanghebbenden informatie te geven over hun toepassing met betrekking tot snelheid, stabiliteit en schaalbaarheid. Wat nog belangrijker is: Performance Testing legt uit wat er verbeterd moet worden voordat het product op de markt komt. Zonder prestatietests zal software waarschijnlijk last hebben van problemen zoals: traag werken terwijl meerdere gebruikers het tegelijkertijd gebruiken, inconsistenties tussen verschillende besturingssystemen en slechte bruikbaarheid.

Prestatietests zullen bepalen of hun software voldoet aan de vereisten voor snelheid, schaalbaarheid en stabiliteit onder verwachte workloads. Applicaties die naar de markt worden gestuurd met slechte prestatiestatistieken als gevolg van niet-bestaande of slechte prestatietests, krijgen waarschijnlijk een slechte reputatie en voldoen niet aan de verwachte verkoopdoelen.

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

Volgens Dunn & Bradstreet ervaart 59% van de Fortune 500-bedrijven wekelijks naar schatting 1,6 uur downtime. Als je bedenkt dat het gemiddelde Fortune 500-bedrijf met minimaal 10.000 werknemers $ 56 per uur betaalt, zou het arbeidsdeel van de downtime-kosten voor zo'n organisatie $ 896.000 per week bedragen, wat zich vertaalt in meer dan $ 46 miljoen per jaar.

Slechts 5 minuten downtime van Google.com (19 aug. 13) kost de zoekgigant naar schatting maar liefst $ 545.000.

Naar schatting hebben bedrijven een omzet van $ 1100 per seconde verloren als gevolg van een recente Amazon Web Service-storing.

Daarom zijn prestatietests belangrijk.

Soorten prestatietests

• Load testing - controleert het vermogen van de applicatie om te presteren onder de verwachte gebruikersbelasting. Het doel is om knelpunten in de prestaties te identificeren voordat de softwareapplicatie live gaat.
• Stresstests - omvat het testen van een applicatie onder extreme belasting om te zien hoe deze omgaat met veel verkeer of gegevensverwerking. Het doel is om het breekpunt van een applicatie te identificeren.
• Duurzaamheidstests - worden 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.
• Volumetest - Onder Volumetest groot nr. van. De gegevens worden in een database gevuld en het algemene gedrag van het softwaresysteem wordt gecontroleerd. Het doel is om de prestaties van de softwareapplicatie bij verschillende databasevolumes te controleren.
• Schaalbaarheidstests - 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, reactietijd, laadtijd en slechte schaalbaarheid. Snelheid is vaak een van de belangrijkste kenmerken van een applicatie. Een traag draaiende applicatie zal potentiële gebruikers verliezen. Prestatietests worden uitgevoerd om ervoor te zorgen dat een app snel genoeg werkt om de aandacht en interesse van een gebruiker vast te houden. Bekijk de volgende lijst met veelvoorkomende prestatieproblemen en merk op dat snelheid bij veel problemen een gemeenschappelijke factor is:

• Lange laadtijd - Laadtijd is normaal gesproken de eerste keer dat een toepassing nodig heeft om te starten. Dit moet over het algemeen tot een minimum worden beperkt. Hoewel het voor sommige toepassingen onmogelijk is om binnen een minuut te laden, moet de laadtijd indien mogelijk onder een paar seconden worden gehouden.
• Slechte responstijd - Reactietijd is de tijd die nodig is vanaf het moment dat een gebruiker gegevens in de applicatie invoert totdat de applicatie een reactie op die invoer uitvoert. Over het algemeen zou dit erg snel moeten zijn. Nogmaals, als een gebruiker te lang moet wachten, verliest hij zijn interesse.
• Slechte schaalbaarheid - Een softwareproduct lijdt aan een slechte schaalbaarheid wanneer het het verwachte aantal gebruikers niet aankan of wanneer het niet geschikt is voor een voldoende breed scala aan gebruikers. Er moeten belastingtests worden uitgevoerd om er zeker van te zijn dat de toepassing het verwachte aantal gebruikers aankan.
• Knelpunten - Knelpunten zijn obstakels in een systeem die de algehele systeemprestaties verslechteren. Een knelpunt is wanneer codeerfouten of hardwareproblemen een afname van de doorvoer veroorzaken onder bepaalde belastingen. Knelpunten worden vaak veroorzaakt door een defect gedeelte van de code. De sleutel tot het oplossen van een knelpunt is het vinden van het gedeelte van de code dat de vertraging veroorzaakt en proberen het daar op te lossen. Knelpunten worden over het algemeen verholpen door slecht lopende processen te verhelpen of door extra hardware toe te voegen. Enkele veelvoorkomende knelpunten in de prestaties zijn
  • CPU-gebruik
  • Geheugengebruik
  • Netwerkgebruik
  • Beperkingen van het besturingssysteem
  • Schijfgebruik

Prestatietestproces

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

Hieronder vindt u een algemeen proces voor het uitvoeren van prestatietests

1. Identificeer uw testomgeving - Ken uw fysieke testomgeving, productieomgeving en welke testtools beschikbaar zijn. Begrijp de details van de hardware, software en netwerkconfiguraties die tijdens het testen zijn gebruikt voordat u met het testproces begint. Het helpt testers om efficiëntere tests te maken. Het helpt ook bij het identificeren van mogelijke uitdagingen die testers kunnen tegenkomen tijdens de prestatietestprocedures.
2. Identificeer de prestatie-acceptatiecriteria - Dit omvat doelen en beperkingen voor doorvoer, reactietijden en toewijzing van middelen. Het is ook nodig om criteria voor het succes van projecten te identificeren buiten deze doelen en beperkingen. Testers moeten de bevoegdheid krijgen om prestatiecriteria en doelen vast te stellen, omdat de projectspecificaties vaak niet een voldoende grote verscheidenheid aan prestatiebenchmarks bevatten. Soms is er helemaal geen. Indien mogelijk is het vinden van een vergelijkbare applicatie om mee te vergelijken een goede manier om prestatiedoelen vast te stellen.
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.
4. Configureren van de testomgeving - Bereid de testomgeving voor voordat deze wordt uitgevoerd. Regel ook tools en andere bronnen.
5. Testontwerp implementeren - Maak de prestatietests volgens uw testontwerp.
6. Voer de tests uit - Voer de tests uit en controleer deze.
7. Analyseer, stem af en test opnieuw - Consolideer, analyseer en deel testresultaten. Stem vervolgens af en test opnieuw om te zien of de prestaties verbeteren of afnemen. Aangezien verbeteringen over het algemeen kleiner worden bij elke nieuwe test, moet u stoppen wanneer bottlenecking wordt veroorzaakt door de CPU. Dan kunt u de optie overwegen om het CPU-vermogen te vergroten.

Prestatieteststatistieken: bewaakte parameters

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

• Processorgebruik - een 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 - de 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 dat niet kan worden gedeeld met andere processen. Deze worden gebruikt om geheugenlekken en -gebruik te meten.
• Toegewezen geheugen - hoeveelheid gebruikt virtueel geheugen.
• Geheugenpagina's / seconde - aantal pagina's geschreven naar of gelezen van de schijf om fouten op de harde pagina op te lossen. Fouten op harde pagina's zijn wanneer code die niet uit de huidige werkset komt ergens anders vandaan wordt opgeroepen en van een schijf wordt opgehaald.
• Paginafouten / seconde - de algehele snelheid waarmee foutpagina's door de processor worden verwerkt. Dit gebeurt weer wanneer een proces code van buiten de werkset nodig heeft.
• CPU-onderbrekingen per seconde - is de gem. aantal hardware-interrupts dat een processor elke seconde ontvangt en verwerkt.
• Lengte schijfwachtrij - is de gem. Nee. van lees- en schrijfverzoeken in de wachtrij voor de geselecteerde schijf tijdens een steekproefinterval.
• Lengte van netwerkuitvoerwachtrij - lengte van de uitvoerpakketwachtrij in pakketten. Alles meer dan twee betekent vertraging en knelpunten moeten worden gestopt.
• Netwerkbytes totaal per seconde - snelheid welke bytes worden verzonden en ontvangen op de interface, inclusief frametekens.
• Reactietijd - tijd vanaf het moment dat een gebruiker een verzoek invoert totdat het eerste teken van het antwoord is ontvangen.
• Doorvoersnelheid - een computer of netwerk ontvangt verzoeken per seconde.
• Hoeveelheid pooling van verbindingen - het aantal gebruikersverzoeken waaraan wordt voldaan door gepoolde verbindingen. Hoe meer aanvragen worden beantwoord door verbindingen in de pool, hoe beter de prestaties zullen zijn.
• Maximale actieve sessies - het maximale aantal sessies dat tegelijkertijd actief kan zijn.
• Hitratio's - Dit heeft te maken met het aantal SQL-instructies dat wordt afgehandeld door gegevens in de cache in plaats van dure I / O-bewerkingen. Dit is een goede plek om te beginnen om knelpunten op te lossen.
• Hits per seconde - de nee. aantal hits op een webserver tijdens elke seconde van een laadtest.
• Rollback-segment - de hoeveelheid gegevens die op elk moment in de tijd kan worden teruggedraaid.
• Databasevergrendelingen - het vergrendelen van tabellen en databases moet worden gecontroleerd en zorgvuldig worden afgestemd.
• Top wacht - worden gecontroleerd om te bepalen welke wachttijden kunnen worden verkort bij het omgaan met de snelheid waarmee gegevens uit het geheugen worden opgehaald
• Thread counts - De gezondheid van een applicatie kan worden gemeten aan de hand van de no. van threads die actief zijn en momenteel actief zijn.
• Garbage collection - Het heeft te maken met het terugsturen van ongebruikt geheugen naar het systeem. Garbage collection moet worden gecontroleerd op efficiëntie.

Voorbeeld van prestatietestgevallen

• Controleer of de responstijd niet meer dan 4 seconden bedraagt ​​wanneer 1000 gebruikers tegelijkertijd toegang hebben tot de website.
• Controleer of de responstijd van de toepassing onder belasting binnen een acceptabel bereik ligt wanneer de netwerkverbinding traag is
• Controleer het maximale aantal gebruikers dat de applicatie aankan voordat deze crasht.
• Controleer de uitvoeringstijd van de database wanneer 500 records tegelijkertijd worden gelezen / geschreven.
• Controleer het CPU- en geheugengebruik van de applicatie en de databaseserver onder piekbelasting
• Controleer de responstijd van de applicatie 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 cijfers. Prestatie-ingenieurs stellen deze cijfers in volgens de zakelijke vereisten en het technische landschap van de applicatie.

Tools voor prestatietests

Er is een breed scala aan prestatietesttools op de markt beschikbaar. De tool die u kiest om te testen, is afhankelijk van vele factoren, zoals typen protocol dat wordt ondersteund, licentiekosten, hardwarevereisten, platformondersteuning enz. Hieronder vindt u een lijst met veelgebruikte testtools.

• LoadNinja - revolutioneert de manier waarop we testen laden. Deze cloudgebaseerde loadtesttool stelt teams in staat om uitgebreide loadtests op te nemen en direct af te spelen, zonder complexe dynamische correlatie, en deze loadtests op schaal in echte browsers uit te voeren. Teams kunnen de testdekking vergroten. & verkort de testtijd van de belasting met meer dan 60%.
• NeoLoad - is het prestatietestplatform ontworpen voor DevOps dat naadloos kan worden geïntegreerd in uw bestaande Continuous Delivery-pijplijn. Met NeoLoad testen teams 10x sneller dan met traditionele tools om te voldoen aan het nieuwe niveau van vereisten gedurende de volledige Agile-softwareontwikkelingscyclus - van component- tot volledige systeembrede belastingtests.
• HP LoadRunner - zijn de meest populaire tools voor prestatietesten die momenteel op de markt zijn. Deze tool is in staat honderdduizenden gebruikers te simuleren, waardoor applicaties in de praktijk worden belast om hun gedrag onder verwachte belasting te bepalen. Loadrunner beschikt over een virtuele gebruikersgenerator die de acties van levende menselijke gebruikers simuleert.
• Jmeter - een van de toonaangevende tools die wordt gebruikt voor het testen van web- en applicatieservers.

FAQ

Welke applicaties moeten we prestatietesten?

Prestatietests worden altijd alleen uitgevoerd voor client-server-gebaseerde systemen. Dit betekent dat elke toepassing die geen client-servergebaseerde architectuur is, geen prestatietests nodig heeft.

Microsoft Calculator is bijvoorbeeld niet client-server-gebaseerd en heeft ook geen toegang tot meerdere gebruikers; daarom is het geen kandidaat voor prestatietests.

Wat is het verschil tussen Performance Testing & Performance Engineering

Het is belangrijk om het verschil te begrijpen tussen Performance Testing en Performance Engineering. Een begrip wordt hieronder gedeeld:

Performance Testing is een discipline die zich bezighoudt met het testen en rapporteren van de huidige prestaties van een softwareapplicatie onder verschillende parameters.

Performance engineering is het proces waarmee software wordt getest en afgestemd met de bedoeling de vereiste prestaties te realiseren. Dit proces is bedoeld om de belangrijkste eigenschap van de applicatieprestaties, namelijk de gebruikerservaring, te optimaliseren.

Historisch gezien waren testen en afstemmen duidelijk gescheiden en vaak concurrerende domeinen. In de afgelopen jaren hebben verschillende groepen testers en ontwikkelaars echter onafhankelijk samengewerkt om afstemmingsteams te creëren. Omdat deze teams aanzienlijk succes hebben geboekt, is het concept van het koppelen van prestatietests met prestatieafstemming aangeslagen, en nu noemen we het prestatie-engineering.

Gevolgtrekking

Bij Software Engineering zijn prestatietests nodig 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 meestal meer dan goedgemaakt door verbeterde klanttevredenheid, loyaliteit en retentie.