Hvad er skalerbarhedstest? Lær med eksempel

Hvad er skalerbarhedstest?

Skalerbarhedstest er en ikke-funktionel testmetode, der måler et systems eller netværks ydeevne, når antallet af brugeranmodninger skaleres op eller ned. Formålet med skalerbarhedstest er at sikre, at systemet kan håndtere en forventet stigning i brugertrafik, datavolumen og transaktionsfrekvens. Det tester systemets evne til at imødekomme den voksende efterspørgsel.

Skalerbarhedstestning er en undertype af test af ydeevne, så den fokuserer på en applikations opførsel, når den implementeres i et større system eller trænes under overbelastning. Software EngineeringSkalerbarhedstestning måler det punkt, hvor en applikation stopper med at skalere, og identificerer årsagen bag det.

Hvorfor udføre skalerbarhedstestning?

Kapacitetsproblemer opstår sjældent under funktionel testning. De dukker op på årets travleste handelsdag, når en marketingkampagne lander, eller når et datasæt, der har vokset stille og roligt i to år, endelig bremser alle forespørgsler. Skalerbarhedstestning afdækker først disse begrænsninger i et kontrolleret miljø. Specifikt hjælper det dig med at:

• Bestem, hvordan applikationen skaleres, når arbejdsbyrden stiger, og hvor denne kurve flader ud.
• Bestem grænsen for samtidige brugere for webapplikationen, før svartiderne bliver uacceptable.
• Bestem forringelsen på klientsiden og slutbrugeroplevelsen under belastning, såsom langsom skærmgengivelse.
• Bestem serversides robusthed og forringelse, herunder CPU-mætning, hukommelseslækager og udtømning af forbindelsespuljen.

Forholdet er nemmest at forestille sig som en kurve: gennemløbsmængden stiger i takt med den øgede belastning, indtil en ressource mættes, hvorefter ekstra brugere blot forlænger køen.

Typer af skalerbarhedstest

Skalerbarhed er ikke en enkelt egenskab, så en testplan dækker normalt mere end én dimension. De fire typer nedenfor er dem, som de fleste teams måler, og de to første bestemmer selve testmiljøets form.

Vertikal skalering er enklere, fordi arkitekturen sjældent ændrer sig, men en enkelt maskine har altid et loft. Horisontal skalering fjerner dette loft og forbedrer fejltolerancen, på bekostning af netværkslatens, datakonsistens og koordinationsoverhead – alt dette skal testen måle snarere end antage.

Hvad skal man teste i skalerbarhedstest

Skalerbarhed bedømmes ud fra målinger, ikke visninger. Registrer følgende attributter ved hvert indlæsningstrin, så tendensen og ikke kun det endelige tal er synlig.

Teststrategi for skalerbarhedstest

Teststrategien for skalerbarhedstestning varierer afhængigt af den type applikation, der testes. Hvis en applikation tilgår en database, vil testparametrene omfatte databasens størrelse i forhold til antallet af brugere og så videre.

Forudsætninger for skalerbarhedstest

• Belastningsfordelingsevne — Kontroller, om belastningstestværktøjet gør det muligt at generere belastningen fra flere maskiner og styre den fra et centralt punkt.
• Operating System — Tjek hvad operativsystemer load generation agents og load test master kører under.
• Processor — Kontroller, hvilken type CPU der kræves til den virtuelle brugeragent og indlæsningstestmasteren.
• Hukommelse — Kontroller, hvor meget hukommelse der er nok til den virtuelle brugeragent og indlæs testmasteren.
• Testmiljø — Kontroller, at testmiljø afspejler produktionen tilstrækkeligt til, at resultaterne kan overføres.

Sådan laver du skalerbarhedstest

1. Definer en gentagelig proces til udførelse af skalerbarhedstests gennem hele applikationens livscyklus
2. Bestem kriterierne for skalerbarhed
3. Kortliste de softwareværktøjer, der kræves for at køre belastningstesten
4. Indstil testmiljøet, og konfigurer den nødvendige hardware til at udføre skalerbarhedstest
5. Planlæg testscenarierne samt skalerbarhedstestene
6. Opret og bekræft det virtuelle brugerscript
7. Opret og verificer belastningstestscenarier
8. Udfør testene
9. Evaluer resultaterne
10. Generer de nødvendige rapporter

Skalerbarhedstestplan

