Vad är uthållighetstestning i mjukvarutestning? (med exempel)

⚡ Smart sammanfattning

Uthållighetstestning kör en applikation under normal förväntad belastning under en längre period för att avslöja om prestandan försämras över tid. Det är testet som upptäcker de defekter som en timmes belastning inte kan nå.

  • 🕒 Hållbar belastning: Förväntad produktionstrafik hölls i timmar eller dagar snarare än minuter.
  • 📉 Fokus på nedbrytning: Frågan är om svarstiderna glider uppåt, inte om målet uppnås en gång.
  • ???? Vanliga fynd: Minnesläckor, uttömning av anslutningspoolen och obegränsad logg- eller cachetillväxt.
  • 📊 Övervakningsuppsättning: Minne, CPU, svarstid, dataflöde och databasanslutningar över hela körningen.
  • 🛠️ Verktyg: Standardlastverktyg driver trafiken medan APM-verktyg registrerar resurskurvorna.
  • ⚖️ Avvägning: Resultaten är av hög värde men det går långsamt att få fram dem, vilket begränsar hur ofta testet kan köras.

Vad är uthållighetstestning

Vad är uthållighetstestning?

Uthållighetstestning är en icke-funktionell typ av mjukvarutestning där en mjukvara testas med hög belastning som sträcker sig över en betydande tidsperiod för att utvärdera mjukvaruapplikationens beteende under långvarig användning. Huvudsyftet med uthållighetstestning är att säkerställa att applikationen är tillräckligt kapabel att hantera långvarig belastning utan försämring av svarstiden.

Denna typ av testning utförs i det sista skedet av prestandakörningscykeln. Uthållighetstestning är en lång process och varar ibland i upp till ett år. Detta kan inkludera applicering av externa belastningar som internettrafik eller användaråtgärder. Detta gör att uthållighetstestning skiljer sig från Lasttestning, som vanligtvis slutar om ett par timmar eller så.

Uthållighet betyder kapacitet, så med andra ord kan du kalla uthållighetstestning som Kapacitetstestning.

Mål för uthållighetstestning

  • Det primära målet med uthållighetstestning är att kontrollera minnesläckor.
  • För att upptäcka hur systemet fungerar under långvarig användning.
  • För att säkerställa att efter en lång period kommer systemets svarstid att förbli densamma eller bättre än vid starten av testet.
  • För att bestämma antalet användare och/eller transaktioner kommer ett givet system att stödja och uppfylla prestationsmål.
  • För att hantera framtida belastningar måste vi förstå hur många ytterligare resurser (som processorkapacitet, diskkapacitet, minnesanvändning eller nätverksbandbredd) som behövs för att stödja användning i framtiden.
  • Uthållighetstestning görs vanligtvis genom att antingen överbelasta systemet eller genom att minska vissa systemresurser och utvärdera konsekvenserna.
  • Den utförs för att säkerställa att defekter eller minnesläckor inte uppstår efter vad som anses vara en relativt "normal" användningsperiod.

Vad man ska övervaka vid uthållighetstester

Uthållighetstestning

I uthållighetstestning testas följande saker.

  • Testa minnesläckage– Kontroller görs för att verifiera om det finns något minnesläckage i applikationen, vilket kan orsaka att systemet eller OS kraschar
  • Testa anslutningsstängning mellan systemets lager – Om anslutningen mellan skikten i systemet inte sluts framgångsrikt, kan det stanna några eller alla moduler i systemet.
  • Testa databasanslutningen avslutas– Om databasanslutningen inte stängs, kan det leda till systemkrasch
  • Testa svarstid – Systemet testas för systemets svarstid eftersom applikationen blir mindre effektiv till följd av den långvariga användningen av systemet.

Hur man utför uthållighetstester

Nedan är den grundläggande testmetoden för Endurance Test

  • Testmiljö – Identifiera hårdvaran, mjukvaran, operativsystemet som krävs för uthållighetstestning, tilldelning av roller och ansvar inom teamet, etc. Miljön bör vara redo innan testkörningen. Du måste också uppskatta den vanliga databasens produktionsstorlek och årlig tillväxt. Detta krävs som sådan måste du testa hur din ansökan kommer att svara efter ett år, två eller fem.
  • Skapa testplanen, scenarier – Baserat på testets karaktär – manuell eller automatisering eller kombination av båda, Testfall design, granskningar och utförande bör planeras. Testning för att stressa systemet, brytpunktstestning etc. bör också ingå i testplanen. Testning för att stressa systemet bestämmer brytpunkten i applikationen.
  • Testuppskattning – Ge en uppskattning av hur lång tid det kommer att ta att slutföra testfasen. Den bör analyseras på grundval av ett antal inblandade testare och antalet testcykler som krävs.
  • Riskanalys - Analysera risken och vidta lämpliga åtgärder för att förebygga. Prioritering av testfall enligt riskfaktorn och identifiera nedanstående risk- och problemtestare kan fasa under uthållighetstestet.
  • Kommer prestandan att förbli konsekvent över tiden?
  • Finns det andra mindre problem som ännu inte har upptäckts?
  • Finns det externa störningar som inte åtgärdades?
  • Testschema – Bestäm budgeten, leveranser inom tidsramarna. Som Uthållighetstestning tillämpar ett enormt men naturligt belastningsarrangemang av transaktioner på systemet/applikationen under en kontinuerlig tidsperiod.

Exempel på uthållighetstest

Medan Stresstestning tar det testade systemet till sina gränser, Uthållighetstestning tar applikationen till sin gräns över tid.

Till exempel uppstår de mest komplexa problemen – minnesläckor, databasserveranvändning och system som inte svarar – när programvara körs under en längre tid. Om du hoppar över uthållighetstesterna är dina chanser att upptäcka sådana fel före driftsättning ganska låga.

