Hva er skalerbarhetstesting? Lær med eksempel

Hva er skalerbarhetstesting?

Skalerbarhetstesting er en ikke-funksjonell testmetode som måler ytelsen til et system eller nettverk når antallet brukerforespørsler skaleres opp eller ned. Formålet med skalerbarhetstesting er å sikre at systemet kan håndtere en anslått økning i brukertrafikk, datavolum og transaksjonsfrekvens. Den tester systemets evne til å møte økende etterspørsel.

Skalerbarhetstesting er en undertype av ytelsestesting, så den konsentrerer seg om oppførselen til en applikasjon når den distribueres til et større system eller trenes under overbelastning. Engineering programvareSkalerbarhetstesting måler punktet der en applikasjon slutter å skalere og identifiserer årsaken bak dette.

Hvorfor skalerbarhetstesting?

Kapasitetsproblemer oppstår sjelden under funksjonstesting. De dukker opp på årets travleste handelsdag, når en markedsføringskampanje starter, eller når et datasett som har vokst stille i to år endelig bremser alle spørringer. Skalerbarhetstesting avdekker først disse begrensningene i et kontrollert miljø. Mer spesifikt hjelper det deg med å:

• Bestem hvordan applikasjonen skaleres etter hvert som arbeidsmengden øker, og hvor kurven flater ut.
• Bestem grensen for samtidige brukere for webapplikasjonen før responstidene blir uakseptable.
• Bestem forringelse på klientsiden og sluttbrukeropplevelsen under belastning, for eksempel treg skjermgjengivelse.
• Bestem robusthet og degradering på serversiden, inkludert CPU-metning, minnelekkasjer og uttømming av tilkoblingspoolen.

Forholdet er enklest å se for seg som en kurve: gjennomstrømningen øker i takt med økt belastning inntil en ressurs mettes, hvoretter ekstra brukere bare forlenger køen.

Typer skalerbarhetstesting

Skalerbarhet er ikke en enkelt egenskap, så en testplan dekker vanligvis mer enn én dimensjon. De fire typene nedenfor er de som de fleste team måler, og de to første bestemmer formen på selve testmiljøet.

Vertikal skalering er enklere fordi arkitekturen sjelden endres, men en enkelt maskin har alltid et tak. Horisontal skalering fjerner dette taket og forbedrer feiltoleransen, på bekostning av nettverkslatens, datakonsistens og koordineringsoverhead – alt dette må testen måle i stedet for å anta.

Hva du skal teste i skalerbarhetstesting

Skalerbarhet vurderes ut fra målinger, ikke visninger. Registrer følgende attributter ved hvert innlastingstrinn, slik at trenden, og ikke bare det endelige tallet, er synlig.

Teststrategi for skalerbarhetstesting

Teststrategien for skalerbarhetstesting varierer avhengig av hvilken type applikasjon som testes. Hvis en applikasjon får tilgang til en database, vil testparametrene inkludere størrelsen på databasen i forhold til antall brukere, og så videre.

Forutsetninger for skalerbarhetstesting

• Lastdistribusjonsevne — Sjekk om lasttestverktøyet gjør det mulig å generere lasten fra flere maskiner og styre den fra et sentralt punkt.
• Operating System – Sjekk hva operativsystemer Lastgenereringsagentene og lasttestmasteren kjører under.
• prosessor — Sjekk hvilken type CPU som kreves for den virtuelle brukeragenten og lasttestmasteren.
• Minne — Sjekk hvor mye minne som er nok for den virtuelle brukeragenten og last inn testmasteren.
• Test miljø — Sjekk at test miljø speiler produksjonen godt nok til at resultatene kan overføres.

Slik gjør du skalerbarhetstesting

1. Definer en repeterbar prosess for å utføre skalerbarhetstester gjennom hele applikasjonens livssyklus
2. Bestem kriteriene for skalerbarhet
3. Liste over programvareverktøyene som kreves for å kjøre belastningstesten
4. Still inn testmiljøet og konfigurer maskinvaren som kreves for å utføre skalerbarhetstester
5. Planlegg testscenariene samt skalerbarhetstestene
6. Opprett og bekreft det virtuelle brukerskriptet
7. Opprett og verifiser belastningstestscenariene
8. Utfør testene
9. Evaluer resultatene
10. Generer de nødvendige rapportene

Skalerbarhetstestplan

