Hvad er udholdenhedstest i softwaretest? (med eksempel)

⚡ Smart opsummering

Udholdenhedstest kører en applikation under en normal forventet belastning i en længere periode for at afsløre, om ydeevnen forringes over tid. Det er testen, der fanger de defekter, som en times belastning ikke kan nå.

  • 🕒 Vedvarende belastning: Forventet produktionstrafik holdt i timer eller dage i stedet for minutter.
  • 📉 Fokus på nedbrydning: Spørgsmålet er, om svartiderne stiger, ikke om målet nås én gang.
  • ???? Almindelige fund: Hukommelseslækager, udtømning af forbindelsespuljen og ubegrænset vækst i logfiler eller caches.
  • 📊 Overvågningssæt: Hukommelse, CPU, svartid, gennemløbshastighed og databaseforbindelser på tværs af hele kørslen.
  • 🛠️ Værktøj: Standardværktøjer driver trafikken, mens APM-værktøjer registrerer ressourcekurverne.
  • ⚖️ Afvejning: Resultaterne er af høj værdi, men de er langsomme at opnå, hvilket begrænser, hvor ofte testen kan køres.

Hvad er udholdenhedstest

Hvad er udholdenhedstest?

Udholdenhedstest er en ikke-funktionel type softwaretest, hvor en software testes med høj belastning over et betydeligt tidsrum for at evaluere softwareapplikationens adfærd under vedvarende brug. Hovedformålet med udholdenhedstest er at sikre, at applikationen er i stand nok til at håndtere forlænget belastning uden nogen forringelse af responstiden.

Denne type test udføres på det sidste trin af præstationskørselscyklussen. Udholdenhedstest er en lang proces og varer nogle gange i op til et år. Dette kan omfatte anvendelse af eksterne belastninger såsom internettrafik eller brugerhandlinger. Dette gør at udholdenhedstest adskiller sig fra Load Testing, som normalt slutter om et par timer eller deromkring.

Udholdenhed betyder kapacitet, så med andre ord kan du betegne udholdenhedstest som Kapacitetstest.

Mål for udholdenhedstestning

  • Det primære mål med udholdenhedstest er at kontrollere for hukommelseslækager.
  • For at finde ud af, hvordan systemet fungerer under vedvarende brug.
  • For at sikre, at systemets responstid efter en lang periode forbliver den samme eller bedre end starten af ​​testen.
  • For at bestemme antallet af brugere og/eller transaktioner vil et givet system understøtte og opfylde præstationsmål.
  • For at styre de fremtidige belastninger skal vi forstå, hvor mange ekstra ressourcer (såsom processorkapacitet, diskkapacitet, hukommelsesforbrug eller netværksbåndbredde) er nødvendige for at understøtte brugen i fremtiden.
  • Udholdenhedstest udføres generelt ved enten at overbelaste systemet eller ved at reducere visse systemressourcer og evaluere konsekvenserne.
  • Det udføres for at sikre, at defekter eller hukommelseslækager ikke opstår efter, hvad der anses for at være en relativt "normal" brugsperiode.

Hvad skal man overvåge ved udholdenhedstest

Udholdenhedstest

I udholdenhedstestning testes følgende ting.

  • Test hukommelseslækage- Der udføres kontrol for at verificere, om der er nogen hukommelseslækage i applikationen, som kan forårsage nedbrud af systemet eller OS
  • Test forbindelseslukningen mellem systemets lag – Hvis forbindelsen mellem systemets lag ikke lukkes korrekt, kan det gå i stå, nogle eller alle systemets moduler.
  • Test databaseforbindelsen lukket– Hvis databaseforbindelsen ikke lukkes korrekt, kan det resultere i systemnedbrud
  • Test responstid – Systemet testes for systemets responstid, da applikationen bliver mindre effektiv som følge af længere tids brug af systemet.

Sådan udfører du udholdenhedstest