Før du rent faktisk opretter testene, skal du udvikle en detaljeret testplan. Det er et vigtigt skridt at sikre, at testen overholder applikationskravene.

Følgende er attributterne til at skabe en veldefineret Testplan til skalerbarhedstest.

• Trin til scriptsTestscriptet skal have detaljerede trin, der bestemmer de præcise handlinger, en bruger vil udføre.
• Run-Time DataTestplanen bør bestemme eventuelle runtime-data, der er nødvendige for at interagere med applikationen.
• Datadrevne testsHvis scriptsene har brug for varierende data under kørsel, skal du have en forståelse af alle de felter, der kræver disse data.

Eksempel på skalerbarhedstest

Forestil dig en onlinebutik, der forventer 2,000 samtidige kunder under et sæsonudsalg. Teamet bliver først enige om et beståelseskriterium: Betalingstransaktionen skal gennemføres på under tre sekunder for 95 procent af brugerne, med en fejlrate på under én procent.

Testen kører derefter det samme browse-search-cart-checkout-script ved 250, 500, 1,000, 1,500 og 2,000 virtuelle brugere. Svartiden holder sig tæt på to sekunder op til 1,000 brugere, falder til 2.8 sekunder ved 1,500 og når ni sekunder ved 2,000, mens database-CPU'en ligger på 98 procent. Skalerbarhedsgrænsen er derfor cirka 1,500 brugere, og flaskehalsen er databaseniveauet – ikke de applikationsservere, som teamet havde planlagt at tilføje.

Værktøjer til skalerbarhedstestning

Skalerbarhedstestning kræver et værktøj, der kan generere belastning fra flere maskiner på én gang og rapportere resultater centralt. Valget følger normalt teamets primære sprog og de protokoller, der testes.

Cloud-hostede runners som f.eks. BlazeMeter, LoadView og Gatling Enterprise ligger oven på flere af disse motorer og er værd at overveje, når en test kræver titusindvis af virtuelle brugere eller trafik fra flere geografiske regioner. En bredere oversigt over kategorien er tilgængelig i guiden til præstationstestværktøjer.

Udfordringer og bedste praksis inden for skalerbarhedstestning

De mest skuffende skalerbarhedsresultater tractilbage til testopsætningen i stedet for applikationen. Det er de problemer, der opstår igen, og de vaner, der forhindrer dem.

Fælles udfordringer

• Underdimensionerede miljøer — En testplatform med halvdelen af ​​produktionshukommelsen rapporterer en flaskehals, der ikke findes i produktionen.
• Urealistiske arbejdsbelastningsmodeller — Scripts uden tænketid eller datavariation rammer caches, som rigtige brugere ville overse.
• Støjende resultater — Automatisk skalering, garbage collection og delt cloud-hardware gør to identiske kørsler uensartede.
• Tynd observerbarhed — Uden server-side metrikker viser et langsomt resultat, at noget gik i stykker, men ikke hvad.
• Pris — Generering af meget høj samtidighed kræver sin egen flåde af loadgeneratorer, hvilket er let at underbudgettere.

Bedste praksis

• Aftal beståelseskriterierne, såsom en svartidspercentil og et loft for fejlprocent, inden første kørsel.
• Øg belastningen i planlagte trin, og hold hvert trin længe nok til, at systemet kan stabilisere sig.
• Varier testdata pr. virtuel bruger, så caching ikke flatterer resultaterne.
• Indsaml applikations-, database- og infrastrukturmålinger sammen med klientsidetal.
• Gem testscripts i versionskontrol og kør en kort skalerbarhedskontrol på hvert build, og kør derefter en fuld kørsel før udgivelsen.
• Sammenlign tendenser på tværs af builds i stedet for at bedømme en enkelt rapport isoleret.

Skalerbarhedstest vs. belastningstest

De to forveksles ofte, fordi begge anvender belastning. Forskellen ligger i det spørgsmål, som hver enkelt besvarer: Skalerbarhedstestning spørger, hvor langt systemet kan vokse, mens belastningstest spørger, om den klarer den allerede forventede belastning.

Begge sidder under ikke-funktionel testning paraply ved siden af stress test, spike-testning, udholdenhedstest og volumentestning, og en moden præstationsstrategi kører normalt flere af dem mod de samme scripts.

Ofte Stillede Spørgsmål