Versions Compared

Old Version 21

changes.mady.by.user Lene Andersen

Saved on

compared with

New Version Current

changes.mady.by.user Henrik Eidnes Nielsen

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: SDS-6048 Ret URL og propertynavn til integrationstest

Indhold

Table of Contents

Introduktion

...

  • Unittests: Unittests tester, at de individuelle/isolerede enheder (klasser) i kildekoden virker som de skal.

  • Integrationstest: Integrationstests afvikles op i mod en kørende LAR service til verifikation af funktion og deployment. Herved verificeres det, at de individuelle enheder kan integreres og arbejde sammen i en kørende service.

  • Performancetest: Verificerer, at servicen performer med hensyn til svartider og er stabil under et specifikt load.

    Vurdering af historiske data: På et par data samples er der kørt indlæsning gennem LAR service interfacet 

Andre typer af tests (ikke en del af udviklingen af LAR):

  • Endurancetests, der verificerer at servicen fungerer under længerevarende belastning og ikke har f.eks. memory leaks, som kan udføres i stagning/produktionslignende miljø.
  • Vurdering af historiske data: På et par data samples er der kørt indlæsning gennem LAR service interfacet 

De i LAR anvendte tests gennemgåes i det følgende.

...

Læseren forventes at have kendskab til Java software udvikling, herunder unittesting ved anvendelse af JUnit og Maven.

Dokument historik

Dato

Ansvarlig

Beskrivelse

26/2

...

-2018KvalitetsITInitiel version
07/04-2021KvalitetsITFlere detaljer vedr. integrationstest med docker-compose

Definitioner og referencer

Reference

Beskrivelse

LAR

Lægemiddelallergiregisrering

Afviklede komponenttest

Følgende tests er afviklet som en del af udviklingen af LAR.

Der henvises i øvrigt til LAR Udviklerguide- Guide til udviklere for udførselsvejledning og LAR - Testrapport for resultat.

UnitTests

Der findes UnitTests af alle centrale enheder (klasser) i LAR.

...

./larservice-cave/src/main/java/dk/sdsnsp/larservice/cave/client/CaveClientConverter.java

...

./larservice-cave/src/test/java/dk/sdsnsp/larservice/cave/client/CaveClientConverterTest.java

...

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

Integrationstest til verifikation af funktionalitet og deployment

Integrationstestene for LAR er implementeret vha JUnit, og er beregnet til afvikling mod en kørende udgave af LAR.

For at integrationstesten kan eksekveres med success skal CVR 46837428 være whitelisted i samtykke administration. 

Integrationstest aktiveres via Maven ved følgende kommando:

mvn test -Pintegration-test   -Dconsentadministration.endpoint=http://test1-cnsp.ekstern-test.nspop.dk:8080/consent-administration/service -Dlarservice.wsdlendpoint=http://localhost:80658082/larservicelar/MedicationAllergyService?wsdl

Parametrene, der skal sættes er dokumenteret herunder

Property

Beskrivelse

consentadministration.endpointEndpoint til samtykkeadministrationen, der skal benyttes
larservice.wsdlendpointURL, der udpeger Larservicens WSDLLarservicen


Ved aktivering af integrationstesten vil helbreds/versionsservice afprøves. Denne kaldes også health servicen.

Derudover vil der laves test af oprettelse samt hentning af allergioplysninger via LAR med udgangpunkt i de User Stories og krav som er beskrevet i krav specifikationen.

Kørsel af integrationstest mod lokalt kørende service

Udfør følgende trin, hvis du ønsker at køre integrationstest mod lokal version deployed vha. docker-compose (Se detaljer i udvikler guides til LAR og CAVE service)

  1. Tjek source ud til LAR og CAVE servicene
  2. Byg servicene
  3. Start CAVE servicen lokalt med docker-compose
  4. Start LAR servicen lokalt med docker-compose
  5. Kør mvn test -Pintegration-test   -Dconsentadministration.endpoint=http://test1-cnsp.ekstern-test.nspop.dk:8080/consent-administration/service -Dlarservice.endpoint=http://localhost:8082/lar/MedicationAllergyService

