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å.
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
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
- WebLOAD
- Indlæsning fuldført
- Apache JMeter
- LoadRunner
- Appvance
- LoadUI
- OpenSTA
- Rational Performance Tester
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.


