Testledning i praktiken: Att hantera prestandatestning
Redaktörens anmärkning: Välkommen till serien Ledarskap inom testning från mjukvarutestningsgurun och konsulten Paul Gerrard. Serien är utformad för att hjälpa testare med några års erfarenhet – särskilt de som arbetar i agila team – att lyckas i sina roller som testledare och testchefer.
I den föregående artikeln utforskade vi tjänstetestning och dess huvudkomponenter: prestandatestning, redundansväxlingstester/uthållighetstester och hanterbarhet. Som utlovat kommer vi här att utforska prestandatestning lite mer i detalj.
Prenumerera på nyhetsbrevet från The QA Lead för att få ett meddelande när nya delar av serien publiceras. Dessa inlägg är utdrag ur Pauls kurs i ledarskap inom testning, som vi varmt rekommenderar om du vill fördjupa dig i detta och andra ämnen. Om du gör det, använd vår exklusiva kupongkod QALEADOFFER för att få 60 dollar rabatt på det fullständiga kurspriset!
Hej och välkommen till serien Ledarskap inom testning. I den förra artikeln tittade vi på tjänstetestning för webbapplikationer.
Syftet med det här kapitlet är att ge råd och bästa praxis för hantering av en kritisk komponent inom tjänstetestning som nämndes i den artikeln. Och nu kommer trumvirveln … prestandatestning!
Vi kommer att gå igenom:
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
- Mål för prestandatestning
- Fyra förutsättningar för ett prestandatest
- Verktygslåda för prestandatestning
- Processen för prestandatestning
Då kör vi.
Mål för prestandatestning
Som en snabb repetition kan vi definiera det primära målet med prestandatestning så här:
”Att visa att systemet fungerar enligt specifikationen, med godtagbara svarstider, samtidigt som det bearbetar de transaktionsvolymer som krävs i en databas av produktionsstorlek.”
Din prestandatestmiljö är en testbädd som kan användas för andra tester med bredare mål, som vi kan sammanfatta så här:
- Bedöma systemets kapacitet för tillväxt (Om du är osäker på vilken programvara som kan hantera dina behov kan vår lista över de bästa lösningarna för databashantering hjälpa dig.)
- Identifiera svaga punkter i arkitekturen
- Finjustera systemet
- Upptäcka svåridentifierade fel i programvaran
- Verifiera motståndskraft och tillförlitlighet.
Din teststrategi bör definiera kraven på en testinfrastruktur som gör det möjligt att uppfylla alla dessa mål.
Fyra förutsättningar för ett prestandatest
”Om någon av dessa förutsättningar saknas bör du vara mycket försiktig innan du går vidare med att köra tester och publicera resultat. Att använda verktyg för automatisering av kvalitetssäkring kan hjälpa till att säkerställa att dessa förutsättningar är uppfyllda. Testerna kan vara svåra eller omöjliga att genomföra, eller så kan trovärdigheten hos publicerade resultat vara allvarligt bristfällig och lätt att ifrågasätta.”
1. Kvantitativa, relevanta, mätbara, realistiska och uppnåeliga krav
Som grund för alla tester bör prestandakraven (målen) fastställas innan testet, så att det går att avgöra om systemet uppfyller dessa krav.
Krav på systemets genomströmning eller svarstider bör, för att vara användbara som baslinje vid jämförelse av prestandaresultat, ha följande egenskaper. De måste vara:
- Uttryckta i kvantifierbara termer.
- Relevanta för den uppgift som användaren vill utföra.
- Mätbara med hjälp av ett verktyg (eller ett stoppur) till en rimlig kostnad.
- Realistiska jämfört med hur lång tid användaruppgiften tar.
- Uppnåeliga till en rimlig kostnad.
Ofta är prestandakraven vaga eller saknas helt. Försök hitta dokumenterade krav om du kan. Om det finns luckor kan du behöva dokumentera dem i efterhand.
Innan ett prestandatest kan specificeras och utformas måste krav fastställas för:
- Svarstider för transaktioner.
- Lastprofiler (antalet användare och transaktionsvolymer som ska simuleras).
- Databasvolymer (antalet poster i databastabeller som förväntas i produktion).
Det är vanligt att prestandakraven definieras i vaga termer. Dessa krav baseras ofta på ungefärligt uppskattade prognoser för verksamhetsvolymer, och det kan därför vara nödvändigt att få verksamhetsanvändarna att tänka realistiskt kring prestandakraven.
Du kan också behöva utföra en del av kravanalysen själv och dokumentera dessa krav som de avsedda prestandamålen.
2. Ett stabilt system
Om systemet är felbehäftat och opålitligt kommer du inte långt med ett prestandatest. Prestandatester belastar alla arkitekturkomponenter i någon utsträckning. Men för att prestandatestning ska ge användbara resultat måste systemet och den tekniska infrastrukturen från början vara rimligt tillförlitliga och motståndskraftiga.
3. Realistisk testmiljö
Testmiljön måste konfigureras så att testet blir meningsfullt. Du kan förmodligen inte återskapa mål- eller produktionssystemet, men testmiljön bör helt eller delvis vara jämförbar med den slutliga produktionsmiljön. Du behöver komma överens med systemets arkitekt om vilka kompromisser som är acceptabla och vilka som inte är det, eller åtminstone om vilken användbar tolkning som kan göras av testresultaten.
Att skapa en realistisk testmiljö är avgörande för meningsfulla prestandatester. För verktyg som kan hjälpa dig att simulera verkliga förhållanden kan du ta en titt på vårt handplockade urval av plattformar för programvarutestning
4. Kontrollerad testmiljö
Prestandatestare kräver stabilitet. Det gäller inte bara tillförlitligheten och motståndskraften hos maskinvara och programvara, utan även att förändringar i miljön eller den programvara som testas minimeras. Om exempelvis gränssnittet ändras ens något är testskript som utformats för att styra användargränssnitt ofta benägna att omedelbart misslyckas.
Alla förändringar i miljön bör kontrolleras strikt. Om förändringen åtgärdar fel som sannolikt inte påverkar prestandan kan du överväga att inte godkänna leveransen. Endast förändringar som är avsedda att förbättra prestandan eller tillförlitligheten bör godkännas.
Verktygslåda för prestandatestning
Din verktygslåda för prestandatestning består av fem huvudverktyg:
- Skapande och underhåll av testdata – för att skapa de stora datamängder i databasen som krävs för testet. Vi förväntar oss att detta är ett SQL-baserat verktyg eller kanske en datorbaserad produkt som Microsoft Access, ansluten till testdatabasen.
- Lastgenerering – de vanligaste verktygen använder testdrivrutiner som simulerar virtuella klienter genom att skicka HTTP-meddelanden till webbservrar.
- Verktyg för att köra applikationen – detta styr en eller flera instanser av applikationen via webbläsargränssnittet och registrerar mätningar av svarstider. (Detta är vanligtvis samma verktyg som används för lastgenerering, men det behöver inte vara det.)
- Resursövervakning – verktyg som övervakar och loggar klient- och serversystemresurser, nätverkstrafik, databasaktivitet med mera.
- Resultatanalys och rapportering – verktyg för testkörning och resursövervakning genererar stora mängder resultatdata för analys.
Relaterad läsning: DE 10 BÄSTA SQL-ANALYSTJÄNSTERNA FÖR QA-TEAM
Processen för prestandatestning
Nedan visas en figur som beskriver en generell process för prestandatestning och finjustering. Finjustering är egentligen inte en del av testprocessen, men den är en oskiljaktig del av arbetet med att förbättra prestanda och tillförlitlighet. Finjustering kan innebära ändringar i den arkitektoniska infrastrukturen, men bör inte påverka funktionaliteten hos systemet som testas.
Nu ska vi titta på hur man utvecklar, genomför, analyserar och rapporterar om ett prestandatest.
Inkrementell testutveckling
Testutveckling utförs vanligtvis stegvis i fyra faser:
- Varje testskript förbereds och testas separat för att felsökas.
- Skripten integreras i den version av arbetsbelastningen som är under utveckling, och arbetsbelastningen körs för att testa att det nya skriptet är kompatibelt.
- När arbetsbelastningen växer förfinas, felsöks och görs det testningsramverk som utvecklas kontinuerligt mer tillförlitligt. Erfarenheten av och förtrogenheten med verktygen ökar också.
- När det sista skriptet har integrerats i arbetsbelastningen körs testet som en ”torrkörning” för att säkerställa att det är helt repeterbart och tillförlitligt samt redo för de formella testerna.
Interimistiska tester kan ge användbara resultat
Körningar av den partiella arbetsbelastningen och testtransaktionerna kan avslöja prestandaproblem. Tester med låg belastning kan också ge en tidig indikation på nätverkstrafik och potentiella flaskhalsar när testet skalas upp.
Långa svarstider kan orsakas av bristande applikationsdesign och kan undersökas och åtgärdas av utvecklarna tidigare. Tidiga tester kan också köras under längre perioder som uthållighetstester.
Testkörning
Testkörning kräver viss etapphantering eller samordning. Du bör samarbeta med de deltagare som ger stöd och övervakar systemet medan du kör testerna. Teamet för ”testövervakning” kan vara distribuerat, så du behöver hålla dem informerade om testet ska genomföras smidigt och resultaten registreras korrekt.
Utöver samordningen av de olika teammedlemmarna följer körning av prestandatester vanligtvis en standardiserad rutin.
- Förbered databasen (återställ från band om det behövs).
- Förbered testmiljön efter behov och verifiera dess tillstånd.
- Starta övervakningsprocesser (nätverk, klienter och servrar, databas).
- Starta belastningssimuleringen och observera systemövervakaren eller systemövervakarna.
- Om ett separat verktyg används ska du, när belastningen är stabil, starta verktyget för körning av applikationstester och mätning av svarstider.
- Övervaka testet noggrant under hela testets varaktighet.
- Om verktygen för testkörning inte stoppas automatiskt ska du avsluta testet när testperioden är slut.
- Stoppa övervakningsverktygen och spara resultaten.
- Arkivera alla insamlade resultat och se till att alla resultatdata säkerhetskopieras på ett säkert sätt.
- Ta fram interimistiska rapporter och diskutera eventuella avvikelser med andra teammedlemmar.
- Förbered analyser och rapporter.
Det kan vara utmanande att samordna olika teammedlemmar under testkörningen. Effektivisera processen genom att integrera avancerade testhanteringsverktyg utformade för Jira, som erbjuder funktioner som samarbete och rapportering i realtid
Finjustering följer vanligtvis efter testning när det finns problem eller när kända optimeringsmöjligheter finns. Om ett test körs på nytt är det viktigt att alla förändringar i miljön dokumenteras. På så sätt kan skillnader i systemets beteende och därmed prestandaresultaten kopplas till förändringarna i konfigurationen.
När det gäller hantering av testfall för prestandatester kan programvara för testhantering förändra förutsättningarna avsevärt. Den möjliggör bättre organisering, uppföljning och till och med automatisering av testfall.
Som regel är det klokt att ändra endast en sak i taget, så att skillnader i beteendet kan spåras tillbaka till de ändringar som gjorts när de upptäcks.
Resultatanalys och rapportering
Den vanligaste rapporten för en testkörning sammanfattar dessa mätningar, och för varje genomförd mätning rapporteras följande:
- Antalet mätningar.
- Minsta svarstid.
- Största svarstid.
- Genomsnittlig svarstid.
- Svarstid vid den n:te percentilen (vanligtvis den 95e percentilen).
Verktyget för belastningsgenerering i din verktygslåda bör registrera antalet transaktioner av varje typ under testperioden. Om dessa antal divideras med testets varaktighet får man den transaktionshastighet eller genomströmning som faktiskt uppnåddes.
Antalet transaktioner utgör den belastning som tillämpas på systemet. Detta förutsätter att proportionerna mellan de genomförda transaktionerna motsvarar den belastningsprofil du försöker tillämpa.
Den tillämpade belastningen bör motsvara den simulerade belastningsprofilen – men kanske inte gör det om systemet svarar långsamt och transaktionerna körs med varierande hastighet.
Vanligtvis genomför du en serie testkörningar med varierande belastning. Använd resultaten från en serie tester för att rita en graf över svarstiden för en transaktion i förhållande till den belastning som tillämpats.
Verktyg för resursövervakning har vanligtvis statistiska eller grafiska rapportfunktioner som visar resursanvändningen över tid. Förbättrade rapporter över resursanvändning i förhållande till tillämpad belastning är mycket användbara och kan underlätta identifieringen av flaskhalsar i ett systems arkitektur.
Lycka till!
Prenumerera på nyhetsbrevet från The QA Lead för att få meddelanden när nya delar av serien publiceras. Dessa inlägg är utdrag ur Pauls kurs i ledarskap inom testning, som vi varmt rekommenderar om du vill fördjupa dig i detta och andra ämnen. Om du gör det kan du använda vår exklusiva kupongkod QALEADOFFER och få $60 rabatt på det ordinarie kurspriset!
Relaterad läsning: SERVERÖVERVAKNINGSMÅTT ATT FÖLJA FÖR SYSTEMHÄLSA OCH PRESTANDA
