Vad är skalbarhetstestning? Lär dig med exempel
Thomas Hamilton
⚡ Smart sammanfattning
Skalbarhetstestning mäter hur en applikation beter sig när användarbelastning, datavolym eller transaktionshastighet ökar eller minskar, vilket avslöjar den exakta punkten där prestandan slutar skalas och identifierar den ansvariga flaskhalsen.
Vad är skalbarhetstestning?
Skalbarhetstestning är en icke-funktionell testmetod som mäter prestandan hos ett system eller nätverk när antalet användarförfrågningar skalas upp eller ner. Syftet med skalbarhetstestning är att säkerställa att systemet kan hantera en förväntad ökning av användartrafik, datavolym och transaktionsfrekvens. Det testar systemets förmåga att möta den växande efterfrågan.
Skalbarhetstestning är en undertyp av prestandatester, så den fokuserar på en applikations beteende när den distribueras till ett större system eller används under överbelastning. MjukvaruutvecklingSkalbarhetstestning mäter den punkt då en applikation slutar skala och identifierar orsaken bakom det.
Varför utföra skalbarhetstestning?
Kapacitetsproblem uppstår sällan under funktionstestning. De dyker upp under årets mest hektiska handelsdag, när en marknadsföringskampanj släpps, eller när en datamängd som vuxit tyst i två år slutligen saktar ner varje fråga. Skalbarhetstestning exponerar först dessa begränsningar i en kontrollerad miljö. Mer specifikt hjälper det dig att:
- Bestäm hur applikationen skalas när arbetsbelastningen ökar och var kurvan planar ut.
- Bestäm gränsen för samtidiga användare för webbapplikationen innan svarstiderna blir oacceptabla.
- Fastställ försämring på klientsidan och slutanvändarupplevelsen under belastning, såsom långsam skärmrendering.
- Bestäm serversidans robusthet och försämring, inklusive CPU-mättnad, minnesläckor och utmattning av anslutningspoolen.
Sambandet är enklast att föreställa sig som en kurva: genomströmningen ökar i takt med ökad belastning tills en resurs mättas, varefter extra användare bara förlänger kön.
Typer av skalbarhetstestning
Skalbarhet är inte en enskild egenskap, så en testplan täcker vanligtvis mer än en dimension. De fyra typerna nedan är de som de flesta team mäter, och de två första avgör själva testmiljöns form.
| Typ | Vad som är skalat | Vad testet bevisar |
|---|---|---|
| Vertikal skalbarhet (uppskala) | CPU, minne eller lagring tillagd till en enda server | Hur mycket extra belastning en uppgraderad maskin absorberar, och var taket för en enda nod sitter |
| Horisontell skalbarhet (skala ut) | Ytterligare servrar, containrar eller noder bakom en lastbalanserare | Huruvida dataflödet ökar ungefär i proportion till antalet noder som läggs till, eller om delade resurser begränsar det |
| Funktionell skalbarhet | Nya funktioner, moduler eller tjänster | Huruvida tillagd funktionalitet kan absorberas utan att försämra befintliga transaktioner |
| Administrativ skalbarhet | Användare, hyresgäster, team eller miljöer att hantera | Huruvida onboarding, behörigheter och övervakning fortsätter att fungera allt eftersom organisationen växer |
Vertikal skalning är enklare eftersom arkitekturen sällan ändras, men en enskild maskin har alltid ett tak. Horisontell skalning tar bort det taket och förbättrar feltoleransen, på bekostnad av nätverkslatens, datakonsistens och koordinationskostnader – allt detta måste testet mäta snarare än anta.
Vad man ska testa vid skalbarhetstestning
Skalbarhet bedöms utifrån mätningar, inte visningar. Registrera följande attribut vid varje laddningssteg så att trenden, och inte bara det slutliga talet, är synlig.
| Attribut | Vad det säger dig |
|---|---|
| Svarstid | Tid mellan en användarförfrågan och systemsvaret; den bör förbli oförändrad allt eftersom samtidigheten ökar |
| Skärmövergång | Hur snabbt en sida eller vy ger vika för nästa under belastning |
| genomströmning | Volym av bearbetade förfrågningar per tidsenhet; en platå markerar skalbarhetsgränsen |
| Tidsmätningar | Sessionstid, omstartstid, utskriftstid, transaktionstid och körningstid för uppgifter |
| Prestanda jämfört med användarantal | Hur varje mätvärde förändras när samtidiga användare läggs till i steg |
| Begär priser | Förfrågningar per sekund, transaktioner per sekund och träffar per sekund |
| Nätverksanvändning | Bandbredd som förbrukas och paketfördröjning mellan nivåer |
| CPU- och minnesanvändning | Resurskostnad per transaktion; en stadigt stigande siffra signalerar ofta en läcka |
| Webbserverräknare | Förfrågningar och svar per sekund, ködjup och avvisade anslutningar |
| Prestanda under belastning | Kombinerat beteende när varje mätvärde läses tillsammans vid topp |
Teststrategi för skalbarhetstestning
Teststrategin för skalbarhetstestning skiljer sig åt beroende på vilken typ av applikation som testas. Om en applikation ansluter till en databas, testparametrarna kommer att inkludera databasens storlek i förhållande till antalet användare, och så vidare.
Förutsättningar för skalbarhetstestning
- Lastfördelningsförmåga — Kontrollera om lasttestverktyget gör det möjligt att generera lasten från flera maskiner och styra den från en central punkt.
- Operating System — Kontrollera vad operativsystem lastgenereringsagenterna och lasttestmastern körs under.
- Processorn — Kontrollera vilken typ av CPU som krävs för den virtuella användaragenten och belastningstestmastern.
- Minne — Kontrollera hur mycket minne som skulle räcka för den virtuella användaragenten och ladda testmastern.
- Testmiljö — Kontrollera att testmiljö speglar produktionen tillräckligt noggrant för att resultaten ska kunna överföras.
Hur man gör skalbarhetstestning
- Definiera en repeterbar process för att utföra skalbarhetstester under hela applikationens livscykel
- Bestäm kriterierna för skalbarhet
- Lista de programvaruverktyg som krävs för att köra belastningstestet
- Ställ in testmiljön och konfigurera den hårdvara som krävs för att utföra skalbarhetstester
- Planera testscenarier såväl som skalbarhetstester
- Skapa och verifiera det virtuella användarskriptet
- Skapa och verifiera belastningstestscenarierna
- Utför testerna
- Utvärdera resultaten
- Generera de rapporter som krävs
Skalbarhetstestplan
Innan du faktiskt skapar testerna, utveckla en detaljerad testplan. Det är ett viktigt steg för att säkerställa att testet uppfyller applikationskraven.
Följande är attributen för att skapa en väldefinierad Testplan för skalbarhetstestning.
- Steg för skriptTestskriptet bör ha detaljerade steg som avgör exakt vilka åtgärder en användare skulle utföra.
- Run-Time DataTestplanen bör fastställa eventuella körtidsdata som krävs för att interagera med applikationen.
- Datadrivna testerOm skripten behöver varierande data vid körning behöver du förståelse för alla fält som kräver dessa data.
Exempel på skalbarhetstestning
Tänk dig en webbutik som förväntar sig 2 000 samtidiga kunder under en säsongsrea. Teamet kommer först överens om ett godkänt kriterium: kassatransaktionen måste slutföras på under tre sekunder för 95 procent av användarna, med en felfrekvens under en procent.
Testet kör sedan samma browse-search-cart-checkout-skript vid 250, 500, 1 000, 1 500 och 2 000 virtuella användare. Svarstiden är nästan två sekunder upp till 1 000 användare, sjunker till 2.8 sekunder vid 1 500 och når nio sekunder vid 2 000 medan databasens CPU ligger på 98 procent. Skalbarhetsgränsen är därför ungefär 1 500 användare, och flaskhalsen är databasnivån – inte de applikationsservrar som teamet hade planerat att lägga till.
Verktyg för skalbarhetstestning
Skalbarhetstestning behöver ett verktyg som kan generera belastning från flera maskiner samtidigt och rapportera resultat centralt. Valet följer vanligtvis teamets primära språk och de protokoll som testas.
| Verktyget | scripting | Passar bäst till |
|---|---|---|
| Apache JMeter | GUI plus XML-testplaner, Java baserat | Bred protokolltäckning inklusive JDBC, JMS, LDAP och SOAP |
| Grafana k6 | JavaManus eller TypeScript | API- och mikrotjänsttester kopplade till en CI/CD-pipeline |
| gatling | Java, Kotlin eller Scala DSL | Högt antal virtuella användare per injektor med detaljerade HTML-rapporter |
| Gräshoppa | Enkel Python | Python team som behöver utöka klienten bortom HTTP |
| LoadRunner | C-liknande skript inspelade i VuGen | Stora företagsanläggningar med äldre och paketerade applikationer |
Molnbaserade löpare som t.ex. BlazeMeter, LoadView och Gatling Enterprise ligger ovanpå flera av dessa motorer och är värda att överväga när ett test behöver tiotusentals virtuella användare eller trafik från flera geografiska regioner. En bredare översikt över kategorin finns i guiden till verktyg för prestandatestning.
Utmaningar och bästa praxis inom skalbarhetstestning
De mest nedslående skalbarhetsresultaten tracTillbaka till testuppställningen snarare än applikationen. Det är dessa problem som återkommer och vanorna som förhindrar dem.
Vanliga utmaningar
- Underdimensionerade miljöer — En testrigg med hälften av produktionsminnet rapporterar en flaskhals som inte finns i produktionen.
- Orealistiska arbetsbelastningsmodeller — Skript utan betänketid eller datavariation träffar cacher som riktiga användare skulle missa.
- Bullriga resultat — Automatisk skalning, sophämtning och delad molnhårdvara gör att två identiska körningar inte överensstämmer.
- Tunn observerbarhet — Utan serversidesmätvärden visar ett långsamt resultat att något gick sönder, men inte vad.
- Pris — Att generera mycket hög samtidighet kräver en egen flotta av lastgeneratorer, vilket är lätt att underbudgetera.
Bästa praxis
- Kom överens om kriterierna för godkänt resultat, såsom en percentil för svarstid och ett tak för felfrekvens, före första körningen.
- Öka belastningen i planerade steg och håll varje steg tillräckligt länge för att systemet ska stabilisera sig.
- Variera testdata per virtuell användare så att cachning inte misslyckas med resultaten.
- Samla in applikations-, databas- och infrastrukturstatistik tillsammans med klientsidans siffror.
- Lagra testskript i versionshantering och kör en kort skalbarhetskontroll på varje version, sedan en fullständig körning innan lansering.
- Jämför trender mellan olika versioner snarare än att bedöma en enskild rapport isolerat.
Skalbarhetstestning kontra belastningstestning
De två förväxlas ofta eftersom båda tillämpar belastning. Skillnaden ligger i frågan som var och en besvarar: Skalbarhetstestning frågar hur mycket systemet kan växa, medan belastningstestning frågar om den klarar den redan förväntade belastningen.
| Bas | Skalbarhetstestning | Lasttestning |
|---|---|---|
| Fokus | Den fokuserar på prestandan hos dina webbplatser, programvara, hårdvara och applikationer när ändringar görs i systemets storlek eller volym för att möta ett växande behov. | Lasttestning fokuserar på att testa en applikation under tung belastning för att avgöra vid vilken tidpunkt systemets svarstid misslyckas. |
| Lastmönster | Belastningen höjs i steg, och resurser kan läggas till mellan stegen. | Lasten hålls vid en förväntad topp under en fastställd tid |
| Fråga besvarad | Hur långt kan detta system växa, och vad begränsar det? | Uppfyller detta system de överenskomna målen idag? |
| Typisk utgång | En skalbarhetsgräns, en flaskhals och en kapacitetsplan | Godkänt eller misslyckat mot mål för svarstid och dataflöde |
Båda sitter under icke-funktionell testning paraply bredvid stresstestning, spiktestning, uthållighetstestning och volymtestning, och en mogen prestationsstrategi kör vanligtvis flera av dem mot samma skript.
