Fælles udviklingsmiljø

For at have et fælles miljø, der ligner et rigtigt NSP testmiljø, så er der blevet opsat et miljø hos medcom.

NR-106

Cdaviewer: https://cdaviewer.nspnxrg.medcom.dk/cdaviewer/

DDS Repository: https://dds.nspnxrg.medcom.dk/ddsrepository/services?wsdl

DDS Registry: https://dds.nspnxrg.medcom.dk/ddsregistry/services?wsdl

DRS: https://drs.nspnxrg.medcom.dk/drs/wsdl/drs.wsdl

DROS:

https://dros.nspnxrg.medcom.dk/dros/iti41?wsdl

https://dros.nspnxrg.medcom.dk/dros/iti42?wsdl

https://dros.nspnxrg.medcom.dk/dros/iti57?wsdl

https://dros.nspnxrg.medcom.dk/dros/iti61?wsdlNR-106

NXRG:

https://nxrg.nspnxrg.medcom.dk/nxrg/iti18?wsdl

https://nxrg.nspnxrg.medcom.dk/nxrg/iti42?wsdl

https://nxrg.nspnxrg.medcom.dk/nxrg/iti57?wsdl

https://nxrg.nspnxrg.medcom.dk/nxrg/iti61?wsdl

PhpMyadmin (NXRG db viewer): https://phpmyadmin.nspnxrg.medcom.dk/

Der er sat en splunk op (hvis den bliver genstartet, så mister den al data, men det er nok ok til vores formål. Man kan se data ved at vælge "NXRG Report": https://splunk.nspnxrg.medcom.dk/en-US/app/search/reports

XDS Test Toolkit2: https://iheos-toolkit2.nspnxrg.medcom.dk/xdstools2/

Unittests

Der findes UnitTests af centrale enheder (klasser) i NXRG.

Placeringen af disse følger standarden foreskrevet af Maven og er placeret i src/test/java i hvert af NXRG servicens moduler.

Unittests er navngivet med navnet på den klasse, som de tester, efterfulgt af Test.

Således ligger unittesten for klassen:

./nxrg-app/src/main/java/dk/nsp/nxrg/ws/Iti42WS.java

implementeret i:

./nxrg-app/src/test/java/dk/nsp/nxrg/ws/Iti42WSTest.java

Unittests er stilmæssigt opbygget på følgende måde:

• Hver testcase er implementeret som en metode i den relevante testklasse
• Testcasen er navngivet, så det tydeligt fremgår, hvad formålet med testen er
• Kommentarer i testcasen inddeler tydeligt i præcondition (Given), udførsel (When), tjek (Then) som beskrevet f.eks. Martin Fowler: Given-When-Then

Unittests er implementeret vha JUnit og kan eksekveres af Mavens standard testplugin SureFire.

Til udregning af testcoverage anvendes Jacoco Maven Plugin (se JaCoCo Maven plug-in).

Testcoverage udregnes i de enkelte Maven moduler i NXRG og aggregeres til en samlet rapport i modulet nxrg-testreport.

Således er en samlet rapport over testcoverage tilgængelig i

./nxrg-testreport/target/site/jacoco-aggregate

Unittests og tilhørende udregning af testcoverage udføres som en integreret del af byg af komponenten (se i øvrigt NXRG - Guide til Udviklere).

Integrationstest til verifikation af funktionalitet og deployment

Integrationstestene for NXRG er implementeret vha Cucumber og JUnit i modulet nxrg-qa, og er beregnet til afvikling mod en kørende udgave af NXRG.

Afvikling af Integrationstests aktiveres via Maven ved følgende kommando i modulet nxrg-qa:

mvn verify -Pintegration-test  -Dvariabel=value

Det kræves at følgende properties angives ved afvikling af integrationstesten

For nemheds skyld er der angivet følgende profiler (kan angives med -P), med variabeldefinitioner for et givent miljø

Testrapporter kan for integrationstesten genereres som html og json og kan ses i /target/cucumber-reports/cucumber.html og /target/cucumber-reports/cucumber.json

Sammenhæng mellem integrationstests og user stories

I NXRG - Brugerhistorier findes en liste over, hvilke user stories, der er relevante for NXRG. Er installereret: https://iheos-toolkit2.nspnxrg.medcom.dk/xdstools2/

Disse brugerhistorier går igen i integrationstestene, da hver brugerhistorie svarer til en integrationstestssuite (feature) i NXRG.

Således findes testscenarier for brugerhistorien 'Registrer Dokumentsæt med ReferenceIdList' i featurefilen:

./nxrg-qa/src/test/resources/dk/nsp/nxrg/test/verification/RegistrerDokumentsaetMedReferenceIdList.feature

XDS Toolkit 2: Testing

XDS Toolkit er en samling test tools, der fokuserer på XDS.

Det understøtter tests for en række IHE XDS aktører f.eks Document Registry, Document Repository og flere.

I forhold til NXRG er det relevant at kigge på, hvilke tests, der findes, der fokuserer på Document Registry.

Vælg "alternate" som environment. Test11897 test 1 og 2 fejler ellers.

I menuen i XDS Toolkit kan man vælge "Conformance Tests". Herved fåes et overblik over de forskellige IHE XDS aktøerer. I sektionen vedr. Document Registry er testene grupperet. I forhold til NXRG MVP er det relevant at koncentrere sig om de tests, der ligger i de sektionerne:

• Document Registry / XDS / Required
• Document Registry / XDS / Metadata Update Option
• Document Registry / XDS / On demand Option

For lokal test: værktøjet startes op docker compose setup under ./compose/development og kan herefter tilgåres via: http://localhost:3308/xdstools2/

For testserver test: se link ovenfor for "XDS Test Toolkit2"

Det er ikke alle tests inden for de tre kategorier, som vi forventer at kunne gennemføre i NXRG MVP (vi udbyder f.eks. kun en delmængde af de søgetyper, der findes som en del af ITI-18). Kategorierne og testcases gennemgås nedenfor og relevans krydses af.

*)De fleste pga at update metadata pt ikke tillader udeladt version

