Testning av programvaruprestanda - Software performance testing

I kvalitetssäkring av programvara är prestandatestning i allmänhet en testmetod som utförs för att avgöra hur ett system fungerar när det gäller respons och stabilitet under en viss arbetsbelastning. Det kan också användas för att undersöka, mäta, validera eller kontrollera andra kvalitetsattribut i systemet, såsom skalbarhet , tillförlitlighet och resursanvändning.

Prestandatestning, en delmängd av prestandateknik , är en datavetenskaplig praxis som strävar efter att bygga prestandastandarder i implementering, design och arkitektur av ett system.

Testtyper

Lastprovning

Lastprovning är den enklaste formen av prestandatestning. Ett belastningstest utförs vanligtvis för att förstå systemets beteende under en specifik förväntad belastning. Denna belastning kan vara det förväntade samtidiga antalet användare i programmet som utför ett specifikt antal transaktioner inom den inställda varaktigheten. Detta test ger svarstider för alla viktiga affärskritiska transaktioner. Den databas , applikationsserver , etc. övervakas också under testet, kommer detta att hjälpa till att identifiera flaskhalsar i programmet och hårdvaran som programvaran är installerad på.

Stresstestning

Stresstester används normalt för att förstå de övre gränserna för kapacitet inom systemet. Denna typ av test görs för att bestämma systemets robusthet när det gäller extrem belastning och hjälper applikationsadministratörer att avgöra om systemet kommer att fungera tillräckligt om den nuvarande belastningen går långt över det förväntade maxvärdet.

Blötläggningstest

Blötprovning , även känd som uthållighetstest, görs vanligtvis för att avgöra om systemet kan upprätthålla den kontinuerliga förväntade belastningen. Under blötläggningstester övervakas minnesutnyttjandet för att upptäcka potentiella läckor. Också viktigt, men ofta förbisedd är prestandaförsämring, det vill säga att se till att genomströmningen och/eller svarstiderna efter en lång period av långvarig aktivitet är lika bra som eller bättre än i början av testet. Det innebär i huvudsak att applicera en betydande belastning på ett system under en längre, betydande tid. Målet är att upptäcka hur systemet beter sig under långvarig användning.

Spikprovning

Spikprovning görs genom att plötsligt öka eller minska belastningen som genereras av ett mycket stort antal användare och observera systemets beteende. Målet är att avgöra om prestanda kommer att drabbas, om systemet kommer att misslyckas, eller om det kommer att kunna hantera dramatiska förändringar i belastningen.

Brytpunktstestning

Brytpunktstestning liknar stresstester. En inkrementell belastning appliceras över tiden medan systemet övervakas för förutbestämda felförhållanden. Brytpunktstestning kallas ibland för kapacitetsprovning eftersom det kan sägas bestämma den maximala kapaciteten under vilken systemet kommer att utföra enligt sina krav eller servicenivåavtal. Resultaten av brytpunktsanalys som tillämpas på en fast miljö kan användas för att bestämma den optimala skalningsstrategin när det gäller erforderlig hårdvara eller förhållanden som ska utlösa skalningshändelser i en molnmiljö.

Konfigurationstestning

I stället för att testa prestanda ur ett lastperspektiv skapas tester för att bestämma effekterna av konfigurationsändringar i systemets komponenter på systemets prestanda och beteende. Ett vanligt exempel är att experimentera med olika metoder för lastbalansering .

Isoleringstestning

Isoleringstestning är inte unik för prestandatestning utan innebär att en testkörning upprepas som resulterade i ett systemproblem. Sådan testning kan ofta isolera och bekräfta feldomänen.

Internettestning

Detta är en relativt ny form av prestandatestning när globala applikationer som Facebook, Google och Wikipedia testas prestanda från lastgeneratorer som placeras på själva målkontinenten, oavsett om det är fysiska maskiner eller virtuella molnmaskiner. Dessa test kräver vanligtvis en enorm mängd förberedelser och övervakning för att kunna genomföras framgångsrikt.