Uthållighetstestverktyg

Fördelar med uthållighetstestning

  • Det hjälper till att avgöra hur arbetsbelastningen kan hantera systemet under belastning.
  • Tillhandahåller korrekt data som kunden kan använda för att validera eller förbättra sina infrastrukturbehov.
  • Identifierar prestandaproblem som kan uppstå efter att ett system har körts på hög nivå under en längre tid
  • Typiska problem identifieras i mindre riktade prestandatester, vilket innebär att det säkerställer att applikationen förblir tillgänglig även när det är stor belastning på mycket kort tid.
  • Uthållighetstestet används också för att kontrollera om det finns någon prestationsförsämring efter en lång tids utförande

Nackdelar med uthållighetstestning

  • Det är ofta svårt att definiera hur mycket stress som är värt att applicera.
  • Uthållighetstestning kan orsaka program- och/eller nätverksfel som kan resultera i betydande störningar om Testmiljö är inte isolerade.
  • Permanent dataförlust eller korruption kan uppstå genom att systemet överbelastas.
  • Resursutnyttjandet förblir mycket högt efter att stressen tagits bort.
  • Vissa programkomponenter svarar inte.
  • Ohanterade undantag observeras av slutanvändaren.

Hur detta test passar in i prestationstestfamiljen

Prestandatestning är ett paraplybegrepp. Varianterna nedan skiljer sig endast åt i formen av den applicerade belastningen och hur länge den hålls, vilket är anledningen till att de så ofta förväxlas med varandra.

Testtyp Lastmönster Fråga den svarar
Lasttestning Förväntad toppbelastning, kort varaktighet Uppfyller systemet sina mål under normal trafikbelastning?
Stresstestning Ökade utöver kapaciteten tills fel uppstod Var går det sönder, och fallerar det graciöst?
Spike testning Plötslig extrem ökning, sedan tillbakadragande Överlever och återhämtar den sig från en trafikchock?
Uthållighetstestning Normal belastning hålls i många timmar Försämras prestandan med tiden?
Blötläggningstestning Ihållande belastning under en längre period Finns det minnesläckor eller resursutmattning?
Stabilitetstestning Varierande belastning beroende på förhållanden Förblir systemet tillförlitligt även när förhållandena förändras?
Volymtestning Vanliga användare, mycket stor datamängd Klarar den sig av att databasen växer?

Uthållighets- och blötläggningstestning behandlas ofta som synonymer. Vanligtvis används de som: båda håller en ihållande belastning under en lång period. Där team skiljer dem åt fokuserar uthållighetstestning på om svarstiderna glider uppåt, medan soak-testning fokuserar på resursförbrukning som minne, filreferenser och anslutningspooler. Att köra en ger dig vanligtvis bevis för båda.

Viktiga mätvärden att fånga upp under testet

En prestandakörning är bara så bra som vad du spelar in medan den körs. Registrera dessa sex på server- och klientsidan och jämför dem sedan mot baslinjen snarare än mot en magkänsla.

metrisk Vad det säger dig Varningstecken
Genomsnittlig svarstid Typisk användarupplevelse Eventuell uppåtgående drift över banan
95:e percentilens svarstid Upplevelsen för de långsammaste användarna Långt över genomsnittet, vilket betyder inkonsekvens
genomströmning Hanterade förfrågningar per sekund Faller medan belastningen förblir konstant
Felhastighet Andel misslyckade eller tidsgränsade förfrågningar Varje höjning över det överenskomna tröskelvärdet
CPU- och minnesanvändning Serverresursutrymme Minne som klättrar och aldrig återvänder
Databasanslutningar och trådar Poolutmattning Antal som växer stadigt utan utgivning

Läs av medelvärdet och percentilen tillsammans. Ett genomsnitt på 800 ms med en 95:e percentil på 900 ms beskriver ett konsekvent system. Samma genomsnitt med en 95:e percentil på 9 sekunder innebär att en användare av tjugo har det dåligt, och genomsnittet döljer det.

Titta på formen, inte bara på värdet. I alla långvariga tester är en platt resurslinje ett godkänt resultat och en stigande är en läcka, även om det absoluta antalet fortfarande ligger bekvämt inom gränsen när körningen avslutas.

Uthållighetstestning: Viktiga slutsatser

  • In Mjukvaruutveckling, Uthållighetstestning är en delmängd av belastningstestning.
  • Uthållighetstestning är en lång process och pågår ibland i upp till ett år
  • Kontroller görs för att verifiera
  • Testa minnesläckage
  • Testa svarstid
  • Testa databasanslutning osv.

Vanliga frågor

Belastningstestning verifierar att systemet uppfyller sina mål vid maximal belastning under en kort körning. Uthållighetstester håller en normal belastning i timmar för att avslöja om dessa mål fortfarande håller i slutet av körningen.

Varje ihållande uppåtgående trend i svarstid eller resursanvändning, även om inget tröskelvärde överskrids. Defekten är själva driften, eftersom den så småningom kommer att överskrida gränsen i produktionen.

Efter godkänd funktions- och belastningstestning, och tillräckligt tidigt för att en upptäckt läcka fortfarande kan åtgärdas. Att köra den kvällen före release ger ingen tid att agera utifrån resultatet.

AI-baserad övervakning upptäcker den punkt där ett mätvärde ändrar trend och korrelerar det med driftsättningar eller schemalagda jobb, vilket förvandlar timmar av grafer till en specifik misstänkt faktor.

Det kan hjälpa till att prioritera. Riskmodeller markerar vilka som släpper kod som är benägen att läcka vid beröring, så fullständiga körningar reserveras för de ändringar som mest sannolikt behöver dem.

Sammanfatta detta inlägg med: