Ledelse inden for test: Styring af performancetest

Hej og velkommen til serien Ledelse inden for test. I den seneste artikel så vi på servicetest af webapplikationer. 

Formålet med dette kapitel er at give nogle råd og bedste praksisser til håndtering af en kritisk komponent inden for servicetest, som blev nævnt i den artikel – trommehvirvel, tak... ydeevnetest!

Vi gennemgår:

• Mål for ydeevnetest
• Fire forudsætninger for en ydeevnetest
• Værktøjskasse til ydeevnetest
• Processen for ydeevnetest

Lad os komme i gang.

Mål for ydeevnetest

Som en kort opsummering kan vi definere det primære mål med ydeevnetest således:

“At demonstrere, at systemet fungerer i henhold til specifikationen med acceptable svartider, mens det behandler de nødvendige transaktionsmængder på en database i produktionsstørrelse.”

Dit ydeevnetestmiljø er en testplatform, der kan bruges til andre test med bredere mål, som vi kan opsummere således:

• Vurdering af systemets kapacitet til vækst (Hvis du er usikker på, hvilken software der kan håndtere dine behov, kan vores liste over de bedste løsninger til databasestyring hjælpe dig.)
• Identifikation af svage punkter i arkitekturen
• Finjustering af systemet
• Opdagelse af uklare fejl i softwaren
• Verificering af robusthed og pålidelighed.

Din teststrategi bør definere kravene til en testinfrastruktur, der gør det muligt at opfylde alle disse mål.

Fire forudsætninger for en ydeevnetest

"Hvis nogen af disse forudsætninger mangler, skal du være meget forsigtig, før du går videre med at udføre test og offentliggøre resultater. Brug af værktøjer til automatisering af kvalitetssikring kan hjælpe med at sikre, at disse forudsætninger er opfyldt. Testene kan være vanskelige eller umulige at udføre, eller troværdigheden af de resultater, du offentliggør, kan være alvorligt mangelfuld og let at undergrave.

1. Kvantitative, relevante, målbare, realistiske og opnåelige krav

Som grundlag for alle test bør ydeevnekravene (målene) aftales før testen, så det er muligt at afgøre, om systemet opfylder disse krav. 

Krav til systemets gennemløb eller svartider bør, for at være nyttige som grundlag for sammenligning af ydeevneresultater, have følgende egenskaber. De skal være:

• Udtrykt i kvantificerbare termer.
• Relevante for den opgave, en bruger ønsker at udføre.
• Målbare ved hjælp af et værktøj (eller et stopur) til en rimelig pris.
• Realistiske sammenlignet med varigheden af brugerens opgave.
• Opnåelige til en rimelig pris.

Ydeevnekrav er ofte uklare eller ikke-eksisterende. Find dokumenterede krav, hvis du kan. Hvis der er mangler, kan det være nødvendigt at dokumentere dem efterfølgende. 

Før en ydeevnetest kan specificeres og designes, skal der aftales krav til:

• Transaktionssvarstider.
• Belastningsprofiler (antallet af brugere og de transaktionsmængder, der skal simuleres).
• Databasemængder (antallet af poster i databasetabeller, der forventes i produktionen).

Det er almindeligt, at ydelseskrav defineres i vage vendinger. Disse krav er ofte baseret på skønnede prognoser for forretningsmængder, og det kan være nødvendigt at få forretningsbrugere til at tænke realistisk over ydelseskravene. 

Du kan også være nødt til selv at analysere kravene og dokumentere dem som de ønskede ydelsesmål. 

2. Et stabilt system

Hvis systemet er fejlbehæftet og upålideligt, kommer du ikke langt med en ydelsestest. Ydelsestests belaster alle arkitektoniske komponenter i et vist omfang. Men for at ydelsestests kan give nyttige resultater, skal systemet og den tekniske infrastruktur fra starten være rimeligt pålidelige og robuste.

3. Realistisk testmiljø

Testmiljøet skal konfigureres, så testen er meningsfuld. Du kan sandsynligvis ikke genskabe mål- eller produktionssystemet, men testmiljøet bør helt eller delvist kunne sammenlignes med det endelige produktionsmiljø. Du skal blive enig med systemets arkitekt om, hvilke kompromiser der er acceptable, og hvilke der ikke er, eller i det mindste hvilken nyttig fortolkning der kan foretages af testresultaterne.

