Performance Engineering

Performance engineering (eng. Performance engineering ) - en del av systemteknik , som inkluderar en uppsättning roller, kunskap, praxis, verktyg och resultat och som används i varje steg av mjukvaruutvecklingscykeln för att säkerställa att den arkitektoniska lösningen skapade, programmerade och stödda icke-funktionella prestandakrav för denna lösning.

Samma term kan också användas för att referera till Software Performance Engineering , men eftersom Performance Engineering inte bara inkluderar programvara, är det att föredra att använda det vanliga namnet.

Performance engineering har vuxit fram som en egen disciplin i flera stora företag och ingår vanligtvis i systemarkitekturdivisionen. Performance engineering kan föra samman människor från olika verksamhetsområden, men är främst inriktad på personer från informationsteknikområdet.

Mål för Performance Engineering

Öka verksamhetens ROI genom att verifiera att systemet kan behandla transaktioner inom en given tidsram.
Förhindra att det byggs system som kräver att man skriver kod från grunden om de prestationsmål som dokumenterats i kraven inte har uppnåtts.
Förhindra förseningar av systemdistribution på grund av prestandaproblem.
Förhindra omarbetning av systemet på grund av prestandaproblem som kan undvikas.
Förhindra systemjusteringsinsatser som kunde ha undvikits.
Undvik extra och onödiga hårdvarukostnader.
Minska de ökade kostnaderna för programvarusupport under underhållsfasen på grund av upptäckta prestandaproblem.
Minska de ökade kostnaderna för programvarusupport på grund av icke-systemiska korrigeringar för prestandaproblem.

Tillvägagångssätt

På grund av det faktum att denna industri kan tillämpas i olika metoder för mjukvaruutveckling , kan aktiviteterna som beskrivs nedan utföras i olika skeden. Vid användning av RUP-metoden ( Rational Unified Process ), kommer deras ordning att vara följande:

Början

I stadiet av att utveckla konceptet för en applikation eller ett projekt identifieras kritiska affärsprocesser . Klassificeringen av affärsprocessens betydelse baseras vanligtvis på intäkter, kostnadsbesparingar eller andra attribut som är viktiga för verksamheten.

I detta skede identifieras och beskrivs de risker på hög nivå som systemet med största sannolikhet kommer att utsättas för.

I det sista skedet av detta steg identifieras uppgifter, roller och resultat för nästa utvecklingsstadium. Uppgifterna och de resurser som avsatts för deras genomförande ingår i projektplanen för utvecklingsstadiet.

Utarbetning

Tidigt i designfasen bryts kritiska affärsprocesser upp i kritiska användningsfall . Vid behov kan sådana användningsfall sönderdelas ytterligare i elementära övergångar eller skärmövergångar, som blir grunden för skriptdrivna prestandatestning .

En typ av krav relaterat till Performance Engineering är Non- Functional Requirements (eller NFR). Medan ett funktionskrav anger hur en affärsverksamhet ska utföras, anger ett prestationsrelaterat icke-funktionellt krav hur snabbt den affärsverksamheten ska löpa under vissa förutsättningar.

"Vissa förhållanden" måste vara avgörande.

Exempel 1:

Ogiltigt krav: systemets svar på användarens begäran får inte överstiga 10 sekunder.
Korrekt krav: för ABC-användningsfallet bör systemets svar på en giltig användarförfrågan inte överstiga 5 sekunder för en belastning på 250 aktiva användare och 2000 onlineanvändare i 95 % av fallen; eller bör inte överstiga 10 sekunder för en toppbelastning på 500 aktiva användare och 4000 onlineanvändare 90 % av tiden.

Det finns en betydande skillnad mellan dessa två krav: det första ger inga villkor, det andra definierar tydligt under vilka villkor systemet måste fungera och, till skillnad från det första, kan det ha SLA ; arkitekter och systemkapacitetsplanerare kan planera och bygga ett system baserat på endast det andra, korrekta kravet; testare kan bara komma med ett tillförlitligt prestandatest för det andra, korrekta kravet.

De icke-funktionella kraven är inte begränsade till användningsfall, utan de övergripande systemanvändningsförhållandena bör också specificeras . De beskriver den totala belastningen på systemet under en viss tidsperiod, och beskriver hur många affärstransaktioner av varje typ som utförs per tidsenhet. I allmänhet definierar systemanvändningsförhållanden en typisk arbetsdag uppdelad i timmar, vilket gör att du kan beskriva hur belastningen på systemet förändras under dagen.

Exempel 2:

Det finns 1200 A-transaktioner, 300 B-transaktioner och 3300 C-transaktioner på en hel arbetsdag; under den första timmen görs dessutom 10 % av transaktionerna A, 20 % av transaktionerna B och 5 % av transaktionerna C; för den andra - 10 % av transaktionerna A, 25 % av transaktionerna B och 50 % av transaktionerna C, och så vidare

Sådan information presenteras vanligtvis i form av en tabell. Om interaktion på transaktionsnivå utförs av olika typer av användare ingår detta faktum även i de icke-funktionella kraven.

De systemutnyttjandeförhållanden som anges i de icke-funktionella kraven används som indata för lasttestning och stresstestning under prestandatestning .

Vissa prestationstekniska uppgifter relaterade till prestandatester, inklusive utveckling och validering av en teststrategi; utveckla en prestationstestningsplan; bestämning av mängden data som ska testas; utveckling av testscenarier utförs också i detta skede.

För alla system som behöver stödja en betydande belastning, definierar detta steg också en plan för övervakning av det och utvecklar en lämplig design. Performance engineering överväger uppgifter relaterade till systemövervakning för lasttestning och produktionssystem.

I bearbetningsskedet granskas de risker som dokumenterats i föregående skede. En riskreduceringsplan definieras för varje systemprestandarisk. Även kostnad, tid och ansvar definieras och dokumenteras.

I det sista skedet av detta steg tilldelas uppgifter, roller och leveranser för nästa steg av utförande. Uppgifterna och de resurser som avsatts för deras genomförande ingår i projektplanen för genomförandefasen.

Utförande

Allra i början av detta skede utarbetas en verktygslåda för resultatanalys, som inkluderar:

Identifiering av nyckelmedlemmar i utvecklingsteamet som är engagerade i expertis inom det valda verktygslådan
Definiera ett profileringsverktyg för komponentenhetstestning eller utvecklingsstadietester.
Definiera ett verktyg för automatiserad komponenttestning; används när det inte finns något grafiskt gränssnitt för de utvecklade komponenterna ännu.
Definition av ett verktyg för automatisk komponent-för-komponent-testning av serverdelen av systemet.
Definition av ett fleranvändarskriptbaserat systemtestverktyg; behövs för att testa användningsfall som drivs av skärmövergångar eller elementära övergångar.
Definiera ett databastestverktyg
Tillhandahåller prestandatestverktyg till utvecklare
Presentationer och utbildningar för utvecklare.

Prestandaförbättringsteamet bör ha en grundläggande checklista för konfigurering av operativsystem, nätverk, servrar (applikationer, webbservrar, databaser, lastbalansering och så vidare). När prestationstestteamet samlar in data finjusterar prestationsteamet systemet för att distribuera produktionssystemet senare. Denna aktivitet kräver deltagande av specialister från relevanta områden. Till exempel, för att finjustera databasen, måste du ansluta en DBA som har en uppsättning kunskaper inom detta område.

I det vanliga fallet utför testteamet inte tester med ett system som är konfigurerat för utveckling, utan en konfiguration som ligger närmast det framtida produktionssystemet. Detta team utför prestandatester baserat på användningsfall för att säkerställa att kritiska systemanvändningsfall uppfyller icke-funktionella krav. Testteamet kör belastningstester baserat på den genomsnittliga förväntade belastningen på systemet samt toppbelastningen. Stresstester kan också utföras för att identifiera flaskhalsar. Data som samlas in och analyseras delas med prestationsförbättringsteamet. Vid behov justeras systemet ytterligare för att möta icke-funktionella krav.

Om tillvägagångssättet Performance Engineering har tillämpats korrekt i varje steg fram till denna punkt, kommer det troligen att räcka för att systemet ska klara prestandacertifieringen. Men om testresultaten av någon anledning inte uppfyller kraven är det nödvändigt att lämna tillbaka delar av systemet till utvecklarna för omfaktorisering. I vissa fall kan problem lösas genom att använda ytterligare hårdvaruresurser, men detta tillvägagångssätt leder snabbt till minskad datorkraftseffektivitet.

Exempel 3:

Anta att vi kan förbättra prestandan för 70 % av modulen genom att parallellisera den och köra själva modulen på 4 processorkärnor tillsammans 1. Om vi tar delen av sekventiella beräkningar som α, så är (1-α) en del av de beräkningar som utförs parallellt, och då kan den maximala hastighetsökningen uppnås genom att använda antalet kärnor P enligt Amdahls lag :

$S_{p}={\frac {1}{\alpha +{\frac {1-\alpha }{p))))$

I vårt exempel får vi:

$S_{4}={\frac {1}{0.3+{\frac {1-0.3}{4))))=2.105$

En ökning av antalet processorkärnor med 4 gånger leder alltså till en ökning av prestanda endast två gånger (från 1 till 2,105). Och vi är redan på väg mot minskad datorkraftseffektivitet.

