Page History
Navitabs | ||||||
---|---|---|---|---|---|---|
| ||||||
Table of Contents |
---|
Introduktion
...
Version | Dato | Ansvarlig | Beskrivelse |
1.0 | 29.06.2012 | Systematic | Initiel udgave |
1.1 | 21.08.2012 | Systematic | Beskrivelse af keystores i afsnit 2.2.1 uddybet, Maven-kommando i afsnit 2.2 opdateret. Integrationstests med specielle forudsætninger er nu beskrevet i afsnit 2.2.2 og 2.2.3. Opdateret placeringen af environment fil. |
1.1a | 19.04.2012 | Systematic | Opdateret placeringen af flere tests, grundet refaktorering af kode Udgave til Release Candidate 1 |
1.2 | 19.06.2013 | Systematic | Kvalitetssikret |
1.3 | 23.05.2014 | Systematic | Rettelser som konsekvens af opsplitning af tidl. NPI-mavenprojekt i selvstændige komponenter. |
1.4 | 28.11.2014 | Systematic | Nationalt Patientindeks (NPI) erstattet med Dokumentdelingsservice (DDS) |
1.5 | 14.01.2015 | Systematic | Nye kommandoer til maven og ændring af npi og npiservices til dds |
1.6 | 05.05.2015 | Systematic | Kodereferencer er opdaterede pga. navneskifte fra NPI til DDS |
1.7 | 17.12.2016 | Systematic | Opdateret header billede |
1.8 | 3.10.2017 | Systematic | Forældet reference til TRP/0009 erstattet med TRP/0112. |
1.9 | 13.06.2018 | Systematic | Migreret til NSPOP SVN |
1.10 | 12.11.2018 | KvalitetsIT | Flyttet dokumentation til Confluence |
2.3.24 | 8.10.2021 | KvalitetsIT | SDS-4961: Opdatering af oplysninger om testdata |
Definitioner og referencer
...
Integrationstestene til DDS Registry er baseret på en genereret klient til den allerede eksisterende DocumentRegistry service.
DDS Registry har en integrationstest, der afvikles automatisk:
dds\ddsregistry\integrationtest\src\test\java\dk\nsi\ddsregistry\ws\DDSRegistryIT.java
dds\ddsregistry\integrationtest\src\test\java\dk\nsi\ddsregistry\ws\DDSRegistryRegisterIT.java
Tester DDS Registry via DDS Registry web service interfacet. Opslag gennemføres under anvendelse af Registry Stored Query, der i testnavne er forkortet regSQ.
ligger under /integrationtest.
Der er udviklet integrationstests, der matcher user stories og test cases i dokumentet DDS - Guide til anvendereDerudover findes der integrationstests beskrevet i afsnit 2.2.2 og 2.2.3, der kræver specielle forudsætning og derfor ikke igangsættes automatisk.
Testdata
Keystores benyttes i forbindelse med integrationstestene både af test-drivere og af services deployeret til JBoss.Integrationstestenes test-drivere benytter keystores validVocesVault.jks, expiredVocesVault.jks og validMocesVault.jks, der udtrækkes automatisk fra maven-artefaktet remote-test-resources (dk.nsi.dgws) ved kørsel af integrationstest.
Services deployeret til JBoss (fx DDS Registry) benytter validVocesVault.jks, der ved deployering ligeledes udtrækkes fra remote-test-resources.
Integrationstestene er afhængige af pre-installeret testdata for:
...
Whitelist
Stamdata (SOR-data og autorisationsregister-data)
Når integrationstestene afvikles på miljø uden stamdata bliver alle ovennævnte testdata installeret, når data-sources etableres (se [UdviklerGuide]).
Når integrationstestene afvikles på NSP (hvor stamdata allerede er etableret), bliver samtykker og whitelist testdata installeret. Dette sker tillige automatisk i forbindelse med etablering af data-sources (se [UdviklerGuide]).
Integrationstest med utilgængelig DDS Registry
Under integrationstests er der følgende fil, der ikke afvikles automatisk:
dds\ddsregistry\integrationtest\src\test\java\dk\nsi\ddsregistry\ws\DDSRegistryDisabled.java
Testen validerer at den korrekte fejlmeddelelse bliver returneret, når IHE Registry er nede. Inden afvikling af testen skal IHE Registry gøres utilgængelig, fx ved at konfigurere en invalid service URL i DDSRegistry-konfigurationsfilen. Dette er beskrevet i filen HowToRun-DDSRegistryDisabled.txt.
Testen afvikles manuelt med følgende kommando:
mvn -Dit.test=DDSRegistryDisabled verify –Pexternal-test
Integrationstest med HSStub
Under integrationstests er der følgende fil, der ikke afvikles automatisk:
dds\ddsregistry\integrationtest\src\test\java\dk\nsi\ddsregistry\ws\DDSRegistryTestRequiringHSStub.java
Testen validerer at DDSRegistry kan håndtere voluminøse svar fra IHE Registry. Inden afvikling af testen skal:
IHE Registry erstattes med HSStub i DDSRegistry-konfigurationsfilen. I DDSRegistry.properties skal documentregistry.wsdl.location, der peger på hsbus/HS.IHE.XDSb.Registry.Services.cls udkommenteres og erstattes af tilsvarende indgang, der peger på DocumentRegistry_Service/HSStub.
HSStub være deployeret og startet.
Testen afvikles manuelt med følgende kommando:
mvn -Dit.test=DDSRegistryTestRequiringHSStub verify –Pexternal-test
Performancetests
Performancetesten af baseret på requests fra integrationstesten. Ved integrationstesten gemmes to DDS Registry soap requests, per default under c:\dds. Dette kan konfigureres vha. environment property filen, som findes under dds\environment.properties, ved at sætte property’en soaprequest.log.dir.
Herefter skal databasen på test target (fx NIAB) initieres hvilket gøres fra performance folderen med:
mvn initialize -Pperf-setup
Selve performancetestene er lavet i JMeter og er gemt under:
performance\src\main\test\resources\jmeter\regSQHealthcareProfessionalDataSpecNegConsentOrgHavingDataSpecPosConsentAndOnBehalfOfPerf.jmx
performance\src\main\test\resources\jmeter\regSQHealthcareProfessionalPerformingConsentOverridePerf.jmx
Hvis man har valgt at sætte soaprequest.log.dir property’en til noget andet end c:\dds skal filnavet i jmx-filen ligeledes ændres. Dette gøres i JMeter ved at redigere ’Filename’ under ’DDSRegistry’ > Loop Controller > SOAP/XML-RPC Request”.
Verificer at test target URL er konfigureret korrekt (hostname:port) i JMeter SOAP/XML dialog.
Der bør udføres check fra JMeter at request til test target fungerer korrekt inden den automatiske test gennemføres og der genereres chronos rapporter.
Performance tests gennemføres fra en workstation med adgang til test target med kommandoen:
mvn verify –Pddsregistry-data chronos-report:report
mvn verify –Pddsregistry-consentoverride chronos-report:report
Chronos HTML reporter findes under performance\target\site (folderne css og images medtages).
Efter at havde kørt performancetesten kan load data fjernes fra databasen på test target med.
mvn initialize -Pperf-teardown
Testdata
Integrationstests opretter selv sine testdata i form af spærringer og dokumenter.
Følgende testpersoner benyttes i integrationstesten:
Navn | CPR | CVR | Autorisation | Autorisationskode | YderNr | National rolle | Certifikat | Certifikat udløbsdato |
---|---|---|---|---|---|---|---|---|
Casper Rasmussen | 0804769723 | 33257872 | CBTH1 | 7170 | 658309 | Casper_Rasmussen_Laege.jks | 5. november 2024 | |
Grethe Pedersen | 1812792476 | 33257872 | nspSundAssistR2 | Grethe_Pedersen.jks | 5. november 2024 | |||
Peter Rasmussen | 0112809169 | 33257872 | nspSundAssistR1 | Peter_Rasmussen.jks | 5. november 2024 | |||
Trine Pedersen | 1112874860 | 33257872 | (frataget autorisation) | Trine_Pedersen.jks | 5. november 2024 |
Hvis feltet er tomt, så er det fordi oplysningen ikke er relevant for personen.
Testpersonerne oprettes på følgende måde:
- Først skal de oprettes i DTG:
- Se beskrivelsen her: https://www.nspop.dk/display/public/web/DTG+-+Guide+til+anvendere
- Her skal man bruge navn, CPR og adresseoplysninger.
- Efter testpersonen er oprettet tilknyttes evt. autorisationer (Tilføj event + opret ny autorisation).
- Her efter kan der udstedes certifikater:
- Det er SDS der udsteder dem og de skal bruge navn, CPR-oplysninger og hvilken email adresse de skal udstedes til.
- De skal altid udstedes til nsp.support@arosii.dk (bemærk: links hvor man kan hente certifikaterne sendes til denne postkasse).
Når certifikaterne hentes første gang er de i PCKS 12 format de kan konverteres til JKS på følgende måde:
keytool -importkeystore -srckeystore Casper_Rasmussen_Laege.p12 -srcstoretype pkcs12 -srcstorepass Test1234 -destkeystore Casper_Rasmussen_Laege.jks -deststoretype jks -deststorepass Test1234
- Når certifikaterne er blevet udstedt kan der tilknyttes SEB-roller:
- Det er SDS SEB-ansvarlig der kan tilknytte roller og skal bruge følgende oplysninger om testpersonen: navn, CPR, RID og rolle.
- Man kan finde RID'en i certifikatet på følgende måde:
keytool -v -list -keystore Casper_Rasmussen_Laege.jks -storepass Test1234 | grep RID
I dette tilfælde vil RID'en være 40718906
Øvrige certifikater der benyttes i integrationstesten:
Certifikat | Certifikat udløbsdato | Bemærkning |
---|---|---|
ssl-trust.jks | 12. marts 2022 | |
Statens_Serum_Institut_VOCES.jks | 16. august 2024 | Findes to steder |
validVocesVault1.jks | 13. februar 2023 | Findes to steder |
TEST trusted IdP SOSI alias (til bootstrap token).jks | 13. februar 2023 | |
TEST whitelisted SP SOSI alias.jks | 13. februar 2023 |
Integrationstest mod miljøer
Testene kan afvikles mod følgende miljøer:
- local (udviklingsmiljøet som defineret i docker-compose setup, se udviklerguide for en beskrivelse af hvordan dette startes op.)
- test1 (DDS deployet på TEST1 miljøet)
- test2 (DDS deployet på TEST2 miljøet)
Testen afvikles manuelt med følgende kommando:
mvn verify -P<miljø>,integration-tests
Performancetests
Der er ikke kørt nogen separat performance test på DDS Repository.
Testdata
Der er ingen særlige testdata eller krav til testdata for disse tests.Test dataene bliver skabt af DDSPerfTestSetup.sql sql-scriptet som ligger under performance\src\main\test\resources\sql\DDSPerfTestSetup.sql
Endurancetest
Der er ikke kørt nogen separat endurance test på DDS Registry.
...