User Stories og krav anvendt

...

  1. Som en sundhedsperson, vil jeg registrere medicin-allergioplysninger for en patient, så oplysningerne bliver tilgængelige på tværs af parterne i sundhedsvæsenet
  2. Som en sundhedsperson, vil jeg se medicin-allergioplysninger for en patient, så jeg kan undgå at ordinere medicin, som patienten ikke kan tåle
  3. Som en sundhedsperson, vil jeg opdatere medicin-allergioplysninger for en patient, så oplysningerne bliver tilgængelige på tværs af parterne i sundhedsvæsenet

Derudover er der følgende krav som hver har deres forudsætninger og formål:

  • Registrering af lægemiddelallergi-oplysning, user story 1
    • Med og uden Uuid for identifikation
  • Læsning af lægemiddelallergi-oplysning, user story 2
    • læsning for en given patient
    • angivelse af om historik ønskes eller ej
      • Uden historik returneres kun aktive allergier
      • Med historik er det
      det er
      • op til det modtagene system at sortere i aktive og inaktive allergier
    • negativ samtykke håndteres
    • Der registreres i minlog og behandler relation servicen.
  • Opdatering af lægemiddelallergi-oplysning, user story 13
    • en eksisterende allergi for en given patient kan ikke opdateres, der registreres en ny med ændrede dataopdateres, når den har status aktiv
    • patient kan ikke opdateres
    • kun seneste version af allergien kan opdateres
    • alt historik gemmes
  • Sletning af lægemiddelallergi-oplysning, user story 1 + 3
    • en eksisterende allergi for en given patient kan ikke slettes. Der registreres opdateres en ny eksisterende med status inaktiv istedet
  • Transformation af LAR oplysninger til CAVE oplysninger, user story 1 + 2 + 3
    • LAR servicen modtager et format, som gemmes vha. CAVE servicen som har sit eget format.
  • Fejlhåndtering ved kald af LAR servicen, user story 1 + 2 + 3
    • Der er en række status koder, med mere detaljerede status tekster til fejlhåndtering

...

Minlog og behandler relations service kaldes under integrationstesten, og valideres indirekte ved at en eventuelt fejlsituation vil får LAR servicen til at fejle. Resultatet i selve de 2 services valideres dog ikke automatisk, da det vil være meget omstændigt. Efter at integrationstesten er kørt på test serveren bør MinLog tjekkes manuelt for at se at den i properties angive tekst er kommet korrekt ind, også med de specielle danske bogstaver. Pt er denne tekst: "Medicin intolerens læst (ÆæØøÅå)".

Registrering

  1. registrering af allergi med uuid - postivt udfald
    • input: gyldig allergi med uuid
    • udfald: status ok, værdier i allergi som forventet
    • test:

...

    • U1T1testAtAllergiKanOprettesPaaLovligtCprNummerUuidMedsendes
  2. registrering af allergi uden uuid - positivt udfald
    • input: gyldig allergi uden uuid
    • udfald: status ok, uuid er udfyldt på registreret allergi 
    • test:

...

    • U1T2testAtAllergiKanOprettesPaaLovligtCprNummerUuidMedsendesIkke
  2. registrering af allergi med eksisterende uuid - negativt udfald,

...

  1. genbrug af uuid ikke tilladt
    • input: gyldig allergi med eksisterende uuid
    • udfald: status valideringsfejl, allergien er ikke gemt
    • test:

...

    • U1T3testAtAllergiIkkeKanOprettesNårEksisterendeUuidAnvendes
  2. registrering af allergi med formål at afslutte (slettemuligheden) -

...

  1. negativt udfald
    • input gyldig allergi med status inaktiv (forudsætning, der findes allerede en aktiv)
    • udfald: status