Nedenfor er den grundlæggende testmetode for Endurance Test

  • Testmiljø – Identificer den hardware, software, operativsystem, der kræves til udholdenhedstestningen, tildeling af roller og ansvar i teamet osv. Miljøet skal være klar før testen udføres. Du skal også estimere fælles databaseproduktionsstørrelse og årlig vækst. Dette er påkrævet, som sådan skal du teste, hvordan din ansøgning vil reagere efter et år, to eller fem.
  • Oprettelse af testplanen, scenarier – Baseret på testens art – manuel eller automatisering eller kombination af begge, Test sag design, anmeldelser og udførelse bør planlægges. Test for at stresse systemet, brudpunktstest osv. bør også være en del af testplanen. Test for at stresse systemet bestemmer brudpunktet i applikationen.
  • Testvurdering – Giv et skøn over, hvor lang tid det vil tage at fuldføre testfasen. Det bør analyseres på grundlag af et antal involverede testere og antallet af krævede testcyklusser.
  • Risikoanalyse - Analysere risikoen og træffe passende foranstaltninger til forebyggelse. Prioritering af testsager i henhold til risikofaktoren og identificer nedenstående risiko- og problemer, testeren kan fase under udholdenhedstesten.
  • Vil ydeevnen forblive ensartet over tid?
  • Er der andre mindre problemer, som endnu ikke er blevet opdaget?
  • Er der ekstern interferens, som ikke blev rettet?
  • Testplan – Bestem budgettet, leverancer inden for tidsrammerne. Som Udholdenhedstest anvender et enormt, men naturligt belastningsarrangement af transaktioner på systemet/applikationen i en sammenhængende periode.

Eksempel på udholdenhedstest

Mens Stresstest tager det testede system til dets grænser, Udholdenhedstest tager applikationen til sin grænse over tid.

For eksempel opstår de mest komplekse problemer – hukommelseslækager, udnyttelse af databaseserveren og et system, der ikke reagerer – når software kører i længere tid. Hvis du springer udholdenhedstestene over, er dine chancer for at opdage sådanne defekter før implementering ret lave.

Værktøjer til udholdenhedstest

Fordele ved udholdenhedstest

  • Det hjælper med at bestemme, hvordan arbejdsbyrden kan håndtere systemet under belastning.
  • Giver nøjagtige data, som kunden kan bruge til at validere eller forbedre deres infrastrukturbehov.
  • Identificerer ydeevneproblemer, der kan opstå efter et system har kørt på et højt niveau i længere tid
  • Typiske problemer identificeres i mindre målrettede ydeevnetest, hvilket betyder, at det sikrer, at applikationen forbliver tilgængelig, selv når der er stor belastning på meget kort tid.
  • Udholdenhedstesten bruges også til at kontrollere, om der er nogen præstationsforringelse efter en længere periode med udførelse

Ulemper ved udholdenhedstestning

  • Det er ofte svært at definere, hvor meget stress er værd at påføre.
  • Udholdenhedstest kan forårsage applikations- og/eller netværksfejl, der kan resultere i betydelige forstyrrelser, hvis Testmiljø er ikke isolerede.
  • Permanent datatab eller korruption kan opstå ved at overbelaste systemet.
  • Ressourceudnyttelsen forbliver meget høj, efter at stressen er fjernet.
  • Nogle programkomponenter reagerer ikke.
  • Ubehandlede undtagelser observeres af slutbrugeren.

Hvordan denne test passer til præstationstestfamilien

Ydelsestest er en paraplybetegnelse. Varianterne nedenfor adskiller sig kun i formen af ​​den påførte belastning og den varighed, den holdes i, hvilket er grunden til, at de så ofte forveksles med hinanden.