Genom att fördubbla beräkningskraften får vi:

$S_{8}={\frac {1}{0.3+{\frac {1-0.3}{8))))=2.581$

Alltså, genom att återigen öka beräkningskraften med 2 gånger, fick vi en prestandaökning på nivån 1/5 (från 2,105 till 2,581).

Driftsättning

Under det sista steget distribueras systemet till en produktionskonfiguration, vilket kräver följande förberedande steg:

Konfiguration av operativsystem, nätverk, servrar (applikationer, webbservrar, databaser, lastbalanserare etc.) enligt de grundläggande checklistorna och optimeringar som gjorts under prestandaanalysen på testkonfigurationen.
Säkerställa konfiguration och drift av alla systemövervakningsverktyg.
Kör statistik på databasen efter att ha laddat in produktionsdata i den.

När du underhåller systemet efter lanseringen kan de aktuella prestandauppgifterna vara:

En regelbunden (vecko- eller månadsrapport) som visar att prestandan för kritiska systemanvändningsscenarier uppfyller icke-funktionella krav.
I händelse av att användningsfallet faller utanför de gränser som definieras av icke-funktionella krav, utfärdas ett defekt .
Kvartalsvis projektförloppsanalys som används för systemkapacitetshanteringsuppgifter.

Tjänstehantering

Under systemunderhållsfasen fokuserar Performance Engineering på tre huvudområden: servicenivåhantering, kapacitetshantering och problemhantering.

Servicenivåhantering

Inom området för servicenivåhantering fokuserar Performance Engineering på servicenivåavtal eller SLA och övervakning av relaterade system, vilket tjänar till att fastställa servicenivåefterlevnad, identifiera problem och analysera beteendedynamik. Till exempel kan ett system upprättas för att övervaka slutanvändarna av systemet för att säkerställa att deras transaktioner genomförs i en takt som överensstämmer med icke-funktionella krav. Transaktionsbehandlingstiden registreras i databasen så att den senare kan samplas från dessa data och analysera utvecklingsdynamiken för användning i kapacitetshantering. I fallet när transaktionsbehandlingstiden börjar falla utanför de tilldelade gränserna, utfärdas en varning om behovet av att uppmärksamma situationen.

Kapacitetshantering

Inom området för systemkapacitetshantering är målet med Performance Engineering att säkerställa att systemen fortsätter att uppfylla icke-funktionella krav. Det innebär att man samlar in statistik och historisk analys av beteendedynamiken i volymer som gör det möjligt att förutsäga efterlevnad eller bristande efterlevnad i framtiden. Till exempel, om systemets prestanda visar en trend mot ökad transaktionsexekveringstid (på grund av ökad datavolym, ökat antal samtidiga användare, etc.), kan man dra slutsatsen att vid någon tidpunkt kommer systemet inte längre att uppfylla prestandan kriterier som anges i avtalet om servicenivå. Kapacitetshantering ansvarar för att proaktivt lägga till kapacitet till systemet i sådana fall (t.ex. extra processorkraft, RAM, databasindex etc.) på ett sätt som håller prestandamåtten inom de gränser som krävs.

Problemhantering

Inom området problemhantering fokuserar Performance Engineering på att lösa grundorsaken till prestandaproblem, inklusive systemjustering, ändring av operativsystem eller enhetsinställningar, eller till och med mjukvaruomstrukturering för att fixa prestandaproblem orsakade av dålig design eller kodningsmetoder.

Övervakning

Alla stora system kräver ett övervakningsdelsystem för att säkerställa att korrekt statistik finns tillgänglig för att bedöma om systemet uppfyller icke-funktionella krav. Planering, installation, konfigurering och kontroll av övervakningsdelsystemet utförs inom ramen för en specifik övervakningsprocess, som har följande fördelar:

Möjligheten att ange en SLA på nivån för användningsfall.
Möjlighet att slå på och av övervakning med jämna mellanrum eller att åtgärda problem.
Låter dig generera regelbundna rapporter.
Ger möjlighet att övervaka dynamiken i systembeteende över tid, såsom effekten av ökad användarbelastning och ökade dataflöden på prestanda på användningsfallsnivå.

Se även

Länkar

Tester Knowledge Base (ryska) - Buggtrackers, automatiserad testning, belastningstestning, användbarhetstestning, gemenskaper, tryckta publikationer, böcker
Lasttestautomation (ryska)
Ladda testanteckningar (ryska)

Litteratur

Lisa Crispin, Janet Gregory. Agila testning: En praktisk guide för testare och agila team. - M. : "Williams", 2010. - 464 sid. - (Addison-Wesley Signature Series). - 1000 exemplar. - ISBN 978-5-8459-1625-9 .