...

    • valideringsfejl, og der findes

...

    • fortsat kun den oprindelige allergi som aktiv
    • test:

...

    • U1T4testAtAllergiIkkeKanOprettesOgEfterfølgendeInaktiveresUuidMedsendes
  2. registrering af ugylding allergi - negativt udfald
    • input: ugyldig allergi, substance code mangler i input
    • udfald: status valideringsfejl, allergien er ikke gemt
    • test:

...

    • U1T5testAtAllergiIkkeOprettesNårSubstanceCodeMangler

Læsning

  1. læsning af allergi - positivt udfald, ingen historik
    • input: patient uden negativ samtykke, ingen værdispring, ingen historik
    • udfald: status ok, patientens nyeste version af allergier med status aktiv hentes
    • test:

...

    • U2T1testAtToAllergierKanHentesForPatientUdenNegativeSamtykkerUdenBrugAfVaerdiSpring
  2. læsning af allergi - negativ samtykke uden værdispring, ingen historik - negativt udfald
    • input: patient med negativ samtykke mod kaldende sundhedsperson, ingen værdispring, ingen historik
    • udfald: status negativ samtykke, ingen allergier vises
    • test:

...

    • U2T2testAtAllergierIkkeKanHentesForPatientMedNegativSamtykkeModSundhedsPersonenDerForetagerFremsoegningUdenBrugAfVaerdispring
  2. læsning af allergi - negativ samtykke med værdispring, ingen historik - positivt udfald
    • input: patient med negativ samtykke mod kaldende sundhedsperson, værdispring, ingen historik
    • udfald: status ok, patientens nyeste version af allergier med status aktiv hentes
    • test:

...

    • U1T3testAtAllergierKanHentesForPatientMedNegativSamtykkeModSundhedsPersonDerForetagerFremsoegningMedBrugAfVaerdispring
  2. læsning af allergi - negativ samtykke mod anden person, ingen historik, positivt udfald, ingen historik
    • input: patient med negativ samtykke mod anden person end kaldende sundhedsperson, ingen værdispring
    • udfald: status ok, patientens nyeste version af allergier med status aktiv hentes
    • test:

...

    • U2T4testAtAllergierKanHentesForPatientMedNegativSamtykkeModEnAndenSundhedsPersonenEndDenDerForetagerFremsoegning
  2. læsning af allergi - dataspecifik negativ samtykke uden værdispring, ingen historik, delvist positivt udfald
    • input: patient med dataspecifikt negativ samtykke, ingen værdispring, ingen historik
    • udfald: status succes men dataspec., et udsnit af patientens nyeste version af

...

    • allergier med status aktiv hentes
    • test:

...

    • U2T5testAtAllergierForRegistreringerPaaSorkodeHvorPatientHarDataSpecifiktNegativtSamtykkeFiltreresFraNaarDerIkkeBrugesVaerdispring
  2. læsning af allergi - dataspecifik negativ samtykke med værdispring, ingen historik, postivt udfald
    • input: patient med dataspecifikt negativ samtykke, værdispring, ingen historik
    • udfald: status success, patientens nyeste version af allergier med status aktiv hentes
    • test:

...

    • U2T6testAtAllergierForRegistreringerPaaSorkodeHvorPatientHarDataSpecifiktNegativtSamtykkeIkkeFiltreresFraNaarDerBrugesVaerdispring
  2. læsning af allergi med ikke eksisterende patient, ingen historik - postivt udfald
    • input: patient som ikke har allergier registreret, ingen værdspring, ingen historik
    • udfald: status ok, der er ingen allergier at hente
    • test:

