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.

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?wsdl

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.

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

Performance test

Følgende beskrivelser er "work in progress" og justeres til, som tingene bliver lagt fast og gjort færdigt.

Der laves performance test for hver af de 4 snitflader:

• Iti 18: registry stored query (“find documents”)
• Iti 42: register document  (create)
• Iti 61: register on demand document (replace)
• Iti 57: update document (status deprecate)

For at antallet af performance test ikke bliver alt for stort, køres der test på iti-42 create (create er et nyt dokument, som registreres) og på iti-61 replace (replace er det at erstattet et dokument med et andet). Tanken bag denne beslutning er følgende:

• der skal testes både iti-42 og iti-61, selvom de minder meget om hinanden
• forskellen på create og replace er ikke stor, men begge typer bør testes
• ved at teste de to request på denne “kryds-måde" med create/replace vil eventuelle performance problemer blive synliggjort uden at der skal køres 4 testkørsler.

Performance krav

Fremsøgning (iti-18) er det kald, som vil blive udført oftest og som sådan vil belaste XDS registry mest. Det vil derfor være hensigtsmæssigt at undersøge, hvordan performance for dette kald er i den nuværende XDS registry. Derudover skal den gennerelle performance for NXRG synliggøres.

Krav:

1. Iti-18 snitfladen skal være mindst lige så hurtig som for den nuværende XDS registry
2. De øvrige 3 snitflader (iti-42, 61 og 57) skal måles og svartiderne vurderes
3. Måling af, hvor stort et load, de fire snitflader kan håndtere per time og per uge 

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

Forudsætninger

Testen skal køre mod et registry med en “passende” mængde baggrundsdata. Dette er:

1. Antal dokumenter
2. Fordelt på antal CPR numre:
3. Dokumenttyper:
4. Antal fordelt på dokumenttyper:
5. Fordelt på antal status:

(Antal afgøres når eksisterende XDS registry er undersøgt.)

Baggrundsdata

Baggrundsdata for test kørslerne oprettes med SQL inserts. De anvendte CPR numre og relevant dokument information gemmes i tekstfiler, som performance testen kan køre på.

Udover fordelingen angivet ovenfor i "forudsætninger" gemmes dokumenterne fordelt over en 3 årig periode.

For at test kørslerne kan arbejde på data som findes i databasen, anvender de tekst filer, som input. Derfor er der brug for følgende tekst filer:

• En liste over alle cpr numre, som har dokumenter (iti-18 og iti-42)
• For den dokumenttype, der køres iti-61 test mod, med status “approved”: liste over cpr numre med tilhørende entryUuid (iti-61)
• For dokumenter med “approved” status: liste over cpr numre med tilhørende entryUuid, typecode og repositoryUniqueId (iti-57)

SQL scripts og teksfiler kan med fordel generes fra et java program. Sådan at med en given fordeling af de forskellige parametre som cpr og dokumenttyper skabes sql inserts og tilhørende tekstfiler der hænger sammen.

Vedr baggrundsdata til iti-18 test mod eksisterende XDS registry. Da vi ikke kender databasens opbygning for det eksisterende XDS registry, skabes baggrundsdata med en “test” i jmeter på iti-42 kaldet. Der sættes en række iti-42 kald op i et loop (konfigureret med data som ovenstående nævnt) og antal “loops” sættes for testen, som herefter køres.

Design af test

iti-18 registry stored query

Dette er en fremsøgning af dokumenter.

Overvejelser omkring opsætningen

• søg på færre dokumenttyper, end der findes
• søg på indsnævret dato interval i forhold til fuld 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
• Både stable og on-demand dokumenter
• Dato interval: det midterste år ud af de 3 tilgængelige 
• Dokument typer, som hentes
• PHMR (53576-5)
• APD (56446-8)
• QRD (74465-6)
• FSK (52460-3)
• Der søges efter “approved” dokumenter (deprecate udelades)

iti-42

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
• Der anvendes derudover de i ovenstående skærmbillede angivne test data eller tilsvarende (faktisk anvendte angives i performance rapporten)

iti-61

Dette er en registrering af et “on-demand” dokument, som erstatning fra et allerede eksisterende.

Overvejelser omkring opsætningen

• Opret et erstatnings dokument
• Anvend forskellige cpr numre og 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
• Dokumentet som opdateres er fra samme liste som CPR numret
• Der anvendes derudover de i ovenstående skærmbillede angivne test data eller tilsvarende (faktisk anvendte angives i performance rapporten)

iti-57

Dette er en opdatering af til et eksisterende dokuments metadata. 

Overvejelser omkring opsætningen

• Anvend forskellige cpr numre og 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
• Dokumentet som deprecates er fra samme liste som CPR numret
• Der deprecates

Nye opgaver i forbindelse med ovenstående

I forbindelse med ovenstående design af test, er følgende punkter dukket frem, som ting, der skal kigges på/ laves:

• Er det muligt at lave en performance test af nuværende XDS registry som beskrevet ovenfor?
  • Hvis ja, så skal iti-42 kaldende sættes op i en test med en liste af cpr numre
• Produktionsdata skal undersøges for indhold som beskrevet i “forudsætninger”
• Der skal laves et program (i NXRG QA modulet), som kan skabe SQL/ tekstfiler baggrundsdata (der findes allerede logik, som hjælpe til dette)
• Der er følgende nye justeringer til det nuværende test framework, på baggrund af ovenstående:
  • Test at iti-18, iti42 kan køre på liste af cpr numre
  • iti-61 (og iti-42) rettes sådan at replace funktionalitet køre på liste af cprnumre og entry ids (Forslag: getCitizenCPRNumber skal læse 2 parametre og gemme entryuuid i threadcontext)
  • iti-57 rettes sådan at deprecate funktionalitet køre på liste af cprnumre og entry ids mm (Forslag: getCitizenCPRNumber skal læse flere parametre og gemme dokumentEntry specifikke i threadcontext)

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. Tom database, de respektive scripts, som nævnt under baggrundsdata, køres.

Der skal være en kørende version af NXRG, man kan teste imod. Og host.properties skal være sat korrekt op jf. arosiis performance test framework.

Kørsel

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

iti-18 

iti-42

iti-61

iti-57

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

Version

'* ' betyder hvilken som helst