Detta dokument beskriver testsviten för GetAccessLogsForPatient 1.1. Testsviten innehåller ett antal testfall som kan användas för att verifiera implementationen innan integrationen med den nationella tjänsteplattformen.
Testsviten använder SoapUI för att verifiera implementationen. Dokumentation om SoapUI hittas här: www.soapui.org.
Klicka på den här länken för att ladda hem en gratisversion av SoapUI. Installera enligt anvisning.
Innan man kör testfallen i SoapUI så måste den data som skickas med i anropen anpassas utifrån det system som man vill testa. Detta görs genom att ändra i filen data.xml enligt nedan.
Filen är i XML-format och i början finns en sektion som heter "globaldata". Här anger man den konfiguration som kommer att användas av alla testfall.
Varje element i "globaldata" kan omdefinieras för ett specifikt testfall vid behov. Följande element är globala:
De parametrar man anger för ett specifikt testfall kompletterar och/eller omdefinierar de parametrar som anges i "globaldata".
Det betyder att både parametrar från "globaldata" och det specifika testfallets sektion i filen används för det aktuella testfallet.
OBS! Om en parameter med samma namn definieras både i "globaldata" och specifikt för testfallet, så kommer värdet från testfalls-sektionen att användas.
Ett exempel kan vara "patientId". Denna definieras i "globaldata", eftersom det är troligt att det mesta av testdatan kommer att röra samma patient.
Men för vissa testfall vill man kunna använda en annan patient och för dessa testfall definierar man detta genom att ta bort kommentars-markeringen runt parametern "patientId" i testfallets sektion.
Glöm inte att spara data.xml efter att du har ändrat i den.
- 1.1.1 Personnummer
Filtrering. Verifierar att resultatet endast innehåller poster för given patient.
- 1.1.2 Samordningsnummer
Filtrering. Testfall för filtrering på samordningsnummer. Ersätt patientId med det samordningsnummer som du vill filtrera på.
Testfalls-specifika parametrar
- 1.1.3 Reservnummer
Filtrering. Testfall för filtrering på reservnummer. Ersätt patientId med det reservnummer som du vill filtrera på och ersätt patientIdType med lokalt definierat OID för reservnummer.
Testfalls-specifika parametrar
- 1.2.1 fromDate
Syftet med testfallet är att säkerställa att tjänsteproducenten kan returnera de poster som matchar angivet tidsintervall, genom att variera intervallets startdatum.
Testfallet sker i flera steg:
- Anrop med fromDate/toDate satt enligt inparametrar. Svaret måste innehålla minst tre loggposter på unika tidpunkter.
- Av tidpunkterna i svaret väljs en i mitten tidsmässigt.
- Anrop med fromDate satt till tidpunkten i mitten och toDate som i steg 1. Resultatet jämförs med förväntat resultat (posterna före fromDate ska filtreras bort).
- 1.2.2 toDate
Syftet med testfallet är att säkerställa att tjänsteproducenten kan returnera de poster som matchar angivet tidsintervall, genom att variera intervallets slutdatum.
Testfallet sker i flera steg:
- Anrop med fromDate/toDate satt enligt inparametrar. Svaret måste innehålla minst tre loggposter på unika tidpunkter.
- Av tidpunkterna i svaret väljs en i mitten tidsmässigt.
- Anrop med toDate satt till tidpunkten i mitten och fromDate som i steg 1. Resultatet jämförs med förväntat resultat (posterna efter toDate ska filtreras bort).
- 1.8 SoapException
Verifierar att resultatet är ett SOAP Exception. Detta testfall kräver att tjänsteproducenten skapar förutsättningar för ett internt fel att uppstå.
Exempel kan vara att man stänger av kopplingen mot databas.
- 1.9 NonExisting Patient
Verifierar att tjänsteproducenten kan hantera ett anrop med ett patient ID som det inte finns loggposter för. Med hantera avses att den ska skicka en tom respons inom 15 sekunder.
- 1.10 technical_error
Verifierar att tjänsteproducenten kan returnera resultCode "ERROR" vid ett internt tekniskt fel. Testfallet förutsätter att det skapas förutsättningar för ett sådant internt fel att uppstå.
- 2.1 Encoding_HeaderProlog
Verifierar att
- Header-attributet "Content-type" har, om attributet finns, en teckenuppsättning som är satt till UTF-8 eller UTF-16
- Attributet "XML Prolog" har, om attributet finns, en teckenuppsättning som är satt till UTF-8 eller UTF-16
- Om båda attributen finns så ska de vara lika
- 5.1 queueHandling_with_queueTime
Verifierar att tjänsteproducenten kan hantera köhantering med kötid och inom stipulerad kötid levererar den efterfrågade loggrapporten.
- 5.2 queueHandling_without_queueTime
Verifierar att tjänsteproducenten kan hantera köhantering utan kötid och inom stipulerad kötid levererar den efterfrågade loggrapporten.
- 5.3 storage_time
Verifierar att tjänsteproducenten kan returnera minst en loggpost som är minst 17 månader gammal.
- 5.4 max_query_result_exceeded
Verifierar att tjänsteproducenten kan returnera resultCode MAX_QUERY_RESULT_EXCEEDED om patienten har fler än 10.000 loggposter.
- 5.5 validation_error
Verifierar att tjänsteproducenten kan returnera resultCode VALIDATION_ERROR om ett logiskt fel finns i anropet.
- 5.6 report_not_found
Verifierar att tjänsteproducenten kan returnera resultCode REPORT_NOT_FOUND om anropet innehåller ett köID (queuedReportId) som ej finns i systemet.
Testfalls-specifika parametrar
- 5.7 purpose_vard_och_behandling
Verifierar att tjänsteproducenten kan returnera en loggpost med syfte 'Vård och behandling'.
- 5.8 purpose_kvalitetsregister
Verifierar att tjänsteproducenten kan returnera en loggpost med syfte 'Kvalitetsregister'.
- 5.9 purpose_administration
Verifierar att tjänsteproducenten kan returnera en loggpost med syfte 'Administration'.
- 5.10 purpose_statistik
Verifierar att tjänsteproducenten kan returnera en loggpost med syfte 'Statistik'.
- 5.11 purpose_annan_dokumentation
Verifierar att tjänsteproducenten kan returnera en loggpost med syfte 'Annan dokumentation enligt lag'.
- 5.12 purpose_kvalitetssakring
Verifierar att tjänsteproducenten kan returnera en loggpost med syfte 'Kvalitetssäkring'.
- 6.1 Loadtest
Syftet med samtidighetstestet är att testa att tjänsteproducenten kan hantera simultana anrop utan att blanda ihop data i de olika svaren.
6.1.1 Grund
Syftet med testet är dels att verifiera att systemet kan hantera minst 10 samtidiga trådar, dels att skapa sig en bild av systemets prestanda. Testet är designat att ta max 3 minuter.
I SLA-kapitlet i självdeklarationen, under "Övrig kommentar", ange genomsnittlig responstid som visas i sista raden i kolumn "avg" med enhet millisekunder (ms).
6.1.2 Uthållighet
Syftet med testet är att undersöka prestanda hos systemet över lite längre tid (30 minuter). I SLA-kapitlet i självdeklarationen, under "Övrig kommentar", notera om testet gick att genomföra utan problem. Om inte, notera hur lång tid det var möjligt att köra.
I och med att patient-id ej finns med i loggposten så sker jämförelsen mot userId. Detta betyder att man behöver ha:
- patientId1: patient med loggposter
- userPatient1: hsaid för användare som har berett sig åtkomst till data för patientId1. Denna användare får ej ha berett sig åtkomst till data för patientId2.
- patientId2: patient med loggposter
- userPatient2: hsaid för användare som har berett sig åtkomst till data för patientId2. Denna användare får ej ha berett sig åtkomst till data för patientId1.
Testet kräver alltså att endast poster med "userPatient1" returneras för patientId1 och angiven tidsperiod. Samma för "userPatient2".
Testfalls-specifika parametrar
- patientId1
- fromDate1
- toDate1
- userPatient1
- patientId2
- fromDate2
- toDate2
- userPatient2
- 6.2 Recovery
Syftet med samtidighetstestet är att testa att tjänsteproducenten kan hantera simultana anrop utan att blanda ihop data i de olika svaren.
6.2.1 Återhämtning
Syftet med testet är att utsätta systemet för maximal last och verifiera att systemet automatiskt återhämtar sig. För att kontrollera att systemet har kunnat återhämta sig efter maximal last så rekommenderas att köras testfall "1.1.1 Personnummer" för att se att systemet svarar. I SLA-kapitlet i självdeklarationen, under "Övrig kommentar", notera om systemet kunde återhämta sig efter att ha utsatts för maximal last. Ange även hur många trådar som testet avslutades med.
I och med att patient-id ej finns med i loggposten så sker jämförelsen mot userId. Detta betyder att man behöver ha:
- patientId1: patient med loggposter
- userPatient1: hsaid för användare som har berett sig åtkomst till data för patientId1. Denna användare får ej ha berett sig åtkomst till data för patientId2.
- patientId2: patient med loggposter
- userPatient2: hsaid för användare som har berett sig åtkomst till data för patientId2. Denna användare får ej ha berett sig åtkomst till data för patientId1.
Testet kräver alltså att endast poster med "userPatient1" returneras för patientId1 och angiven tidsperiod. Samma för "userPatient2".
Testfalls-specifika parametrar
- patientId1
- fromDate1
- toDate1
- userPatient1
- patientId2
- fromDate2
- toDate2
- userPatient2