Før du faktisk lager testene, bør du utvikle en detaljert testplan. Det er et viktig trinn for å sikre at testen samsvarer med applikasjonskravene.

Følgende er attributtene for å lage en veldefinert Testplan for skalerbarhetstesting.

• Trinn for skriptTestskriptet bør ha detaljerte trinn som bestemmer nøyaktig hvilke handlinger en bruker ville utføre.
• KjøretidsdataTestplanen bør bestemme eventuelle kjøretidsdata som kreves for å samhandle med applikasjonen.
• Datadrevne testerHvis skriptene trenger varierende data under kjøring, må du ha en forståelse av alle feltene som krever disse dataene.

Eksempel på skalerbarhetstesting

Tenk deg en nettbutikk som forventer 2,000 samtidige kunder i løpet av et sesongsalg. Teamet blir først enige om et beståttkriterium: kassetransaksjonen må fullføres på under tre sekunder for 95 prosent av brukerne, med en feilrate under én prosent.

Testen kjører deretter det samme «browse-search-cart-checkout»-skriptet ved 250, 500, 1,000, 1,500 og 2,000 virtuelle brukere. Responstiden holder seg nesten to sekunder opp til 1,000 brukere, går ned til 2.8 sekunder ved 1,500, og når ni sekunder ved 2,000 mens database-CPU-en ligger på 98 prosent. Skalerbarhetsgrensen er derfor omtrent 1,500 brukere, og flaskehalsen er databasenivået – ikke applikasjonsserverne teamet hadde planlagt å legge til.

Verktøy for skalerbarhetstesting

Skalerbarhetstesting trenger et verktøy som kan generere belastning fra flere maskiner samtidig og rapportere resultater sentralt. Valget følger vanligvis teamets primære språk og protokollene som testes.

Skybaserte løpere som BlazeMeter, LoadView og Gatling Enterprise ligger oppå flere av disse motorene og er verdt å vurdere når en test trenger titusenvis av virtuelle brukere eller trafikk fra flere geografiske regioner. En bredere oversikt over kategorien er tilgjengelig i veiledningen til verktøy for ytelsestesting.

Utfordringer og beste praksis innen skalerbarhetstesting

De mest skuffende skalerbarhetsresultatene tractilbake til testoppsettet i stedet for applikasjonen. Dette er problemene som gjentar seg, og vanene som forhindrer dem.

Vanlige utfordringer

• Underdimensjonerte miljøer — En testrigg med halvparten av produksjonsminnet rapporterer en flaskehals som ikke finnes i produksjonen.
• Urealistiske arbeidsbelastningsmodeller — Skript uten tenketid eller datavariasjon treffer mellomlagringer som ekte brukere ville gått glipp av.
• Støyende resultater — Automatisk skalering, søppeltømming og delt skymaskinvare gjør at to identiske kjøringer ikke stemmer overens.
• Tynn observerbarhet – Uten serversidemålinger viser et tregt resultat at noe feilet, men ikke hva.
• Kostnad — Generering av svært høy samtidighet krever sin egen flåte av lastgeneratorer, noe som er lett å underbudsjettere.

Beste praksis

• Bli enige om beståttkriteriene, som en persentil for responstid og et tak for feilrate, før første kjøring.
• Øk belastningen i planlagte trinn og hold hvert trinn lenge nok til at systemet roer seg.
• Varier testdata per virtuell bruker, slik at mellomlagring ikke flaterer resultatene.
• Samle inn applikasjons-, database- og infrastrukturmålinger sammen med tallene fra klientsiden.
• Lagre testskript i versjonskontroll og kjør en kort skalerbarhetssjekk på hver versjon, deretter en full kjøring før utgivelse.
• Sammenlign trender på tvers av bygg i stedet for å bedømme én enkelt rapport isolert.

Skalerbarhetstesting kontra belastningstesting

De to blir ofte forvekslet fordi begge legger belastning. Forskjellen ligger i spørsmålet hver av dem svarer på: Skalerbarhetstesting spør hvor langt systemet kan vokse, mens lastetesting spør om den takler den allerede forventede belastningen.

Begge sitter under ikke-funksjonell testing paraply ved siden av stresstesting, piggtesting, utholdenhetstesting og volumtesting, og en moden ytelsesstrategi kjører vanligvis flere av dem mot de samme skriptene.

Spørsmål og svar