Testtype Indlæsningsmønster Spørgsmål det besvarer
Belastningstest Forventet spidsbelastning, kort varighed Opfylder systemet sine mål under normal spidsbelastning?
Stresstest Øget ud over kapaciteten indtil fejl Hvor knækker den, og fejler den yndefuldt?
Spike test Pludselig ekstrem stigning, derefter tilbagetrækning Overlever og kommer den sig efter et trafikchok?
Udholdenhedstest Normal belastning holdt i mange timer Forringes ydeevnen over tid?
Soak-test Vedvarende belastning over en længere periode Er der hukommelseslækager eller ressourceudtømning?
Stabilitetstest Varierende belastning under forskellige forhold Forbliver systemet pålideligt, når forholdene ændrer sig?
Volumentest Normale brugere, meget stor datamængde Klarer den sig, når databasen vokser?

Holdbarheds- og gennemvædningstestning behandles ofte som synonymer. I almindelig brug er de: begge holder en vedvarende belastning i en lang periode. Hvor teams adskiller dem, fokuserer udholdenhedstest på, om svartiderne stiger, mens soak-test fokuserer på ressourceforbrug såsom hukommelse, filhandles og forbindelsespuljer. At køre en giver dig normalt bevis for begge.

Nøglemålinger, der skal registreres under testen

En performancekørsel er kun så god som det, du optager, mens den udføres. Registrer disse seks på server- og klientsiden, og sammenlign dem derefter med baseline i stedet for med en mavefornemmelse.

metric Hvad den fortæller dig Advarselsskilt
Gennemsnitlig svartid Typisk brugeroplevelse Enhver opadgående drift på tværs af løbet
95. percentil responstid Oplevelsen for de langsomste brugere Langt over gennemsnittet, hvilket betyder inkonsekvens
gennemløb Anmodninger behandlet pr. sekund Fald mens belastningen forbliver konstant
Fejlrate Andel af mislykkede eller timeout-forespørgsler Enhver stigning over den aftalte tærskel
CPU- og hukommelsesforbrug Serverressource headroom Hukommelse der klatrer og aldrig vender tilbage
Databaseforbindelser og tråde Udmattelse af poolen Antal der vokser støt uden frigivelse

Læs gennemsnittet og percentilen sammen. Et gennemsnit på 800 ms med en 95. percentil på 900 ms beskriver et konsistent system. Det samme gennemsnit med en 95. percentil på 9 sekunder betyder, at én ud af tyve brugere har det dårligt, og gennemsnittet skjuler det.

Se på formen, ikke kun værdien. I enhver langvarig test er en flad ressourcelinje et bestået resultat, og en stigende er en lækage, selv når det absolutte tal stadig er komfortabelt inden for grænsen i det øjeblik, kørslen slutter.

Udholdenhedstest: Vigtige konklusioner

  • In Software Engineering, Udholdenhedstest er en delmængde af belastningstest.
  • Udholdenhedstest er en lang proces og varer nogle gange i op til et år
  • Der udføres kontrol for at verificere
  • Test hukommelseslækage
  • Test responstid
  • Test databaseforbindelse osv.

Ofte Stillede Spørgsmål

Belastningstest verificerer, at systemet opfylder sine mål ved spidsbelastning over en kort periode. Udholdenhedstest holder en normal belastning i timevis for at afsløre, om disse mål stadig holder ved slutningen af ​​perioden.

Enhver vedvarende opadgående tendens i svartid eller ressourceforbrug, selvom ingen tærskelværdi overskrides. Fejlen er selve driften, fordi den til sidst vil overskride grænsen i produktionen.

Efter bestået funktions- og belastningstest, og tidligt nok til at en opdaget lækage stadig kan repareres, giver det ikke tid til at reagere på resultatet, hvis det køres aftenen før udgivelsen.

AI-baseret overvågning registrerer det punkt, hvor en metrik ændrer tendens, og korrelerer det med implementeringer eller planlagte job, hvilket gør timer med grafer til en specifik mistanke.

Det kan hjælpe med at prioritere. Risikomodeller fremhæver, hvilke koder der frigiver berøringslækage, så fulde kørsler reserveres til de ændringer, der mest sandsynligt har brug for dem.

Opsummer dette indlæg med: