Stresstestning (mjukvara)

Stresstestning är en mjukvarutestaktivitet som bestämmer mjukvarans robusthet genom att testa bortom gränserna för normal drift. Stresstester är särskilt viktigt för " uppdragskritisk " programvara, men används för alla typer av programvara. Stresstester lägger vanligtvis större tonvikt på robusthet, tillgänglighet och felhantering under hög belastning än på vad som skulle anses vara korrekt beteende under normala omständigheter.

Ett systemstresstest avser tester som lägger större tonvikt på robusthet , tillgänglighet och felhantering under en tung belastning, snarare än på vad som skulle anses vara korrekt beteende under normala omständigheter. I synnerhet kan målen med sådana test vara att säkerställa att programvaran inte kraschar under förhållanden med otillräckliga beräkningsresurser (som minne eller diskutrymme ), ovanligt hög samtidighet eller överbelastningsattacker .

Exempel:

  • En webbserver kan stresstestas med hjälp av skript , bots och olika överbelastningsverktyg för att observera prestandan på en webbplats under toppbelastningar. Dessa attacker är vanligtvis under en timme långa, eller tills en gräns för mängden data som webbservern kan tolerera hittas.

Stresstestning kan jämföras med belastningstestning:

  • Belastningstestning undersöker hela miljön och databasen, samtidigt som svarstiden mäts, medan stresstester fokuserar på identifierade transaktioner och skjuter till en nivå för att bryta transaktioner eller system.
  • Under stresstester, om transaktioner är selektivt stressade, kanske databasen inte upplever mycket belastning, men transaktionerna är kraftigt stressade. Å andra sidan, under belastningstestning upplever databasen en stor belastning, medan vissa transaktioner kanske inte stressas.
  • Systemstresstester, även känt som stresstester, laddar de samtidiga användarna över och utöver den nivå som systemet kan hantera, så det bryter vid den svagaste länken i hela systemet.

Fälterfarenhet

Misslyckanden kan vara relaterade till:

  • egenskaper hos icke-produktion som miljöer, t.ex. små testdatabaser
  • fullständig brist på belastning eller stresstester

Logisk grund

Anledningar till stresstester inkluderar:

  • Mjukvaran som testas är "missionskritisk", det vill säga fel på programvaran (som en krasch ) skulle få katastrofala konsekvenser.
  • Mängden tid och resurser som ägnas åt att testa är vanligtvis inte tillräcklig, med traditionella testmetoder, för att testa alla situationer där programvaran kommer att användas när den släpps.
  • Även med tillräckligt med tid och resurser för att skriva test, kanske det inte är möjligt att i förväg fastställa alla olika sätt på vilka programvaran kommer att användas. Detta gäller särskilt för operativsystem och mellanprogram , som så småningom kommer att användas av programvara som inte ens existerar vid tidpunkten för testet.
  • Kunder kan använda programvaran på datorer som har betydligt färre beräkningsresurser (som minne eller diskutrymme ) än de datorer som används för testning.
  • Indataintegritet kan inte garanteras. Indata är mjukvaruomfattande: det kan vara datafiler, strömmar och minnesbuffertar, såväl som argument och alternativ som ges till en körbar kommandorad eller användarinmatningar som utlöser åtgärder i en GUI-applikation. Fuzzing- och apatestmetoder kan användas för att hitta problem på grund av datakorruption eller inkoherens.
  • Samtidighet är särskilt svårt att testa med traditionella testmetoder. Stresstester kan vara nödvändigt för att hitta tävlingsförhållanden och dödlägen .
  • Programvara som webbservrar som kommer att vara tillgängliga över Internet kan bli föremål för överbelastningsattacker .
  • Under normala förhållanden kan vissa typer av buggar , som minnesläckor , vara ganska godartade och svåra att upptäcka under de korta tidsperioder som testning utförs. Dessa buggar kan dock fortfarande vara potentiellt allvarliga. På ett sätt kan stresstester under en relativt kort tidsperiod ses som att simulera normal drift under en längre tid.

Förhållande till filialtäckning

Filialtäckning . (en specifik typ av kodtäckning ) är ett mått på antalet grenar som körs under test, där "100 % grentäckning" betyder att varje gren i ett program har körts minst en gång under något test Branschtäckning är en av de viktigaste måtten för mjukvarutestning; programvara för vilken filialtäckningen är låg anses i allmänhet inte vara noggrant testad. Observera att [ redigera ] kodtäckningsmått är en egenskap hos testerna för en mjukvara, inte hos den programvara som testas.

Att uppnå hög grentäckning innebär ofta att man skriver negativa testvarianter, det vill säga varianter där programvaran ska misslyckas på något sätt, utöver de vanliga positiva testvarianterna, som testar avsedd användning. Ett exempel på en negativ variation skulle vara att anropa en funktion med olagliga parametrar. Det finns dock en gräns för grentäckningen som kan uppnås även vid negativa variationer, eftersom vissa grenar endast får användas för hantering av fel som ligger utanför testets kontroll. Till exempel skulle ett test normalt inte ha någon kontroll över minnesallokering, så grenar som hanterar ett "utom minne"-fel är svåra att testa.

Stresstestning kan uppnå högre grentäckning genom att ta fram villkoren under vilka vissa felhanteringsgrenar följs. Täckningen kan förbättras ytterligare genom att använda felinjektion .

Exempel

Lasttest vs stresstest

Ytterligare information: Testning av mjukvarubelastning

Stresstestning består vanligtvis av tester bortom angivna gränser för att fastställa felpunkter och testfelsåterställning.


Belastningstestning innebär att en kontrollerad miljö går från låg belastning till hög. Stresstester fokuserar på mer slumpmässiga händelser, kaos och oförutsägbarhet. Med hjälp av en webbapplikation som exempel här är sätt på vilka stress kan introduceras:

  • dubbla baslinjenumret för samtidiga användare/HTTP-anslutningar
  • slumpmässigt stänga av och starta om portarna på nätverksväxlarna/routrarna som ansluter servrarna (via SNMP-kommandon till exempel)
  • ta databasen offline och starta om den
  • bygga om en RAID-array medan systemet körs
  • köra processer som förbrukar resurser (CPU, minne, disk, nätverk) på webben och databasservrar
  • observera hur systemet reagerar på fel och återställer sig
    • Räddar det sitt tillstånd?
    • Hänger applikationen och fryser eller misslyckas den på ett elegant sätt?
    • Kan den återhämta sig från det senaste goda tillståndet vid omstart?
    • Skickar systemet ut meningsfulla felmeddelanden till användaren och till loggarna?
    • Har systemets säkerhet äventyrats på grund av oväntade fel?

Pålitlighet

Ett mönsterbaserat ramverk för programvarutestning för exploateringsutvärdering av sårbarheter i korruption av metadata utvecklat av Deng Fenglei, Wang Jian, Zhang Bin, Feng Chao, Jiang Zhiyuan, Su Yunfei diskuterar hur det finns ökad uppmärksamhet inom kvalitetssäkring och skydd av programvara. Men dagens mjukvara kan tyvärr fortfarande inte skyddas från cyberattacker, särskilt i närvaro av osäker organisation av heap-metadata. Författarna syftar till att undersöka om heap-metadata kan skadas och utnyttjas av cyberangripare, och de föreslår RELAY, ett ramverk för mjukvarutestning för att simulera mänskligt utnyttjandebeteende för metadatakorruption på maskinnivå. RELAY använder också de färre resurser som förbrukas för att lösa ett layoutproblem enligt exploateringsmönstret, och genererar den slutliga exploateringen.

En metod för att definiera inlärningsobjekts granularitet utvecklad av BENITTI, Fabiane Barreto Vavassori. Författarna diskuterar först hur lärandeobjekt är ett av de viktigaste forskningsämnena inom e-lärande community de senaste åren och granularitet är en nyckelfaktor för återanvändning av lärobjekt. Författarna presenterar sedan en metodik för att definiera inlärningsobjektens granularitet i datorområdet samt en fallstudie inom mjukvarutestning. Senare genomför författarna fem experiment för att utvärdera inlärningspotentialen från de producerade lärobjekten, samt för att demonstrera möjligheten till återanvändning av lärobjekt. Resultat från experimentet presenteras också i artikeln som visar att lärandeobjekt främjar förståelsen och tillämpningen av begreppen.

En färsk artikel, Reliability Verification of Software Based on Cloud Service, har en banbrytande effekt och den utforskar hur mjukvaruindustrin behöver ett sätt att mäta tillförlitligheten för varje komponent i programvaran. I den här artikeln föreslogs en metod för garantiverifiering baserad på molntjänst . Artikeln diskuterar först hur tillförlitliga varje komponent är kommer att definieras i termer av komponentservicegarantiverifiering. Sedan definierades en effektiv komponentmodell i artikeln och utifrån den föreslagna modellen illustreras processen för att verifiera en komponenttjänst i ett applikationsexempel.

Se även

Hämtad från " https://en.wikipedia.org/w/index.php?title=Stress_testing_(software)&oldid=1143328664 "