Performancetest af patientkritisk system DSTB Per Skjoldager ahoc - Jesper Mortensen ahoc

Transkript

1 Performancetest af patientkritisk system DSTB 2017 Per Skjoldager ahoc - per@skjoldager.eu Jesper Mortensen ahoc jesper@mortensen.com

2 Hvem er vi Per Skjoldager Testmanager / ahoc Senior Test Manager med 15 års erfaring i Test Management indenfor Banking og Healthcare. Endvidere 15 års erfaring som udvikler og udviklingsprojektleder. Test Management opgaverne har omfattet både traditionelle test projekter med hoved fokus på manuel og automatiseret funktionstest såvel som performance test projekter. Jesper Mortensen Værktøjsspecialist, Seniorpartner / ahoc Specialist i HP s testredskaber siden Konsulentopgaver indenfor undervisning, implementering og gennemførelse med fokus på Quality Center/ALM, Testautomatisering/UFT og Performancetest / LoadRunner /Performancecenter.

3 Performancetest af patientkritisk system Et patientkritisk system i Region Syddanmark i fuld produktion med samtidige brugere oplever utilfredsstillende svartider for brugerne. I dette indlæg kommer vi først ind på hvordan omfanget af svartidsproblemet blev fastlagt vha. automatiske svartidsmålinger. Dernæst ser vi på hvordan Region Syddanmark ud fra en række anbefalinger og grundforudsætninger etablerede et performance test projekt der havde til formål at finde områder i Systemet der kunne optimeres. Vi ser på grundforudsætningerne, projektforløbet og konklusionen af forløbet. Efter 2 års udvikling er performancetesten fra 1/ overdraget til Region Syddanmark og afvikles i forbindelse med kvartalsvise releases af Systemet.

4 Definitioner Performance test Samlebetegnelse for alle de forskellige typer test og målinger som vedrører applikationens performance. Performancetesten omfatter altså de forskellige specifikke testtyper: Svartidsmåling Loadtest Stresstest Stabilitetstest/langtidstest Skaleringstest Det primære formål med at gennemføre en performancetest er at måle og/eller verificere svartider som funktion af et bestemt antal brugere, med andre ord at verificere at et System kan overholde driftsmålene inden ibrugtagning. Desuden kan der være et antal sekundære mål, vedrørende optimering, skalering, stabilitet, risikostyring og dokumentation.

5 Problemformulering Svartidsmålinger. Som en første forudsætning var det nødvendigt at finde konkrete, præcise og relevante målinger på svartider. Konkrete, præcise og relevante målinger danner grundlaget for at vurdere om der ER svartidsproblemer på bestemte arbejdsgange eller lokationer. Denne indsigt danner igen grundlaget for en målrettet indsats.

6 Overvejelser Punkter der blev overvejet: OUH klient Db Server OUH router FYA net TDCH router TDCH net Appl. Server Probe 1 Probe 2 Probe 3 Har det betydning for svartiden, HVOR på netværket der måles.

7 Svartidsmålinger Målingerne foretages direkte på Systemets brugergrænseflade af en robot som trin for trin følger specifikationen af en række nærmere definerede kliniske arbejdsgange. Der måles på 54 punkter som tidligere har været målt manuelt, hver 14. dag på en række lokationer i regionen. Til den automatiske måling anvendes én testpatient. Der afvikles på flere forskellige lokationer, og der anvendes overalt samme patient og samme opsætning. Det er et valg der er truffet for at man kan sammenligne svartiderne direkte med hinanden.

8 UFT indlæg og film

9 Tendenser

10 Tendenser

11 Tendenser

12 Problemformulering Performance test Nedenstående figur illustrerer generisk hvorledes det er muligt generisk at opgøre et produktionstab på en given arbejdsgang i et vilkårligt System: Produktionstabet per år, opgøres derefter som: (svartid 1 SLA 1 + svartid 2 SLA 2 ) * antal arbejdsgange * antal medarbejdere * 220 arbejdsdage

13 OUH

14 vtdch

15 REG

16 Login mod prod. miljø, set med Wireshark Statistics: Packets: Between first and last packet:53,400 sec Avg. packets/sec: 218,894 Avg packet size: 551,716 bytes Bytes: Avg bytes/sec: ,393 Avg Mbit/sec: 0,966

17 Konklusion 1) Svartiderne stiger som funktion af belastning. 2) Svartiderne er generelt stigende i Systemet. 3) Der er samtidigt frie ressourcer på platformen, både på front ends og database server. Anbefaling: At finde årsagen til at systemet ikke udnytter de frie ressourcer.

18 Forudsætningerne Grundforudsætning 1 (Testmiljøet) Som udgangspunk skal testmiljøet være en kopi af produktionsmiljøet både hvad angår platform, applikations(version) og interfaces. Grundforudsætning 2 (Testdata grundlaget) Testdata grundlaget for testen skal modsvare produktion. Det er vigtigt at testen bliver afviklet på en fuld kopi af produktionsdatabasen. Grundforudsætning 3 (Leverandørens rolle) Det er en indlysende grundforudsætning at leverandøren indtager en positiv og bidragende rolle i projektet. Grundforudsætning 4 (Performance center) Omfatter de værktøjer der skal henholdsvis anskaffes og installeres for at kunne afvikle performancetest.

19 Resultatet

20 Definitioner Skaleringstest Formålet med skaleringstest er, at fastslå et systems eller delsystems evne til at performe som funktion af horisontal og vertikal skalering. Der testes udover den normale operationelle kapacitet, ofte til systemet fejler, for at måle og observere hvordan og hvorfor det sker. Horisontal skalering:= flere maskiner. Vertikal skalering:= mere cpu og memory ,5 3 2,5 3 Trans 2 Trans 2 1 Tid 1,5 1 0,5 Tid

21 Definitioner Svartidsmåling En svartidsmåling vedrører kun svartider. Svartidsmålingen i sig selv siger altså ikke meget om systemets performance. Først når svartidsmålingen kombineres med en loadtest eller stresstest kendes et systems performance. Loadtest Formålet med loadtest er at validere at et system kan håndtere et load tilsvarende det forventede produktionsload (spidsbelastning), med svartider der overholder svartidskravene.

22 Definitioner Stresstest Formålet med stresstest er, at fastslå et systems eller delsystems øvre grænse. Der testes udover den normale operationelle kapacitet, ofte til systemet fejler, for at måle og observere hvordan og hvorfor det sker. Stabilitetstest/langtidstest Formålet med en stabilitetstest er at teste om systemet korrekt frigør ressourcer efter brug. Hvis loadtesten eller stresstesten indikerer at et system mister ressourcer, f.eks. at memory eller databaseforbindelser ikke frigives efter brug gennemføres en stabilitetstest. Dette gøres typisk ved at lade testen køre over flere dage/uger med en belastning svarende til 70-80% af den der anvendes i loadtesten (produktionsload).