Belastningstestning är en undertyp av prestandatestning, insamling av indikatorer och bestämning av prestanda och svarstid för ett mjukvaru- och hårdvarusystem eller -enhet som svar på en extern begäran för att fastställa överensstämmelse med kraven för detta system (enhet).
För att studera systemets svarstid vid höga eller toppbelastningar utförs stresstestning , där belastningen som skapas på systemet överstiger de normala scenarierna för dess användning. Det finns ingen tydlig gräns mellan belastningstestning och stresstester, men de två bör inte förväxlas eftersom dessa typer av tester svarar på olika affärsfrågor och använder olika metoder.
I allmänhet hänvisar belastningstestning till praktiken att modellera den förväntade användningen av en applikation genom att emulera flera användares arbete samtidigt. Således är sådan testning mest lämpad för fleranvändarsystem, oftast med en klient-server-arkitektur (till exempel webbservrar). Andra typer av mjukvarusystem kan dock testas på liknande sätt. Till exempel kan en text- eller grafikredigerare fås att läsa ett mycket stort dokument; och det finansiella paketet ska generera en rapport baserad på data för flera år. Det mest adekvat utformade belastningstestet ger mer exakta resultat.
I det ideala fallet är kriterierna för framgång med lasttestning kraven på systemets prestanda, som formuleras och dokumenteras vid utvecklingen av funktionskraven för systemet innan de huvudsakliga arkitektoniska lösningarna programmeras. Det händer dock ofta att sådana krav inte var tydligt formulerade eller inte var formulerade alls. I det här fallet kommer den första lasttestningen att vara utforskande lasttestning och baseras på rimliga antaganden om den förväntade lasten och hårdvarans resursförbrukning .
En av de bästa metoderna för att använda lasttestning för att mäta systemprestanda är testning i ett tidigt utvecklingsskede. Belastningstestning i de första stadierna av beredskapen av en arkitektonisk lösning för att fastställa dess livskraft kallas "proof-of-concept"-testning.
Det unika med förfrågningar - även om du har skapat ett realistiskt scenario för att arbeta med systemet baserat på dess användningsstatistik, måste du förstå att det alltid kommer att finnas undantag från detta scenario.
Systemsvarstid - i allmänhet följer systemets svarstid normalfördelningsfunktionen . I synnerhet betyder detta att det, med ett tillräckligt antal mätningar, är möjligt att bestämma sannolikheten med vilken systemets svar på en begäran kommer att falla inom ett visst tidsintervall.
Beroendet av systemets svarstid på distributionsgraden av detta system - variansen mellan normalfördelningen av systemets svarstid på en begäran är proportionell mot förhållandet mellan antalet systemnoder som behandlar sådana förfrågningar parallellt och antalet förfrågningar per nod. Det vill säga spridningen av systemsvarstidsvärden påverkas samtidigt av antalet förfrågningar som faller på varje nod i systemet och antalet noder i sig, som var och en lägger till en slumpmässig mängd fördröjningar i behandlingen av förfrågningar.
Variation i systemets svarstid - med ett tillräckligt stort antal mätningar av värdet av förfrågningsbehandlingstiden i vilket system som helst, kommer det alltid att finnas förfrågningar vars handläggningstid överskrider de maximivärden som definieras i kraven; dessutom, ju längre den totala tiden för experimentet, desto högre blir de nya maxima. Detta faktum tas med i beräkningen när kraven på systemets prestanda ställs, såväl som vid regelbunden belastningstestning.
Lastprofiltrohet - Den erforderliga lastprofiltroheten är dyrare ju fler komponenter systemet innehåller. Det är ofta inte möjligt att ta hänsyn till alla aspekter av lastprofilen för komplexa system, eftersom ju mer komplext systemet är, desto mer tid kommer att läggas på att designa, programmera och underhålla en adekvat lastprofil för det, vilket inte alltid är nödvändigt. Det optimala tillvägagångssättet i detta fall är att balansera mellan kostnaden för att utveckla ett test och täckningen av systemfunktionaliteten, som ett resultat av vilket det finns antaganden om inverkan på den övergripande prestandan för en eller annan del av systemet som testas.
Några lasttestverktyg [1] [2] :
| 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 | HP | Ett belastningstestverktyg som ursprungligen utvecklades för att efterlikna arbetet hos ett stort antal samtidiga användare. Den kan också användas för enhets- eller integrationstestning . |
| LoadComplete | Smart björn | Proprietär produkt som låter dig ladda testwebbapplikationer |
| SilkPerformer | Micro Focus (Borland) | |
| Belägring | Joe Dog programvara | Siege är ett testverktyg för webbserverbelastning. [3] |
| Visual Studio Team System | Microsoft | Visual Studio tillhandahåller ett prestandatestverktyg inklusive last-/enhetstestning |
| QTest | Quotium | |
| httperf | ||
| QALoad | Compuware Ltd. | |
| (Den) Kvarnen | ||
| WebLOAD | RadView programvara | Lasttestverktyg för webb- och mobilapplikationer inklusive webbinstrumentpaneler för analys av prestandatestning. Används för storskaliga arbetsbelastningar som även kan genereras från molnet. licensierad. [fyra] |
Ett av de resultat som erhållits under belastningstestning och som används för vidare analys är applikationens prestandaindikatorer.
CPU-resursförbrukning är ett mått som visar hur mycket tid av ett givet specifikt 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.
RAM-förbrukning är ett mått som visar mängden minne som används av en applikation. Användt minne är indelat i flera kategorier:
När en applikation körs fylls minnet med referenser till objekt, som, om de inte används, kan rensas upp med en speciell automatisk process som kallas 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.
Nätverksresursförbrukning är ett mått som inte är direkt relaterat till applikationsprestanda, men dess indikatorer kan indikera prestandagränserna för systemet som helhet.
I/O-undersystemets prestanda kan avsevärt påverka systemets prestanda, så att samla in statistik om att arbeta med enheter kan hjälpa till att identifiera flaskhalsar inom 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 förbrukningen av processorresurser och ökar svarstiden.
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 tid som krävs för serialisering och deserialisering , vidarebefordran och bearbetning av begäran. Men inte alla prestandatestapplikationer kan mäta båda dessa tider.