...

    • U2T7testAtIngenAllergierHentesForPatientUdenNegativeSamtykkerUdenBrugAfVaerdiSpring
  2. læsning af allergi med manglende søgekriterie, ingen historik - negativt udfald
    • input: ingen patient, ingen værdispring, ingen historik
    • udfald: status valideringsfejl, ingen allergier returneres
    • test: U2T8testAtIngenAllergierHentesForBlankPatientUdenBrugAfVaerdiSpring
  3. læsning af allergi, med historik , allergi har historik og er inaktiv - positiv udfald
    1. input: patient uden negativ samtykke, ingen værdispring, historik
    2. udfald: status ok, patientens allergier med alle status hentes i alle versioner
    3. test: U2T9testAtAllergierKanHentesMedHistorik
  4. læsning af allergi, ingen historik (selvom der er en del historik) - positiv udfald
    1. input: patient uden negativ samtykke, ingen værdispring, ingen historik
    2. udfald: status ok, patientens nyeste version af allergier med status aktiv hentes
    3. test

...

    1. : U2T10testAtAllergierKanHentesUdenHistorik
  2. læsning af allergi, ingen historik (selvom der er en del historik og inaktiv) - positiv udfald
    1. input: patient uden negativ samtykke, ingen værdispring, ingen historik
    2. udfald: status ok, der er ingen allergier at hente
    3. test: U2T11testAtAllergierIkkeKanHentesUdenHistorikNaarInactive
  3. læsning af allergi uden angivelse af om historik (som ved ingen historik) - positiv udfald
    1. input: patient uden negativ samtykke, ingen værdispring, med historik
    2. udfald: status ok, patientens nyeste version af allergier med status aktiv hentes
    3. test: U2T11testAtAllergierKanHentesUdenHistorikDefault

Opdatering

  1. opdatering af allergi med uuid - postivt udfald
    • input: gyldig eksisterende allergi med uuid
    • udfald: status ok, værdier i allergi opdateret som forventet
    • test: U3T1testAtAllergiKanOpdateresPaaLovligtCprNummer
  2. opdatering af allergi uden uuid - negativt udfald
    • input: gyldig eksisterende allergi uden uuid (findes reelt ikke da uuid er null)
    • udfald: status fejl, allergien er ikke opdateret
    • test: U3T2testAtAllergiIkkeKanOpdateresPaaLovligtCprNummerUuidMedsendesIkke
  3. opdatering af allergi med ukendt uuid - negativt udfald
    • input: gyldig eksisterende allergi med ikke eksisterende uuid (findes reelt ikke da uuid ikke findes)
    • udfald: status fejl, allergien er ikke opdateret
    • test: U3T3testAtAllergiIkkeKanOpdateresNaarIkkeEksisterendeUuidAnvendes
  4. opdatering af allergi med patient ændret - negativt udfald
    • input: gyldig eksisterende allergi med opdateret patient
    • udfald: status fejl, allergien er ikke opdateret
    • test: U3T4testAtAllergiIkkeKanOpdateresNaarPatientAendres
  5. opdatering af ikke seneste version af allergi - negativ udfald
    • input: gyldig eksisterende allergi med ikke nyeste version id
    • udfald: status fejl, allergien er ikke opdateret
    • test: U3T5testAtAllergiIkkeKanOpdateresNaarIkkeNyesteVersion
  6. opdatering af allergi 3 gange og al historik gemmes - postivt udfald
    • input: gyldig eksisterende allergi
    • udfald: status ok
    • test: U3T6testAtAllergiKanOpdateresTreGangeOgHistorikGemmes
  7. opdatering af allergi med inaktiv status (slettemarkering) -  postivt udfald
    • input: gyldig eksisterende allergi
    • udfald: status ok
    • test: U3T7testAtAllergiKanOpdateresMedStatusInaktiv
  8. opdatering af inaktiv allergi - negativt udfald
    • input: gyldig eksisterende allergi med status inaktiv
    • udfald: status fejl, allergien er ikke opdateret
    • test: U3T8testAtAllergiIkkeKanOpdateresNaarStatusInaktiv
  9. opdatering af allergi med invalid data - negativt udfald
    • input: gyldig eksisterende allergi og blank drugid
    • udfald: status fejl, allergien er ikke opdateret
    • test: U3T9testAtAllergiIkkeKanOpdateresPaaLovligtCprNummerNaarDrugidBlankes
  10. opdatering af allergi uden versionid - negativt udfald
    1. input: gyldig eksisterende allergi men uden versionid
    2. udfald: status fejl, allergien er ikke opdateret
    3. test: U3T10testAtAllergiIkkeKanOpdateresNaarVersionNull

