Performance Testing ( eng . Performance Testing ) inom mjukvaruteknik är tester som utförs för att fastställa hur snabbt ett datorsystem eller en del av det fungerar under en viss belastning . Det kan också användas för att testa och validera andra systemkvalitetsattribut som skalbarhet , tillförlitlighet och resursförbrukning.
Prestandatestning är ett av de framväxande områdena inom prestandateknik inom datavetenskap som försöker överväga prestanda i modellerings- och designfasen av ett system, innan huvudkodningsfasen börjar .
I prestandatestning särskiljs följande områden:
Det finns två metoder för testning av mjukvarans prestanda [1] :
Lasttestning är den enklaste formen av prestandatestning. Belastningstestning görs vanligtvis för att utvärdera beteendet hos en applikation under en given förväntad belastning. Denna belastning kan till exempel vara det förväntade antalet samtidiga användare av applikationen som gör ett givet antal transaktioner per tidsintervall. Denna typ av testning låter dig vanligtvis få svarstiden för alla de viktigaste affärstransaktionerna. När det gäller övervakning av en databas, en applikationsserver , ett nätverk, etc., kan denna typ av testning också identifiera vissa applikationsflaskhalsar.
Stresstestning används ofta för att förstå genomströmningsgränserna för en applikation. Denna typ av testning utförs för att bestämma systemets tillförlitlighet under extrema eller oproportionerliga belastningar och svarar på frågor om systemets tillräckliga prestanda om den aktuella belastningen avsevärt överstiger det förväntade maxvärdet.
Stabilitetstestning görs för att säkerställa att applikationen tål den förväntade belastningen på lång sikt. Denna typ av testning övervakar applikationens minnesförbrukning för att identifiera potentiella läckor. Dessutom avslöjar sådan testning prestandaförsämring, vilket uttrycks i en minskning av hastigheten på informationsbehandlingen och/eller en ökning av applikationens svarstid efter en lång körning jämfört med början av testet.
Konfigurationstestning är en annan typ av traditionell prestandatestning. I det här fallet, istället för att testa systemets prestanda i termer av den applicerade belastningen, testas prestandaeffekten av konfigurationsändringar. Ett bra exempel på sådan testning skulle vara att experimentera med olika lastbalanseringsmetoder. Konfigurationstestning kan också kombineras med last-, stress- eller stabilitetstestning.
I allmänna fall kan prestationstestning tjäna olika syften.
Många prestationstester görs utan något försök att förstå deras verkliga syfte. Innan man börjar testa bör man alltid ställa affärsfrågan: "Vad är målet vi eftersträvar med prestationstestning?". Svaren på denna fråga är en del av förstudien (eller affärsfallet ) av testning. Målen kan variera beroende på vilken teknik som används av applikationen eller dess syfte, men de inkluderar alltid något av följande:
Om slutanvändarna av applikationen anses vara användare som loggar in i systemet i någon form, är det mycket önskvärt att uppnå parallellitet i detta fall. Per definition är detta det maximala antalet samtidiga körande användare av en applikation som applikationen förväntas stödja vid varje given tidpunkt. Användarbeteendemönstret kan avsevärt påverka en applikations förmåga att bearbeta förfrågningar parallellt, särskilt om det innebär att regelbundet logga in och ut ur systemet.
Om konceptet med applikationen inte är att fungera med specifika slutanvändare, kommer det eftersträvade prestationsmålet att baseras på den maximala genomströmningen eller antalet transaktioner per tidsenhet. Ett bra exempel i det här fallet skulle vara att surfa på webben, till exempel på Wikipedia-portalen.
Detta koncept är uppbyggt kring svarstiden för en applikationsnod på en begäran som skickas till en annan. Ett enkelt exempel är en HTTP 'GET'-begäran från en arbetsstations webbläsare till en webbserver. Nästan alla applikationer som utvecklats för lasttestning fungerar exakt enligt detta mätschema. Ibland är det vettigt att sätta mål för att uppnå serverns svarstidsprestanda över alla applikationsnoder.
Visningstid är ett av de svåraste koncepten för en lasttestapplikation, eftersom de i allmänhet inte använder konceptet att arbeta med vad som händer på individuella noder i systemet, eftersom de endast är begränsade till att känna igen en tidsperiod under vilken det inte finns någon nätverksaktivitet. Att mäta visningstid kräver i allmänhet att funktionella testfall inkluderas i benchmark-tester, men de flesta benchmark-applikationer inkluderar inte denna möjlighet.
Det är mycket viktigt att detaljera prestationskraven och dokumentera dem i någon form av prestationstestplan. Helst görs detta under kravutvecklingsfasen av systemutvecklingen, innan designdetaljerna utarbetas. Se prestandateknik .
Men prestandatestning utförs ofta inte enligt specifikationen, eftersom det inte finns någon fast förståelse för den maximala svarstiden för ett givet antal användare. Prestandatestning används ofta som en del av prestationsprofileringsprocessen. Hans idé är att hitta en "svag länk" - en sådan del av systemet, genom att optimera reaktionstiden för vilken du kan förbättra systemets övergripande prestanda. Att avgöra vilken del av systemet som befinner sig på denna kritiska väg är ibland en mycket svår uppgift, så vissa testapplikationer inkluderar (eller kan läggas till via tillägg) verktyg som körs på servern (agenter) som övervakar exekveringstidstransaktioner, databasåtkomst tid, nätverkskostnader och andra indikatorer för serverdelen av systemet som kan analyseras tillsammans med annan prestandastatistik.
Benchmarktestning kan göras över ett stort nätverk och till och med på geografiskt avlägsna platser, med tanke på att hastigheten på Internet varierar beroende på plats. Det kan också utföras lokalt, men i det här fallet är det nödvändigt att konfigurera nätverksroutrar på ett sådant sätt att det finns en fördröjning som finns i alla publika nätverk. Belastningen som appliceras på systemet måste matcha det faktiska tillståndet. Så, till exempel, om 50 % av systemanvändarna använder en 56K nätverkskanal för att komma åt systemet, och den andra hälften använder en optisk kanal, bör datorer som skapar en testbelastning på systemet använda samma anslutningar (idealiskt) eller emulera förseningarna av ovanstående nätverksanslutningar, efter givna användarprofiler.
Prestandakraven bör åtminstone ta upp följande frågor:
Det finns ett vanligt missförstånd att testverktyg för systembelastning är samma inspelnings- och uppspelningsverktyg som verktyg för att automatisera regressionstestning . Lasttestverktyg fungerar med ett protokoll, medan verktyg för att automatisera regressionstestning fungerar både med ett protokoll och med GUI-objekt.
| Exempel 1:
Det finns en standard webbläsare som utför funktionen att följa den angivna länken när en knapp trycks ned. I det här fallet, för att automatisera regressionstestning, måste du skriva ett skript som skickar ett musklick och ett knappklick till webbläsaren, medan du för att skapa ett skript för belastningstestning måste skriva en hyperlänköverföring från webbläsaren till flera användare , inklusive ett unikt användarnamn och lösenord för var och en av dem. |
Det finns olika verktyg för att upptäcka och utreda problem i olika delar av systemet. Alla noder i systemet kan klassificeras enligt följande:
Också anmärkningsvärt är uppkomsten av nätverksanslutna Business-to-business (B2B)-applikationer som använder ett servicenivåavtal (eller SLA, Service Level Agreement). Den växande populariteten för B2B-applikationer har lett till att fler och fler applikationer går över till en tjänsteorienterad arkitektur , där utbyte av information sker utan medverkan av webbläsare. Ett exempel på sådan interaktion skulle vara en resebyrå som begär information om en specifik flygning mellan St. Petersburg och Omsk, medan flygbolaget måste ge ett svar inom 5 sekunder. Ofta hotar brott mot SLA-avtalet med stora böter.
De mest populära lasttestverktygen listas nedan.
| PÅ | Tillverkarens namn | Kommentarer |
|---|---|---|
| OpenSTA | "Testarkitektur för öppet system" | Fri programvara för belastnings-/stresstestning, licensierad under GNU GPL. Använder en distribuerad applikationsarkitektur baserad på CORBA . En Windows-version är tillgänglig, även om det finns kompatibilitetsproblem med Windows Vista. Supporten upphörde 2007. |
| IBM Rational Performance Tester | IBM | Baserat på utvecklingsmiljön Eclipse , programvara som låter dig skapa en stor belastning och mäta svarstiden för applikationer med en klient-server-arkitektur. Kräver licens. |
| jmeter | Öppna Apache Jakarta Project | Java-baserad plattformsoberoende verktygslåda som låter dig utföra belastningstester med JDBC / FTP / LDAP / SOAP / JMS / POP3 / HTTP / TCP-anslutningar. Det låter dig skapa ett stort antal förfrågningar från olika datorer och styra processen från en av dem. |
| HP LoadRunner | Micro Focus (köpt från HP) | Ett belastningstestverktyg som ursprungligen utvecklades för att efterlikna arbetet hos ett stort antal samtidiga användare. Kan även användas för enhets- eller integration . |
| Silk_Performer | Mikrofokus | |
| Visual Studio Load Test | Microsoft | Visual Studio tillhandahåller ett prestandatestverktyg inklusive last-/enhetstestning |
Ett av de resultat som erhållits under belastningstestning och som används för vidare analys är applikationens prestandaindikatorer. De viktigaste diskuteras nedan.
1. CPU resursförbrukning (CPU, %)Ett mått som visar hur mycket tid av ett givet definierat intervall som processorn spenderade på beräkningar för den valda processen. I moderna system är en viktig faktor förmågan hos en process att köras i flera trådar, så att processorn kan utföra beräkningar parallellt. Analys av CPU-resursförbrukningens historia kan förklara inverkan på systemets övergripande prestanda av bearbetade dataflöden, applikations- och operativsystemkonfiguration, flertrådig datoranvändning och andra faktorer.
2. Minnesanvändning (Mb)Ett mått som visar mängden minne som används av programmet. Användt minne kan delas in i tre kategorier:
När applikationen körs fylls minnet med referenser till objekt, som, om de inte används, kan rensas genom en speciell automatisk process som kallas "garbage collector" (Eng. Garbage Collector ). Den tid det tar för processorn att rensa upp minnet på detta sätt kan vara betydande när processen har förbrukat allt tillgängligt minne (i Java, den så kallade "persistent Full GC") eller när processen har tilldelats stora mängder minne som behöver städas upp. Under den tid det tar att rensa upp minnet kan en processs åtkomst till sidor med tilldelat minne blockeras, vilket kan påverka den slutliga bearbetningstiden för den processen.
3. Förbrukning av nätverksresurserDetta mått är inte direkt relaterat till applikationens prestanda, men dess indikatorer kan indikera prestandagränserna för systemet som helhet.
| Exempel 2:
Serverapplikationen, som behandlar användarens begäran, returnerar en videoström till honom med hjälp av en nätverkskanal på 2 megabit. Kravet anger att servern ska behandla 5 användarförfrågningar samtidigt. Lasttestning visade att servern effektivt kan tillhandahålla data till endast 4 användare samtidigt, eftersom multimediaströmmen har en bithastighet på 500 kilobit. Det är uppenbart att tillhandahållandet av denna ström till 5 användare samtidigt är omöjligt på grund av överskottet av nätverkskanalens bandbredd, vilket innebär att systemet inte uppfyller de specificerade prestandakraven, även om dess förbrukning av processor- och minnesresurser kan Nedan. |
Att arbeta med diskundersystemet kan avsevärt påverka systemets prestanda, så att samla in statistik om att arbeta med disken kan hjälpa till att identifiera flaskhalsar i detta område. Ett stort antal läsningar eller skrivningar kan göra att processorn går i viloläge medan den väntar på att data ska behandlas från disken, och som ett resultat ökar CPU-förbrukningen och ökar svarstiden.
5. Begär svarstid (ms)Exekveringstiden för en begäran av en applikation förblir en av de viktigaste indikatorerna på prestandan hos ett system eller en applikation. Denna tid kan mätas på serversidan som ett mått på den tid det tar för serversidan att behandla en begäran; och på klienten, som en indikator på den totala tiden som krävs för serialisering/deserialisering , vidarebefordran och bearbetning av begäran. Det bör noteras att inte alla prestandatestapplikationer kan mäta båda dessa tider.
Några av de vanligaste myterna listas nedan.
1. Prestandatestning görs för att bryta systemet. Stresstestning görs för att hitta den kritiska punkten för systemets styrka. I andra fall görs den vanliga lasttestningen för att undersöka systemets beteende under förväntad belastning. Beroende på andra krav kan stabilitetstestning, konfigurationstestning eller stresstestning krävas.
2. Benchmark-testning bör endast göras efter integration. Benchmark-testning Även om detta praktiskt taget är normen inom mjukvaruutvecklingsbranschen, kan prestandatester också göras i det inledande skedet av applikationsutveckling. Detta tillvägagångssätt kallas Early Performance Testing . Det främjar ett holistiskt tillvägagångssätt för utveckling med hänsyn till prestandaparametrar och minskar därmed inte bara chansen att hitta ett prestandaproblem precis innan release, utan också kostnaden för att åtgärda sådana problem.
3. Prestandatestning består endast av att skriva skript och varje ändring i applikationen resulterar i en liten refaktorisering av dessa skript. Prestandatestning i sig är en växande gren av mjukvaruindustrin . Även om skript är viktigt, är det bara en del av prestandatestning. Den svåraste uppgiften för en testare är att fastställa vilka tester som ska utföras och analysera olika prestandamått för att identifiera systemflaskhalsar.
Den andra delen av myten om små ändringar av skript stämmer inte heller, eftersom eventuella ändringar i användargränssnittet, särskilt i nätverksprotokollet, kommer att leda till en fullständig omskrivning av skripten från första början. Problemet blir mer märkbart när man använder protokoll som Web Services, Siebel, Citrix, SAP.
4. Stresstestning, lasttestning och stabilitetstestning är en och samma. En av de vanligaste myterna förknippade med ett missförstånd av terminologi. Stresstestning och belastningstestning är två olika typer av aktiviteter, som kallas den allmänna termen prestationstestning , och löser olika problem. Stresstestningens uppgift är att hitta den kritiska punkten för systemets hållfasthet under belastningar som är betydligt högre än förväntat eller oproportionerliga; Lasttestningens uppgift är att verifiera att systemet uppfyller kraven under förväntad belastning.
| Mjukvaruutveckling | |
|---|---|
| Bearbeta | |
Koncept på hög nivå | |
| Vägbeskrivning |
|
| Utvecklingsmetoder _ | |
| Modeller |
|
| Anmärkningsvärda siffror |
|