Performance test

Der laves performance test af regsistry og repository som et hele - dvs det er brugeroplevelsen som sådan, der vurderes.

Testen grupperes logisk i en test suite. Hver trin bør udføres i angivne orden. Og databasen til registry og repository kan med fordel kopieres efter trin 2, sådan at de følgende testtrin kan genkøres, skulle behovet opstå.

Test suite 1

1. ITI-41: Registrer stable dokument
2. ITI-61: Registrer on-demand dokument med referencer
   (tag kopi af databaserne)
3. ITI-41: Replace stable dokument
4. ITI-61: Replace on-demand dokument med referencer
5. ITI-18: Registry stored query (“find documents”) og ITI-43: retrieve document set
6. ITI-18: Registry stored query (“find documents by reference”)
7. ITI-57: Update metadata (deprecate dokument)

Der køres på en liste af cpr numre. Trin 1 og 2 opretter data og trin 3-7 arbejder herefter på disse data. Replace document og update metadata arbejder på konkrete dokumenter. Disse findes ved først at lave en ITI-18 søgning (som udelades af selve throughput beregningen).

Performance krav

Der findes ikke en officiel liste af krav til performance. Det vil derfor være hensigtsmæssigt at undersøge, hvordan performance er for det nuværende registry (og repository). Men vil herefter kunne vurdere, at man ialtfald ikke er dårligere stillet med det nye.

Krav:

1. Snitfladerne skal være mindst lige så hurtig som for den nuværende XDS registry (og repository)
2. Snitfladerne skal måles og svartiderne vurderes
3. Vurdering af, hvor stort et load, snitfladerne kan håndtere per time og per uge 

Add 3: Der måles en periode på 15 minutter og denne ganges op på time og uge basis.

Forudsætninger

Testen skal køres på en liste af cpr numre. Listen indeholder 100.000 forskellige numre. Udover disse cpr numre skal testen kunne afvikles selvstændigt og ikke være afhængig af andet test data.

Testen skal køre mod et registry og repository med en “passende” mængde baggrundsdata. Dette er et par millioner dokumenter af typerne stable og on-demand. Disse skabes i testens trin 1 og 2.

Baggrundsdata

Testens trin 3-6 forudsætter er der findes baggrundsdata at køre på. Trin 3 og 4 skal erstatte et eksisterende "approved" dokument, og trin 5 samt 6 skal fremsøge eksisterende dokumenter, og trin 7 skal deprecate eksisterende dokumenter.

Dette baggrundsdata skables i testens trin 1 og 2. Vurderes det, at disse 2 trin ikke har skabt nok baggrundsdata (et par millioner dokumenter) kan trin 1 og 2 gentages indtil, der er nok dokumenter. Da trin 7 deprecate i princippet fjerner sit eget data grundlag for at finde dokumenter at slette markere, skal der efter en deprecate oprettes et tilsvarende dokument.

Design af test

Overblik

Der findes følgende test planer til NXRG. 

Man kan i de forskellige test plan angive om der skal køres med eller uden dgws. Dette skal gøres nede på de enkelte samplers. Dette har betydning for, hvilken "path" der anvendes efter et givet endpoint.

Denne path kan også variere om kaldet er mod NXRG eller det eksisterende OpenText. Denne path justeres i kildekoden til test frameworket.

ITI-41 register

Dette er en registrering af et “stable” dokument.

Overvejelser omkring opsætningen

• Opret nye dokumenter
• Anvend forskellige cpr numre

Der er følgende muligheder for opsætning af testen:

Til testen anvendes følgende opsætning:

• CPR tilfældigt fra liste af numre
• Dokumenttypen APD
• De i sampler "OpretAftaleSampler.java" angivne værdier

ITI-61 register

Dette er en registrering af et “on-demand” dokument.

Overvejelser omkring opsætningen

• Opret nye dokumenter
• Anvend forskellige cpr numre

Der er følgende muligheder for opsætning af testen:

Til testen anvendes følgende opsætning:

• CPR tilfældigt fra liste af numre
• Dokumenttypen APD
• For referencer angives 5 for "generate document reference". Dette betyder, at dokumentet får 5 tildelte referencer i varianet af ef cpr nummer hashed
• Der anvendes derudover de i ovenstående skærmbillede angivne test data eller tilsvarende 

ITI41 replace og ITI-61 replace

Dette er som for ITI-41 register og ITI-61 register ovenfor. Forskellen er, at et eksisterende dokument skal erstattes. 

Overvejelser omkring opsætning:

• Anvend forskellige cpr numre og dokumenter

Til testen anvendes følgende opsætning:

• CPR tilfældigt fra liste af numre
• Dokumenterne fremsøges med et ITI-18 kald for et konkret cpr nummer og et af de fundne dokumenter replaces (Extract document identification from previous call)
• (Søgning udeledes af throughput beregningen ved at lave ordet "ignore" indgå i samplerens navn i opsætningen) 
• Der replaces med info som for "register"

ITI-18 registry stored query og ITI-43 retrieve document set

Dette er en fremsøgning af dokumenter og efterfølgende hent.

Overvejelser omkring opsætningen

• Søgnining imellem mange dokumenter

Der er følgende muligheder for opsætning af testen:

Fremsøgning:

Hent:

Til testen anvendes følgende opsætning:

• CPR tilfældigt fra liste af numre
• Der hentes kun stable documenter, da det efterfølgende iti-43 kald ellers vil fejle på on-demand dokumenterne
• Dato interval: skal ligge indenfor de datoer, hvor dokumenterne er registreret 
• Dokument typer, som hentes: APD 39289-4
• Der søges efter “approved” dokumenter (deprecate udelades)

ITI-18 registry stored query - by reference

Dette er en fremsøgning af dokumenter ud fra dokuments reference

Overvejelser omkring opsætningen

• Søgnining imellem mange dokumenter
• søgning med forskellige referencer, men ikke fra en "ekstern" liste

Der er følgende muligheder for opsætning af testen:

Til testen anvendes følgende opsætning:

• CPR tilfældigt fra liste af numre
• Der hentes kun on-demand documenter, da der kun er oprettet referencer på disse
• Dato interval: skal ligge indenfor de datoer, hvor dokumenterne er registreret 
• Dokument typer, som hentes: APD 39289-4
• Der søges efter “approved” dokumenter (deprecate udelades)
• For referencer angives 5 for "generate document reference". Dette betyder, at der tilfældig udvælges en reference - ud af 5 varianter over en cpr nummer hashed reference.

iti-57

Dette er en opdatering af til et eksisterende dokuments metadata - mere konkret dokument status bliver deprecated. 

Overvejelser omkring opsætningen

• Anvend forskellige cpr numre og dokumenter
• Man skal ikke "udhule" data grundlaget ved at deprecate alle dokumenter

Der er følgende muligheder for opsætning af testen:

Til testen anvendes følgende opsætning:

• CPR tilfældigt fra liste af numre
• Dokumenterne fremsøges med et ITI-18 kald for et konkret cpr nummer og on-demand typen, og et af de fundne dokumenters metadata opdateres
• Der deprecates som opdatering
• Der oprettes med et ITI-61 kald et nyt tilsvarende dokument.
• (Søgning og register) udelades af throughput beregningen ved at lave ordet "ignore" indgå i samplerens navn i opsætningen) 

Udførsel af test

Forberedelse

Testen hentes fra https://svn.nspop.dk/svn/components/performance/trunk i den revision, der er angivet nedenfor per release af NXRG.

Databasen klargøres; en tom database for både registry og repository

Der skal være en kørende version af NXRG, som er konfigureret med et tilhørende repository. Og host.properties skal være sat korrekt op jf. arosiis performance test framework.

I sourcekodens samplers findes metoden getPath(). Denne sti ned til det enkelte endpoint varierer efter, hvilken version af servicene som rammes. Det kan derfor være nødvendig at rette test sourcerne inden testen køres.

Eksempel for iti-18:

• kørsel mod open xds: /axis2/services/xdsregistryb
• kørsel mod nuværende open text registry: /registry/services/xds-iti18
• kørsel mod ny nxrg registry: /nxrg/iti18

Kørsel

Når databasen er på plads, NXRG og repository kørende og testen konfigureret, kan følgende køres:

(distributionen 15min.template.jmx kører 15 minutter)

ITI-41 register

tests/aftaler/src/test/jmeter/templates/testplans/nxrg_opret.template.jmx

ITI-61 register

tests/ihe/src/test/jmeter/templates/testplans/nxrg_opret_iti61.template.jmx

ITI-41 replace

iti-61 replace

tests/ihe/src/test/jmeter/templates/testplans/nxrg_replace_iti61.template.jmx

iti-18 og iti-43

tests/aftaler/src/test/jmeter/templates/testplans/nxrg_hent.template.jmx

iti-18 og by reference

iti-57 deprecate

tests/ihe/src/test/jmeter/templates/testplans/nxrg_deprecate_iti57.template.jmx

Version

'* ' betyder hvilken som helst