Transformation

Transformering testes som en del af testen "registrering af allergi med uuid - postivt udfald" hvor input og output sammenlignes. Dermed har data ikke ændret sig under transformering fra LAR >> CAVE >> LAR format.

...

Fejlhåndtering testes som en del af både registrering, opdatering og læsning, i det test som har negativ udfald.

...

Udover ovenstående user story drevne teste kontrolleres følgende med forventet negativ udfald

  1. Test at Headers mangler i DGWS
    • test:

...

    • S1T1testHeadersMissing
  2. Test at Voces afvises
    • test:

...

    • S1T2testVocesIsRejected
  2. Test at ID Card er udløbet
    • test:

...

    • S1T3testExpiredIdCard

Performancetests

Test data

...

Et forslag til data til performance testen findes sammen med selve performance testen på SVN serveren i projektet: https://svn.nspop.dk/svn/kvalitetsit/cave-performance

...

attached på dette dokument.

  • cavedatebasedump.sql - import script til en fhir database
  • cprSample.txt - liste af cpr numre som matcher databasen
  • readme_data.txt - beskriver indholdet af data

Databasen indeholder 50.000 allergier, fordelt på ligeså mange patienter. 

Før test kørslen skal databasen importeres til en tom allergi database fhir database (CAVE servicens database) samt cprSample placeres i sampler biblioteket for integrationstesten

...

Ønskes et nyt datagrundlag kan performance data generes fra LAR service projektet. Dette aktiveres via Maven ved følgende kommando eller tilsvarende med justerede parametre:

mvn test -Pperformancedata-test   -Dconsentadministration.endpoint=http://test1-cnsp.ekstern-test.nspop.dk:8080/consent-administration/service  -Dlarservice.wsdlendpoint=http://localhost:8065/larservice/MedicationAllergyService?wsdl

Vær opmærksom på, at justeringer kan være nødvendige i kildekoden (Modulet larservice-integrationtest, pakken .performancedata, klassen PerformanceTestDataImport.java) omkring antallet af records, fordeling af recorder information samt cpr nummer genereringen).

...

Udførsel af test

Forberedelse

[TBD]

Kørsel

Testen hentes fra https://svn.nspop.dk/svn/components/performance/trunk i den revision, der er angivet for versionen af LAR servicen.

Databasen klargøres. Tom allergi (fhir) database, hvor cavedatebasedump.sql er indlæst.

Der skal være en kørende version af LAR og CAVE servicen, 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, servicene kørende og testen configureret kan følgende køres:

run_test.sh -h hosts.properties -p 9012 lar listallergy test900

(distributionen test900 kører 15 minutter, der findes også kørsler til 10 sekunder (test10) og 1 minut (test60))

Version

LAR ReleasePerformance test revision
1.*.*178 eller nyere






'* ' betyder hvilken som helst


Endurancetests

Denne test indgår som en del af performance testen[TBD]

Vurdering af historiske data

...

mvn test -Pdataimport-test   -Dconsentadministration.endpoint=http://test1-cnsp.ekstern-test.nspop.dk:8080/consent-administration/service  -Dlarservice.wsdlendpoint=http://localhost:8065/larservice/MedicationAllergyService?wsdl

Kørslerne tager udgangspunkt i navngivne filer (se kildekode)  som placeres i test resources biblioteket, og disse bliver så læst ind i allergi databasen.

...