Sätta prestationsmål

Prestandatester kan tjäna olika syften:

  • Det kan visa att systemet uppfyller prestandakriterier.
  • Den kan jämföra två system för att hitta vilka som fungerar bättre.
  • Den kan mäta vilka delar av systemet eller arbetsbelastningen som får systemet att fungera dåligt.

Många prestandatester genomförs utan att sätta tillräckligt realistiska, målorienterade prestationsmål. Den första frågan ur ett affärsperspektiv bör alltid vara "varför testar vi prestanda?". Dessa överväganden är en del av affärsnyttan av testningen. Prestandamålen varierar beroende på systemets teknik och syfte, men bör alltid innehålla några av följande:

Samtidighet och genomströmning

Om ett system identifierar slutanvändare genom någon form av inloggningsprocedur är ett samtidighetsmål mycket önskvärt. Per definition är detta det största antalet samtidiga systemanvändare som systemet förväntas stödja vid ett givet tillfälle. Arbetsflödet för en skriptad transaktion kan påverka verklig samtidighet, särskilt om den iterativa delen innehåller in- och utloggningsaktiviteten.

Om systemet inte har något begrepp om slutanvändare kommer prestandamålet sannolikt att baseras på en maximal genomströmning eller transaktionshastighet.

Server svarstid

Detta avser den tid det tar för en systemnod att svara på en annan begäran. Ett enkelt exempel skulle vara en "GET" -förfrågan från HTTP från webbläsarklient till webbserver. När det gäller svarstid är detta vad alla lasttestverktyg faktiskt mäter. Det kan vara relevant att sätta serverns responstidsmål mellan alla noder i systemet.

Gör svarstid

Lasttestverktyg har svårt att mäta render-responstid, eftersom de i allmänhet inte har någon uppfattning om vad som händer inom en nod förutom att känna igen en tidsperiod där det inte finns någon aktivitet "på tråden". För att mäta svarstid för render är det i allmänhet nödvändigt att inkludera funktionella testskript som en del av prestandatestscenariot. Många lasttestverktyg erbjuder inte den här funktionen.

Prestandaspecifikationer

Det är viktigt att specificera prestandaspecifikationer (krav) och dokumentera dem i en prestandatestplan. Helst görs detta under kravutvecklingsfasen för alla systemutvecklingsprojekt, före eventuella konstruktionsansträngningar. Se Performance Engineering för mer information.

Prestandatestning utförs dock ofta inte mot en specifikation; t ex kommer ingen att ha uttryckt vad den maximala acceptabla responstiden för en given population av användare ska vara. Prestandatester används ofta som en del av processen för prestationsprofilinställning. Tanken är att identifiera den "svagaste länken" - det finns oundvikligen en del av systemet som, om det görs för att svara snabbare, kommer att resultera i att det övergripande systemet fungerar snabbare. Det är ibland en svår uppgift att identifiera vilken del av systemet som representerar denna kritiska väg, och några testverktyg inkluderar (eller kan ha tillägg som tillhandahåller) instrumentation som körs på servern (agenter) och rapporterar transaktionstider, databasåtkomsttider , nätverksoverhead och andra servermonitorer, som kan analyseras tillsammans med råprestandastatistiken. Utan sådan instrumentering kan man behöva ha någon hukad över Windows Aktivitetshanterare på servern för att se hur mycket CPU -belastning prestandatesterna genererar (förutsatt att ett Windows -system testas).

Prestandatestning kan utföras över hela webben, och till och med utföras i olika delar av landet, eftersom det är känt att svarstiderna på internet i sig varierar regionalt. Det kan också göras internt, även om routrar då skulle behöva konfigureras för att införa den fördröjning som vanligtvis skulle inträffa på offentliga nätverk. Belastningar bör införas i systemet från realistiska punkter. Till exempel, om 50% av ett systems användarbas kommer att komma åt systemet via en 56K modemanslutning och den andra halvan över en T1 , bör lastinjektorerna (datorer som simulerar verkliga användare) antingen injicera belastning över samma blandning av anslutningar (ideal) eller simulera nätverkslatensen för sådana anslutningar, efter samma användarprofil.

Det är alltid bra att ha ett uttalande om det troliga toppantalet användare som kan förväntas använda systemet vid högtider. Om det också kan finnas ett uttalande om vad som utgör den högsta tillåtna svarstiden på 95 procentil, kan en injektorkonfiguration användas för att testa om det föreslagna systemet uppfyllde den specifikationen.

Frågor att ställa

Prestandaspecifikationer bör ställa minst följande frågor:

  • I detalj, vad är prestandatestets omfattning? Vilka delsystem, gränssnitt, komponenter etc. är in och utanför tillämpningsområdet för detta test?
  • Hur många samtidiga användare förväntas för varje användargränssnitt (UI) (ange topp vs. nominell)?
  • Hur ser målsystemet (hårdvaran) ut (ange alla server- och nätverksapparatkonfigurationer)?
  • Vilken är applikationsarbetsbelastningsmixen för varje systemkomponent? (till exempel: 20% inloggning, 40% sökning, 30% objektval, 10% kassa).
  • Vad är System Workload Mix? [Flera arbetsbelastningar kan simuleras i ett enda prestandatest] (till exempel: 30% arbetsbelastning A, 20% arbetsbelastning B, 50% arbetsbelastning C).
  • Vad är tidskraven för alla/alla back-end-batchprocesser (ange topp vs. nominell)?

Förkunskaper

En stabil konstruktion av systemet som måste likna produktionsmiljön så nära som möjligt.

För att säkerställa konsekventa resultat bör prestandatestmiljön isoleras från andra miljöer, till exempel test av användaracceptans (UAT) eller utveckling. Som bästa praxis är det alltid lämpligt att ha en separat prestandatestmiljö som liknar produktionsmiljön så mycket som möjligt.

Testvillkor

Vid prestandatestning är det ofta avgörande att testförhållandena liknar den förväntade faktiska användningen. I praktiken är detta dock svårt att ordna och inte helt möjligt, eftersom produktionssystem utsätts för oförutsägbara arbetsbelastningar. Testbelastningar kan efterlikna händelser i produktionsmiljön så långt som möjligt, men bara i de enklaste systemen kan man exakt replikera denna arbetsbelastningsvariabilitet.

Löst kopplade arkitektoniska implementeringar (t.ex. SOA ) har skapat ytterligare komplexitet med prestandatestning. För att verkligen replikera produktionsliknande tillstånd, företagstjänster eller tillgångar som delar en gemensam infrastruktur eller plattform krävs samordnad prestandatestning, där alla konsumenter skapar produktionsliknande transaktionsvolymer och belastar delade infrastrukturer eller plattformar. Eftersom denna aktivitet är så komplex och kostsam i pengar och tid, använder vissa organisationer nu verktyg för att övervaka och simulera produktionsliknande förhållanden (även kallat "buller") i sina prestandatestmiljöer ( PTE ) för att förstå kapacitet och resurskrav och verifiera / validera kvalitetsattribut.

Tidpunkt

Det är avgörande för kostnadsprestanda för ett nytt system att prestandatestförsök börjar vid utvecklingsprojektets början och sträcker sig till distribution. Ju senare en prestandafel upptäcks, desto högre blir kostnaden för sanering. Detta är sant när det gäller funktionstestning, men ännu mer med prestandatester, på grund av dess omfattning från ände till ände. Det är avgörande för ett prestandatestteam att vara med så tidigt som möjligt, eftersom det är tidskrävande att skaffa och förbereda testmiljön och andra viktiga prestandakrav.

Verktyg

Prestandatestning är huvudsakligen uppdelad i två huvudkategorier:

Prestandaskript

Denna del av prestandatestning handlar främst om att skapa/skripta arbetsflödena för viktiga identifierade affärsprocesser. Detta kan göras med en mängd olika verktyg.

Var och en av verktygen som nämns i listan ovan (som inte är uttömmande eller komplett) använder antingen ett skriptspråk (C, Java, JS) eller någon form av visuell representation (dra och släpp) för att skapa och simulera slutanvändares arbetsflöden. De flesta av verktygen möjliggör något som kallas "Record & Replay", där i prestandatestaren kommer att starta testverktyget, koppla det till en webbläsare eller tjock klient och fånga alla nätverkstransaktioner som händer mellan klienten och servern. Därigenom utvecklas ett manus som kan förbättras/modifieras för att efterlikna olika affärsscenarier.

Prestandaövervakning

Detta utgör det andra ansiktet på prestandatester. Med prestandaövervakning observeras beteendet och svarsegenskaperna hos den applikation som testas. Nedanstående parametrar övervakas vanligtvis under utförandet av ett prestandatest

Serverhårdvaruparametrar

  • CPU -användning
  • Minnesutnyttjande
  • Diskanvändning
  • Nätverksanvändning

Som ett första steg ger de mönster som genereras av dessa 4 parametrar en bra indikation på var flaskhalsen ligger. För att avgöra den exakta orsaken till problemet använder programvaruingenjörer verktyg som profiler för att mäta vilka delar av en enhet eller programvara som bidrar mest till dålig prestanda, eller för att fastställa genomströmningsnivåer (och trösklar) för bibehållen acceptabel svarstid.

Teknologi

Prestandatestningsteknik använder en eller flera datorer eller Unix -servrar för att fungera som injektorer, var och en emulerar förekomsten av antal användare och var och en kör en automatiserad sekvens av interaktioner (inspelade som ett skript eller som en serie skript för att emulera olika typer av användare interaktion) med värden vars prestanda testas. Vanligtvis fungerar en separat dator som en testledare, som koordinerar och samlar mätvärden från var och en av injektorerna och samlar prestandadata för rapporteringsändamål. Den vanliga sekvensen är att öka belastningen: att börja med några virtuella användare och öka antalet över tiden till ett förutbestämt maximum. Testresultatet visar hur prestandan varierar med belastningen, givet som antal användare jämfört med responstid. Olika verktyg finns tillgängliga för att utföra sådana tester. Verktyg i denna kategori utför vanligtvis en uppsättning tester som efterliknar riktiga användare mot systemet. Ibland kan resultaten avslöja konstigheter, till exempel att även om den genomsnittliga svarstiden kan vara acceptabel, finns det avvikelser för några få viktiga transaktioner som tar betydligt längre tid att slutföra - något som kan orsakas av ineffektiva databasfrågor, bilder etc.

Prestandatester kan kombineras med stresstester för att se vad som händer när en acceptabel belastning överskrids. Kraschar systemet? Hur lång tid tar det att återhämta sig om en stor belastning minskar? Orsakar dess misslyckande säkerhetsskador?

Analytisk prestandamodellering är en metod för att modellera beteendet hos ett system i ett kalkylblad. Modellen matas med mätningar av transaktionsresursbehov ( CPU , disk I/O, LAN , WAN ), viktat av transaktionsmixen (affärstransaktioner per timme). De vägda transaktionsresursbehovet summeras för att erhålla resurskrav per timme och divideras med resurskapaciteten per timme för att erhålla resursbelastningar. Med hjälp av svarstidsformeln (R = S/(1-U), R = responstid, S = servicetid, U = belastning) kan svarstider beräknas och kalibreras med resultaten av prestandatesterna. Analytisk prestandamodellering gör det möjligt att utvärdera designalternativ och systemstorlek baserat på verklig eller förväntad affärsanvändning. Det är därför mycket snabbare och billigare än prestandatestning, även om det kräver grundlig förståelse för hårdvaruplattformarna.

Uppgifter att utföra

Uppgifter för att utföra ett sådant test skulle omfatta:

  • Besluta om du vill använda interna eller externa resurser för att utföra testerna, beroende på egen expertis (eller brist på det).
  • Samla eller framkalla krav på prestanda (specifikationer) från användare och/eller affärsanalytiker.
  • Utveckla en plan på hög nivå (eller projektcharter), inklusive krav, resurser, tidslinjer och milstolpar.
  • Utveckla en detaljerad prestandatestplan (inklusive detaljerade scenarier och testfall , arbetsbelastning, miljö info, etc.).
  • Välj testverktyg .
  • Ange testdata som behövs och charteransträngning (ofta förbises, men avgörande för att utföra ett giltigt prestandatest).
  • Utveckla proof-of-concept- skript för varje applikation/komponent som testas med hjälp av utvalda testverktyg och strategier.
  • Utveckla detaljerad prestandatestprojektplan, inklusive alla beroenden och tillhörande tidslinjer.
  • Installera och konfigurera injektorer/styrenhet.
  • Konfigurera testmiljön (idealiskt identisk hårdvara med produktionsplattformen), routerkonfiguration, tyst nätverk (vi vill inte att resultaten ska störas av andra användare), distribution av serverinstrument, databastestuppsättningar utvecklade osv.
  • Torrkörning av testerna - innan lasttestet faktiskt utförs med fördefinierade användare utförs en torrkörning för att kontrollera att skriptet är korrekt.
  • Utför tester-förmodligen upprepade gånger (iterativt) för att se om någon faktor som inte är redovisad kan påverka resultaten.
  • Analysera resultaten - antingen godkänt/misslyckat eller undersökning av kritisk väg och rekommendation av korrigerande åtgärder.

Metodik

Prestandatestning av webbapplikationer

Enligt Microsoft Developer Network består prestandatestmetoden av följande aktiviteter:

  1. Identifiera testmiljön. Identifiera den fysiska testmiljön och produktionsmiljön samt de verktyg och resurser som är tillgängliga för testteamet. Den fysiska miljön inkluderar hårdvara, programvara och nätverkskonfigurationer. Att ha en grundlig förståelse av hela testmiljön från början möjliggör effektivare testdesign och planering och hjälper dig att identifiera testutmaningar tidigt i projektet. I vissa situationer måste denna process ses över regelbundet under projektets livscykel .
  2. Identifiera kriterier för godkännande av prestanda. Identifiera responstid, genomströmning och mål och begränsningar för resursanvändning. I allmänhet är svarstid ett användarproblem, genomströmning är ett affärsproblem och resursanvändning är ett systemproblem. Identifiera dessutom projekts framgångskriterier som kanske inte fångas upp av dessa mål och begränsningar; till exempel att använda prestandatester för att utvärdera vilken kombination av konfigurationsinställningar som kommer att resultera i de mest önskvärda prestandaegenskaperna.
  3. Planera och designa tester. Identifiera viktiga scenarier , bestäm variationen bland representativa användare och hur man simulerar den variabiliteten, definiera testdata och fastställ mätvärden som ska samlas in. Konsolidera denna information till en eller flera modeller av systemanvändning som ska implementeras, köras och analyseras.
  4. Konfigurera testmiljön. Förbered testmiljön, verktygen och resurserna som är nödvändiga för att utföra varje strategi, eftersom funktioner och komponenter blir tillgängliga för test. Se till att testmiljön är nödvändig för resursövervakning.
  5. Implementera testdesignen. Utveckla prestandatesterna i enlighet med testdesignen.
  6. Utför testet. Kör och övervaka dina tester. Validera tester, testdata och resultatinsamling . Utför validerade tester för analys medan du övervakar testet och testmiljön.
  7. Analysera resultat, ställ in och testa igen. Analysera, konsolidera och dela resultatdata. Gör en inställningsändring och testa igen. Jämför resultaten från båda testerna. Varje förbättring ger mindre förbättringar än den tidigare förbättringen. När slutar du? När du når en CPU -flaskhals är alternativen antingen att förbättra koden eller lägga till mer CPU.

Se även