Wat is schaalbaarheidstesten? Leer met voorbeeld
Thomas Hamilton
⚡ Slimme samenvatting
Schaalbaarheidstesten meten hoe een applicatie zich gedraagt wanneer de gebruikersbelasting, het datavolume of de transactiesnelheid toe- of afneemt. Dit onthult het exacte punt waarop de prestaties niet meer meeschalen en identificeert het verantwoordelijke knelpunt.
Wat is schaalbaarheidstesten?
Schaalbaarheid testen Schaalbaarheidstesten zijn een niet-functionele testmethode die de prestaties van een systeem of netwerk meet wanneer het aantal gebruikersverzoeken wordt op- of afgeschaald. Het doel van schaalbaarheidstesten is ervoor te zorgen dat het systeem een verwachte toename in gebruikersverkeer, datavolume en transactiefrequentie aankan. Het test het vermogen van het systeem om aan een groeiende vraag te voldoen.
Schaalbaarheidstesten is een subtype van prestatie testenHet richt zich dus op het gedrag van een applicatie wanneer deze wordt ingezet in een groter systeem of wordt getest onder een hoge belasting. Software EngineeringSchaalbaarheidstesten meten het punt waarop een applicatie niet meer schaalbaar is en identificeren de oorzaak daarvan.
Waarom schaalbaarheidstesten uitvoeren?
Capaciteitsproblemen komen zelden aan het licht tijdens functionele tests. Ze duiken meestal op tijdens de drukste handelsdag van het jaar, bij de lancering van een marketingcampagne of wanneer een dataset die twee jaar lang ongemerkt is gegroeid, uiteindelijk elke query vertraagt. Schaalbaarheidstesten leggen deze beperkingen eerst bloot in een gecontroleerde omgeving. Concreet helpt het u bij:
- Bepaal hoe de applicatie schaalt naarmate de werklast toeneemt, en waar die curve afvlakt.
- Bepaal de limiet voor gelijktijdige gebruikers van de webapplicatie voordat de responstijden onacceptabel worden.
- Bepaal de prestatievermindering aan de clientzijde en de gebruikerservaring onder belasting, zoals trage schermweergave.
- Bepaal de robuustheid en degradatie aan de serverzijde, inclusief CPU-verzadiging, geheugenlekken en uitputting van de verbindingspool.
Het verband is het gemakkelijkst voor te stellen als een curve: de doorvoer neemt toe naarmate de belasting toeneemt, totdat een bron verzadigd raakt. Daarna zorgen extra gebruikers er alleen maar voor dat de wachtrij langer wordt.
Soorten schaalbaarheidstesten
Schaalbaarheid is geen eendimensionale eigenschap, dus een testplan omvat meestal meer dan één aspect. De vier onderstaande typen worden door de meeste teams gemeten, en de eerste twee bepalen de vorm van de testomgeving zelf.
| Type | Wat is geschaald? | Wat de test bewijst |
|---|---|---|
| Verticale schaalbaarheid (opschalen) | CPU, geheugen of opslag toegevoegd aan één server. | Hoeveel extra belasting een geüpgrade machine absorbeert, en waar de maximale belasting voor een enkele node ligt. |
| Horizontale schaalbaarheid (uitschalen) | Extra servers, containers of knooppunten achter een load balancer | Of de doorvoer ruwweg evenredig toeneemt met het aantal toegevoegde knooppunten, of dat gedeelde resources de doorvoer beperken, is de vraag. |
| Functionele schaalbaarheid | Nieuwe functies, modules of diensten | Of de toegevoegde functionaliteit kan worden geïntegreerd zonder de bestaande transacties te verslechteren. |
| Administratieve schaalbaarheid | Gebruikers, huurders, teams of omgevingen die beheerd moeten worden | Of de onboarding, machtigingen en monitoring nog steeds werkbaar zijn naarmate de organisatie groeit. |
Verticale schaling is eenvoudiger omdat de architectuur zelden verandert, maar een enkele machine heeft altijd een maximumcapaciteit. Horizontale schaling heft die maximumcapaciteit op en verbetert de fouttolerantie, ten koste van netwerklatentie, gegevensconsistentie en coördinatiekosten – factoren die allemaal gemeten moeten worden in plaats van aangenomen.
Wat te testen bij schaalbaarheidstesten?
Schaalbaarheid wordt beoordeeld op basis van metingen, niet op impressies. Registreer de volgende kenmerken bij elke laadstap, zodat de trend, en niet alleen het eindresultaat, zichtbaar is.
| Kenmerk | Wat het je vertelt |
|---|---|
| Reactietijd | De tijd tussen een gebruikersverzoek en het systeemantwoord; deze moet constant blijven naarmate de gelijktijdigheid toeneemt. |
| Schermovergang | Hoe snel de ene pagina of weergave plaatsmaakt voor de volgende onder belasting |
| Doorvoer | Het aantal verwerkte verzoeken per tijdseenheid; een plateau markeert de schaalbaarheidslimiet. |
| Tijdmetingen | Sessietijd, herstarttijd, printtijd, transactietijd en taakuitvoeringstijd |
| Prestaties ten opzichte van het aantal gebruikers | Hoe elke meetwaarde verandert naarmate er stapsgewijs meer gelijktijdige gebruikers worden toegevoegd. |
| Tarieven opvragen | Verzoeken per seconde, transacties per seconde en hits per seconde |
| Netwerk gebruik | Verbruikte bandbreedte en pakketlatentie tussen lagen |
| CPU- en geheugengebruik | Resourcekosten per transactie; een gestaag stijgend cijfer duidt vaak op een lek. |
| Webservertellers | Verzoeken en reacties per seconde, wachtrijdiepte en geweigerde verbindingen |
| Prestaties onder belasting | Gecombineerd gedrag zodra alle meetwaarden op het hoogtepunt samen worden uitgelezen. |
Teststrategie voor schaalbaarheidstesten
De teststrategie voor schaalbaarheidstesten verschilt afhankelijk van het type applicatie dat wordt getest. Als een applicatie toegang heeft tot een databankDe testparameters zullen onder andere de grootte van de database in verhouding tot het aantal gebruikers omvatten.
Vereisten voor schaalbaarheidstests
- Capaciteit voor belastingverdeling — Controleer of de tool voor de belastingstest het mogelijk maakt om de belasting te genereren met meerdere machines en deze vanuit een centraal punt te beheren.
- Operating-systeem — Controleer wat besturingssystemen De load generation agents en de load test master draaien onder deze omstandigheden.
- Gegevensverwerker — Controleer welk type CPU vereist is voor de virtuele gebruikersagent en de loadtestmaster.
- Geheugen — Controleer hoeveel geheugen voldoende is voor de virtuele gebruikersagent en de loadtestmaster.
- Test omgeving — Controleer of de test omgeving Het productieproces wordt voldoende nagebootst om de resultaten overdraagbaar te maken.
Schaalbaarheidstesten uitvoeren
- Definieer een herhaalbaar proces voor het uitvoeren van schaalbaarheidstests gedurende de gehele levenscyclus van de applicatie.
- Bepaal de criteria voor schaalbaarheid
- Maak een shortlist van de softwaretools die nodig zijn om de belastingstest uit te voeren
- Stel de testomgeving in en configureer de hardware die nodig is om schaalbaarheidstests uit te voeren
- Plan de testscenario's en de schaalbaarheidstests.
- Maak en verifieer het script voor de virtuele gebruiker.
- Creëer en verifieer de belastingtestscenario's
- Voer de tests uit
- Evalueer de resultaten
- Genereer de vereiste rapporten.
Schaalbaarheidstestplan
Voordat je daadwerkelijk tests gaat maken, ontwikkel je een gedetailleerd testplan. Dit is een belangrijke stap om ervoor te zorgen dat de test voldoet aan de eisen van de applicatie.
Hieronder staan de kenmerken voor het maken van een goed gedefinieerde Testplan voor schaalbaarheidstesten.
- Stappen voor scriptsHet testscript moet gedetailleerde stappen bevatten die de exacte acties bepalen die een gebruiker zou uitvoeren.
- Runtime-gegevensHet testplan moet bepalen welke runtime-gegevens nodig zijn om met de applicatie te communiceren.
- Datagedreven testenAls de scripts tijdens de uitvoering wisselende gegevens nodig hebben, moet u inzicht hebben in alle velden die deze gegevens vereisen.
Voorbeeld van schaalbaarheidstesten
Stel je een webwinkel voor die tijdens een seizoensuitverkoop 2,000 gelijktijdige klanten verwacht. Het team spreekt eerst een criterium af: de transactie moet voor 95 procent van de gebruikers binnen drie seconden voltooid zijn, met een foutpercentage van minder dan één procent.
De test voert vervolgens hetzelfde browse-search-cart-checkout-script uit met 250, 500, 1,000, 1,500 en 2,000 virtuele gebruikers. De responstijd blijft rond de twee seconden tot 1,000 gebruikers, loopt op tot 2.8 seconden bij 1,500 en bereikt negen seconden bij 2,000, terwijl de CPU-belasting van de database 98 procent bedraagt. De schaalbaarheidslimiet ligt daarom ruwweg bij 1,500 gebruikers en de bottleneck zit in de databaselaag – niet in de applicatieservers die het team van plan was toe te voegen.
Schaalbaarheidstesttools
Voor schaalbaarheidstesten is een tool nodig die tegelijkertijd belasting kan genereren vanaf meerdere machines en de resultaten centraal kan rapporteren. De keuze hangt meestal af van de primaire programmeertaal van het team en de te testen protocollen.
| Gereedschap | Scripting | Het meest geschikt voor: |
|---|---|---|
| Apache JMeter | GUI plus XML-testplannen, Java gebaseerde | Brede protocolondersteuning, waaronder JDBC, JMS, LDAP en SOAP. |
| Grafana k6 | JavaScriptie of TypeScript | API- en microservicetests geïntegreerd in een CI/CD-pipeline. |
| Gatling | Java, Kotlin of Scala DSL | Hoog aantal virtuele gebruikers per injector met gedetailleerde HTML-rapporten |
| Sprinkhaan | Eenvoudig Python | Python teams die de client verder willen uitbreiden dan HTTP |
| LoadRunner | C-achtige scripts opgenomen in VuGen | Grote bedrijfsomgevingen met zowel verouderde als standaardapplicaties. |
Cloud-gehoste runners zoals BlazeMeterLoadView en Gatling Enterprise maken gebruik van verschillende van deze engines en zijn het overwegen waard wanneer een test tienduizenden virtuele gebruikers of verkeer uit meerdere geografische regio's vereist. Een uitgebreider overzicht van deze categorie is te vinden in de handleiding voor prestatietestinstrumenten.
Uitdagingen en beste praktijken bij schaalbaarheidstesten
Meest teleurstellende schaalbaarheidsresultaten tracWe gaan terug naar de testopstelling in plaats van naar de applicatie. Dit zijn de problemen die steeds terugkomen, en de gewoonten die ze voorkomen.
Gemeenschappelijke uitdagingen
- Ondermaatse omgevingen — Een testopstelling met de helft van het productiegeheugen meldt een knelpunt dat in de productieomgeving niet bestaat.
- Onrealistische werkbelastingsmodellen — Scripts zonder denktijd of variatie in gegevens maken gebruik van caches die echte gebruikers zouden missen.
- Ruisende resultaten — Door automatische schaling, garbage collection en gedeelde cloudhardware kunnen twee identieke uitvoeringen van elkaar verschillen.
- Dunne waarneembaarheid Zonder server-side metrics laat een traag resultaat zien dat er iets mis is gegaan, maar niet wat.
- Kosten — Het genereren van een zeer hoge gelijktijdigheid vereist een eigen vloot van loadgeneratoren, en het budget hiervoor kan gemakkelijk worden overschreden.
Beste praktijken
- Spreek vóór de eerste testronde de slaagcriteria af, zoals een responstijdpercentiel en een maximumfoutpercentage.
- Verhoog de belasting in geplande stappen en houd elke stap lang genoeg aan totdat het systeem zich stabiliseert.
- Varieer de testgegevens per virtuele gebruiker, zodat caching de resultaten niet vertekent.
- Verzamel naast de clientgegevens ook statistieken over de applicatie, de database en de infrastructuur.
- Bewaar testscripts in versiebeheer en voer bij elke build een korte schaalbaarheidstest uit, gevolgd door een volledige test vóór de release.
- Vergelijk trends over verschillende builds heen in plaats van één enkel rapport op zichzelf te beoordelen.
Schaalbaarheidstesten versus belastingstesten
De twee worden vaak door elkaar gehaald omdat ze allebei een belasting meten. Het verschil zit hem in de vraag die ze beantwoorden: schaalbaarheidstesten onderzoeken hoe ver het systeem kan groeien, terwijl schaalbaarheidstesten onderzoeken hoe ver het systeem kan groeien, terwijl schaalbaarheidstesten onderzoeken hoe ver het systeem kan groeien. belasting testen De vraag is of het de reeds verwachte belasting aankan.
| Basis | Schaalbaarheid testen | load Testen |
|---|---|---|
| Focus | Het richt zich op de prestaties van uw websites, software, hardware en applicaties wanneer er wijzigingen worden aangebracht in de omvang of het volume van het systeem om aan een groeiende behoefte te voldoen. | Bij belastingstesten wordt een applicatie getest onder zware belasting om te bepalen op welk punt de reactietijd van het systeem tekortschiet. |
| Belastingspatroon | De belasting wordt stapsgewijs verhoogd en tussen de stappen kunnen extra resources worden toegevoegd. | De belasting wordt gedurende een vaste tijd op een verwachte piekwaarde gehouden. |
| Vraag beantwoord | Hoe ver kan dit systeem groeien, en wat zijn de beperkingen ervan? | Voldoet dit systeem vandaag de dag aan de afgesproken doelstellingen? |
| Typische output | Een schaalbaarheidslimiet, een knelpunt en een capaciteitsplan. | Een beoordeling van de responstijd en doorvoersnelheid (geslaagd of niet geslaagd). |
Beide zitten onder de niet-functionele testen paraplu ernaast stresstests, piektesten, duurtesten en volumetestenEn een volwaardige prestatiestrategie voert doorgaans meerdere van deze tests uit op dezelfde scripts.