Det er afgørende at skabe et realistisk testmiljø for at opnå meningsfulde ydelsestests. Se vores håndplukkede udvalg af softwaretestplatforme for at finde værktøjer, der kan hjælpe dig med at simulere virkelige forhold

4. Kontrolleret testmiljø

Ydelsestestere kræver stabilitet. Ikke kun med hensyn til hardware- og softwarens pålidelighed og robusthed, men også med hensyn til at minimere ændringer i miljøet eller den software, der testes. Hvis grænsefladen eksempelvis ændres blot en smule, er testskripter, der er designet til at styre brugergrænseflader, tilbøjelige til at fejle med det samme.

Alle ændringer i miljøet bør kontrolleres strengt. Hvis ændringen løser fejl, som sandsynligvis ikke påvirker ydelsen, kan du overveje ikke at acceptere udgivelsen. Kun ændringer, der har til formål at forbedre ydelsen eller pålideligheden, bør accepteres.

Værktøjssæt til ydelsestest

Dit værktøjssæt til ydelsestest består af fem hovedværktøjer:

• Oprettelse/vedligeholdelse af testdata – til at oprette de store datamængder i databasen, som kræves til testen. Vi forventer, at dette vil være et SQL-baseret værktøj eller måske et pc-baseret produkt som Microsoft Access, der er forbundet med din testdatabase.
• Belastningsgenerering – de almindelige værktøjer bruger testdrivere, der simulerer virtuelle klienter ved at sende HTTP-meddelelser til webservere.
• Værktøj til kørsel af applikationer – dette driver en eller flere instanser af applikationen ved hjælp af browsergrænsefladen og registrerer målinger af svartider. (Dette er normalt det samme værktøj, som bruges til belastningsgenerering, men det behøver det ikke at være).
• Ressourceovervågning – værktøjer, der overvåger og logger klient- og serversystemressourcer, netværkstrafik, databaseaktivitet osv.
• Resultatanalyse og rapportering – værktøjer til testkørsel og ressourceovervågning genererer store mængder resultatdata til analyse.

Relateret læsning: DE 10 BEDSTE SQL-ANALYSETJENESTER TIL QA-TEAM

Processen for ydelsestest

Nedenfor vises en figur, der illustrerer en generisk proces for ydelsestest og optimering. Optimering er egentlig ikke en del af testprocessen, men den er en uadskillelig del af opgaven med at forbedre ydelse og pålidelighed. Optimering kan omfatte ændringer i den arkitektoniske infrastruktur, men bør ikke påvirke funktionaliteten i det system, der testes.

Nu ser vi på, hvordan man udvikler, udfører, analyserer og rapporterer om en ydelsestest.

Trinvis testudvikling

Testudvikling udføres normalt trinvist i fire faser:

1. Hvert testscript forberedes og testes isoleret for at fejlfinde det.
2. Scripts integreres i udviklingsversionen af arbejdsbelastningen, og arbejdsbelastningen køres for at teste, om det nye script er kompatibelt.
3. Efterhånden som arbejdsbelastningen vokser, finjusteres, fejlfindes og gøres den teststruktur, der er under udvikling, løbende mere pålidelig. Erfaringen med og fortroligheden med værktøjerne vokser også.
4. Når det sidste script er integreret i arbejdsbelastningen, køres testen som en “prøvekørsel” for at sikre, at den er fuldstændig gentagelig og pålidelig og klar til de formelle tests.

Midlertidige tests kan give nyttige resultater

Kørsler af den delvise arbejdsbelastning og testtransaktioner kan afsløre problemer med ydeevnen. Tests med belastninger af lav volumen kan også give en tidlig indikation af netværkstrafik og potentielle flaskehalse, når testen skaleres op. 

Dårlige svartider kan skyldes dårligt applikationsdesign og kan undersøges og løses af udviklerne på et tidligere tidspunkt. Tidlige tests kan også køres i længere perioder som udholdenhedstests.

Testudførelse

Testudførelse kræver en vis stadieledelse eller koordinering. Du bør samarbejde med de deltagere, der understøtter testen, og som overvåger systemet, mens du kører tests. Teamet, der står for “testovervågning”, kan være distribueret, så du skal holde dem orienteret, hvis testen skal forløbe problemfrit, og resultaterne skal registreres korrekt.

Ud over koordineringen af de forskellige teammedlemmer følger udførelsen af ydeevnetests typisk en standardprocedure.

1. Forbered databasen (gendan fra bånd, hvis det er nødvendigt).
2. Forbered testmiljøet efter behov, og kontrollér dets tilstand.
3. Start overvågningsprocesser (netværk, klienter og servere, database).
4. Start belastningssimuleringen, og observer systemmonitoren eller systemmonitorerne.
5. Hvis der bruges et separat værktøj, skal du, når belastningen er stabil, starte værktøjet til kørsel af applikationstesten og målingen af svartider.
6. Overvåg testen nøje under hele testens varighed.
7. Hvis værktøjerne til testkørsel ikke stopper automatisk, skal du afslutte testen, når testperioden slutter.
8. Stop overvågningsværktøjerne, og gem resultaterne.
9. Arkivér alle registrerede resultater, og sørg for, at alle resultatdata sikkerhedskopieres forsvarligt.
10. Udarbejd midlertidige rapporter, og drøft eventuelle uregelmæssigheder med de øvrige teammedlemmer.
11. Udarbejd analyser og rapporter.

Koordinering af forskellige teammedlemmer under testudførelsen kan være udfordrende. Gør processen mere effektiv ved at integrere avancerede teststyringsværktøjer designet til Jira, som tilbyder funktioner som samarbejde og rapportering i realtid

Finjustering følger normalt efter test, når der er problemer, eller hvor der er kendte mulige optimeringer. Hvis en test gentages, er det vigtigt, at alle ændringer i miljøet registreres. På den måde kan eventuelle forskelle i systemets adfærd og dermed i ydeevneresultaterne sammenholdes med ændringerne i konfigurationen.

Når det gælder håndtering af testcases til ydeevnetest, kan software til teststyring gøre en stor forskel. Det giver bedre organisering, sporing og endda automatisering af testcases.

Som regel er det klogt kun at ændre én ting ad gangen, så forskelle i adfærden kan føres tilbage til de foretagne ændringer, når de registreres.

Analyse og rapportering af resultater

Den mest typiske rapport for en testkørsel opsummerer disse målinger, og for hver måling rapporteres følgende:

• Antallet af målinger.
• Minimumssvartid.
• Maksimal svartid.
• Gennemsnitlig svartid.
• Svartid ved N-te (typisk 95^te) percentil.

Belastningsgenereringsværktøjet fra dit værktøjssæt bør registrere antallet af hver transaktionstype i testperioden. Hvis disse antal divideres med testens varighed, fås den faktisk opnåede transaktionsrate eller gennemstrømning. 

Antallet af transaktioner er den belastning, der påføres systemet. Dette forudsætter, at proportionerne af de udførte transaktioner svarer til den belastningsprofil, du forsøger at anvende.

Den påførte belastning bør svare til den simulerede belastningsprofil – men gør det muligvis ikke, hvis systemet reagerer langsomt, og transaktionerne kører med varierende hastigheder.

Normalt gennemfører du en række testkørsler ved varierende belastninger. Ved hjælp af resultaterne fra en række tests kan du plotte en graf over svartiden for en transaktion i forhold til den anvendte belastning.

Ressourceovervågningsværktøjer har normalt statistiske eller grafiske rapporteringsfunktioner, der viser ressourceforbruget over tid. Udvidede rapporter over ressourceforbrug i forhold til den anvendte belastning er meget nyttige og kan hjælpe med at identificere flaskehalse i et systems arkitektur.

Held og lykke!

Tilmeld dig nyhedsbrevet fra The QA Lead for at få besked, når nye dele af serien udgives. Disse indlæg er uddrag fra Pauls Ledelse inden for test-kursus, som vi varmt anbefaler, hvis du vil gå mere i dybden med dette og andre emner. Hvis du gør det, kan du bruge vores eksklusive kuponkode QALEADOFFER og få $60 i rabat på kursets fulde pris!

Relateret læsning: SERVEROVERVÅGNINGSMÅLINGER, DU BØR FØLGE FOR SYSTEMETS SUNDHED OG YDEEVNE